Cet article est la traduction d’un article de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici

Sur Oracle, certains concepts sont si fondamentaux qu’on doit toujours les avoir en tête à chaque fois qu’on veut étudier un problème de performance. Et voici l’un d’eux:

Les histogrammes et les bind variables existent pour des raison diamétralement opposées: sans y prêter garde, ils ne fonctionneront pas bien ensemble.

Vous utilisez des bind variables parce que vous voulez que tout le monde partage le même plan d’exécution pour une requête SQL qui va être utilisé fréquemment. Tout le monde va faire la même charge de travail avec (charge normalement faible). Son plan d’exécution sera optimal pour tout le monde. Et vous ne voulez pas ré-optimiser cette requête à chaque fois, car cette réoptimisation utiliserait à elle seule plus de ressources qu’il n’en faut ensuite pour l’exécuter.

En général on utilise beaucoup les bind variables lorsqu’on est en transactionnel (OLTP) – sauf quelques cas particuliers où on préférera des valeurs littérales.

Et vous créez des histogrammes pour des requêtes qui, mêmes si elles sont similaires, vont faire un travail très différent les unes des autres. Elles ont besoin de plans d’exécution différents. Et de toute façon le travail d’optimisation est négligeable par rapport au travail d’exécution de la requête. Alors que si on utilise un plan d’exécution qui n’est pas optimal, on peut se retrouver à gaspiller beaucoup de ressources.

En général, on a besoin des histogrammes en datawarehouse, en BI, où les requêtes peuvent être très grosses et coûteuses.

C’est là qu’est la contradiction: on a une technologie qui est censée nous donner un seul plan d’exécution partagé par tout le monde, et une autre qui elle est censée trouver pour chacun le plan qui lui convient le mieux.

Gardez celà en mémoire, et vous vous rappellerez qu’il faut être très prudent lorsqu’on met des histogrammes sur une base transactionnelle (OLTP) et qu’il ne faut pas non plus transformer absolument toutes les valeurs littérales en bind variables.

A noter les commentaires de Doug Burns et Hemant K Chitale sur le fait qu’en 10g Oracle collecte par défaut des histogrammes avec la méthode ‘FOR ALL COLUMNS SIZE AUTO’ de dbms_stats.

Jonathan Lewis a mis les liens de l’article original et de la traduction sur son blog.

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 ?

En général, c’est parce que au lieu d’avoir lu les spécifications métiers en étudiant l’état ‘avant’ et ‘après’ des données, puis d’en avoir déterminé la manière la plus efficace de faire ces modifications de données, les développeurs PL/SQL ont fait une traduction littérale de chaque règle/exigence lues dans les specs, une par une. On devine cela lorsqu’on voit du code qui parcours un curseur ligne par ligne, mais aussi dans du PL/SQL qui ne fait qu’exécuter une série de requêtes SQL souvent mal concues.

Etude de cas de la lenteur codée ‘en dur’

La suite est basée sur une histoire vécue. Seuls les noms ont été modifiés pour protéger les innocents.

Voici un extrait de pseudo-code que j’ai rencontré dans un POC:

{truncate de toutes les tables intermédiaires}
insert into temp1 select * from t1 where create_date = hier;
insert into temp1 select * from t2 where create_date = hier;
insert into temp1 select * from t3 where create_date = hier;
insert into temp2 select * from temp1 where {conditions};
insert into target_table select * from temp2;
pour chacune des  20 colonnes
loop
  update target_table t
    set t.column_name =
      (select column_name
       from t4
       where t.id=t4.id )
    where i.column_name is null
end loop
update target_table t set {liste de 50 columns} = select {50 colonnes} from t5 where t.id=t5.id;

Je m’arrête ici car la suite risquerait de vous faire pleurer.
J’hésite un peu à poser la question, mais n’est-ce pas évident ce qu’il y a de pas correct dans ce traitement ?
Voici les principales raisons que je vois à cette inefficacité:

• Pourquoi insérer toutes les données dans temp1, et ne les filtrer que lorsqu’on remplit temp2 ? Si vous n’avez jamais entendu le conseil ‘filtrez les données au plus tôt’ alors vous avez des devoirs à faire.
• Pourquoi publier dans la table cible, puis faire 20 update d’une seule colonne chacun, suivi d’un update de 50 colonnes ? Meilleure question: pourquoi faire des update de masse ? Les update (et delete) de masse sont à proscrire, il faut les éviter à tout prix.

Et alors, comme beaucoup de client qui font un POC (preuve de concept) sur une machine Exadata, ils n’ont pas du tout envie de modifier leur code, ils veulent juste voir quelle performance la plateforme Exadata peur leur délivrer. Et pour leur plus grand bonheur, ils ont réduit la durée du traitement de 2.5 jours (batch de week-end qui commence le vendredi après midi et n’est toujours pas terminé le lundi matin) à 10 heures, gagnant ainsi plus de 2 jours. Maintenant, le batch peut planter et ils auront le temps de le relancer avant l’ouverture aux utilisateurs du lundi matin. Eh, je suppose que je serais aussi très exité si je gagnait 24 heures sur un traitement de 38 heures. Mais ce n’est pas le cas lorsque je suis un ingénieur de performance de base de données qui sait qu’il y a encore plus de performance à gagner.

Comme je n’était pas satisfait par cela, j’ai pris sur moi de prouver que de re-designer le code peut avoir un retour très intéressant sur la plateforme Exadata, et j’ai codé complètement un flux de donnée qui travaille de manière ensembliste, avec juste une poignée de requêtes SQL (et pas de PL/SQL). Le résultat: le traitement d’une semaine complète de données (plusieurs centaines de millions de lignes) prend maintenant 12 minutes. C’est exact: 7 jours de données nettoyées, transformées, enrichies et publiées en 12 minutes seulement.

Lorsque j’ai annoncé la nouvelle au client, qu’il était possible de charger une semaine de données en seulement 12 minutes, ils étaient très excités, c’est le moins que l’on puisse dire. En fait, il y en a un qui a même dit, un peu hors du contexte, que maintenant une seule journée de données pourrait être chargées en 2 minutes, et que cela donnerait un autre niveau de fraîcheur aux données, ce qui permettrait au métier de prendre des décision meilleures et plus rapides, grâce aux données actualisées plus souvent. Ma réponse: CQFD ! Le client voit maintenant ce qu’il est possible de faire avec Exadata, et qui était impossible avant.

C’est pas obligatoire, mais c’est souhaitable

Je ne vais pas changer ma casquette d’ingénieur base de données en vendeur de produit, pas maintenant, et probablement jamais, mais c’est le réalité telle qu’elle existe. Les boites informatiques ont démarré avec des faibles volumes de données, et une logique de programmation sur des petits volumes, et cela a fonctionné un certain temps. Pourquoi ? Parce que le traitement peu efficace d’un faible volume de données est seulement un peu inefficace Mais la même logique de développement sur un gros volume de données devient alors très inefficace.
C’est pourquoi j’ai déjà dit: pour exploiter à fond la plateforme Exadata (ou n’importe quelle plateforme actuelle), il faut changer le code. Ne me faites pas dire ce que je n’ai pas dit: je ne dis pas qu’il est nécessaire revoir le code de l’application pour Exadata. Je dis que vous pouvez choisir de revoir le code pour Exadata parce que l’application n’est tout simplement pas conçue pour profiter du traitement massivement parallèle que Exadata permet. Il est temps que les décisions de design de l’application soient basées sur les technologies d’aujourd’hui, et non sur celles sur lesquelles l’application a été faite. Avance rapide vers aujourd’hui.

Ceci est une traduction de d’un ancien post de Jonathan Lewis sur forums.oracle.com, référencé récemment sur son blog. Il décrit le fonctionnement de la journalisation en mémoire (IMU – In Memory Undo), une optimisation introduite en 10g qui utilise des structures en mémoire pour diminuer la contention sur les blocs d’undo et le redo log buffer.

Le contenu des blocs d’undo et des fichiers de redo log sont quasiment les même que l’on utilise in-memory undo (et les private redo threads) ou que l’on utilise la journalisation ‘normale’.
La principale différence se trouve dans l’ordre où sont faites les choses.
Il y a aussi, avec in-memory undo, une diminution du nombre de redo records même si le nombre de change vectors reste le même.

Voici le séquencement d’une transaction courte avec gestion normale de la journalisation.

• Vous modifiez un bloc de table ou d’index. Un vecteur de changement (redo change vector) est généré pour cette modification.
• En même temps, vous devez enregistrer l’information nécessaire pour défaire (rollback) de cette modification. C’est un enregistrement d’annulation (undo record) qui est généré pour décrire ce qui a été altéré.
• Mais comme cet undo record est stocké dans un bloc d’undo (rollback segment), alors un vecteur de changement redo change vector est généré pour décrire cette modification du bloc d’undo
• Oracle combine ces deux redo change vector (vecteurs de changement du bloc de donnée et du bloc d’undo) dans en un enregistrement de redo (redo record), ce qui incrémente la statistique de session ‘redo entries’.
• Donc pour cette modification, Oracle doit acquérir de l’espace dans le tampon journalisation redo log buffer avec le latch ‘redo allocation’ et y copier l’enregistrement de redo avec le latch ‘redo copy’

Si l’on insère 10 lignes, une par une, dans une table qui a 4 indexes, alors on va générer 50 redo records et 50 undo records, et faire appel 50 fois au latches de redo: 5 redo record par ligne (un pour la table et un pour chaque index) pour 10 lignes.

Lorsque la fonctionnalité de journalisation en mémoire (in-memory undo) est activée, et parce que dans cet exemple il s’agit d’une petite transaction, voici ce qu’il se passe:

• A moment où on modifie la première ligne de la table, Oracle alloue dans la shared pool son propre buffer de redo privé (appelé redo strand) et son propre buffer de « undo ». En fait, ce buffer de « undo » contient du redo: c’est le redo qui décrit ce qui doit être modifié dans les bloc d’undo.
• Lors de la mise à jour de la table et des index, chaque change vector qui décrit la modification est écrit dans le buffer de redo privé.
• En même temps, les change vector qui décrivent le undo record correspondant sont écrits dans le buffer de « undo » privé.
• Le nombre total de change vectors, et leur contenu sont exactement les mêmes que pour les change vectors traditionnels.
• Au commit, oracle concatène ces 2 buffers pour faire un seul redo record et l’écrit dans le tampon de journalisation normal (redo log buffer)
• En même temps, ces 100 change vectors sont appliqués: 10 sur la table, 10 sur chaque index, et 50 sur les blocs d’undo. Et en dehors de cela, tout ce qui doit se faire lors d’un commit s’applique aussi.
• Le nombre de modification de blocs (« db block changes ») reste le même dans tous les cas
• La différence la plus significative dans le volume de redo généré vient de l’entête du redo record qui fait 12 octets. Avec la gestion ‘in-memory’ de l’undo il n’y qu’un seul redo record, donc un header de 12 octets, alors que la méthode traditionnelle en génère 50, donc 50*12=600 octets.

Il y a de nombreux détails et variations autour de ce qui se passe là. Par exemple au début et à la fin de la transaction, ou lorsque un des deux buffers est plein (puisqu’ils ne font que 64Ko ou 128Ko) mais la description faite ci-dessus couvre les différences essentielles.

Question: Supposons que je démarre l’instance et effectue quelques mises à jour. J’ai donc un buffer privé de redo et un buffer privé de undo, créés en shared pool. Immédiatement après le système se plante et rien n’est encore écrit dans les fichiers de redo ni dans les blocs d’undo. Dans cette situation comment fait Oracle pour récupérer les données d’undo ?

Il y a deux chose que vous devez prendre en compte dans ma description:

• la précision: ‘Il y a de nombreux détails et variations’
• la partie qui montre que les modifications faites dans les blocs tables et index est tout à la fin.

Si la session a fait un commit, elle a écrit le redo privé dans le redo thread public, qui doit être écrit sur disque avant que le commit ne soit terminé. Donc il n’y a rien de différent au niveau du recovery.

Maintenant, si la session n’a pas encore fait de commit, alors du point de vue des autres utilisateurs, rien ne s’est encore passé (ils ne sont censés voir que les effets des transactions commitées). Du coup, cela n’a pas d’importance que les redo et undo privés aient disparu.

Mais voici où ca devient plus complexe: Comment les autres sessions voient que vous êtes en train de modifier les mêmes blocs qu’elles, si vous ne les mettez à jour que lorsque vous faites le commit de votre transaction ? Comment Oracle fait pour minimiser le temps que prennent toutes les modifications de blocs qui doivent être faites lors du commit ? J’ai quelques réponses à ces questions, mais elles ne sont ni exactes, ni complètes, alors je ne préfère pas les publier.

Cependant, un point clé de ce mécanisme, c’est le fait qu’il ne s’applique qu’à des petites transactions. Les zones privées ne font que 64Ko ou 128Ko suivant qu’on est en 32 ou 64 bits, et dès que la transaction devient trop grande, Oracle les écrit dans les redo buffer et poursuit avec le mécanisme normal.

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.

Ceci est une traduction de d’un post de Jonathan Lewis sur son blog – la quatrième et dernière partie d’une série de quatre sur la fragmentation (original en anglais). Il est conseillé de lire avant: Fragmentation – Introduction, Fragmentation – Disque et Tablespace, Fragmentation – Table

Fragmentation Index

La fragmentation en extents multiples et la fragmentation due à ASSM que j’ai décrit dans la note précédente à propos des tables s’appliquent aussi aux indexes, bien sûr, et nous importe de la même manière, c’est à dire presque jamais. Lorsque les gens parlent de fragmentation d’index, ils pensent en général au problème des blocs avec un faible taux de remplissage (sparsely populated blocks) qui est aussi un phénomène que j’ai décrit à propos de la fragmentation des tables, mais il y a quelques différences entre une table et un index, que nous allons examiner tout de suite.
Il est intéressant de considérer aussi un autre sens possible pour la fragmentation d’un index, que nous allons aussi examiner: c’est l’effet de bord de la division d’un bloc feuille (leaf block splitting) qui fait que des blocs qui sont logiquement à la suite se retrouvent physiquement dispersés.

Nous allons commencer avec une suppression en masse, et étudier les mêmes cas représentatif que nous avons vu à propos des tables (c’est à dire 20% des blocs ayant 100% de leurs ligne supprimées, et 100% des blocs ayant 20% de leur lignes supprimées). Et quand on fait ça, il faut garder à l’esprit que la suppression dans un index est différente de la suppression dans une table, d’où une différence de comportement dans ce qui suit.
Lorsqu’une transaction supprime une ligne d’une table (DELETE) la ligne est réduite à un stub de quelques octets, avant que ne se fasse le commit, et elle peut réutiliser immédiatement l’espace libéré dans le bloc de la table. Mais lorsqu’une transaction supprime une ligne d’un index, il doit laisser en place l’entrée d’index entière, et la marquer comme supprimée. Elle ne peut pas réutiliser l’espace immédiatement, mais cela doit attendre que le commit soit fait.

Une autre différence majeure entre une table et un index est le fait que dans un index chaque entrée a sa place et doit aller au bon endroit. Ce qui fait que lorsqu’un bloc d’index a de l’espace libre, sans être complètement vide, il n’y a que les lignes qui correspondent exactement à cette partie de l’index (à cette plage de valeurs) qui peuvent réutiliser cet espace.

De plus, lorsqu’un bloc feuille devient complètement vide, il reste toujours chaîné dans la même position de la structure de l’index, même s’il est aussi référencé par la freelist. (Mon hypothèse là dessus est qu’il est probablement plus facile de gérer les problèmes de lecture cohérente – read consistency – mais cela peut aussi être lié à des problèmes de rollback et au coût de la modification de 3 pointeurs dans la structure de l’index.) Ce qui veut dire que si on a un index qui a eu une large suppression des valeurs les plus basses, alors une requête qui demande la valeur minimum va devoir faire un range scan d’un grand nombre de blocs vides avant de trouver le bloc feuille qui contient une donnée présente. C’est pour cela qu’il faut toujours penser à faire un ALTER INDEX … COALESCE sur un index lorsqu’on supprime fréquemment les premières entrées. Et de manière plus générique, même si c’est moins courant, lorsque on un supprime un grand nombre de valeurs consécutives n’importe où dans l’index.

Dans le cas plus général d’un suppression en masse, on peut se retrouver avec un espace libre important dans tous les blocs feuilles et, contrairement à l’espace libre des tables, on ne peut pas faire en sorte qu’Oracle le réutilise en choisissant une valeur idéale pour PCTUSED puisque ce paramètre n’a pas de sens pour un index. Donc, dans le cas des index, la question que l’on doit se poser est: à quel point cet espace libre a un impact sur l’application.

Les considérations habituelles s’appliquent ici, bien sûr: un plus gros volume à sauvegarder lors des backup et plus de blocs à garder en buffer cache. Mais nous devons voir si le fait d’avoir un grand nombre de blocs feuilles faiblement remplis n’a pas un impact plus direct et plus significatif sur les performances.
La réponse est dépendante de l’application, bien sûr. Mais en général un index est utilisé pour lister les valeurs clés et les regrouper dans un faible espace. Et en gardant cela à l’esprit, on peut voir que le plus gros du travail de la plupart des requêtes est passé à aller voir les lignes de la table après avoir récupéré un certain nombre de valeurs clés dans l’index. Par conséquent, le travail supplémentaire venant du fait qu’il y a une grand quantité d’espace libre dans les blocs feuilles de l’index n’est qu’une petite fraction du travail total de la requête. Et on peut donc décider de ne pas dépenser des ressources à réorganiser les index sauf s’ils sont vraiment très faiblement remplis. (Un index B-Arbre typique avec une arrivée aléatoire va tourner avec un taux d’utilisation de 70%, donc 30% d’espace libre, dans les blocs feuilles. Je ne suis pas particulièrement inquiet des performances d’un index avant que le taux d’utilisation ne passe en dessous de 50%, sauf si j’ai une preuve que cet index contribue significativement au temps d’exécution d’un ensemble de requêtes critiques.)

Il y a cependant deux autres problèmes de ‘fragmentation’ spécifiques aux index, et qui n’existent pas avec les tables.

Le premier est le fait qu’on ne met pas à jour une entrée d’index: on supprime l’entrée correspondant à l’ancienne valeur, et on ajoute la nouvelle entrée correspondant à la nouvelle valeur. Si ces mises à jours se font de manière aléatoire, alors il n’y a aucun des problèmes associés aux suppressions de masse. Mais si il y a un pattern de modification lié au temps, par exemple si vous avez un index sur une colonne ‘dernière_modification’ alors vous pouvez vous retrouver avec le pire effet d’un index partiellement rempli. Dans un cas comme celui-ci, vous allez supprimer (lentement) des entrées vers le début de l’index pour les insérer tout à la fin. Et l’espace libéré par les suppression ne sera jamais réutilisé puisque les lignes ne peuvent pas êtres modifiées dans le passé. En plus, si vous continuez à modifier des lignes du passé vers le futur, vous continuez à visiter des blocs faiblement remplis. Et si c’est un système transactionnel où les utilisateurs modifient une ou deux lignes à chaque fois, la recherche de l’entrée et la mise à jour dans l’index peut prendre une proportion significative du travail effectué par chaque requête d’update. Vous devez au moins être au courant de ce type d’activité afin de prévoir comment en mesurer l’impact sur les performances et adopter une stratégie pour y faire face.

Le deuxième type de fragmentation propre aux index, pour lequel le terme de fragmentation semble le plus approprié, vient des divisions des blocs feuilles (leaf block split). Si vous voulez ajouter une entrée dans un bloc feuille qui est plein, alors Oracle doit trouver un bloc vide quelque part, y déplacer à peu près la moitié des données du bloc courant, puis lier ce bloc à sa bonne place dans la structure de l’index. Par consequent, les blocs qui sont ‘logiquement’ adjacents ne sont pas nécessairement ‘physiquement’ adjacents. Cela veut dire que lorsque vous faites un index range scan assez large (ou un index full scan) vous vous retrouvez à faire beaucoup de lectures aléatoires de blocs.

C’est ici que SQL Server (et probablement sybase et peut-être DB2) entrent en jeu. La manière dont SQL Server gère l’espace libre pour les tables non clusterisées (heap tables) n’est pas très efficace. Donc c’est presque un article de foi (voire un dogme) que toutes les tables dans SQL Server doivent être construites en index cluster (clustered indexes), ce qui veut dire dans les termes Oracle, que toutes les tables sont des IOT (index organized tables tables organisées en index). Si vous avez essayé de regrouper (cluster) vos données, et y avez réfléchi soigneusement et délibérément, alors les divisions des blocs feuilles (leaf block split) détruisent votre effort de garder ensemble les données liées. Il n’est donc pas surprenant que les DBA qui ont une expérience en SQL Server (et Sybase et DB2) soient si favorables à l’idée de reconstruire les index fréquemment. Si vous reconstruisez un index cluster, vous ramenez les enregistrements là où vous voulez. Heureusement, cela ne nécessite pas de reconstruire tous les autres indexes de la table puisque, comme les index secondaires des IOT d’Oracle, les autres indexes en SQL Server utilisent la clé unique (ou rendue unique) comme identifiant de la ligne.

Pour Oracle, ce type de fragmentation ne pose généralement pas de problème, à condition qu’il concerne des index B-arbre standard, vu que, comme c’est précisé plus haut, la plupart des requêtes passent la plus grande partie de leur temps à visiter la table. Mais le cas de SQL Server donne une indication du cas où vous devrez considérer plus sérieusement les effets de la ‘fragmentation’ et le besoin de reconstruire les index. Si, en tant que DBA Oracle vous avez crée une table en IOT, alors vous aviez probablement une bonne raison de faire ce choix, et il s’agissait probablement de s’assurer que les données qui arrivent dans un certain ordre sont stockées dans un autre ordre, afin de garder ensemble des données qui sont liées.

Si vous avez crée une IOT pour garder les données regroupées, alors les divisions de blocs feuilles vont amener les données à être un peu dispersées. Avant de s’inquiéter, il faut étudier l’importance de cette dispersion, et le bénéfice, peut-être marginal, d’y faire quelque chose. Pour illustrer cela, imaginez que vous ayez une requête sur une table IOT importante qui récupère 200 lignes de 200 octets. Comme sur une table normale cela aurait demandé à lire 200 blocs différents dispersés aléatoirement, vous avez décidé d’implémenter la table en IOT. Si l’on prends le cas le pire pour le divisions de blocs feuilles (50/50 avec aucun re-remplissage) alors les 200 lignes vont aller dans la IOT avec environ 20 lignes par blocs sur un total de 10 blocs feuilles. A cause du moment où chaque division de bloc feuille a lieu, on peut penser que ces 1à blocs vont finir dispersés assez aléatoirement dans tout le segment d’index. Si vous reconstruisez l’index, vous allez pouvoir compacter les données sur seulement 5 blocs, et ces 5 blocs vont souvent être adjacents dans le segment plutôt que dispersés. Et ce regroupement ca probablement faire que vous aurez un petit bénéfice de performance si l’index range scan doit aller sur disque. Note: SQL Server travaille avec des tailles d’extents de 8 blocs de 8 KB et le logiciel de base de donnée peut coopérer avec le système d’exploitation pour négocier une lecture en avance (readahead) de l’extent complet dans ce genre de situation. Cet ensemble de détails font que la réorganisation d’index dans ces circonstances et plus bénéfique sur SQL Server que ce cerait le cas sur Oracle.

Après avoir passé un peu de temps à réfléchir à ce genre de scénario, il est plus facile de comprendre comment évaluer le bénéfice que vous pouvez tirer de la réorganisation d’une IOT. Quelle est la rédution du nombre total de visites de blocs que vous aurez à faire ? Combien de ces visites seraient des I/O disque distincts ? Quel serait le bénéfice du point de vue d’Oracle, du système d’exploitation, des drivers hardware, capable d’implémenter un readahead qui réduit le temps de lecture de ces blocs ? Gardez à l’esprit la remarque importante que j’ai fait dans l’article sur la fragmentation de disque: même si deux blocs aparaissent comme adjacent du point de vue des fichiers Oracle, l’introduction du stripping, et du load balancing peuvent faire que ces deux blocs sont sur des disques différents.

Fin de la série

Ceci est une traduction de d’un post de Jonathan Lewis sur son blog – la troisième partie d’une série de quatre sur la fragmentation (original en anglais). Il est conseillé de lire avant: Fragmentation – Introduction, Fragmentation – Disque et Tablespace

Fragmentation Table

Dans l’introduction nous avons parlé d’un type de fragmentation au niveau table qui, en général, ne pose pas de problème: la fragmentation d’une table en plusieurs extents. Et il y a une chose amusante, c’est que ASSM (Automatic Segment Space Management – la gestion automatique de l’espace libre dans les segments) a introduit une nouvelle forme de fragmentation, mais qui ne pose généralement pas de problème non plus.

En ASSM, lorsqu’un processus Oracle vérifie le bitmap qui garde la trace de l’espace libre d’un objet, et qu’il ne trouve pas assez d’espace libre pour insérer de nouvelles données, alors il va formater 16 blocs quelque part dans l’extent en cours (après avoir alloué un nouvel extent si nécessaire). Ces 16 blocs peuvent être n’importe où dans l’extent (du moment que le numéro du bloc de départ par rapport à l’extent soit un multiple de 16).
L’emplacement de cet ensemble de 16 blocs est déterminé par l’identifiant du processus (le PID – process id), de même que le choix du bloc à utiliser parmi ces 16. Ce qui veut dire si vous créez une table dans un tablespace qui a des extents uniformes de 1Mo, vous pouvez vous retrouver à ce que la première ligne que vous insérez se retrouve dans le tout dernier bloc de son extent.
Cela n’a généralement pas d’importance parce que:

• la plupart des accès I/O se font bloc par bloc plutot que par full scan, et donc l’emplacement du bloc dans l’extent n’a pas beaucoup d’importance.
• ce ‘désordre’ ne se retrouve en principe que sur le dernier extent de la table
• en cas de full scan, pour savoir quel morceaux de 16 blocs doivent être traités de manière spéciale, Oracle utilise un mécanisme qui minimise le surcoût de cette vérification, en utilisant les LHWM (low high water mark) and HHWM (high high water mark).

Le type de fragmentation de table le plus important, et le plus courant, vient des données qui sont supprimées, et on peut alors se préoccuper des blocs qui ont un faible taux de remplissage. Lorsqu’on crée une table, on précise l’espace qui doit être réservé dans chaque bloc afin de garder une marge pour les lignes qui vont être modifiées (UPDATE) et – explicitement en freelist ou implicitement en ASSM – on précise aussi l’espace libre que doit contenir un bloc pour qu’il puisse être à nouveau la cible d’une nouvelle insertion de données (INSERT).

Si on regarde tous les scénarios possibles qui doivent être pris en compte avec avec des insertions de données, des modifications et des suppressions, on se rend compte à quel point il peut être difficile pour Oracle d’écrire du code qui gère l’espace libre de façon efficace et opportune. On voit aussi à quel point il est difficile, en tant que développeur ou DBA, de préciser des limites raisonnables pour la gestion de l’espace afin de minimiser les problèmes de performances dans des cas extrêmes. Au final, il est possible de se retrouver avec une table qui a une quantité importante d’espace libre dans chaque bloc, et il faut alors se poser les questions suivantes: Comment ce espace libre est arrivé là ? Est-ce qu’il pose un problème de performance ? Est-ce que vous allez pouvoir le réutiliser ? Est-ce que vous allez pouvoir le réutiliser en temps opportun ? Si vous arrivez à le réutiliser, est-ce que ca n’introduit pas un autre type de problème de performance ?

Prenez le cas où vous purgez la première année de données après que votre système ait tourné pendant 5 ans. Cela va probalement faire que les 20% premiers blocs de la table seront complètement vides. Il iront en freelist. Ou en ASSM, à l’exception de quelques bugs, ils seront marqués comme ayant de l’espace libre. Et cet espace libre pourra donc être réutilisé plus tard. De plus, si les performances de votre application dépendent du fait que les données qui arrivent au même moment se retrouvent ensembles (clustering par rapport à la date/heure d’arrivée) alors de la manière dont l’espace libre est rempli, le clustering va normalement rester intact.
Par une bizarrerie de l’implémentation, les blocs vont être utilisés dans l’ordre inverse en gestion freelist et dans l’ordre normal en ASSM (et une question me traverse l’esprit à ce moment à propos de l’impact de cet ordre inverse sur les indexes non-uniques qui ont peu de valeurs distinctes).

Cependant, pour un bon moment, avant cette réutilisation, les full scan de la table vont prendre 20% de temps en plus de ce qui est nécessaire. Et vous pouvez vous retrouver à faire un backup d’un fichier plus gros que ce dont vous avez réellement besoin. Ces considérations peuvent alors vous décider à faire une réorganisation de la table (et d’un rebuild des index) en la déplaçant vers un autre tablespace. Et elles peuvent aussi vous amener a réfléchir au partitionnement de la table.

Imaginez le cas d’un système de vente par internet où les utilisateurs remplissent leur panier, paniers qui à la fin deviennent une commande. Inévitablement, certains utilisateurs vont remplir un panier sans passer la commande par la suite. Alors vous avez peut-être un programme en tâche de fond qui regarde les vieux paniers et le supprime de la base. Il y a deux imperfections dans cette implémentation, mais ce genre d’erreur se voit souvent sur des systèmes en production. Alors dans ce cas, vous vous retrouvez avec une table qui subit constamment des delete sur le passé récent, de telle sorte que si vous analysez la table, vous verrez qu’en moyenne elle a, disons, 20% d’espace libre dans chaque bloc, à l’exception des quelques blocs qui contiennent les paniers récents.

Si vous êtes en ASSM, ces 20% ne seront jamais réutilisés (sauf si en recréant la table) parce que la granularité de ASSM fait qu’il faut au moins 25% d’espace libre dans un bloc avant que son statut ne passe de ‘plein’ à ‘0% – 25% libre’. Mais si vous êtes en freelist alors vous avez peut-être prévu le coup en mettant PCTUSED à un peu plus que 80. Dans ce cas, les blocs reviennent en freelist dès que l’espace libre atteint 20%, et l’espace va être réutilisé.
Cela semble être une bonne idée, sauf qu’il y a un autre problème à prendre en considération.

Peut-être que les bonnes performances de votre application venaient du fait que les paniers des derniers jours sont stockés dans les N derniers blocs de la table. Du fait que vous libérez 20% de l’espace des blocs du passé, alors les paniers qui étaient stockés sur N blocs sont maintenant répartis sur 5 fois plus de blocs. Et cela veut dire que, si vous voulez garder le même niveau de performance, vous allez avoir besoin de plus de mémoire en buffer cache.

La conclusion générale est la suivante. Une fois que vous avez résolu une fois pour toutes le problème de la taille des extents d’une table, le seul problème de ‘fragmentation’ qui vous reste à prendre en compte est celui des blocs qui ne sont que partiellement remplis. Et il y a des patterns de suppression de données qui peuvent amener à cette situation de blocs sous-utilisés. Dans certains cas, il n’est possible de récupérer cet espace que par une réorganisation de la table (et dans tous les cas, c’est le partitionnement de la table qui peut faire que cette option est viable). Mais il y a aussi des patterns de suppression de données qui font que l’espace libre est réutilisable, mais que vous ne voulez pas toujours réutiliser cet espace, car cela peut amener un autre type de problème.

La suite: Fragmentation – Index

Ceci est une traduction d’un post de Jonathan Lewis sur son blog – la première partie d’une série de quatre sur la fragmentation (original en anglais)

Cet article a commencé comme une note brève, jusqu’à ce que je réalise que ça allait être plus important, et que j’en fasse plutôt une série de quatre articles:

• Fragmentation – Introduction
• Fragmentation – Disque et Tablespace
• Fragmentation – Table
• Fragmentation – Index

Introduction

Le mot ‘fragmentation‘ donne l’idée de quelque chose qui est cassé en plusieurs morceaux, mais il a aussi une connotation émotionnelle qui fait penser qu’il y a beaucoup de petits morceaux. Dans le contexte d’une base Oracle, vous devez savoir ce que vous entendez par ‘morceau’, ainsi que la granularité de ces morceaux, et leur impact possible sur les performances.

Vu qu’il est possible de parler de fragmentation au niveau disque (disque logique), ou au niveau fichier, niveau tablespace, niveau segment, niveau extent ou niveau block, il est important de savoir très clairement ce que vous essayez de dire lorsque vous faites un commentaire du genre ‘Mon tablespace est fragmenté’ ou ‘Mon index est fragmenté’

Partons sur un exemple: Je crée un nouveau tablespace et je déplace une table dedans (ALTER TABLE … MOVE).
Lorsque je regarde DBA_EXTENTS, ma table a 100 extents. Il est évident qu’il y a ‘fragmentation’ dans le sens premier de ce mot, puisque j’ai 100 différents morceaux. Mais d’autre part, puisque cette table est la première chose que j’ai créé dans ce tablespace, je vois que ces extents sont adjacents. On pourrait alors dire que la table est ‘logiquement fragmentée‘ mais ‘physiquement contiguë ‘.

Est-ce que ce type de fragmentation a un impact sur les performances du système ?

Vu qu’Oracle fait la plupart des I/O par bloc (nous lisons des blocs vers le buffer cache, nous écrivons des blocs dans les fichiers), et vu qu’il n’y a pas de conséquences au fait qu’un bloc appartienne à extent plutôt qu’un autre, alors la réponse est probablement: non.
Cependant, il y a des fois où on essaie de lire plusieurs blocs contigus en un seul I/O (full table scan et index fast full scan), alors y a-t-il des conséquences au fait que notre table ‘physiquement contiguë’ soit ‘logiquement fragmentée’ en un grand nombre d’extents ?

Que se passe-t-il si les extents font, disons, 64Ko chacun. Est-ce que cela limite la taille d’une lecture multi-bloc (db file multiblock read) ? Ou bien ces lectures peuvent-elles être à cheval sur deux extents ? Et si le tablespace a deux datafiles ou plus, dans ce cas l’allocation des extents se fait généralement en alternant les datafiles (round-robin), est-ce que cela affecte la manière dont les lectures pourront se faire ? Et si on fait des full table scan en parallel query (parallel tablescan), est-ce qu’il y a des restrictions différentes pour les lectures directes (direct-path reads) ?

Si vous faites tourner un datawarehouse qui passe beaucoup de son temps à faire ce type d’opérations, alors ce sont quelques unes des questions auquelles vous devrez savoir répondre. Voir, par exemple, une note que j’ai écrit il y a trois ans à propos d’anomalies dans les tailles d’I/O lorsqu’on est en parallel query, et l’amélioration faite là dessus en 11G qui a été décrite ici par Christian Antognini il y a quelques années.

Vous ne pouvez commencer à comprendre les problèmes posés par la fragmentation, et si elle a un impact - ou non - sur les performances, que lorsque vous aurez commencé à définir de manière claire ce que vous entendez par ‘fragmentation’. Dans la deuxième partie, je vais faire quelques commentaires sur la manière de réfléchir à la fragmentation au niveau disque et au niveau tablespace.

La suite: Fragmentation – Disque et Tablespace

Ceci est une traduction de d’un post de Jonathan Lewis sur son blog – la deuxième partie d’une série de quatre sur la fragmentation (original en anglais). Il est conseillé de lire avant: Fragmentation – Introduction

Fragmentation Disque

Les tablespaces sont composés de fichiers, et les fichiers sont stockés sur disque. Il s’agit la plupart du temps de disques logiques (logical volumes) plutôt que de vrais disques directement (real devices).
Lorsqu’on fait une lecture sur un vrai disque, la taille des données qu’on peut lire en une seule opération physique est quelque chose comme 400Ko ou 500Ko. C’est le contenu d’une seule piste sur un seul plateau d’un disque physique. Une lecture plus large continue en passant sur un autre plateau (ce n’est pas un mouvement physique des têtes, mais une commutation ‘électronique’) , ou bien en passant sur une autre piste (c’est alors un mouvement physique, mouvement latéral de la tête), ou encore en passant sur un autre disque. Passer sur un autre disque, c’est rejoindre une autre file d’attente de disque, et dans ce cas le logiciel du SAN, ou l’équivalent, aura probablement anticipé les disques dont vous aurez besoin et aura lancé en parallèle ces demandes de lectures dans les files d’attentes correspondantes.

Lorsque vous créez un datafile sous Oracle, vous ne savez pas à quel point le fichier est dispersé sur les disques physiques du système. Au mieux, une lecture de 1Mo va impliquer 3 ou 4 rotations d’un même disque, avec seulement des passage d’un plateau à l’autre (commutations ‘électroniques’). Et au pire, j’ai déjà vu un seul I/O impliquer jusqu’à 32 opérations différentes sur les disques, à cause des nombreuses couches de logicielles utilisés pour stripper sur les disques, puis sur les groupes de disques (diskgroup), puis sur les volumes logiques (logical volumes), etc.
Si on est tout seul sur le SAN, ce dernier cas où la lecture est parallélisée sur tous les disques est vraiment optimal pour les performances. Mais sur un système en production, c’est une calamité pour les files d’attentes. C’est pour cette raison que c’est une bonne stratégie de présenter des disques ‘bruts’ à ASM, en ayant une seule couche logicielle entre Oracle et les disques, et il s’agit en plus d’une couche logicielle qui connaît le comportement et les données d’Oracle.

A retenir: Ne pas mettre trop de couches de logiciels ‘intelligents’ entre Oracle et les lecteurs de disque.

Fragmentation Tablespace

Bien sûr, vous pouvez créer un tablespace avec plusieurs fichiers. Alors, par définition, le tablespace est fragmenté, même si il n’y a à la base rien de négatif avec ce type de fragmentation. Mais comme je l’ai précisé dans la note précédente (introduction), cela peut avoir des effets de bord sur la disposition des extents d’un segment, et arriver à des cas où vous voulez faire une seule lecture d’un gros volume de données, et vous retrouver en fait à faire plusieurs I/O plus petits – avec pour conséquence une augmentation de l’attente sur les I/O.

Le cas de fragmentation que la plupart des gens ont à l’esprit quand ils parlent de fragmentation de tablespace, c’est à dire le fait qu’il y ait des ‘trous’ d’espace libre au milieu de l’espace alloué, est quelque chose qui a aussi été appelé ‘gruyèrisation’ (ou en anglais honey-combing ou bubbling). C’est un effet de bord lorsqu’on supprime (DROP) ou réduit (SHRINK) des objects, qu’on déplace des tables (MOVE) ou qu’on reconstruit des indexes (REBUILD). On finit par avoir des morceaux d’espace libre dispersés sur tout le tablespace. Chaque fois que vous réorganisez un objet, vous allez probablement remplir certains de ces morceaux, mais en laisser d’autres vides là où se trouvait l’objet avant.

Fondamentalement, il est rare que ce type de fragmentation pose un problème, parce que cet espace vide n’entraîne pas de travail supplémentaire, sauf lorsque on fait un backup du fichier. Si vous pensez que le temps passé à copier cet espace vide lors d’un backup a un impact important sur la durée de la sauvegarde (dans le cas où le backup dépasse la fenêtre de temps permise avant le prochain cycle de chargement de données, par exemple), alors vous pouvez prévoir de déplacer des objets de telle sorte que l’espace libre se trouve à la fin de fichiers. Cela permet ensuite de réduire la taille des fichiers: voir par exemple cette note sur la réduction de la taille des tablespaces (en anglais).
Par contre, il faut garder à l’esprit qu’il peut y avoir des effets indésirables lors de cette réorganisation. Il y avait cette question sur le forum OTN il y a quelques années où un DBA s’est aperçu que déplacer des tables les a rendu plus volumineuses. j’ai écrit une note (en anglais) à propose de cela, en reprenant la question et la réponse (réponse que j’avais publiée dans ‘Practical Oracle 8i’).

Les difficultés liées à cette fragmentation ‘gruyère’ on été en grande partie un effet secondaire du paramètre PCTINCREASE d’Oracle qu’on pouvait spécifier pour les segments de données, amplifié par l’idée reçue qu’il vaut mieux réduire les objets à un seul extent. Mais depuis l’introduction des tablespaces dont l’espace libre est géré localement (LMT – Locally Managed Tablespaces), qui simplifient les options de dimensionnement des extents (surtout pour la taille d’extent UNIFORM), la seule question est quand l’espace libéré va être réutilisé et non comment est gérée cette réutilisation.

Pour en lire un peu plus là dessus: une histoire ancienne que j’ai publié bien avant qu’Oracle n’introduise les Locally Managed Tablespaces avec une taille d’extent uniforme, republié il y a 2 ans.

La suite: Fragmentation – Table

Cet article est la traduction d’un article de Tom Kyte publié dans Oracle Magazine en Novembre 2005. L’article original en anglais se trouve ici.
Il peut être utile de lire avant Lectures cohérentes et multi-versionnage (traduit aussi de Tom Kyte).

Question posée sur AskTom:

J’ai lu le manuel ‘Database Concepts’ de la documentation Oracle, au chapitre « Data Concurrency and Consistency » mais je n’ai pas vraiment compris la différence entre les niveaux d’isolation serializable et read-committed. Pouvez-vous donner des exemples qui expliquent cela clairement ?

Réponse de Tom Kyte:

Avant de lire ce qui suit, vous pouvez aller voir l’article d’Oracle Magazine de Mai/Juin 2005 (en anglais) où je décris la fonctionnalité que j’ai toujours préféré dans Oracle: le multi-versioning. Sa compréhension est cruciale pour réussir avec Oracle, mais il vous aidera aussi à comprendre les concepts décrits ci dessous. (Voir la traduction d’un article similaire ici)

[La suite est un extrait de ‘Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions‘]

Le standard SQL ANSI/ISO SQL définit 4 niveaux d’isolation des transactions (transaction isolation levels), qui peuvent donner des résultats différents pour le même scénario de transactions. Cela veut dire que le même travail, effectué de la même manière, avec les mêmes données, peut avoir des résultats différents, en fonction du niveau d’isolation. Ces niveaux sont définis par les 3 phénomènes qui sont autorisés ou non pour un certain niveau d’isolation:

Lecture ‘sale’ (Dirty read): Sa signification est aussi négative que son nom. Vous avez le droit de lire des données non-committées, ou ‘sales’. Vous pouvez avoir le même effet en ouvrant un fichier du système d’exploitation sur lequel quelqu’un est en train d’écrire, et lire n’importe quelle donnée qui s’y trouve. L’intégrité des données est compromise, les clés étrangères sont violées, et les contraintes d’unicité sont ignorées.

Lecture ‘non-répétable’ (Nonrepeatable read): Cela veut simplement dire que si vous lisez un enregistrement à un temps t1, et essayez de le relire à un temps t2, l’enregistrement peut avoir changé. Il a pu disparaître, il a pu être modifié, etc.

Lecture ‘fantôme’ (Phantom read): Cela veut dire que si vous faites une requête à un temps t1, et que vous la relancez à un temps t2, des nouveaux enregistrements ont pu être ajoutés dans la base, ce qui peut modifier votre résultat. C’est différent de la lecture non-répétable dans le sens où les enregistrements que vous avez lu précédemment n’ont pas changé. Mais de nouveaux enregistrements répondent à votre critère de requête.

Il faut noter que le standard ANSI/ISO définit les caractéristiques des niveaux d’isolation au niveau des transactions, et pas seulement au niveau de chaque requête. Je parlerai de l’isolation au niveau transaction, et pas seulement au niveau requête.

Les niveaux d’isolations SQL sont définis par leur le fait d’autoriser ou non chacun des phénomènes précédents. Il est important de noter que le standard SQL n’impose aucun système de verrouillage spécifique, et ne demande aucun comportement particulier, mais il décrit plutôt les niveaux d’isolation en termes de phénomènes permis, afin que puissent exister différentes implémentations pour les mécanismes de verrouillage et de concurrence d’accès).

Les niveaux d’isolation ANSI:

Oracle supporte explicitement les niveaux d’isolation READ COMMITTED et SERIALIZABLE tels qu’ils sont définis dans le standard. Mais ce n’est pas suffisant de dire cela. Les standard SQL voulaient essayer de permettre des degrés de cohérence différents en fonction du niveau d’isolation où la requête est exécutée. REPEATABLE READ est le niveau à partir duquel, d’après le standard SQL, le résultat d’une requête est censé être cohérent. READ COMMITTED, pour le standard SQL, ne garantit pas un résultat cohérent en lecture, et READ UNCOMMITTED est supposé être le niveau qui utilise des lectures non-bloquantes.

Mais sous Oracle, READ COMMITTED a tous les attributs nécessaires pour avoir une lecture cohérente au niveau de la requête. Dans les autres SGBD, READ COMMITTED peut et va retourner des résultats qui n’ont jamais existé en base de donnée. Et en plus, Oracle supporte l’idée de READ UNCOMMITTED. La lecture ‘sale’ a pour but de fournir une lecture non-bloquante, où les requêtes ne bloquent pas et ne sont pas bloquées par les mises à jour concurrentes des mêmes données. Mais Oracle na pas besoin de lectures ‘sales’ pour atteindre ce but, et il ne les implémente pas. La lecture sale (‘dirty reads‘) est une implémentation que les autre SGBD doivent utiliser pour permettre des lectures non-bloquantes.

En plus des 4 nivaux d’isolation définis par le standard SQL, le SGBD Oracle en fournit un autre: READ ONLY (lecture seule). Une transaction READ ONLY est equivalente à une transaction REPEATABLE READ ou SERIALIZABLE, mais qui ne peut faire aucune mise à jour. Une transaction qui utilise le niveau d’isolation READ ONLY ne voit que les modifications qui ont été committées avant que la transaction ne commence. Les insert, update et delete ne sont pas permis dans ce mode (les autres sessions peuvent mettre à jour les données, mais pas la transaction READ ONLY). En utilisant ce mode, vous avez les niveaux d’isolation REPEATABLE READ et SERIALIZABLE.

Je vais maintenant expliquer le rôle du multi-versioning et de la lecture cohérente (read consistency) dans le système d’isolation, et comment les SGBD qui ne font pas du multi-versioning arrivent au même résultat. Cette explication est utile pour tous ceux qui ont utilisé un autre SGBD et qui croient qu’ils ont compris comment les niveaux d’isolation doivent fonctionner. C’est aussi intéressant pour voir comment le standard SQL ISO/ANSI , qui était supposé supprimer les différences entre les SGBD, au contraire les permet. Le standard, même s’il est très détaillé, peut être implémenté de différentes manières.

READ UNCOMMITTED.

Le niveau d’isolation READ UNCOMMITTED permet les lectures ‘sales’ (dirty reads). Le SGBD Oracle n’utilise pas ces dirty reads, et ne les permet même pas. READ UNCOMMITTED est défini dans le standard pour permettre les lectures non bloquantes. Comme vous avez vu, Oracle fait des lectures non bloquantes par défaut. Vous auriez du mal à faire un SELECT en base qui bloque et attends (il y a un cas particulier pour les transactions distribuées). Chaque requête, que ce soit un SELECT, INSERT, UPDATE, MERGE, ou DELETE, fait ses lecture de manière cohérente. Cela peut sembler amusant de dire que l’UPDATE est une requête qui lit, mais c’est le cas. UPDATE a 2 composants: une lecture, qui est définie par la clause WHERE, et une écriture qui est définie par la clause SET. UPDATE lit et écrit dans la base de donnée, comme tous les ordres DML. La seule exception est l’INSERT d’une ligne unique, avec la clause VALUES, et qui n’a pas de composante de lecture, mais seulement d’écriture.

Dans le chapitre 1 de ‘Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions’ (ou en français ici), J’ai montré comment Oracle fait une lecture cohérente: avec un requête, sur une seule table, qui retourne pourtant les lignes qui ont été supprimées depuis l’ouverture du curseur. Je vais maintenant explorer un exemple du monde réel pour voir ce qu’il se passe sous Oracle avec le multi-versioning, et aussi ce qu’il se passe dans un grand nombre d’autres SGBD.

Je vais commencer avec la même table et encore une requête très simple:

Avant de lancer la requête, j’affiche les données:

Ligne      Numéro du Compte              Montant du Compte 

-----      ----------------              ----------------- 

1          123                           500,00 € 

2          456                           240,25 € 

...        ...                           ... 

342023     987                           100,00 €

A ce moment, mon SELECT démarre et va lire la ligne 1, puis la ligne 2, etc. A un certain moment lorsque cette requête est en cours d’exécution, une transaction fait un virement de 400€ du compte 123 vers compte 987. Cette transaction a fait les deux UPDATE mais ne fait pas encore le COMMIT. La table COMPTES ressemble maintenant à cela:

Ligne      Numéro du Compte              Montant du Compte  

-----      ----------------              ---------------------- 

1          123                           (500,00 €) -> 100,00 €  [vérouillé] 

2          456                           240,25 € 

...        ...                           ... 

342023     987                           (100,00 €) -> 500,00 €  [vérouillé]

Nous voyons que 2 enregistrements sont verrouillés (locked). Si quelqu’un essaie de les modifier, il sera bloqué. Jusque là le comportement qu’on voit est sensiblement le même sur tous les SGBD. La différence va se faire lorsque notre SELECT va tomber sur les données verrouillées.

Lorsque la requête que j’exécute arrive au bloc qui contient la ligne verrouillée (ligne 342023) tout au bout de la table, elle voit que les données ont changé depuis le début de la requête. Pour fournir une réponse cohérente (consistent) et juste, le SGBD Oracle va créer une copie du bloc, mais où cette ligne sera comme elle était au moment où la requête a commencé. C’est à dire qu’on va lire la valeur de 100€, qui était le montant du compte à ce moment là. En effet, au lieu de lire l’information modifiée, Oracle utilise l’undo (aussi appelé rollback segment) pour reconstruire l’information. Une réponse cohérente et juste est alors retournée, sans avoir à attendre que la transaction concurrent ne soit committée.

Par contre, un SGBD qui autorise les lectures ‘sales’ va simplement retourner la valeur qu’il voit pour le compte 987 au moment où il la lit, c’est à dire 500€. La requête va donc compter deux fois les 400€ du montant du virement. Non seulement il retourne la mauvaise réponse, mais en plus il renvoi un total qui n’a jamais existé dans la base. Dans un environnement multi-utilisateur, une lecture ‘sale’ peut être une fonctionnalité très dangereuse. Personnellement, je n’en ai jamais vu l’utilité.
Et si l’on prends le cas où, au lieu d’un virement, la transaction fait juste un dépôt de 400€ sur le compte 987. La lecture sale va compter les 400€ et retourner alors une réponse juste ? Et bien non. Supposons que la transaction fasse un rollback. Alors j’aurais compté les 400€ qui n’ont jamais été réellement en base.

L’idée ici, c’est que la lecture ‘sale’ n’est pas une fonctionnalité, mais un handicap. Et sous Oracle, elle n’est simplement pas nécessaire. Vous avez tous les avantages d’une lecture non-bloquante, mais sans avoir des résultats faux.

READ COMMITTED.

Le niveau d’isolation READ COMMITTED précise que la transction ne doit lire que les données qui ont été committées. Il n’y a pas de lectures ‘sales’ (qui sont les lectures de données non committées). Il peut y avoir des lectures ‘non-répétable’ (nonrepeatable read), ce qui veut dire que la relecture de la même ligne dans la même transaction peut donner un résultat différent. Il peut y avoir des Lecture ‘fantôme’ (phantom read), ce qui veut dire que, dans la même transaction, une ligne nouvellement insérée et committée devient visible par une requête alors qu’elle ne l’était pas avant.
READ COMMITTED est probablement le niveau d’isolation le plus courant dans les applications de base de données, et c’est le mode par défaut pour Oracle. Il est rare de voir un autre niveau d’utilisation utilisé dans une base Oracle.

Cependant, arriver au niveau d’isolation READ COMMITTED est plus compliqué qu’il n’y parait. Si vous regardez le premier tableau (Les niveaux d’isolation ANSI), cela semble simple. On a l’impression qu’une requête qui utilise READ COMMITTED se comporte de la même manière dans n’importe quel SGBD, non ? Et bien ce n’est pas le cas. Dans la pluspart des autres SGBD, si vous lisez plusieurs lignes en une seule requête, le niveau READ COMMITTED peut être aussi mauvais que que des lectures ‘sales’, en fonction de la manière dont il est implémenté.

Sous Oracle, en utilisant le système de multi-versionnage et les lectures cohérentes, la requête sur la table COMPTES donne le même résultat en READ COMMITTED que dans l’exemple du READ UNCOMMITTED. Oracle va reconstruire les données modifiées pour qu’elles apparaissent telles qu’elles étaient lorsque la requête a commencé, retournant la réponse qui était en base de donnée à ce moment là.

Maintenant, je vais regarder comment mon exemple précédant fonctionne en READ COMMITTED dans les autres SGBD. Je reprends au même endroit:
– Je suis au milieu de la table. J’ai lu et additionné les N premières lignes.
– L’autre transaction a viré 400€ du compte 123 vers le compte 987.
– Cette autre transaction n’a pas encore été committée, donc les lignes contenant les informations des comptes 123 et 987 sont verrouillées.

Je sais ce qu’il arrive sous Oracle lorsqu’on arrive au compte 987: il voit la modification, calcule que le montant devait être 100€ et c’est terminé. Voici comment un autre SGBD, dans un mode READ COMMITTED par défaut, peut arriver à donner la réponse.

La première chose à remarquer, c’est que cet autre SGBD va bloquer ma requête lorsque elle lit le compte 987. Ma session doit attendre que la transaction qui détient le verrou exclusif fasse un commit. C’est pourquoi beaucoup de gens ont la mauvaise habitude de faire un commit à chaque requête, au lieu de faire des transaction bien construites, regroupant toutes les requêtes qui font passer la base de donnée d’un état cohérent à un autre. Dans beaucoup de SGBD les mises à jour interfèrent avec les lectures. Mais le pire dans ce scénario, c’est que l’on fait attendre l’utilisateur pour lui donner au final un mauvais résultat. J’ai encore un résultat qui n’a jamais existé en base de donnée, tout comme avec les lectures ‘sales’, mais cette fois je fais attendre l’utilisateur pour lui donner cette mauvaise réponse.

Dans la suite, j’étudierai ce que doivent faire les autres SGBD pour arriver à un résultat cohérent en lecture, un résultat juste.

Ce qu’il faut retenir, c’est que avec le même niveau d’isolation, apparemment sans risque, des SGBD différent peuvent donner des résultats très différents dans les mêmes circonstances. Et ce cas n’est pas seulement une possibilité, ce cas arrivera forcément. Il est important de comprendre qu’avec le SGBD Oracle, les lectures non bloquantes ne se font pas au prix de mauvais résultats. Vous pouvez avoir le beurre et l’argent du beurre, parfois.

REPEATABLE READ.

Le but de REPEATABLE READ est de fournir un niveau d’isolation qui donne des résultats cohérents et justes, et qui évite les mises à jour perdues (lost updates). Je vais donner des exemples de ce que vous devez faire sous Oracle pour atteindre ce but, et étudier ce qu’il se passe dans les autres SGBD. Si vous êtes en niveau d’isolation REPEATABLE READ, le résultat d’une requête donnée doit être cohérente par rapport à un instant donné. La plupart des SGBD (mais pas Oracle) accomplissent cela en utilisant des verrous partagés en lecture, au niveau enregistrement (row-level shared read locks). Un verrou partagé en lecture empêche les autres session de modifier les données que vous avez lu. Bien sûr, cela diminue la capacité multi-utilisateur (concurrency). Le SGBD Oracle a choisi le système de multi-versionnage, meilleur pour la concurrence d’accès, pour fournir des résultats cohérents en lecture.

Avec le multi-versionnage d’Oracle, le résultat de la requête est cohérent par rapport à l’instant où la requête a démarré. Dans les autres SGBD, avec les verrous partagés en lecture, vous avez une réponse qui est cohérente par rapport à l’instant de fin de la requête, c’est à dire au moment où vous pouvez avoir le résultat complet (plus de détail là dessus un peu plus loin).

Dans un SGBD qui utilise les verrous partagés en lecture pour permettre les lectures répétables, vous verrez que les lignes des tables sont verrouillées au fur et à mesure que la requête les lit. Donc, en utilisant l’exemple précédant, je vais laisser des verrous partagés en lecture (shared read locks) sur chaque ligne, comme le montre le scénario suivant:

Avec ce scénario, j’ai maintenant le résultat correct, mais au prix d’avoir bloqué une transaction, et d’avoir dû exécuter les transactions, l’une après l’autre. C’est l’un des effets de bord des verrous partagés en lecture: ceux qui lisent bloquent ceux qui écrivent. Cela se rajoute au fait que, dans ces systèmes, ceux qui écrivent bloquent ceux qui lisent. Imaginez si les Guichet Automatiques Bancaires fonctionnaient comme çà.

Vous voyez donc comment les verrous partagés en lecture inhibent la concurrence d’accès, mais ils peuvent aussi être à l’origine de fausses erreurs. Dans le scénario suivant, je part de la table originale, mais cette fois dans le but de transférer 50€ du compte 987 vers le compte 123.

Et je suis arrivé dans la situation classique du verrou mortel (deadlock). Ma requête bloque des ressources dont l’update a besoin, et vice versa. Ma requête est en deadlock avec la transaction. Une des deux doit être choisie pour être tuée. J’ai attendu un long moment, et j’ai utilisé beaucoup de ressources, juste pour être en erreur et finir par un rollback. C’est le deuxième effet de bord des verrous partagés en lecture: ceux qui écrivent et ceux qui lisent peuvent être en deadlock, et c’est le cas assez souvent.

Comme on l’a vu, sous Oracle, vous avez une lecture cohérente au niveau de chaque requête sans que les lectures ne bloquent les écritures, ou ne fassent de deadlock. Le SGBD Oracle n’utilise jamais de verrous partagés en lecture au niveau des lignes. Oracle a choisi le système de multi-versionnage, plus difficile à implémenter, mais infiniment meilleur en capacité de concurrence d’accès.

SERIALIZABLE

C’est le niveau généralement considéré comme le plus restrictif, mais c’est celui qui fournit le plus haut degré d’isolation. Une transaction SERIALIZABLE opère dans un environnement qui lui apparaît comme si il n’y avait uncun autre utilisateur en train de modifier la base de données. Vous êtes garantis que chaque ligne que vous lisez sera la même si vous la relisez, et que chaque requête que vous exécutez aura le même résultat durant toute la vie de la transaction.

Si vous exécutez par exemple:

Les 2 réponses seront les mêmes, alors que vous avez attendu 24 heures (Mais vous pouvez aussi avoir une erreur ORA-1555, snapshot too old). Ce niveau d’isolation vous assure que les 2 requêtes retournent le même résultat. Votre requête ne voit pas les effets de bord, ni les mises à jour faites par les autres transactions, et ce quel que soit la durée de son exécution.

Sous Oracle, l’implémentation des transactions SERIALIZABLE est faite de telle sorte que la lecture cohérente que vous avez au niveau de la requête est étendue au niveau de la transaction. (Comme il est noté plus haut, il y a une niveau d’isolation sous Oracle qui est appelé READ ONLY. Il a toutes les caractéristiques de SERIALIZABLE, sauf qu’il empêche les mises à jour. Il faut noter aussi que le user SYS (ou les utilisateurs connectés en SYSDBA) ne peuvent pas faire des transactions READ ONLY ou SERIALIZABLE. SYS est spécial pour cela).

Au lieu que les résultats soient cohérents par rapport au début de la requête, ils sont déterminés par le début de la transaction. Autrement dit, Oracle va utiliser les rollback segments pour reconstruire les données telles qu’elles étaient avant que votre transaction ne commence (le début de la transaction au lieu du début de la requête). C’est une pensée assez profonde: la base connait par avance les réponses à toutes les questions que vous pouvez poser, avant que vous le les posiez.

Mais ce degré d’isolation a un prix, vous pouvez vous retrouver avec l’erreur suivante:

Vous aurez ce message à chaque fois que vous essaierez de mettre à jour une ligne qui a été modifiée depuis le début de votre transaction. (Notez que Oracle essaie de faire cela au niveau ligne, mais vous pouvez recevoir l’erreur ORA-08177 même si la ligne que vous voulez mettre à jour n’a pas été modifiée. Cette erreur peut arriver si une autre ligne du même bloc a changé)

Oracle choisit une approche optimiste de la sérialisation: il parie sur le fait que les données que vous voulez mettre à jour dans votre transaction ne seront pas modifiées par une autre transaction. C’est en principe le cas, et le pari est payant, surtout pour des transactions courtes, dans les systèmes transactionnels (OLTP). Si personne ne modifie vos données durant votre transaction, ce niveau d’isolation garde le même degré de concurrence que sans transactions SERIALIZABLE, alors que dans les autres SGBD, il diminue souvent la capacité en concurrence d’accès. Le revers de la médaille, c’est que vous pouvez avoir l’erreur ORA-08177 si le pari ne paie pas. Mais en y réfléchissant, c’est un risque qui vaut le coup d’être pris. Si vous utilisez le niveau SERIALIZABLE, vous ne devriez pas vous attendre à modifier les mêmes données que les autres transactions.

Si c’est le cas, alors vous devriez utiliser SELECT ... FOR UPDATE comme décrit dans le Chapitre 1 [de Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions]. Cela permet de sérialiser l’accès.

Donc vous pouvez utiliser le niveau d’isolation SERIALIZABLE si:

• il y a une forte probabilité que personne d’autre ne modifie les mêmes données que vous
• vous avez besoin de lecture cohérente au niveau de toute la transaction
• vous faites des transactions courtes (pour avoir plus de chance de vérifier le 1er point)

Mais, car il y a toujours un ‘mais’, vous devez comprendre ces différents niveaux d’isolation et leur conséquences. Souvenez-vous, avec le niveau SERIALIZABLE, vous ne verrez aucune modification faite dans la base depuis le début de votre transaction, jusqu’à ce que vous ne committiez. Les applications qui cherchent à vérifier leurs propres contraintes d’intégrité, comme le planificateur de ressources du chapitre 1 [de Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions], doivent faire très attention à cela. Dans le Chapitre 1 le problème était que vous ne pouviez pas vérifier vos contrainte d’intégrité dans un système multi-utilisateur, puisque vous ne pouvez pas voir les modifications faites par les sessions concurrentes, avant qu’elles ne soient committées. En SERIALIZABLE, vous ne verrez toujours pas les modifications non committées, mais vous ne verrez pas non plus les modifications committées depuis le début de votre transaction.

Et pour finir, soyez prévenus que SERIALIZABLE ne veut pas dire que toutes les transactions des utilisateurs vont se comporter comme si elles avaient été exécutées les une après les autres, séquentiellement. Le niveau d’isolation n’impose pas qu’il y ait une sorte d’ordonnancement pour arriver au résultat de SERIALIZABLE. Les phénomènes expliqués précédemment, décrits par le standard SQL, n’imposent pas cela. Ce dernier point est un concept qui est souvent mal compris, et une petite démonstration permet de l’éclaircir.
Le scénario suivant montre comment deux sessions se comportent au cours du temps. Les tables A et B sont vides au démarrage, créées par:

Et voici le scénario:

A la fin de ce scénario, les tables A et B ont chacune une ligne avec la valeur 0. S’il y avait eu un ordonnancement en série des transactions, je ne pourrais pas avoir 0 sur chaque table. Si la session 1 s’était exécutée avant la session 2, la table B aurait la valeur 1. Et dans le cas contraire, c’est la table A qui aurait eu la valeur 1. Mais ici, les deux tables ont la valeur zéro. Chaque transaction s’est exécutée comme si elle était la seule transaction s’exécutant à ce moment là dans la base. Quelle que soit le nombre de fois à la session 1 exécute sa requête, le résultat du count() est celui qui correspond aux données committées en base au moment t1. Même chose pour la session 2 où le résultat du count() sera toujours celui qui correspond aux données committées en base au moment t2.

Le livre en Anglais de Tom Kyte dont est extrait l’article original: Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions Apress (September 15, 2005) La seconde édition (mise à jour avec la 11g) va paraître bientôt.