Catégories: Concepts, Cohérence (consistency), Fragmentation, Objet-Relationnel, Parsing, Partitionnement, Plan d'exécution, Redo, Réseau, Sauvegardes, SCN, Stockage (PCTFREE, INITRANS, etc), Transactions, Verrous, Undo (rollback segment), Wait events

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.

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

Fragmentation Index

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

» Lire la suite!

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

Fragmentation Table

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

» Lire la suite!

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

Fragmentation Disque

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

» Lire la suite!

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

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

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

Introduction

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

» Lire la suite!

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.

» Lire la suite!

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.

» Lire la suite!

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.

» 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.
Pour une description complète des modes de verrous, vous pouvez lire aussi: Les verrous sur les table, et leurs modes (S/X/RS/RX/SRX)

A propos des verrous (locks) et de leur mode (dans les colonnes LMODE et REQUEST de la vue V$LOCK par exemple), je raisonne souvent avec leur numéro. Et je m'apercois que je n'arrive jamais à retenir la correspondance entre le numéro et le lien, sauf pour le mode 6 = exclusive. Donc j'ai finalement mis ici la table de correspondance pour que je puisse la retrouver facilement.

» Lire la suite!

La version anglaise de cet article se trouve sur knol

Le vérouillage (Locking) sous Oracle paraît simple au premier abord. La plupart du temps, on n'a pas à utiliser de vérouillage explicite (LOCK TABLE). Le vérouillage implicite des ordres DML (insert, update, delete, select for update) est transparent et souvent efficace. Un select (sans le for update) ne pose aucun verrou (lock). Les verrous mortels (deadlocks) sont rares et les attentes sur les wait events enqueue ne sont pas si fréquentes.

Mais lorsqu'on veut aller plus loin, pour comprendre une situation de deadlock, ou pourquoi une session est bloquée, ou pour éviter les problèmes de performance dans l'intégrité référentielle, alors les choses deviennent plus complexes. Le mécanisme d'Oracle n'est pas facile à comprendre et les différents nommage des modes de verrous rendent les choses plus difficiles. Un exemple: le mode 3 par exemple peut s'appeler 'Row Exclusif' aussi bien que 'Sub Exclusive', abrégé Row-X, Sub-X, RX ou SX. Et il n'est pas au niveau row (d'ailleurs les verrous au niveau enregistrement ne s'appellent pas row mais TX comme transaction), et il n'est pas si exclusif que ça puisque plusieurs session peuvent l'acquérir sur la même ressource...

Pas de panique, on va tout expliquer. La signification des modes de verrouillage, leurs nommage, et leur matrice de compatibilité. Et prendre un exemple an manipulant les vues du dictionnaire.

» Lire la suite!

Cet article est la traduction d'un article de Greg Rahn publié sur son blog. L'article original en anglais est:The Core Performance Fundamentals Of Oracle Data Warehousing – Partitioning. Cet article fait partie d'une série sur les principes fondamentaux des datawarehouse.

Le partitionnement est une fonctionnalité majeure pour les performance d'un datawarehouse sous Oracle, car l'élagage des partition (partition pruning) va la plupart du temps faire en sorte qu'il y ait moins de données à lire sur une table. Le résultat, c'est qu'il y a besoin de moins de ressources système, et que les requêtes sont plus performantes.
Quelqu'un m'a dit un jour "les I/O les plus rapides sont ceux que l'on ne fait jamais" C'est précisément la raison pour laquelle le partitionnement est ce qu'il y a de mieux pour un datawarehouse: il permet de réduire les I/O.
Je parle souvent de l'élagage des partitions (partition pruning) comme d'un anti-index. Un index est utilisé pour trouver la faible quantité de données qui est nécessaire, alors que le partitionnement est utilisé pour éliminer une grande quantité de données qui n'est pas nécessaire.

Principales utilisations du partitionnement

Je vois quatre raisons pour l'utilisation du partitionnement dans un datawarehouse Oracle:

• Élimination de données
• Jointures partition par partition (Partition-Wise Joins)
• Maintenabilité (chargements par échange de partitions, indexes locaux, etc.)
• Cycle de vie des données (Information Lifecycle Management - ILM)

» 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.
Il montre un fonctionnalité peu connue: la compression des données transférées par SQL*Net lorsque il y a répétition de valeurs d'une ligne à l'autre. Et l'avantage de récupérer ces données triées sur ces colonnes répétitives.

Voici une petite démonstration que j'avais l'intention d'écrire depuis ces dernières années.
C'est très simple: je crée une table, et je l'interroge plusieurs fois.

» Lire la suite!