Définitions Undo, Rollback Segment et Table de transactions , par Jonathan Lewis

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

Statistiques ‘db block gets’ et ‘consistent gets’, par Jonathan Lewis

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

L’article explique à quoi correspondent exactement db block gets et consistent gets que l’on retrouve dans les statistiques de performance à différents endroits: autotrace, statspack, AWR, V$SESSTAT

Dans tkprof, on retrouve ‘db block gets’ dans la colonne ‘current‘ (version courante du bloc) et ‘consistent gets’ dans la colonne ‘query‘ (version consistante par rapport au début de la requête)

Dans V$SQL on retrouve leur somme, sans les différencier, dans la colonne BUFFER_GETS. Leur somme est aussi souvent appelée ‘logical I/O‘ (LIO) ou ‘Lectures en mémoire tampon‘ sous OEM et s’incrémente à chaque fois qu’oracle va lire un bloc en buffer cache en passant par le ‘cache buffer chain‘, donc en nécessitant un latch – verrou sur cette structure mémoire.

db block gets et consistent gets sont deux contextes différents de ces lectures logiques: version courante ou version consistante du bloc.

Comment décrire ‘db block gets’ and ‘consistent gets’ en quelques lignes ?
Ayant posé la question sur mon blog je suppose que je dois donc donner ma version de la réponse.

Lire la suite

nettoyage de blocs (commit cleanout) et blocs sales (dirty block), par Jonathan Lewis

Cet article est la traduction d’un article de Jonathan Lewis publié sur son blog. L’article original en anglais se trouve ici.
En expliquant les significations de ‘clean block’, il détaille le fonctionnement d’Oracle lorsqu’on modifie un bloc, puis lorsque ces modifications sont commitées.

Il y a une certaine confusion à propos du terme ‘clean‘ autour d’Oracle, donc j’ai pensé que je devrais écrire une note pour expliquer les différentes notions que ce mot peut couvrir lorsqu’il est appliqué aux blocs Oracle. Il y a 5 termes:

  1. clean
  2. commit cleanout
  3. block cleanout
  4. delayed block cleanout
  5. delayed logging block cleanout

Lire la suite

System Change Number (SCN), par Jonathan Lewis

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

SCN est l’abréviation de System Change Number ou de System Commit Number (aucun de ces 2 termes n’est vraiment exact)

Le SCN est utilisé comme une sorte d’horloge interne d’une instance Oracle. Mais il n’avance pas régulièrement. C’est un compteur qui est incrémenté à chaque fois qu’une session fait un commit (ou un rollback).

Il peut changer à d’autres occasions: les instances impliquées dans des transactions ou requêtes distribuées vont synchroniser leur SCN (toujours vers un valeur supérieure) à la fin de chaque dialogue. De la même manière, les instances d’une configuration RAC synchronisent leur SCN très fréquemment.

Il y a aussi une autre raison: chaque modification d’un bloc incrémente un ‘change number‘ dans ce bloc qui est composé du SCN courant et d’un compteur sur un octet. Donc s’il y a plus de 255 modifications dans un bloc dans une période où aucun commit ne se fait, alors le SCN va être incrémenté de 1 et ce compteur est remis à 1 (la valeur zéro étant réservée pour marquer un bloc comme corrompu – logically corrupt – ce qui se retrouve dans l’alert.log sous l’erreur ORA-01578).

Une session prend note du SCN courant à différents moments (le début d’une transaction, le commit d’une transaction, le début d’une requête) et le SCN courant est écrit dans la base à différents endroits (controlfiles, entêtes de datafiles, entête de bloc, entrées ITL).

Une session est constamment en train de comparer le SCN courant, ou un des SCN qu’elle a pre-enregistrés, avec les SCN stockés dans la base de données afin de vérifier qu’elle voit une version sûre, correcte et appropriée des données.

Vous pouvez connaître le SCN courant en appelant la fonction dbms_flashback.get_system_change_number ou en faisant select current_scn from v$database. Par contre, chaque requête sur v$database incrémente le SCN, donc CURRENT_SCN sera incrémenté avant d’être affiché.

ITL – Interested Transaction List, par Jonathan Lewis

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

ITL est l’abréviation de Interested Transaction List. C’est une petite liste stockée dans l’entête de chaque bloc de table ou d’index.
Elle identifie les transactions qui ont récemment modifié le contenu de ce bloc. Lorsqu’une transaction veut modifier des enregistrements dans un bloc, elle doit acquérir une des entrées de l’ITL de ce bloc, et y écrire les informations d’identification.

La transaction ne doit acquérir qu’une seule entrée ITL pour un bloc, quel que soit le nombre d’enregistrements qu’elle doit y modifier.
Une transaction peut modifier plusieurs blocs, et doit posséder une entrée ITL dans chacun d’eux.

Si toutes les entrées ITL d’un bloc sont en cours d’utilisation, la transaction peut ajouter une nouvelle entrée à la liste, à condition qu’il y ait assez d’espace libre dans le bloc, et que (pour les anciennes versions d’Oracle) la taille de l’ITL n’a pas atteint sa limite définie par MAXTRANS. A partir de la 10g, Oracle ignore le paramètre MAXTRANS, (et cela peut créer des problèmes dans les indexes – voir space wastage problems in indexes).

La taille initiale de la liste ITL est paramétrée par INITRANS avec un minimum qui dépend de la version d’Oracle et du type d’objet.