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 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.

Cet article est la traduction d’une réponse Tom Kyte à des questions sur les fonctionnalités Objet-Relationnel d’Oracle
(L’article original en anglais se trouve sur AskTom ici).

Tom Kyte donne son avis sur l’utilisation de ces fonctionnalités (Tables Relationnelles, vues Objet-Relationnel, Tables Objet-Relationnel)

Question:

Bonjour Tom,

J’ai quelques questions sur les fonctionnalités Objet-Relationnel d’Oracle.

J’ai la structure suivante:

Mes questions sont les suivantes:
[…]

Réponse:

Je vous déconseille fortement de faire cela. Utilisez des tables relationnelles et créez des vues OR (Object-Relational) au dessus si vous le désirez, mais n’utilisez pas de tables imbriquées (nested tables), ni de tables de type objet. Il y a une surcharge énorme (overhead) pour pouvoir fournir cette syntaxe alléchante.

Une table imbriquée (nested table), par exemple, ajoute 16 octets supplémentaires à la fois sur la table parent et la table fille, avec une contrainte unique sur le parent pour cette colonne de type RAW, et vous force donc à créer un index sur la colonne RAW de la table fille (voir commentaire de Mohamed Houri ci-dessous). Et pourtant vous n’avez besoin de rien de tout ça.

Donc, faites un modèle relationnel approprié, et utilisez-le.

Je suis sûr 100% que vous voudrez un jour interroger la table des adresses, pour des requêtes du genre ‘trouver tous ceux qui vivent dans le pays XXX’. Si vous utilisez une nested table, vous n’avez plus de vraie table. Les modèles objet ont une portée excessivement réduite. Ils présentent un unique point de vue sur les données, et il y a toujours de nombreuses vues possibles sur les données.

Et pour faire une recherche genre ‘annuaire inversé’ à partir d’un numéro de téléphone ? Pas si facile avec un modèle Object-Relationnel, et pourtant banal avec un modèle relationnel approprié.

C’est donc un grande non-réponse à vos questions, mais il faut voir le côté positif: d’après moi, vous étiez en train de faire une grosse erreur.

Autre question:

…J’ai l’impression que que le modèles Orienté Objet et le modèle Relationnel ne se mélangent pas très bien…

Réponse:

Non, pas du tout. Au contraire.

Mais ce qui est très important, c’est que vous devez commencer par bâtir une bonne base relationnelle, et construire les vues orienté objet par dessus.

Je dis que les vues orientées objets sont de faibles portées (‘myopic’). Pourquoi ? Parce qu’elles ne sont focalisées que sur l’application et non pas sur les données.

La suite est sur une autre page de AskTom (ici) sur la comparaison entre le Relationnel et l’Orienté Objet.

Tout d’abord, sous Oracle, vous devez comparer le Relationnel avec l’Objet-Relationnel, et non pas avec l’Orienté Objet. Il y a des extensions objet au relationnel, mais ce n’est pas une base orientée objet.

Pour répondre à cette question, il faut regarder les données avec lesquelles vous travaillez. Disons que vous êtes en train de construire une application bancaire. Vous faites cette application pour le caissier qui s’occupe du client quand il rentre dans la banque. L’objet parfait pour cette application est ‘Client’, identifié par un nom ou un numéro de compte. Le client a tous les attributs d’un client de banque: un nom, une adresse, une liste de comptes avec tous les attributs des comptes, une liste des dernières opérations bancaires, etc. Un gros paquet de données qui représentent toutes les informations d’un client.
C’est parfait du point de vue du caissier. MAIS, à la fin de la journée, il y a quelqu’un qui a une vision complètement différente des données, et qui a besoin de compter le nombre d’opérations bancaires qu’il y a eu dans la journée, ou combien d’argent il y a dans la banque. Sa perspective sur les données est orientée sur les opérations et non sur les clients.
Dans ce cas, le modèle parfait est un modèle RELATIONNEL, avec éventuellement des vues spécifiques objet-relationnel. Vous avez besoin d’une table des comptes, qui est liée à une table des opérations et à une table des clients. Avec ça, celui qui veut compter les opérations est aussi satisfait que celui qui a une vue orienté client.

C’est cela la puissance du modèle relationnel: il est capable de donner des vues différentes sur les mêmes données. Pensez aux tables EMP et DEPT de scott/tiger. Il peut paraître censé de créer un type objet EMP, une nested table de type EMP, un objet DEPT avec un attribut nested table de EMP et enfin une table des types DEPT. Et maintenant, toutes les données de démo scott/tiger tiennent dans une table de 4 lignes.
Cela parait formidable. Mais le problème est que des gens vont poser les questions suivantes:

• Combien ai-je d’employés ?
• KING est là devant la porte, est-ce un employé ou pas ?
• Quelle est somme des salaires des comptables sur l’année dernière ?

etc.

Avec une vision des données orientée sur DEPT, on ne peut répondre facilement à aucune de ces questions.

Juste de quoi y réfléchir. Je n’ai jamais utilisé les concepts objet-relationnel comme un mécanisme de STOCKAGE. Je les ai beaucoup utilisé dans mes programmes PL/SQL. Je tend à rester sur des vraies tables et à utiliser des objets fréquemment dans le code.

Cet article est la traduction d’un article de Tom Kyte sur son blog (L’article original en anglais se trouve ici).
Lectures cohérentes et multi-versionnage, par Tom Kyte


Il est conseillé lire préalablement les premières partie:

• Ecritures cohérentes, par Tom Kyte (1ère partie)
• Ecritures cohérentes – observation d’un redémarrage (2ème partie)

La première chose qui vient à l’esprit, c’est que le trigger se déclenche deux fois. On avait une table avec une seule ligne, et un trigger BEFORE FOR EACH ROW qui se déclanche pour chaque ligne. Un a fait un update sur une seule ligne et le trigger s’est déclanché deux fois.

Vous devez penser aux conséquentes de cela. Si vous faites dans votre trigger quoi que ce soit qui ne soit pas transactionnel, vous pouvez avoir un problème assez sérieux.

Par exemple, imaginez un trigger qui envoie un e-mail avec dans le texte de l’e-mail quelque chose comme: « Voilà comment étaient les données, elles ont été mises à jour et voici la nouvelle valeur. » Si cet e-mail est envoyé directement à partir du trigger, en utilisant UTL_SMTP sous Oracle 9i ou UTL_MAIL depuis Oracle 10g, alors le destinataire va recevoir deux e-mails, dont un qui avertit d’une mise à jour qui n’a jamais eu lieu.

L’update restart a un impact dans tout ce que vous pouvez faire de non-transactionnel dans un trigger. Réflechissez aux consequences suivantes:

• Prenons un trigger qui maintient quelques variables globales PL/SQL, du genre le nombre de lignes traitées. Lorsque un update qui redémarre fait son rollback, les modifications faites sur les variables PL/SQL ne sont pas rollbackées, elles.
• Pratiquement toutes les fonctions qui commencent par UTL_ (UTL_FILE, UTL_HTTP, UTL_SMTP etc) doivent être vues comme sensibles à un redémarrage de requête. Lors du redémarrage, ULT_FILE ne va pas revenir sur ce qu’il a écrit dans le fichier.
• Un trigger qui fait partie d’une transaction autonome (autonomous transaction) doit être suspect. Lorsque la requête redémarre, la transaction autonome ne peut pas être rollbackée.

Toutes ces conséquence doivent être gérées avec attention, en prenant compte du fait qu’elles peuvent être déclenchées plus d’une fois par ligne, ou être déclenchées par une ligne qui n’est au final pas modifiée par la requête.

La deuxième raison pour laquelle vous devez prêter attention aux redémarrages potentiels est une raison de performance. Dans notre exemple, nous avons utilisé une table avec une seule ligne. Mais qu’arrive-t-il si vous lancez un update de toute une table et qu’il redémarre après avoir mis à jour les 100000 premiers enregistrements ? Il va faire un rollback des 100000 modifications, redémarrer en mode SELECT FOR UPDATE, puis refaire à nouveau les 100000 modifications.

Vous pourriez remarquer une dégradation des performance au delà de ce que vous attendiez, après avoir mis un simple trigger qui trace toutes les mises à jour à l’aide de :old et :new. Et ce serait parce vous avez des requête qui redémarrent alors que ce n’était pas le cas avant. Ou bien l’ajout d’un tout petit programme qui fait un update d’une seule une ligne, et qui fait qu’un batch se met à durer des heures à cause d’un restart qui n’avait pas lieu avant.

Ce n’est pas une nouvelle fonctionnalité d’Oracle. Çà existe depuis la version 4.0, lorsque la lecture cohérente (read consistency a été introduite. Je n’étais moi-même pas au courant de cela avant l’été 2003, et lorsque j’ai découvert les conséquences, j’ai pu amener des réponses a des questions que je m’étais posé dans le passé.
Çà m’a fait jurer de renoncer presque complètement au transactions autonomes dans les triggers, et à repenser la manière dont j’avais implémenté certaines de mes applications. Par exemple, je ne vais jamais envoyer un e-mail directement à partir d’un trigger, mais plutôt utiliser DBMS_JOB qui va l’envoyer après que ma transaction soit commitée. Cela rend transactionnel l’envoi d’e-mail car si la requête qui a déclanché le trigger doit être redémarrée, alors le rollback va aussi annuler la soumission du job par DBMS_JOB.
J’ai modifié tout ce qui n’était pas transactionnel dans les triggers pour le faire dans un job, afin de le rendre transactionnellement cohérent.

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.

Cet article est la traduction d’un article de Tom Kyte sur son blog (L’article original en anglais se trouve ici).


Il est conseillé lire préalablement la première partie:

• Ecritures cohérentes, par Tom Kyte (1ère partie)

Voir un redémarrage d’une requête update est plus plus facile qu’on ne pense.
En fait, nous allons même en voir un avec une simple table d’une seule ligne.

Voici la table que nous allons utiliser pour notre test:

Pour observer le restart, nous avons juste besoin d’un trigger qui va afficher des informations. Nous allons utiliser un trigger BEFORE UPDATE FOR EACH ROW qui va simplement afficher l’ancienne et la nouvelle valeur de la ligne lors d’un update.

ops$tkyte@ORA10G> create or replace trigger t_bufer
  2  before update on t for each row
  3  begin
  4          dbms_output.put_line
  5          ( 'old.x = ' || :old.x ||
  6            ', old.y = ' || :old.y );
  7          dbms_output.put_line
  8          ( 'new.x = ' || :new.x ||
  9            ', new.y = ' || :new.y );
10  end;
11  /
Trigger created.

Et maintenant nous faisons un update sur la ligne:

jusqu’ici, tout ce passe comme on s’y attend: le trigger s’est déclenché une fois, et nous voyons les anciennes et nouvelles valeurs. Remarquez que nous n’avons pas encore fait de commit, la ligne est toujours vérouillée. Dans une autre session, nous allons faire l’update suivant:

La requête se bloque tout de suite, évidemment, puisque la première session a verrouillé la ligne. Si nous retournons dans la première session, pour faire un commit, voici ce qu’affiche la deuxième session (j’ai remis l’update pour que ça soit plus clair)

ops$tkyte@ORA10G> update t set x = x+1 where x > 0;
old.x = 1, old.y = 1
new.x = 2, new.y = 1
old.x = 2, old.y = 1
new.x = 3, new.y = 1
1 row updated.

Comme vous pouvez le voir, le trigger a vu deux version de la ligne ici. Le trigger sur la ligne s’est déclenché deux fois:

• Une première fois avec la version d’origine de la ligne, et les nouvelles valeurs calculées par l’update
• et une deuxième fois avec la version finale de la ligne telle qu’elle a réellement été modifiée.

Du fait que c’est un trigger BEFORE FOR EACH ROW, Oracle a vu la version cohérente (read-consistent) de notre ligne et la mise à jour que nous souhaitons y faire. Mais c’est après le déclenchement du trigger BEFORE FOR EACH ROW qu’ Oracle a récupéré le block en mode courant (current mode) pour y faire la mise à jour. Oracle doit attendre la fin du déclenchement du trigger parce que le trigger peut modifier les valeurs :new. Donc, Oracle ne peut modifier le bloc qu’une fois que le trigger ait fini de s’exécuter, et cela peut prendre du temps. Vu qu’un bloc ne peut être pris en mode courant que par une seule session à la fois, Oracle doit limiter le temps passé dans ce mode.

Donc après que le trigger se soit exécuté, Oracle prends le bloc en mode courant et s’aperçoit que la colonne X, qui a été utilisée pour trouver la ligne, n’a plus la même valeur. Et comme X, qui a été utilisé pour trouver cette ligne, a été modifiée, alors la base de données décide de redémarrer notre requête.

Notez que le fait que la valeur de X soit passée de 1 à 2 ne fait pas sortir la ligne du périmètre de la requête. Elle va quand même être touchée par notre update. C’est plutôt le fait que X ait été utilisé pour trouver la ligne, et que la valeur en lecture cohérente (ici 1) soit différente de la valeur en lecture courante (ici 2). Et ensuite, lors du restart, le trigger voit la valeur X=2 (qui vient de la modification faite par l’autre session) comme valeur de :old et la valeur X=3 pour :new

Donc cela prouve qu’un update restart a eu lieu. Il a fallu un trigger pour le voir, sinon ils sont en généralement indétectables. Cela ne veut pas dire qu’on ne peut pas voir d’autres symptômes, comme un gros update qui doit faire un rollback de toutes les modifications effectuées lorsqu’il a découvert qu’une ligne provoqué le restart. Cela veut juste dire qu’il est très difficile de pouvoir affirmer que ce type de symptôme vient du restart.

Il y a une autre chose intéressante, c’est que les triggers eux-mêmes peuvent être la cause d’un restart, même si la requête en elle-même ne le demande pas. Normalement, c’est les colonnes qui sont utilisées dans la clause WHERE d’un UPDATE ou DELETE qui sont utilisées pour déterminer si les modifications nécessitent un redémarrage de la requête. Oracle va faire une lecture en consistent read et lorsqu’il prends le bloc en current mode, il va redémarrer la requête si l’une de ces colonnes a été modifiée. Normalement, les autres colonnes ne sont pas comparées. Par exemple, si nous ré-exécutons la l’exemple précédant en mettant WHERE Y>0 pour trouver la ligne au lieu de X>0 :

On peut se demander pourquoi Oracle encore déclenché le trigger deux fois alors qu’il regardait la valeur de Y. Et on pourrait même croire que toutes les colonnes de la ligne sont examinées. Comme on peut le voir, ici on a eu un update restart alors qu’on filtrait les lignes avec Y>0 et qu’on a jamais modifié Y.

Mais si on recrée le trigger en affichant juste un message ‘fired‘ pour dire qu’il a été déclanché, sans faire référence à :new et :old

et que l’on va à nouveau dans la deuxième session pour exécuter l’update, on voit qu’il bloque, bien sûr. Et après avoir fait le commit sur la première session, la deuxième session se débloque et voici ce qu’elle affiche:

Le trigger ne s’est déclenché qu’une seule fois, pas deux.

Cela montre que les valeurs des colonnes référencées par :new et :old dans le trigger sont aussi utilisées par Oracle pour vérifier s’il faut faire un restart.
Lorsque le trigger référencait :new.X et :old.X alors les valeurs cohérentes et courantes de X ont été comparées. Et cela a entraîner un restart. Mais lorsqu’on a enlevé ces références, le restart n’a plus eu lieu.

La règle est que c’est l’ensemble des colonnes utilisées dans la clause WHERE, plus les colonnes référencées dans les triggers ligne (row trigger) qui sont comparées. La version cohérente et la version courante de la ligne vont être comparées, et si une de ces colonnes a changé, alors la requête va redémarrer.

A noter que cela peut aider à comprendre pourquoi un trigger AFTER FOR EACH ROW est plus performant qu’un trigger BEFORE FOR EACH ROW. Le trigger AFTER n’a pas les memes conséquences. Ce qui nous amène à la question ‘En quoi est-ce que ce comportement interne nous concerne ?’.

A suivre…

La troisième partie sera traduite prochainement:

• Ecritures cohérentes – conséquences pour le développeur, par Tom Kyte

Cet article est la traduction d’un article de Tom Kyte sur son blog (L’article original en anglais se trouve ici). L’article est en 3 parties (il s’agit ici de la partie 1) et il est extrait de son livre Expert Oracle Database Architecture.

Il peut être utile de (re)lire avant:

• Lectures cohérentes et multi-versionnage, par Tom Kyte
• Statistiques ‘db block gets’ et ‘consistent gets’, par Jonathan Lewis

Nous avons étudié précédemment (en français ici) la lecture cohérente: la capacité d’Oracle à utiliser les informations d’undo pour fournir des requêtes non-bloquantes et cohérentes (c’est à dire correctes) pour une lecture. Nous savons que lorsque Oracle lit des blocs pour notre requête, dans le buffer cache, il s’assure que la version du bloc est assez ‘vieille’ pour que notre requête puisse le voir.

Mais cela soulève la question suivante: Qu’en est-il des écritures/modifications ? Qu’est-ce qui se passe lorsque vous exécutez l’instruction UPDATE suivante: UPDATE T SET X = 2 WHERE Y = 5;
et que, pendant que cette requête est en cours d’exécution, quelqu’un modifie une ligne en faisant passer la valeur de Y de 5 vers 6, et commite cette modification, avant que nôtre requête n’ait lu cette ligne ?

Autrement dit, lorsque votre mise à jour a commencé, certaines lignes ont Y=5. Et comme votre mise à jour fait des lectures cohérentes, elle voit pour cette ligne Y=5, puisque c’est la valeur qu’il y avait au moment où votre update a démarré. Cependant, la valeur actuelle de Y est maintenant 6, et non plus 5, et avant de mettre à jour la valeur de X, Oracle va vérifier si la valeur de Y est toujours 5. Maintenant que doit-il se passer ? Et comment cela impacte les update ?

De toute évidence, nous ne pouvons pas modifier une ancienne version d’un bloc: quand on va modifier une ligne, il faut modifier la version actuelle du bloc. En outre, Oracle ne peut pas simplement ignorer cette ligne, car ce serait une lecture incohérente et imprévisible. Ce que nous allons découvrir, c’est que dans ce cas, Oracle va redémarrer à zéro l’écriture des modification.

Lectures cohérentes (Consistent Reads) et lectures courantes (Current Reads)

Oracle peut faire 2 types de lectures de blocs (block gets) lorsqu’il execute un requête de mise à jour (voir aussi cette traduction de Jonathan Lewis). Il fait:

• Des lectures cohérentes (Consistent reads): pour ‘chercher’ les lignes à modifier
• Des lectures courantes (Current reads): pour prendre le bloc dans lequel il y a les lignes à modifier.

On peut voir cela facilement avec TKPROF. Considerons le petit exemple suivant, qui lit et modifie l’unique ligne de la table T qu’on a déjà vu:

ORA10GR1> alter session set sql_trace=true;
Session altered.

ops$tkyte@ORA10GR1> select * from t;

X
----------
10001

ops$tkyte@ORA10G> update t t1 set x = x+1;
1 row updated.

ops$tkyte@ORA10G> update t t2 set x = x+1;
1 row updated.

TKPROF donne le résultat suivant (j’ai supprimé les colonnes ELAPSED, CPU, and DISK):

select * from t

call    count query current rows
------- ----- ----- ------- ----
Parse       1     0       0    0
Execute     1     0       0    0
Fetch       2     3       0    1
------- ----- ----- ------- ----
total       4     3       0    1

update t t1 set x = x+1

call    count query current rows
------- ----- ----- ------- ----
Parse       1     0       0    0
Execute     1     3       3    1
Fetch       0     0       0    0
------- ----- ----- ------- ----
total       2     3       3    1

update t t2 set x = x+1

call    count query current rows
------- ----- ----- ------- ----
Parse       1     0       0    0
Execute     1     3       1    1
Fetch       0     0       0    0
------- ----- ----- ------- ----
total       2     3       1    1

Ainsi, pour un select normal, nous avons 3 lectures cohérentes (query ou consistent gets). Pour le premier UPDATE, nous avons les 3 mêmes lectures (car ici la partie de recherche des lignes doit trouver toutes les lignes qui sont dans la table au moment où la requête démarre), mais aussi 3 lectures courantes.
Les 3 lectures en mode courant (current mode gets) servent

1. à accéder au bloc courant, tel qu’il existe actuellement, celui avec la ligne à modifier
2. à accéder à un bloc de segment d’undo pour commencer notre transaction (l’enregistrer dans la table des transactions)
3. à accéder à un bloc d’undo (pour écrire les informations d’undo)

Le deuximème UPDATE ne fait qu’une lecture en mode courant, car nous n’avons pas à répeter le travail pour les blocs d’undo. Il n’y a que le bloc avec la ligne à mettre à jour. La présence du current get nous indique qu’une modification, de quelque sorte qu’elle soit, a eu lieu. Avant de modifier un bloc avec une nouvelle donnée, il doit avoir sa version la plus récente.

Alors comment la lecture cohérente peut affecter une mise à jour ? Bien, imaginons maintenant l’UPDATE suivant:

Nous savons que la clause WHERE Y=5 , qui est la partie qui doit être cohérente en lecture, va être faite en mode cohérent (consistent, ou query dans TKPROF). Les enregistrements que voit la requête sont ceux qui ont la valeur Y=5, commitée, au moment où la requête démarre (en supposant qu’on est en niveau d’isolation READ COMMITTED sinon, en SERIALIZABLE, ce seraient ceux qui ont la valeur Y=5, commitée, au moment où la transaction démarre). Cela signifie que si la requête dure 5 minutes, du début à la fin, et qu’entre temps quelqu’un insère et commite un nouvel enregistrement qui a la valeur Y=5, alors notre UPDATE ne verra pas cet enregistrement parce que la lecture cohérente ne le lira pas. C’est le comportement attendu et normal. Mais la question qui se pose est maintenant: que se passe-t-il si deux sessions exécutent les requêtes suivantes, dans l’ordre::

Voici ce qu’il se passe en sequence:

1. Session 1: Update t set y = 10 where y = 5;
   mise à jour de la ligne qui correspond au critère.
2. Session 2: Update t Set x = x+1 Where y = 5;
   Du fait de la lecture cohérente, la ligne modifiée par la session 1 correspond au critère (la session 1 n’a pas encore commité) mais ne peut pas la mettre à jour car elle est vérouillée par la session 1. La session 2 est bloquée et attends.
3. Session 1: Commit;
   Cela libère le verrou sur lequel attends la session 2, qui se débloque.
   Elle peut alors faire la lecture courante du bloc qui contient l’enregistrement pour lequel Y=5 au moment où la requête a démarré.

Mais voilà que l’enregistrement qui avait Y=5 au moment du démarrage de l’UPDATE n’a plus la valeur Y=5. La lecture cohérente nous dit qu’il faut mettre à jour cette ligne parce que Y=5 au moment où la requête a démarrée. Mais la version courante du bloc nous dit que non, ce serait une erreur, on ne peut pas mettre à jour cette ligne puisque maintenant Y n’est plus égal à 5.

Si nous décidions juste de passer cette ligne et de l’ignorer, alors l’UPDATE ne serait pas deterministe. Ce serait jeter à la poubelle la cohérence et l’intégrité des données. Le résultat de l’UPDATE (combien de lignes et lesquelles sont modifiées) dépendrait de l’ordre dans lequel on traite les lignes de la table, et des autres activités qu’il y a autour. Vous pourriez prendre le même jeu de données dans 2 bases différentes, chacune exécutant les mêmes transactions dans le même ordre, et vous auriez des résultats différentes, simplement parce que les enregistrements sont placés différemment sur le disque.

Alors dans cette situation, Oracle choisit de redémarrer l’UPDATE. Lorsque il voit que la ligne qui avait Y=5 au début de la requête a maintenant la valeur Y=10, alors Oracle, si on est en niveau d’isolation READ COMMITTED, va silencieusement faire un rollback des modifications faites et redémarrer l’UPDATE. En niveau d’isolation SERIALIZABLE, alors on aurait un message d’erreur ORA-08177 Impossible de sérialiser l'accès pour cette transaction. (can’t serialize access for this transaction). En READ COMMITTED, après avoir rollbacké les modifications, Oracle va relancer l’update (donc le moment du démarrage de la requête, pour la lecture cohérente, n’est plus le même). Mais cette fois il va faire un SELECT FOR UPDATE en essayant de verrouiller toutes les lignes pour lesquelles Y=5. Une fois que c’est fait, il va faire l’UPDATE sur ces lignes qui sont verrouillées par notre session, étant sûr maintenant de pouvoir terminer sans avoir à redémarrer.

Continuons avec les questions ‘que se passe-t-il ?’. Le SELECT FOR UPDATE utilise les mêmes lectures cohérentes (pour trouver les enregistrements) et lectures courantes (pour les verrouiller) que l’UPDATE. Alors que se passe-t-il si une ligne qui avait Y=5 au démarrage de notre update se trouve avoir maintenant la valeur Y=11 ? Alors le SELECT FOR UPDATE va lui aussi redémarrer.

Il ya deux questions qui seront abordées ici, deux questions qui m’ont beaucoup intéressé, de toute façon. La première était: Peut-on observer cela ? Peut-on s’en apercevoir lorsque çà arrive ?
Et la deuxième: Et alors ? En quoi suis-je concerné en tant que développeur ?

Nous traiterons ces questions chacune à leur tour.
A suivre…

Les 2 articles correspondants seront traduits prochainement:

• Ecritures cohérentes – observation d’un redémarrage, par Tom Kyte
• Ecritures cohérentes – conséquences pour le développeur, par Tom Kyte

Cet article est la traduction d’une réponse Tom Kyte à une question sur le paramétrage idéal de PCTFREE, PCTUSED et INITRANS (L’article original en anglais se trouve ici).

PCTFREE

Si vous avez une table qui ne subit que des inserts, mettez PCTFREE à 0, parce que vous n’avez rien à réserver pour les updates.

si vous savez une table dont les lignes doublent de taille, c’est une bonne idée de mettre PCTFREE à 50, pour réserver de la place pour les updates.

Vous devez comprendre comment les données grossissent dans le temps. Si vous faites des inserts, puis sur 10% de ces lignes vous faites des updates qui augmentent leur taille de 20%, alors vous devez:

• savoir combien de lignes par bloc vous avez en moyenne
• calculer ce que les 20% d’une ligne représentent en pourcentage de bloc.
• utiliser ce pourcentage de bloc comme PCTFREE

PCTUSED

Et utilisez ASSM (automatic segment space management), la gestion automatique de l’espace libre des segments, et vous n’avez pas à vous soucier de PCTUSED, FREELISTS, FREELIST GROUPS.

INITRANS

Pour INITRANS, vous devez vous baser sur le nombre maximum de modifications concurrentes qu’il peut y avoir sur un bloc. Si vous avez une table qui ne reçoit que des inserts, et que vous êtes en ASSM, ne vous inquiétez pas et laissez la valeur par défaut. Si vous avez plutôt une petite table que vous updatez comme un fou, alors vous devez y réfléchir.

Question supplémentaire sur PCTFREE

Je ne comprends pas bien la raison du nombre de ligne par bloc ici. Je pensais que si 10% des lignes augmentent de 20% alors – en moyenne – l’espace utilisé dans le bloc augment de 2%.

Réponse:

2% d’un bloc n’est pas vraiment de sens ici. Vous devez comprendre combien de lignes par bloc vous pouvez avoir. Par exemple, je peux avoir 7 lignes de 1024 octets, dans un bloc de 8k. Si je dois en updater 10% pour qu’elles soient 20% plus larges, ce n’est pas les 2% qui comptent, mais le calcul suivant:

• Environ 1 ligne par bloc va augmenter
• Si elle s’accroît de 20%, je ne peut avoir que 6 lignes par bloc
• Je ferais mieux de mettre un PCTFREE qui fait qu’il n’y aura que 6 lignes en moyenne.

2% serait trompeur, car la granularité des lignes est assez « large »

Une précision: Ces explications concernent les tables (heap tables) mais pas les index (ni les Index Organized tables)
Un index a une gestion différente de l’espace libre: chaque ligne y a sa place, puisqu’il est trié: un bloc n’a pas le choix d’accepter des lignes ou non. Les blocs sont remplis jusqu’au bout, et lorsque ils sont pleins à 100%, ils peuvent être coupés (split) en deux blocs qui auront chacun leur part d’espace libre.
Ce qui veut dire que pour les index, PCTUSED n’a pas de sens, PCTFREE ne concerne que l’espace libre laissé à la création de l’index (ou au rebuild ou coalsece) pour qu’il n’y ait pas trop de block splits dès les premières mises à jour. INITRANS est ignoré, il suffit qu’il y ait toujours une entrée possible pour la transaction qui aura à faire le bloc split et on pourra toujours faire de la place. Au fur et à mesure des mises à jour, l’index s’ajustera en fonction du besoin d’espace libre et d’entrées ITL.

Cet article est la traduction d’une réponse Tom Kyte à une question sur les vues cohérentes (L’article original en anglais se trouve ici).

Question:

J’ai lu qu’Oracle garantit une vue cohérente en lecture. Je l’ai lu, mais je n’ai pas l’impression que c’est très clair.
Pouvez-vous expliquer, avec vos mots, ce qu’est une vue cohérente ?

Réponse:

J’ai fais cela dans « Expert One on One Oracle« .
J’ai écrit beaucoup là dessus et voici un court extrait (il y a beaucoup plus dans le livre).

Extrait de ‘Expert One on One Oracle’ de Tomas Kyte – Apress

Multi-Versionnage et Concurrence

Le Multi-versionnage (multiversioning) est un sujet lié au contrôle de concurrence d’accès aux données, car qu’il est à la base de ce mécanisme: Oracle implémente la concurrence d’accès en faisant des lecture multi-versions cohérentes (multi-version read consistent concurrency model). Dans le chapitre suivant ‘Ce que vous devez savoir’, nous allons parler des aspects techniques de manière plus détaillée, mais dans l’essentiel, il s’agit du mécanisme fourni par Oracle pour:

• faire des lectures cohérentes (Read-consistent queries): les requêtes donnent un résultat cohérent à un instant donné.
• Requêtes non bloquantes (Non-blocking queries): les requêtes en lecture ne sont jamais bloquées par les écritures, contrairement à ce qui se passe avec d’autres SGBD.

Oracle utilise l’information des rollback segments (ou undo) pour fournir une vue cohérente sur les données. Les rollback segments étant l’endroit où Oracle stocke les anciennes valeurs (ou ‘image avant’) des données lors de l’exécution des transactions, il peut utiliser ces anciennes valeurs pour fournir à la requête les données telles qu’elles étaient en base au moment où la requête a été lancée. Au fur et à mesure que la requête lit les blocs de données de la table, elle voit si le bloc a été modifié depuis l’instant où la requête a commencé. Et si le bloc a été modifié, Oracle va aller lire les rollback segments pour retrouver à quoi ressemblait le bloc au moment où la requête a commencé. C’est cette version que la requête va voir.

C’est aussi de cette manière que les lectures non bloquantes (non blocking reads) sont implémentées. Oracle va seulement regarder si les données ont été modifiées, il n’a pas besoin de savoir si elles sont verrouillées (ce qui implique qu’elles ont été modifiées). Il va simplement ramener les anciennes valeurs grâce aux rollback segments et passer au bloc de données suivant.

C’est là qu’intervient le terme multi-versionnage (multiversioning): chaque information a plusieurs versions en base de données, chacune correspondant à un instant donné. Ces versions multiples sont fournies par l’undo des rollback segments. Oracle est capable d’utiliser ces ‘photos’ des données correspondant à différents instants (appelées snapshot comme dans le message d’erreur ‘ORA-15555 snapshot too old’), pour nous donner une version cohérente avec des lectures non bloquantes.

Ce sont deux concepts très importants pour le SGBD Oracle. Si vous comprenez comment le multi-versionnage fonctionne, vous comprendrez toujours les réponses que vous obtiendrez de la base de données.
Voici le moyen le plus simple que je connaisse pour démontrer le multi-versionnage sous Oracle:

tkyte@TKYTE816> create table t 

  2  as 

  3  select * from all_users; 

Table created. 

 

tkyte@TKYTE816> variable x refcursor 

 

tkyte@TKYTE816> begin 

  2          open :x for select * from t; 

  3  end; 

  4  / 

PL/SQL procedure successfully completed. 

 

tkyte@TKYTE816> delete from t; 

18 rows deleted. 

 

tkyte@TKYTE816> commit; 

Commit complete. 

 

tkyte@TKYTE816> print x 

 

USERNAME                          USER_ID CREATED 

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

SYS                                     0 04-NOV-00 

SYSTEM                                  5 04-NOV-00 

DBSNMP                                 16 04-NOV-00 

AURORA$ORB$UNAUTHENTICATED             24 04-NOV-00 

ORDSYS                                 25 04-NOV-00 

ORDPLUGINS                             26 04-NOV-00 

MDSYS                                  27 04-NOV-00 

CTXSYS                                 30 04-NOV-00 

... 

DEMO                                   57 07-FEB-01 

 

18 rows selected.

Dans cet exemple, nous avons créé une table de test, T, et avons chargé quelques données à partir de la vue ALL_USERS.

Nous avons ouvert un curseur sur cette table. Nous n’avons fetché aucune donnée de ce curseur: nous l’avons seulement ouvert. Gardez en tête que Oracle ne ‘réponds’ pas à la requête, ne copie pas les données quelque part lorsque vous ouvrez le curseur. Il réponds à la requête plus tard.
Mettons que la table T ait 1 milliard d’enregistrements, Oracle ne va pas ‘répondre’ à la requête et copier les données quelque part. Il va seulement les lire au fur et à mesure que l’on va faire les fetch.

Maintenant, dans la même session (mais cela pourrait être fait d’une autre session), nous supprimons toutes les données de cette table. Nous allons même jusqu’à commiter cette transaction.

Les enregistrement sont partis, mais est-ce vraiment le cas ?

Le fait est que le résultat retourné par la commande OPEN a été pré-établi au moment où nous avons ouvert le curseur. Nous n’avions pas encore touché à un seul bloc de données de cette table durant l’OPEN, mais le résultat de la requête était déjà déterminé. Nous n’avons aucun moyen de connaître le résultat avant de faire les FETCH, mais ce résultat est pourtant immuable du point de vue du curseur.

Oracle n’a pas fait une copie des données lorsque nous avons ouvert le curseur. Imaginez le temps que cela prendrait d’ouvrir un curseur sur un milliard d’enregistrements si c’était le cas. Au contraire, le curseur s’ouvre instantanément – il ne copie pas les données. C’est en fait le delete qui garde les données pour nous (oui, le delete préserve les données pour nous) en les mettant dans les rollback segment.

Voilà ce qu’est la lecture cohérente. Oracle permet des lectures cohérentes grâce au mécanisme de multi-versionnage. Dans le chapitre suivant ‘Ce que vous devez savoir’, nous allons parler des aspects techniques de manière plus détaillée. Il faut noter cependant que jusqu’à ce que vous ne compreniez ce que cette fonctionalité implique, vous ne serez pas capable de profiter à fond d’Oracle, ni d’écrire des applications correctes (c’est à dire qui assurent l’intégrité des données).

fin de l’extrait

La documentation Oracle Concept Guide explique aussi cela très bien.

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)