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.
Lire la suite →