Par défaut, Oracle utilise le niveau ligne serrures.
Ces verrous bloquent uniquement les auteurs (mise à jour, suppression, insertion, etc.). Cela signifie que select fonctionnera tout le temps lorsqu'une table est fortement mise à jour, supprimée de, etc.
Par exemple, soit tableA(col1 number, col2 number), avec ces données à l'intérieur :
col1 | col2
1 | 10
2 | 20
3 | 30
Si l'utilisateur John émet à time1 :
update tableA set col2=11 where col1=1;
verrouillera row1.
À time2 l'utilisateur Marquer émettre un
update tableA set col2=22 where col1=2;
la mise à jour fonctionnera, car la ligne 2 n'est pas verrouillée.
Maintenant, la table regarde dans la base de données :
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
Pour Mark table is(il ne voit pas les modifications non validées)
col1 | col2
1 | 10
2 | 22
3 | 30
Pour John, la table est :(il ne voit pas les modifications non validées)
col1 | col2
1 | 11
2 | 20
3 | 30
Si Mark essaie à time3 :
update tableA set col2=12 where col1=1;
sa session se bloquera jusqu'à time4 quand John émettra un commit .(La restauration déverrouillera également les lignes, mais les modifications seront perdues)
table is(in db, at time4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Immédiatement, après le commit de John, la ligne 1 est déverrouillée et la mise à jour des marques fera le travail :
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
marquons l'émission d'un rollbak à l'heure 5 :
col1 | col2
1 | 11
2 | 20
3 | 30
Le cas d'insertion est plus simple, car les lignes insérées sont verrouillées, mais ne sont pas non plus vues par les autres utilisateurs car elles ne sont pas validées. Lorsque l'utilisateur s'engage, il libère également les verrous, de sorte que d'autres utilisateurs peuvent afficher ces lignes, les mettre à jour ou les supprimer.
MODIFIER :Comme Jeffrey Kemp l'a expliqué, lorsque vous avez PK (il est implémenté dans Oracle avec un index unique), si les utilisateurs essaient d'insérer la même valeur (donc, nous aurions un doublon), le verrouillage se produira dans le index . La deuxième session sera bloquée jusqu'à la fin de la première session car elle essaie d'écrire au même endroit. Si la première session est validée, la seconde lèvera une exception de clé primaire violée et ne parviendra pas à modifier la base de données. Si la première session effectue une restauration, la seconde réussira (si aucun autre problème n'apparaît).
(NB :Dans cette explication par l'utilisateur John, je veux dire une session démarrée par l'utilisateur John.)
