LOCK-Anweisung (lock_statement)
Die LOCK-Anweisung (
lock_statement ) ordnet eine Sperre der aktuellen Transaktion zu (siehe Transaktionen).Syntax
<lock_statement> ::=
LOCK [(WAIT) | (NOWAIT)] <lock_spec> IN SHARE MODE
LOCK [(WAIT) | (NOWAIT)] <lock_spec> IN EXCLUSIVE MODE
LOCK [(WAIT) | (NOWAIT)] <lock_spec> IN SHARE MODE <lock_spec> IN EXCLUSIVE MODE
LOCK [(WAIT) | (NOWAIT)] <row_spec>... OPTIMISTIC
<lock_spec> ::= TABLE <table_name>,... | <row_spec>...
| TABLE <table_name>,... <row_spec>...
Erläuterung
Die angegebene Tabelle darf keine temporäre Basistabelle, keine View-Tabelle (siehe
Tabelle) und kein Synonym sein. Wenn der Tabellenname eine View-Tabelle identifiziert, werden Sperren auf die Basistabellen gesetzt, die der View-Tabelle zugrundeliegen. Zum Setzen von SHARE-Sperren muß der aktuelle Benutzer das SELECT-Privileg, zum Setzen von exklusiven Sperren das UPDATE-, DELETE- oder INSERT-Privileg besitzen.<row_spec>...
Bei Angabe von
<row_spec>... wird eine Sperre für die durch die Schlüsselwerte oder durch einen Standpunkt in einer Ergebnistabelle bezeichnete Zeile einer Tabelle angelegt.Die Angabe einer
row_spec erfordert, daß die angegebene Tabelle eine Schlüsselspalte besitzt, d. h. falls durch den Tabellennamen eine View-Tabelle angegeben ist, muß diese änderbar sein.TABLE <table_name>,...
Bei Angabe von
TABLE <table_name>,... wird eine Sperre für die genannte Tabelle angelegt.Wenn der Tabellenname eine nicht änderbare View-Tabelle identifiziert, ist nur das Setzen einer SHARE-Sperre für diese View-Tabelle möglich. Als Folge dieser SQL-Anweisung sind anschließend alle Basistabellen, die der View-Tabelle zugrundeliegen, SHARE gesperrt.
SHARE
SHARE definiert eine SHARE-Sperre für die aufgeführten Objekte. Wenn eine SHARE-Sperre gesetzt wurde, kann keine konkurrierende Transaktion die gesperrten Objekte verändern.
EXCLUSIVE
EXCLUSIVE definiert eine exklusive Sperre für die aufgeführten Objekte. Wenn eine exklusive Sperre gesetzt wurde, kann keine konkurrierende Transaktion die gesperrten Objekte verändern. Konkurrierende Transaktionen können nur im Isolation-Level 0 lesend auf die gesperrten Objekte zugreifen.
Exklusive Sperren für Zeilen, die noch nicht geändert wurden, können durch die
UNLOCK-Anweisung vor Transaktionsende freigegeben werden.OPTIMISTIC
OPTIMISTIC definiert eine optimistische Sperre auf Zeilen. Diese ist nur sinnvoll zusammen mit den Isolation-Levels 0, 1, 10 und 15. Eine Änderungsoperation des aktuellen Benutzers auf einer von ihm optimistisch gesperrten Zeile wird nur durchgeführt, wenn diese Zeile nicht zwischenzeitlich von einer konkurrierenden Transaktion geändert wurde. Wurde diese Zeile zwischenzeitlich von einer konkurrierenden Transaktion geändert, wird die Änderungsoperation des aktuellen Benutzers zurückgewiesen. In beiden Fällen wird die optimistische Sperre freigegeben. Im Falle der erfolgreichen Änderungsoperation wird eine exklusive Sperre für diese Zeile gesetzt. Im Falle einer erfolglosen Änderungsoperation sollte diese Änderungsoperation erst nach einem erneuten Lesen ohne oder mit optimistischer Sperre wiederholt werden. Im Isolation-Level 0 muß das erneute Lesen mit einer explizit angegebenen Sperre durchgeführt werden. So kann sichergestellt werden, daß die Änderung noch auf dem aktuellen Zustand aufsetzt und keine zwischenzeitlichen Änderungen verloren gehen.
Die Anforderung einer optimistischen Sperre kollidiert nur mit einer exklusiven Sperre. Konkurrierende Transaktionen kollidieren nicht mit einer optimistischen Sperre.
Siehe auch:
TransaktionenSperren können implizit oder explizit angefordert werden. Die explizite Anforderung einer Sperre geschieht mittels der LOCK-Anweisung. Ob eine Sperre implizit angefordert wird und wie lange sie dann der Transaktion zugeordnet bleibt, hängt von der Isolation-Level-Spezifikation der
CONNECT-Anweisung ab.SHARE-Sperren und exklusive Sperren, die sich auf einzelne, noch nicht geänderte Zeilen von Tabellen beziehen, können innerhalb einer Transaktion freigegeben werden. Exklusive Sperren auf geänderte Zeilen oder Tabellensperren können innerhalb einer Transaktion nicht freigegeben werden.
Die durch die LOCK-Anweisung einer Transaktion zugeordneten Sperren werden normalerweise mit Beendigung der Transaktion freigegeben, es sei denn, die
COMMIT-Anweisung bzw. ROLLBACK-Anweisung, die die Transaktion beendet, beinhaltet eine LOCK-Anweisung.WAIT/NOWAIT
Treten beim Setzen von expliziten oder impliziten Sperren zu lange Wartezeiten auf eine Sperrfreigabe auf, so erfolgt eine entsprechende Rückmeldung. Auf diese Rückmeldung kann der Anwender z. B. durch den Abbruch der Transaktion reagieren. Das Datenbanksystem führt in solchen Situationen kein implizites ROLLBACK WORK durch.
Deadlock
Erkennt das Datenbanksystem einen durch explizite oder implizite Sperren verursachten Deadlock, so wird die Transaktion durch ein implizites ROLLBACK WORK beendet.
Reproduzierbarkeit
Werden für das Lesen von Zeilen mittels einer SELECT-Anweisung reproduzierbare Ergebnisse gewünscht, müssen die gelesenen Objekte gesperrt werden, und die Sperren müssen bis zur Reproduktion gehalten werden. Für die Reproduzierbarkeit ist es im allgemeinen erforderlich, die betroffenen Tabellen explizit mittels eines oder mehrerer LOCK-Anweisungen oder implizit durch Verwendung des Isolation-Level 3 SHARE zu sperren. Dadurch wird gewährleistet, daß kein anderer Benutzer die Tabelle ändern kann. Für die Reproduzierbarkeit einer SQL-Anweisung
SELECT DIRECT genügt das implizite oder explizite SHARE-Sperren der zu lesenden Zeile.Anzahl von Sperren
Je weniger Objekte gesperrt sind, desto mehr Transaktionen können gleichzeitig auf der Datenbank arbeiten, ohne bei Sperranforderungen mit anderen Transaktionen zu kollidieren. Aus diesem Grund sollten keine unnötigen Sperren gesetzt werden, und gesetzte Sperren sollten möglichst frühzeitig wieder freigegeben werden.
Werden zu viele Zeilensperren (SHARE-Sperren oder exklusive Sperren) von einer Transaktion für eine Tabelle explizit oder implizit angefordert, versucht das Datenbanksystem, dafür eine Tabellensperre zu erhalten. Treten dabei Kollisionen mit anderen Sperren auf, werden weiter Zeilensperren angefordert. Dies bedeutet, daß zum Erhalt einer Tabellensperre keine Wartezustände eintreten. Die Grenze, ab der versucht wird, Zeilensperren in eine Tabellensperre zu verwandeln, hängt von dem Installationsparameter MAXLOCKS ab.