Le but d'un SGBD est d'assurer l'accès à des informations
à un ensemble d'utilisateurs, ces accès pouvant être
concurrents. Pour assurer cette cohérence, le SGBD propose deux
mécanismes :
- un mécanisme de transaction,
- un mécanisme d'accès concurrent.
Mécanisme de transaction
Une transaction est un ordre de modification d'une donnée. Elle
correspond à un ordre INSERT, UPDATE, DELETE. Elle se termine par un
ordre implicite ou explicite de validation (COMMIT) ou d'annulation
(ROLLBACK).
On peut aussi définir une transaction comme un ensemble d'opérations sql élémentaires. Ces opérations doivent être exécutées entièrement ou pas du tout.
La transaction consiste à passer l'instance d'un état stable vers un autre état stable (ou cohérent).
Nous pouvons considérer que la transaction (amenant une modification)
représente une opération indivisible (elle a lieu en une seule
action au vue du SGBD) et impose un accès unique. Les autres ordres sont
alors sérialisés.
Mécanisme d'accès concurrent
Pour se prémunir des accès concurrents, Oracle propose deux mécanismes de verrous :
- les verrous implicites, gérés automatiquement par
Oracle,
- les verrous explicites, gérés par les
applications.
Les verrous implicites
Le SGBD entretient deux types de données : le dictionnaire et les données.
Ces deux types de données sont partagés entre tous les utilisateurs de l'instance, Oracle propose un mécanisme de verrous sur le LDD et sur le LMD (posé sur une table ou une ligne).
Les verrous explicites
Nous allons disposer de deux types de verrous :
- verrous exclusifs : la transaction verrouille la ressource de
façon exclusive. Une seule action peut exploiter cette
ressource.
- verrous partagés : la ressource est disponible pour
plusieurs transactions.
Les problèmes liés aux verrous
Il existe toujours une possibilité de deadlock lorsque plusieurs entités gèrent des verrous. Ce cas est classique lorsque deux actions concurrentes accèdent aux mêmes ressources. Ce qui donne avec des ordres sql :
Il est donc important qu'Oracle dispose d'une surveillance constante de ce type
de problème.
Les verrous liés au LMD
Les verrous partagés peuvent être positionnés par plusieurs
sessions (ou applications) en simultané.
Les verrous exclusifs bloquent les autres sessions, elles ne peuvent intervenir sur l'objet et sont bloquées sur l'ordre sql de modification ou sur la pose d'un autre verrou.
Le SGBD propose cinq types de verrous pouvant être positionnées
sur les données :
- RS (row share) : dans ce cas, le SGBD verrouille les
enregistrements indiqués.
Il représente le verrou le moins restrictif. Il sert essentiellement à assurer la compatibilité avec Oracle 6. - RX (row exclusive) : dans ce cas, le SGBD verrouille les
enregistrements concernés, mais autorise le travail sur le reste de la
table.
Ce type de verrou est implicitement posé par un ordre INSERT, UPDATE, DELETE, ou de façon explicite par un ordre LOCK TABLE .... in ROW EXCLUSIVE MODE. - S (share) : dans ce cas, le SGBD empêche tout travail de
modification sur la table. Il permet de se prémunir contre la pose d'un
verrou de type SRX et X. Ces derniers se trouvent bloqués tant que le
verrou de type S n'est pas levé.
Ce type de verrou est posé, de façon explicite, par un ordre LOCK TABLE .... in SHARE MODE. - SRX (share row exclusive) : dans ce cas, le SGBD empêche tout
travail de modification sur la table. Il permet de se prémunir contre la
pose d'un verrou de type RX, S, SRX et X. Ces derniers se trouvent
bloqués tant que le verrou de type SRX n'est pas
levé.
Ce type de verrou est posé explicitement par un ordre LOCK TABLE .... in SHARE ROW EXCLUSIVE MODE. - X (exclusive) : dans ce cas, le SGBD empêche tout travail de
modification sur la table. Il n'est compatible avec aucun autre
verrou.
La surveillance des verrous
Pour supprimer des sessions verrouillées, l'administrateur effectue le
travail suivant :
Pose d'un verrou
Les paramètres du fichier init.ora
Il est possible de modifier les modes de verrouillages automatiques du SGBD via deux paramètres qui sont:
- SERIALIZABLE, les valeurs possibles sont FALSE et TRUE, (FALSE par
défaut),
- RAW_LOCKING, les valeurs possibles sont INTENT et ALWAYS (ALWAYS
par défaut).
Le paramètre SERIALIZABLE commande le verrouillage au niveau des tables.
Si sa valeur est passée à TRUE, chaque modification d'une valeur
dans une table induit un verrouillage complet de la table (le verrouillage par
ligne est désactivé). Les transactions sont gérées
en série. Il peut être nécessaire de changer cette valeur
pour obtenir une compatibilité ANSI.
Le paramètre ROW_LOCKING commande le verrouillage au niveau des
enregistrements. Si la valeur est positionnée à ALWAYS, chaque
modification d'un enregistrement bloque ce dernier.
