Catégorie: Undo (rollback segment)

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

» Lire la suite!

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!

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 ?

» Lire la suite!

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

» Lire la suite!