Catégorie: Transactions, Verrous

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 Tom Kyte publié dans Oracle Magazine en Novembre 2005. L'article original en anglais se trouve ici. Il peut être utile de lire avant Lectures cohérentes et multi-versionnage (traduit aussi de Tom Kyte).

Question posée sur AskTom:

J'ai lu le manuel 'Database Concepts' de la documentation Oracle, au chapitre "Data Concurrency and Consistency" mais je n'ai pas vraiment compris la différence entre les niveaux d'isolation serializable et read-committed. Pouvez-vous donner des exemples qui expliquent cela clairement ?

Réponse de Tom Kyte:

Avant de lire ce qui suit, vous pouvez aller voir l'article d'Oracle Magazine de Mai/Juin 2005 (en anglais) où je décris la fonctionnalité que j'ai toujours préféré dans Oracle: le multi-versioning. Sa compréhension est cruciale pour réussir avec Oracle, mais il vous aidera aussi à comprendre les concepts décrits ci dessous. (Voir la traduction d'un article similaire ici)

[La suite est un extrait de 'Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions']

» Lire la suite!

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.