Standardmäßig verwendet Oracle Zeilenebene Schlösser.
Diese Sperren blockieren nur für Schreiber (aktualisieren, löschen, einfügen usw.). Das bedeutet, dass die Auswahl immer funktioniert, wenn eine Tabelle stark aktualisiert wird, löschen aus usw.
Seien Sie beispielsweise tableA(col1 number, col2 number), mit diesen Daten darin:
col1 | col2
1 | 10
2 | 20
3 | 30
Wenn Benutzer John um time1 ausgibt :
update tableA set col2=11 where col1=1;
wird Zeile1 sperren.
Um time2 Benutzer Mark gibt ein
update tableA set col2=22 where col1=2;
das Update funktioniert, weil die Zeile 2 nicht gesperrt ist.
Jetzt sucht die Tabelle in der Datenbank:
col1 | col2
1 | 11 --locked by john
2 | 22 --locked by mark
3 | 30
Für Mark ist die Tabelle (er sieht die nicht festgeschriebenen Änderungen nicht)
col1 | col2
1 | 10
2 | 22
3 | 30
Für John ist die Tabelle:(er sieht die nicht festgeschriebenen Änderungen nicht)
col1 | col2
1 | 11
2 | 20
3 | 30
Wenn Mark es um time3 versucht :
update tableA set col2=12 where col1=1;
seine Sitzung hängt bis time4 wenn John ein commit ausgibt .(Rollback entsperrt auch die Zeilen, aber Änderungen gehen verloren)
Tabelle ist (in db, zu time4):
col1 | col2
1 | 11
2 | 22 --locked by mark
3 | 30
Unmittelbar nach Johns Commit wird die Zeile1 entsperrt und die Aktualisierung von Marks erledigt die Aufgabe:
col1 | col2
1 | 12 --locked by mark
2 | 22 --locked by mark
3 | 30
Lassen Sie uns einen Rollbak zum Zeitpunkt 5 ausgeben:
col1 | col2
1 | 11
2 | 20
3 | 30
Der Einfügungsfall ist einfacher, da eingefügte Zeilen gesperrt sind, aber auch von anderen Benutzern nicht gesehen werden, da sie nicht festgeschrieben sind. Wenn der Benutzer einen Commit durchführt, hebt er auch die Sperren auf, sodass andere Benutzer diese Zeilen anzeigen, aktualisieren oder löschen können.
BEARBEITEN :Wie Jeffrey Kemp erklärte, wenn Sie PK haben (es ist in Oracle mit einem eindeutigen Index implementiert), wenn die Benutzer versuchen, denselben Wert einzufügen (also hätten wir ein Duplikat), erfolgt die Sperrung in der Index . Die zweite Sitzung wird bis zum Ende der ersten Sitzung blockiert, da versucht wird, an derselben Stelle zu schreiben. Wenn die erste Sitzung festgeschrieben wird, löst die zweite die Ausnahme „Primärschlüssel verletzt“ aus und kann die Datenbank nicht ändern. Wenn die erste Sitzung ein Rollback durchführt, wird die zweite erfolgreich sein (wenn kein anderes Problem auftritt).
(NB:In dieser Erklärung von Benutzer John meine ich eine Sitzung, die von Benutzer John gestartet wurde.)
