Dans des systèmes multi-utilisateurs, plusieurs utilisateurs peuvent
mettre à jour la même information en même temps. Le verrouillage permet à
un seul utilisateur de mettre à jour un bloc de données en particulier,
empêchant une autre personne de modifier la même donnée.
L'idée de base du verrouillage consiste à bloquer une donnée
modifiée dans une transaction jusqu'à ce que la transaction soit validée
ou annulée. Le verrou est actif jusqu'à la fin de la transaction,
principe mieux connu sous le terme de concurrence d'accès aux données (data concurrency).
Le deuxième objectif du verrouillage est d'assurer que tous les
process peuvent toujours accéder en lecture aux données originales,
c'est-à-dire telles qu'elles étaient avant la modification par la
transaction non encore validée. On parle alors de consistence de lecture
(read consistency).
Bien que les verrous soient indispensables pour renforcer la
consistence de la base de données, ils peuvent créer des problèmes de
performances. Chaque fois qu'un process engendre un verrou, un autre
utilisateur peut être bloqué, voire débouté de sa demande pour
verrouiller une ligne ou une table. Oracle permet de verrouiller tout
type de ressources : une seule ligne, plusieurs lignes, une table
entière, même plusieurs tables.
1. Niveaux de verrouillage sous Oracle (row-level et table level locking)
Oracle fournit deux différents niveaux de verrouillage : le verrouillage
ligne (row-level lock) et le verrouillage table (table-level lock).
1.1 Verrouillage ligne (row level locking)
Avec la stratégie de verrouillage ligne, chaque ligne dans une
table est verrouillée individuellement. Les lignes verrouillées ne
peuvent être mises à jour que par le process bloquant. Toutes les autres
lignes de la table sont toujours disponibles pour mise à jour par
d'autres process.
Bien entendu, les autres sessions peuvent continuer de lire la
table, y compris la ligne qui est en cours de mise à jour. Lorsque
d'autres sessions lisent des lignes mises à jour, ces sessions ne
peuvent que lire la version ancienne de la ligne avant mise à jour (via
les segments d'annulation « rollback segments ») jusqu'à ce que les
changements soient effectivement validés par la transaction bloquante.
C'est le principe de la lecture consistante pour Oracle (consistent read).
Lorsqu'un process place un verrou ligne sur un enregistrement :
- Premièrement, un verrou de manipulation de données (DML Lock) est placé sur la ligne. Ce verrou empêche les autres sessions de manipuler ou verrouiller cette ligne. Le verrou est relâché seulement lorsque le process bloquant annule ou valide la transaction.
- Ensuite un verrou DDL (data dictionary language, DDL Lock) est placé sur la table pour empêcher les altérations de structure de la table. Ce verrou est relâché également seulement lorsque le process bloquant annule ou valide la transaction.
1.2 Verrouillage table (table level locking)
Avec le verrouillage table, la table entière est verrouillée
intégralement. Une fois qu'un process a verrouillé la table, seule ce
process peut mettre à jour ou verrouiller une ligne de cette table.
Aucune des lignes n'est disponible pour mise à jour par d'autres
sessions. Les autres sessions peuvent toujours cependant continuer à
lire la table, y compris la ligne qui est en cours de mise à jour.
Comment le verrouillage table fonctionne-t-il ? La première
opération DML qui a besoin de mettre à jour une ligne dans une table
obtient ce que l'on appelle un verrou ligne partagé exclusif (Row Share Exclusive lock)
sur la table dans son intégralité. Tous les autres process effectuant
des requêtes et qui ont besoin d'accéder à la table sont informés qu'ils
doivent utiliser les informations des segments d'annulation (rollback
segments). Le verrou est relâché uniquement lorsque le process bloquant
valide ou annule sa transaction.
2. Modes de verrouillage
Oracle utilise 2 modes de verrouillage :
- Le mode de verrou exclusif (X - Exclusive lock mode) : ce mode empêche la ressource associée d'être partagée. Ce mode de verrou est obtenu pour modifier des données. La première transaction qui verrouille une ressource exclusivement est la seule à pouvoir altérer cette ressource (ligne ou table) jusqu'à ce que le verrou exclusif soit relaxé.
- Le mode de verrou partagé (S - Share lock mode) : autorise la ressource associée à être partagée, mais tout dépend des opérations engagées. Plusieurs utilisateurs lisant les données peuvent partager les données, laissant des verrous de partage pour empêcher l'accès concurrent à un process voulant écrire (qui requiert un verrou exclusif). Plusieurs transactions peuvent acquérir des verrous de partage sur la même ressource.
Verrous exclusifs
|
|||||||||||||||||
Verrous de partage
|
|||||||||||||||||
Opérations permises :Les verrous RS tenus par une transaction permettent aux autres transactions les opérations ci-dessous :
Opérations interdites:Un verrou RS posé par une transaction empêche les autres transactions d'avoir un accès exclusif sur les mêmes données de la table.La table emp dans le schéma SCOTT est prise pour les exemples : |
|||||||||||||||||
Aucun commentaire:
Enregistrer un commentaire