Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Deutsch) » SQL Anywhere Server - SQL-Benutzerhandbuch » Datenbanken erstellen » Transaktionen und Isolationsstufen verwenden » Funktionsweise von Sperren

 

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.

  1. Es wird eine gemeinsame Schemasperre für die Tabelle gesetzt, falls eine solche nicht bereits vorhanden ist.

  2. Es wird eine Tabellensperre für Schreibabsicht für die Tabelle gesetzt, falls eine solche nicht bereits vorhanden ist.

    1. Die zu aktualisierenden Zeilen werden festgelegt. Während Zeilen durchsucht werden, sind sie gesperrt. Das Standard-Sperrverhalten wird unter Isolationsstufen und Konsistenz beschrieben.

      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 in einigen Fällen können Sperren für Schreibabsicht bei Zeilen gesetzt werden, die schließlich als Kandidaten für eine Aktualisierung verworfen werden.

    2. Für jede in Schritt 2 festgelegte Kandidatenzeile wird die verbleibende Sequenz durchgeführt.

  3. Die betroffene Zeile wird mit einer Schreibsperre versehen.

  4. Jeder der betroffenen Spaltenwerte wird gemäß der UPDATE-Anweisung aktualisiert.

  5. 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.

  6. Falls Fremdschlüsselwerte in der Zeile geändert wurden, wird eine gemeinsame Schemasperre für die Primärtabelle(n) gesetzt, und für das Einfügen neuer Fremdschlüsselwerte wird die gleiche Prozedur durchgeführt, die unter Sperren bei Einfügungen beschrieben wird. Falls zutreffend, wird ebenfalls die Prozedur für WAIT_FOR_COMMIT durchgeführt.

  7. 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.

Nach dem letzten Schritt können alle AFTER UPDATE-Trigger ausgelöst werden. 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.