Der DELETE-Vorgang verläuft fast in derselben Prozedur wie der INSERT-Vorgang, nur in umgekehrter Reihenfolge. Wie bei Einfügungen und Aktualisierungen 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 die Tabelle gesetzt, falls eine solche nicht bereits vorhanden ist.
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.
Für jede in Schritt 2 festgelegte Kandidatenzeile wird die verbleibende Sequenz durchgeführt.
Für die zu löschende Zeile wird eine Schreibsperre gesetzt.
Die Zeile wird aus der Tabelle entfernt, sodass sie nicht mehr von anderen Transaktionen gesehen werden kann. Die Zeile kann erst gelöscht werden, wenn die Transaktion festgeschrieben wurde, da ansonsten die Transaktion nicht mehr zurückgesetzt werden kann. Die Indexeinträge für die gelöschte Zeile werden aufbewahrt, aber als gelöscht gekennzeichnet, bis die Transaktion abgeschlossen ist. Damit wird verhindert, dass andere Transaktionen die gleiche Zeile neu einfügen.
Wenn die Tabelle eine Primärtabelle in einer referenziellen Integritätsbeziehung ist und es sich bei dem DELETE-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.
Die Transaktion kann festgeschrieben werden, wenn die referenzielle Integrität dadurch nicht beeinträchtigt wird. Zur Überprüfung der referenziellen Integrität protokolliert der Datenbankserver alle Waisen, die als Nebenwirkung des Löschvorgangs geschaffen wurden. Bei COMMIT protokolliert der Server den Vorgang in der Transaktionslogdatei und gibt alle Sperren frei.
Siehe auch |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |