Catégorie: Conception (design)

Cet article est la traduction d'un article de Greg Rahn publié sur son blog. L'article original en anglais est: The Core Performance Fundamentals Of Oracle Data Warehousing – Set Processing vs Row Processing. Cet article fait partie d'une série sur les principes fondamentaux des datawarehouse, mais s'applique à tous les traitements de type batch.

Durant 6 ans à faire des Proof Of Concept et des Benchmarks sur des datawarehouse pour les clients, il y a un domaine qui s'est toujours montré problématique: les traitements par lots (batch). La plupart du temps, ces batchs prennent la forme de procédures et packages PL/SQL, qui font du chargement de donnée, de la transformation, du traitement, ou quelque chose de similaire.
La raison pour laquelle c'est souvent problématique, c'est que les développeurs y ont codé en dur la lenteur du traitement. Je suis certain que les développeurs ne savaient pas qu'ils faisaient cela, lorsqu'ils ont codé leur PL/SQL, mais en tout cas, c'est ce qui est arrivé.

Alors comment ont-ils codé 'en dur' cette lenteur en PL/SQL ?

» Lire la suite!

Cet article est la traduction d'une réponse de Tom Kyte sur son site AskTom décrivant rapidement les points à considérer lorsqu'on a une table a fort volume transactionnel et forte concurrence (L'article original en anglais se trouve ici).

Question

Que puis-je faire du point de vue du design physique pour maximiser les performances et la concurrence lorsque une table va être la cible de centaines de milliers de select et probablement autour de 80000 insert, autant d'update et delete par heure, de manière transactionnels sur une base OLTP.
Ces débits de insert/update/delete sont juste un exemple. En réalité ils seront beaucoup plus élevés, même si on ne sait pas à quel point ils seront plus élevés car nous sommes toujours en phase de design.

Je suis à la recherche de quelques lignes directrices que je pourrais essayer sur mon application.

Réponse

On pourrait écrire un livre là dessus :) Le mien est 'Expert Oracle Database Architecture' et vous serez surement intéressé par de nombreux chapitres, plus particulièrement ceux sur les types de données, les tables et les index.

• Vous pourriez avoir besoin de partitionner: répartir les inserts sur de nombreux segments, afin d'éviter des contentions sur la partie droite des index (sur les dates ou les séquences par exemple)...
• Vous pourriez avoir besoin d'IOT (tables organisées index), plus lent pour les insert dans la plupart des cas, mais si vous faites des requêtes qui ramènent de nombreuses lignes qui sont arrivées dans la table à des moments différents dans le temps, l'IOT peut permettre de regrouper (cluster) ces lignes afin de rendre plus efficace le fait de les récupérer ensembles.
• Vous pourriez aussi utiliser ASSM (Automatic segment space management) pour améliorer la concurrence, pour éviter de chercher les bonnes valeurs de PCTUSED, FREELISTS et FREELIST GROUP (mais vous devez comprendre ce qu'il y a de différent entre ASSM et MSSM...)
• Vous pourriez chercher à comprendre comment les types de données sont stockés physiquement, réfléchir à PCTFREE, et comment maximiser les performances possibles sur les LOB, si vous les utilisez, etc.

En bref, vous voulez comprendre comment fonctionnent les choses à un certain niveau. Le concepts guide de la documentation Oracle et un bon point de départ. Si vous aimez ma manière d'écrire, vous pouvez commencer aussi par 'Expert Oracle Database Architecture'.

Vous aurez besoin de réfléchir à la concurrence, aux choses comme ASSM, le partitionnement, voire les technique de regroupement de données (clustering): IOT, hash/btree clusters.

Vous aurez besoin de réfléchir sur l'archivage des données dans le temps.

Vous devrez peut-être envisager la nécessité de faire une réorganisation des tables à l'occasion, et donc prévoir le design qui permettra de le faire: à nouveau le partitionnement.

Cet article est la traduction d'un article de Jonathan Lewis. L'article original en anglais se trouve ici. J'ai cependant traduit l'exemple de requête dans une syntaxe Oracle, et l'idée d'index cluster de SQL Server correspond à celle d'IOT sous Oracle.
Jonathan Lewis décrit ici une démarche visuelle pour comprendre une requête SQL en faisant un schéma des tables impliquées.

C'est parfois intéressant de s'éloigner du clavier lorsqu'on se bat avec une requête peu performante et assez complexe, et de prendre un papier et un crayon à la place. En faisant un schéma qui montre les tables impliquées, les jointures, les volumes de données manipulées, et les indexes, vous pourrez comparer plus facilement l'efficacité des différents chemins d'exécution que la requête peut prendre pour passer d'une table à une autre.

» Lire la suite!