Sperren während einer Aktualisierung

Der Datenbankserver ändert die in einem bestimmten Datensatz enthaltene Information mit folgenden Schritten. Wie bei Einfügungen gilt diese Reihenfolge der Vorgänge für alle Transaktionen unabhängig von ihrer Isolationsstufe.

Es wird eine gemeinsame Schemasperre für die Tabelle gesetzt, falls eine solche nicht bereits vorhanden ist.
Es wird eine Tabellensperre für Schreibabsicht für jede zu aktualisierende Tabelle gesetzt, falls eine solche nicht bereits vorhanden ist.
1. Bei jeder zu aktualisierende Tabelle, die Trigger aufweist, müssen anschließend die temporären Tabellen für die alten und neuen Werte nach Bedarf erstellt werden.
2. Die zu aktualisierenden Zeilen werden festgelegt. Während Zeilen durchsucht werden, sind sie gesperrt.
  
  Bei den Isolationsstufen 2 und 3 gibt es folgende Abweichungen vom Standard-Sperrverhalten: Sperren für Schreibabsicht auf Zeilenebene werden anstelle von Lesesperren gesetzt und es können Sperren für Schreibabsicht bei Zeilen gesetzt werden, die schließlich als Kandidaten für eine Aktualisierung verworfen werden.
3. Für jede in Schritt 2 festgelegte Kandidatenzeile wird die verbleibende Sequenz durchgeführt.
Die betroffene Zeile wird mit einer Schreibsperre versehen.
Jeder der betroffenen Spaltenwerte wird gemäß der UPDATE-Anweisung aktualisiert.
Wurden indizierte Werte geändert, dann werden neue Indexeinträge hinzugefügt. Die Original-Indexeinträge für die Zeile bleiben bestehen, werden aber als gelöscht gekennzeichnet. Neue Indexeinträge für die neuen Werte werden eingefügt, während eine kurzfristige Einfügesperre besteht. Falls erforderlich, verifiziert der Server die Indexeindeutigkeit.
Wenn eine Verletzung der Eindeutigkeit aufgetreten ist, wird eine temporäre Tabelle erstellt, um die alten und neuen Werte der Zeile zu speichern. Die alten und neuen Werte werden in die temporäre Tabelle kopiert und die Zeile in der Basistabelle wird gelöscht. Vorhandene DELETE-Trigger werden nicht ausgelöst. Verschieben Sie die Schritte 7 bis 9 ans Ende der zeilenweisen Verarbeitung.
Falls Fremdschlüsselwerte in der Zeile geändert wurden, wird eine gemeinsame Schemasperre für die Primärtabelle(n) gesetzt und neue Fremdschlüsselwerte werden gemäß der entsprechenden Prozedur eingefügt.

Falls zutreffend, wird ebenfalls die Prozedur für WAIT_FOR_COMMIT durchgeführt.
Wenn die Tabelle eine Primärtabelle in einer referenziellen Integritätsbeziehung ist und es sich bei dem UPDATE-Vorgang der Beziehung nicht um RESTRICT handelt, werden die betroffenen Zeilen in den Fremdtabellen ermittelt, indem zuerst eine gemeinsame Schemasperre für die Tabellen gesetzt wird, eine Tabellensperre für Schreibabsicht für jede Tabelle, und indem Schreibsperren für alle betroffenen Zeilen gesetzt werden, die wie erforderlich geändert werden. Beachten Sie, dass dieser Prozess möglicherweise kaskadierend durch eine verschachtelte Hierarchie von referenziellen Integritätsregeln durchgeführt wird.
Lösen Sie die erforderlichen AFTER ROW-Trigger aus.

Nach dem letzten Schritt wird nun, sofern eine temporäre Tabelle erforderlich war, jede Zeile aus der temporären Tabelle in die Basistabelle eingefügt (ohne dass jedoch INSERT-Trigger ausgelöst werden). Wenn die Zeileneinfügung erfolgreich ist, werden die oben genannten Schritte 7 bis 9 ausgeführt und die alten und neuen Zeilenwerte in die alten und neuen temporären Tabellen kopiert, damit vorhandene AFTER STATEMENT UPDATE-Trigger alle geänderten Zeilen richtig verarbeiten können. Nachdem alle gespeicherten Zeilen verarbeitet wurden, werden die AFTER STATEMENT UPDATE-Trigger in der entsprechenden Reihenfolge ausgelöst. Bei COMMIT verifiziert der Server die referenzielle Integrität, indem er sicherstellt, dass die Anzahl der durch diese Transaktion erzeugten Waisen gleich 0 ist, und er gibt alle Sperren frei.

Die Änderung eines Spaltenwertes kann eine Vielzahl von Vorgängen nach sich ziehen. Der Datenbankserver hat wesentlich weniger Arbeit, wenn die Spalte, die Sie ändern, nicht Teil eines Primär- oder Fremdschlüssels ist. Die Arbeit ist noch geringer, wenn die Spalte in keinem Index enthalten ist, weder explizit noch implizit, falls die Spalte als eindeutig definiert wurde.

Die Überprüfung der referenziellen Integrität während eines UPDATE-Vorgangs ist nicht einfacher, als wenn die Überprüfung während eines INSERT-Vorgangs durchgeführt wird. Wenn Sie den Wert eines Primärschlüssels ändern, können Sie dadurch Waisen schaffen. Wenn Sie die neuen Werte einfügen, muss der Datenbankserver erneut eine Überprüfung auf Waisen durchführen.

Siehe auch

Kommentieren Sie diese Seite in DocCommentXchange.