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

Merci à Mohamed Houri qui m’a aidé pour cette traduction.

L’article précédent Undo et Redo et Recovery en quelques mots nous montre que l’information undo est contenue dans le redo en tant que change vector pour les blocks d’undo. On peut donc se demander pourquoi Oracle a introduit les tablespaces d’undo (aussi connues comme tablespace des rollback segments) pour implémenter la lecture consistante, au lieu d’utiliser seulement les redo pour retrouver une image passée des données.

Un post sur le forum OTN pose la question suivante: Puisque le redo contient à la fois l’information passée et l’information courante, pourquoi donc Oracle n’utilise pas les redo logs pour récupérer cette information ? Pourquoi avoir besoin de l’undo alors que le redo a déjà cette information ?

Ce fil de discussion a généré des réponses intéréssantes, mais las plupart de ces réponses expliquent comment l’undo et le redo fonctionnent, plutôt que d’expliquer pourquoi les architectes d’Oracle Corp. ont choisi d’implémenter l’undo et le redo tel qu’ils l’ont fait. Comme je suis assis dans un aéroport (Zurich) à attendre un avion, je vais utiliser ce temps pour partager mon opinion sur le pourquoi.

Le redo est là pour deux raisons: pour la récupération des données en cas de panne (recoverability), et pour optimiser les performances (efficiency).
Si l’on journalise chaque modification que l’on fait sur la base de données, alors on peut toujours restaurer une ancienne copie de la base et réappliquer le journal des modifications pour amener la base de données à l’état courant. C’est la récupération en cas de panne.
Maintenant, si nous faisons en sorte que ces journaux soient le premier point de protection des modifications de nos données, alors on n’a plus besoin d’écrire sur disque chaque bloc de données au moment où on le modifie, mais seulement un faible volume d’information. C’est là qu’est l’optimisation. (Cependant, le fait de regrouper toutes les modifications dans un petit volume rends les I/O plus performants, mais on introduit aussi un point de contention vu que l’on concentre une grande activité sur un petit volume).

L’undo (d’une manière ou d’une autre) doit exister si l’on veut faire des lectures consistentes (read consistency). Personne n’est autorisé à voir les modifications de nos données tant que nous ne les avons pas comittées. Et mêmes commitées, nos modifications ne doivent pas être visibles des requêtes qui ont commencé avant notre commit. Il faut donc garder l’ancienne version des données quelque part. C’est où les choses deviennent moins intuitives, mais par contre très ingénieuses avec Oracle.

Observez l’enregistrement de redo (redo record) suivant. C’est un enregistrement de redo généré au milieu d’une transaction, et il représente le redo généré par Oracle lorsqu’on a modifié la quatrième colonne d’une ligne dans une table, de la valeur de 42 à la valeur 43.

REDO RECORD - Thread:1 RBA: 0x000056.00000028.0014 LEN: 0x0128 VLD: 0x01
SCN: 0x0000.0028efae SUBSCN: 3 02/09/2010 14:59:40
CHANGE #1 TYP:0 CLS:20 AFN:2 DBA:0x0080065f OBJ:4294967295 SCN:0x0000.0028efae SEQ: 24 OP:5.1
ktudb redo: siz: 112 spc: 5414 flg: 0x0022 seq: 0x0112 rec: 0x19
  xid: 0x0002.028.000009af
ktubu redo: slt: 40 rci: 24 opc: 11.1 objn: 49428 objd: 49428 tsn: 5
Undo type:  Regular undo       Undo type:  Last buffer split:  No
Tablespace Undo: No
             0x00000000
KDO undo record:
KTB Redo
op: 0x02  ver: 0x01
op: C uba: 0x0080065f.0112.18
Array Update of 1 rows:
tabn: 0 slot: 41(0x29) flag: 0x2c lock: 0 ckix: 11     <----- ligne 42 du bloc (slot indexé à partir de 0)
ncol: 4 nnew: 1 size: 0
KDO Op code:  21 row dependencies Disabled
  xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x0180000a hdba: 0x01800009
itli: 2 ispac: 0 maxfr: 4863
vect = 9
col 3: [ 2] c1 2b     <----- la 4ème colonne revient à la valeur 42 (hexa:2b) (col indexée à partir de 0) 

CHANGE #2 TYP:0 CLS: 1 AFN:6 DBA:0x0180000a OBJ:49428 SCN:0x0000.0028efae SEQ: 41 OP:11.19
KTB Redo
op: 0x02  ver: 0x01
op: C  uba: 0x0080065f.0112.19
Array Update of 1 rows:
tabn: 0 slot: 41(0x29) flag: 0x2c lock: 2 ckix: 11     <----- ligne 42 du bloc
ncol: 4 nnew: 1 size: 0
KDO Op code:  21 row dependencies Disabled
  xtype: XAxtype KDO_KDOM2 flags: 0x00000080  bdba: 0x0180000a  hdba: 0x01800009
itli: 2  ispac: 0  maxfr: 4863
vect = 9
col 3: [ 2] c1 2c     <----- la 4ème colonne prends à la valeur 43 (hexa:2c)

Vous pouvez constater que cet enregistrement de redo comprend deux modifications (les change vectors CHANGE #1 and CHANGE #2) et j’ai annoté les deux lignes qui montrent que la valeur a été modifiée de 42 à 43. En principe, les redo logs d’Oracle contiennent effectivement l’information nécessaire à la génération de l’ancienne version des données. Alors, pourquoi Oracle a introduit les tablespaces d’undo pour la lecture consistente alors que les redo logs semblent avoir toute l’information nécessaire ?

Pour répondre à cette question, nous devons raisonner ‘multi-user‘. C’est très facile d’oublier qu’Oracle est un système multi-utilisateur, lorsqu’on essaie de comprendre certaines fonctionnalités. Mais si on ignore ce fait, on oublie de réfléchir à ce qui se passe du point de vue des autres sessions, et on oublie aussi de réfléchir sur leur impact.

1er point: Je suis en train d’exécuter une très longue transaction, et de nombreuses autres sessions exécutent des petites requêtes et des transactions très courtes. Les autres sessions doivent voir les données telles qu’elles étaient avant que je ne les aie modifiées. Si elles devaient lire le redo pour accéder à ces données, les fichiers redo logs devraient alors pouvoir atteindre la taille nécessaire pour contenir toute l’information de journalisation des modifications (nouvelles et anciennes valeurs) de toutes les sessions pour toutes les transactions qui se sont exécutées depuis que j’ai démarré ma transaction. Qe doit-on faire lorsque les fichier redo log sont pleins ?

2ème point: Si ma longue transaction se plante et doit faire un rollback, alors les informations des anciennes valeurs seront mélangées avec tous les changements (anciennes et nouvelles valeurs) que tout le monde a faits depuis que j’ai démarré ma transaction, et ma session va alors probablement devoir faire un grand nombre d’I/O aléatoires pour trouver les modifications antérieures. Bien sûr, on peut rendre cette tâche plus efficace (et aussi améliorer le point 1) en faisant en sorte que chaque transaction écrive son propre journal dans son propre fichier de redo. Mais cela rendrait plus complexe la gestion de fichiers (ouvrir et fermer des fichiers à chaque début et fin de transaction), ainsi que la récupération en cas de panne car il faut appliquer les redo dans le bon ordre.

3ème point: Oracle ne nettoie pas chaque bloc modifié lorsq’une transaction commite. Si je commite une transaction mais je ne nettoie pas le bloc X, comment la prochaine session qui va voir ce block saura que ma transaction a commité et quand est ce qu’elle a commité ? Si nous n’avions utilisé que les redo logs la prochaine session aurait du aller voir l’endroit du redo log où on a journalisé la modification du bloc X, et avancer jusqu’à ce qu’elle trouve la journalisation du commit (ou aller jusqu’à la fin du redo, ou trouver le SCN correspondant dans le redo et ainsi, en déduire que ma transaction n’a pas commitée ou n’a pas commité à temps). Mais alors, chaque enregistrement redo aurait du avoir un pointeur sur l’enregistrement redo qui le suit, ce qui veut dire qu’à chaque fois que nous aurions créé un enregistrement redo, nous aurions du aller voir le précédent enregistrement redo pour le modifier, ce qui ne serait pas très efficace. Le plan B serait d’avoir un mécanisme pour maintenir une longue liste infinie de toutes les transactions et de leur commit SCN quelque part dans la base de donnée – et c’est cet ‘infini’ qui n’est pas une idée séduisante.

Et cela peut se poursuivre ainsi. Vous pouvez trouver des opérations pour lesquelles il est parfaitement acceptable d’utiliser le redo comme source pour l’undo, mais si vous prenez en compte toutes les options d’un système multi-utilisateur avec une activité diverse, alors vous trouverez que certaines opérations auraient ou causeraient quelques problèmes.

La solution d’Oracle est de garder la partie ‘utilisable’ de l’information de retour arrière, l’undo, à un emplacement complètement différent de celui du redo. Plutôt que de créer une troisième structure de stockage de données, ils ont choisi de les mettre dans la base, en utilisant des blocs de données ordinaires. Vous pouvez réfléchir à la manière dont cela résout les points que j’ai soulevés ci-dessus.

Parce que les blocs d’undo sont des blocs de base de données ordinaires, ils sont protégés par les redo logs, et peuvent être récupérés en cas de panne, comme peut l’être le reste de la base de données, sans avoir à rajouter un code différent pour le recovery. Le change vector de retour arrière que nous avons vu précédemment est en réalité le change vector ‘vers l’avant’ pour rejouer la modification du bloc d’undo. Cela ajoute un overhead sur les redo log, car on écrit les undo deux fois, mais c’est ce que nous faisons de toute façon avec n’importe quelle modification (écriture dans le bloc et écriture dans le redo log). Les blocs d’undo bénéficient en plus du mécanisme standard de cache LRU: si un bloc d’undo est souvent utilisé, il reste en mémoire, et c’est parfait puisque l’undo généré récemment a plus de chance d’être celui dont on aura besoin pour la lecture consistante.

Comme nous gardons les flux d’undo dans la base de donnée, nous n’avons pas à nous préoccuper des sessions qui, constamment, ouvrent ou ferment des fichiers lorsqu’elles démarrent ou terminent des transactions. Nous avons juste à maintenir un catalogue qui liste les transactions actives et qui pointe sur l’adresse du tablespace d’undo où la transaction est en train de mettre ses enregistrements d’undo (c’est le rôle de la table des transactions de l’entête des segments d’undo – voir glossaire)

Parce que nous utilisons le bloc comme unité de stockage, et que l’undo de chaque transaction est à part, lorsque j’écris mes enregistrements d’undo ils sont regroupés ensembles (j’acquiers et je remplis un seul bloc à la fois). Donc, si je dois faire un rollback de ma transaction, la lecture d’un seul bloc ramènera beaucoup d’enregistrements d’undo, et cela minimisera les I/O aléatoires que je dois faire pour lire l’enchaînement d’undo.

Si je lance une très longue transaction alors que d’autres sessions sont aussi en train de générer du redo, il y a une certaine indépendance entre mon undo et celui de ces autres sessions. Dans un compromis entre ‘tous les undo dans un même fichier’ et ‘chaque transaction a son propre fichier’, Oracle a permis d’avoir des segments d’undo multiples, c’est à dire l’équivalent d’un relativement petit nombre de fichiers partagés. Ce qui veut dire que la longue transaction est cantonnée à un seul segment d’undo et que toutes les autres sessions peuvent réutiliser (en réécrivant) tout espace disponible dans le reste de la tablespace d’undo, de manière plus efficace. (Bien sûr on peut toujours se retrouver avec une erreur du type ‘fichier plein’, mais cette stratégie permet à la base de données de survivre plus longtemps lors d’activités concurrentes, sur le même volume d’espace disque).

Ce serait impossible d’expliquer tous les détails subtils des problèmes qui sont évités, ou minimisés, en stockant l’undo dans la base de données, et en l’utilisant comme Oracle le fait, mais l’idée est la suivante: si vous voulez savoir pourquoi Oracle utilise une tablespace d’undo plutôt que les redo logs pour ses lectures consistantes, pour ses rollbacks et pour calculer à quel moment le commit a eu lieu, alors il suffit uniquement de penser à tous les scénarios que vous auriez du prendre en compte et que vous auriez du résoudre seulement à l’aide des redo logs. Cela vous donnerait une idée de la surcharge et de la complexité que vous auriez du introduire, et vous aurait permis de voir à quel point les tablespaces d’undo rendent les choses (relativement) plus simple et plus efficaces.

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

Lorsque vous modifiez un bloc de donnée, en modifiant une ligne d’une table par exemple, ou en marquant une entrée d’index comme supprimée, voici ce que fait Oracle:

1. génération d’information redo sous forme d’un vecteur de modification (change vector pour décrire les modifications qui doivent être faites sur le bloc
2. génération d’information undo pour décrire l’ancienne version des données qui vont changer.
   Cet undo est en réalité une information redo (un autre change vector) qui décrit comment créer cette information undo
3. écriture de ces informations dans le buffer de journalisation (redo log buffer)
   Ces 2 change vectors sont regroupés (celui de l’undo est toujours en premier) en un seul enregistrement redo record
4. la modification sur le bloc d’undo est effectuée
5. la modification sur le bloc de données (table ou index) est effectuée

Le redo doit être écrit sur disque avant que le bloc de donnée et le bloc d’undo ne le soient. [voir note ci-dessous]
Le bloc d’undo et le bloc de donnée seront écrits sur disque plus tard, et ce même si la transaction n’est pas encore commitée.

Question: Si l’instance se plante avant que la transaction ne soit commitée, comment Oracle va pouvoir récupérer l’ancienne version des données, puisque elle a été écrasée par la nouvelle version non commitée ?

Réponse: Après le plantage, le processus de récupération (instance recovery) connait l’heure du dernier checkpoint de chaque fichier de données (datafile) et va appliquer le redo sur les fichiers de la tablespace d’undo, de la même manière qu’il le fait sur les autres fichiers des tablespaces ‘permanentes’.

A partir de là, la base est à jour, et le processus de recovery voit alors voir les dernières versions aussi bien pour les blocs de données que pour les blocs d’undo.

La tablespace d’undo contient la table des transactions (transaction table) dans le bloc d’entête du segment d’undo (undo segment header) et, comme elle est maintenant à jour, le processus de recovery peur détecter que la transaction n’a pas été commitée. Il peut alors faire un rollback, en utilisant les informations contenues dans les blocs d’undo afin de récupérer les anciennes données de la table.

Notes:

Cette description d’une modification de donnée est un schéma général général. Il y a des cas particuliers qui rendent ce mécanisme un peu plus complexe. Entre autres, il y a un traitement particulier quand le changement est fait juste au début de la transaction: en 10g les quelques premières modifications que fait une transaction vont utiliser un mécanisme spécial – à condition qu’il n’y ait qu’une seule instance (donc pas en RAC). Ce mécanisme est optimisé en utilisant la gestion de l’undo en mémoire (private redo threads et in-memory undo)

Voire aussi le glossaire undo à propos du undo segment header et de la transaction table

Oracle s’assure toujours que lorsque les modifications faites en mémoire (dans le buffer cache) sont écrites sur disque (dans les datafiles), alors le redo associé qui a été écrit en mémoire (dans le log buffer) a auparavant été flushé sur disque, dans les fichiers redo log.
Si besoin DBWR (database writer) va attendre que LGWR (log writer) ait terminé cette écriture.
C’est ce mécanisme (écriture du log en premier – connu comme le protocole Write Ahead Log) qui assure que les journaux (redo logs) ont toujours l’information nécessaire pour défaire (undo) les modifications écrites sur disque.

Cet article une traduction du glossaire de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici.

• Bloc d’entête de segment (‘Segment Header Block’ ou simplement ‘Segment Header’)
• L’entête des segments undo (‘Undo Segment Header’)
• Table des transactions (‘Transaction Table’)
• Undo
• Rollback

Bloc d’entête de segment (Segment Header Block ou simplement Segment Header):

Historiquement, c’est le premier bloc du premier extent d’un segment, celui qui maintient les information critiques sur la taille du segment, le nombre et l’emplacement des extents, et des informations de contrôle à propos de l’espace libre du segment.
Dans les versions récentes d’Oracle, il peut y avoir quelques blocs juste avant ce bloc d’entête, utilisés pour la gestion de l’espace libre. Cette variante vient de l’implémentation des tablespaces ASSM (Automatic Segment Space Management – gestion automatique de l’espace libre des segments)

La vue DBA_EXTENTS vous donne le fichier et le numéro de block (file_id et block_id) du premier extent, et la vue DBA_SEGMENTS vous donne la position du block d’entête segment header dans cet extent.

Les segments d’undo ont une particularité: le bloc d’entête de segment contient des informations supplémentaires (la table des transactions – transaction table) qui sont spécifiques au mécanisme d’undo d’Oracle.

L’entête des segments undo (Undo Segment Header):

C’est un cas particulier du bloc segment header. La différence principale, c’est qu’il contient la table des transactions (transaction table). C’est une liste, de taille fixe, des transactions les plus récentes, portant l’information concernant leur statut, leurs SCN, et des pointeurs vers les enregistrements d’undo (undo records) associés à la transaction.
Le undo segment header, dans le cas de la gestion automatique des undo, contient aussi une Retention Map qui note le commit SCN de chaque extent, et permet à Oracle de savoir quand un extent a dépassé la période de rétention undo_retention.

Table des transactions (Transaction Table):

Chaque bloc d’undo segment header a une place pour la table des transactions. Lorsque une transaction débute, elle choisit le segment d’undo qu’elle va utiliser, puis prends la plus ancienne entrée (transaction header ‘slot’) dans cette table des transactions.

Cette entrée (ce ‘slot‘) sera l’identifiant de la transaction, et cette information sera visible de deux manières:

1. Comme identifiant de transaction dans V$TRANSACTION
2. Comme verrou de type TX (transaction) et mode 6 (exclusif) dans V$LOCK, posé par la session qui execute la transaction

Dans les deux cas, la transaction est identifiée par les triplet:

• undo segment number: le numéro du segment d’undo qui contient la table des transactions. C’est la colonne XIDUSN de V$TRANSACTION
• slot number:le numéro d’entrée dans cette table. C’est la colonne XIDSLOT de V$TRANSACTION
• sequence number: le nombre d’entrées dans la table étant limitée, chaque fois qu’une entrée est réutilisée, ce numéro de sequence est incrémenté. C’est la colonne XIDSQN de V$TRANSACTION

Au début de la transaction, le ‘start SCN’ est écrit dans cette table. Lorsque la transaction est commitée, il est remplacé par le ‘commit SCN’ [voir la définition du SCN ici]

Donc une entrée de la table des transaction, c’est à dire un ‘transaction table slot‘ représente une seule transaction. Dans V$TRANSACTION, l’identifiant est sur trois colonnes XIDUSN, XIDSLOT et XIDSQN. Sur les versions les plus récentes d’Oracle, l’identifiant est aussi repris en une seule colonne XID de type RAW(8).
Dans V$LOCK un verrou a deux colonnes pour son identification (ID1 et ID2). Les verrous de type TX ont les informations USN (décalé de 2 octets à gauche) et SLOT dans ID1 et SQN dans ID2

Undo: (aussi appelé information de rollback):

C’est l’information qui décrit comment revenir en arrière sur les modifications d’un block (‘db block change’). L’undo est stocké dans les segments d’undo, qui sont créés dans les tablespaces d’undo, et chacun de ces segments possède son ‘catalogue’ (la table des transactions) qui pointe versà l’endroit où la transaction a écrit son premier enregistrement d’undo.

Dans les versions plus anciennes, le DBA devait décider combien de segments undo (appelés rollback segments à l’époque) il devait créer et où les mettre. Dans les versions récentes, le DBA doit seulement créer une tablespace d’undo par instance (une seule tablespace undo étant active) et laisser Oracle décider dynamiquement de combien de segments d’undo il a besoin. A l’exception de quelques cas particuliers, chaque modification d’un bloc est précédée par la création d’un enregistrement d’undo.

On entend souvent dire que c’est l’image complète du bloc qui est copiée dans les enregistrements d’undo. C’est faux, et cette idée vient probablement d’un ancien comportement d’Oracle, en version 5.0, qui utilisait une ‘image avant’ pour garder une copie du bloc. En fait, une enregistrement d’undo contient normalement un taille fixe de 80 octets, plus l’information minimale qui permet de faire revenir un bloc à son état avant la modification.

A partir de la 10.2, le mécanisme d’undo a changé, avec l’introduction des ‘private redo threads‘ et de l’undo en mémoire (‘in-memory undo‘). On peut dire que celà n’a modifié que le moment où ces enregistrements d’undo sont écrits dans les blocs d’undo. Si on regarde les blocs d’undo après que la transaction ait été comittée, il n’est pas possible de savoir si la transaction a utilisé les ‘in-memory undo’ ou le mécanisme classique.

Rollback:

Ce terme est utilisé comme synonyme d’undo, mais c’est aussi la commande qui indique à Oracle que les modifications qui ont été effectuées par la transaction active courante doivent être défaites. Lorsque vous faites un rollback, votre session va remonter toute la chaine des enregistrements d’undo qu’elle a généré, et se servir de chacun pour faire un retour arrière sur la modification précédente. Elle va aussi flagger l’enregistrement undo comme ‘appliqué par l’utilisateur’.
Chaque modification effectuée durant ce retour arrière va à son tour générer du redo, ce qui veut dire que le rollback peut être aussi couteux que la modification initiale. Il faut donc éviter d’écrire du code qui va écrire des données temporairement avec l’intention de les rollbacker à la fin.

Enfin, la dernière étape du rollback est un commit, qui va appeler le log writer pour synchroniser les fichiers redo à partir du log buffer.