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

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

 

Sperren bei Einfügungen

INSERT-Vorgänge erstellen neue Zeilen. SQL Anywhere setzt während Einfügungen unterschiedliche Sperrentypen ein, um die Datenintegrität zu gewährleisten. Die folgende Reihenfolge der Vorgänge gilt für INSERT-Anweisungen, die auf einer beliebigen Isolationsstufe ausgeführt werden.

  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.

  3. Es wird eine nicht gesperrte Position auf einer Seite gesucht, um die neue Zeile zu speichern. Um Sperrenkonflikte zu minimieren, belegt der Server den Platz, der durch gelöschte (aber noch nicht festgeschriebene) Zeilen verfügbar wurde, nicht sofort wieder. Der Tabelle kann eine neue Seite zugeordnet werden (und die Datenbankdatei könnte anwachsen), um die neue Zeile unterzubringen.

  4. In der neuen Zeile werden die Werte eingetragen.

  5. In der Tabelle, in der die Zeile hinzugefügt wird, wird eine Einfügesperre gesetzt. Bedenken Sie, dass Einfügesperren Exklusivsperren sind. Das heißt, sobald die Einfügesperre gesetzt ist, kann keine andere Transaktion auf Isolationsstufe 3 die Einfügung durch das Setzen einer Phantomsperre blockieren.

  6. Die neue Zeile wird mit einer Schreibsperre versehen. Die Einfügesperre wird freigegeben, sobald die Schreibsperre gesetzt wurde.

  7. Die Zeile wird in die Tabelle eingefügt. Andere Transaktionen auf Isolationsstufe 0 können jetzt zum ersten Mal erkennen, dass die neue Zeile existiert. Diese anderen Transaktionen können jedoch die neue Zeile wegen der zuvor gesetzte Schreibsperre weder ändern noch löschen.

  8. Alle betroffenen Indizes werden aktualisiert und die Eindeutigkeit wird geprüft, wo dies erforderlich ist. Primärschlüsselwerte müssen eindeutig sein. Andere Spalten können ebenfalls so definiert werden, dass sie nur eindeutige Werte enthalten.Wenn solche Spalten definiert wurden, muss auch die Eindeutigkeit überprüft werden.

  9. Wenn es sich bei der Tabelle um eine Fremdtabelle handelt, wird eine gemeinsame Schemasperre für die Primärtabelle gesetzt (falls nicht bereits vorhanden). Für die entsprechende Primärzeile in der Primärtabelle wird eine Lesesperre gesetzt, wenn die eingefügten Werte für die Fremdschlüsselspalte nicht gleich NULL sind. Der Datenbankserver muss gewährleisten, dass die Primärzeile noch vorhanden ist, wenn die COMMIT-Anweisungen der Transaktion ausgeführt werden. Dies geschieht, indem er eine Lesesperre für die Primärzeile setzt. Sobald die Lesesperre gesetzt ist, kann eine andere Transaktion diese Zeile zwar lesen, aber keine Transaktion kann sie löschen oder aktualisieren.

    Falls die entsprechende Primärzeile nicht vorhanden ist, kommt es zu einer Verletzung der referenziellen Integritätsregel.

Nach dem letzten Schritt können alle für die Tabelle definierten AFTER INSERT-Trigger ausgelöst werden. Bei der Verarbeitung innerhalb der Trigger verhalten Sperren sich ebenso wie bei Anwendungen. Sobald die Transaktion festgeschrieben (falls alle referenziellen Integritätsregeln erfüllt wurden) oder zurückgesetzt wurde, werden alle langfristigen Sperren freigegeben.

 Eindeutigkeit
 Waisen und referenzielle Integrität
 wait_for_commit