Zusammenfassung

Transaktionen und Sperren sind fast so wichtig wie die Beziehungen zwischen Tabellen. Die Integrität und Performance einer Datenbank kann durch die richtige Verwendung von Sperren und den sorgfältigen Aufbau von Transaktionen profitieren. Transaktionen und Sperren sind für jede Datenbank unerlässlich, die eine große Anzahl von Befehlen ausführt.

Transaktionen fassen SQL-Anweisungen in logische Arbeitseinheiten zusammen. Um Transaktionen abzuschließen, können Sie entweder alle durchgeführten Änderungen zurücksetzen oder die Änderungen festschreiben, um sie dauerhaft zu machen.

Bei einem Systemausfall sind Transaktionen für die Datenwiederherstellung unerlässlich. Sie spielen auch eine wichtige Rolle bei der Überlagerung der Anweisungen von gleichzeitig ablaufenden Transaktionen.

Für eine verbesserte Performance müssen mehrere Transaktionen gleichzeitig ausgeführt werden. Jede Transaktion besteht aus SQL-Anweisungskomponenten. Werden zwei oder mehrere Transaktionen gleichzeitig ausgeführt, muss der Datenbankserver die Ausführung der einzelnen Anweisungen planen. Im Gegensatz zu sequenziell ausgeführten Transaktionen können parallele Transaktionen zu Inkonsistenzen führen.

Vier Typen von Inkonsistenzen werden verwendet, um Isolationsstufen festzulegen:

Dirty Reads Eine Transaktion liest Daten, die von einer anderen Transaktion geändert, aber noch nicht festgeschrieben wurden.
Nicht-wiederholbare Lesevorgänge Eine Transaktion liest die gleiche Zeile zweimal und erhält unterschiedliche Ergebnisse.
Phantomzeilen Eine Transaktion wählt Zeilen mit einem bestimmten Kriterium zweimal aus und findet in der zweiten Ergebnismenge neue Zeilen.
Verlorenes Update Die Änderungen, die von einer Transaktion in einer Zeile durchgeführt wurden, gehen vollständig verloren, da eine andere Transaktion ein auf früheren Daten beruhendes Update speichern kann.

Ein Schema wird als serialisierbar bezeichnet, wenn die Wirkung durch die Ausführung der Anweisungen in Übereinstimmung mit dem Schema die gleiche ist, als wenn jede Transaktion sequenziell ausgeführt worden wäre. Schemata gelten als korrekt, wenn sie serialisierbar sind. Ein serialisierbares Schema verursacht keine der vorstehend angeführten Inkonsistenzen.

Sperren steuern die Anzahl und Arten der zulässigen Überlagerungen. SQL Anywhere bietet Ihnen vier Sperrstufen: Isolationsstufen 0, 1, 2 und 3. Bei der höchsten Isolationsstufe, Stufe 3, gewährleistet SQL Anywhere, dass das Schema serialisierbar ist, das heißt, dass das Ergebnis aller ausgeführten Transaktionen gleich ist wie bei einer sequenziellen Ausführung.

Leider können aber von einer Transaktion gesetzte Sperren den Fortschritt anderer Transaktionen behindern. Daher ist es wünschenswert, niedrigere Isolationsstufen zu verwenden, wenn die dadurch möglichen Inkonsistenzen akzeptiert werden können. Eine erhöhte Isolation für eine verbesserte Datenkonsistenz bedeutet häufig eine niedrigere Parallelität und Effizienz der Datenbank bei der Bearbeitung gleichzeitig ablaufender Transaktionen. Sie müssen häufig die Notwendigkeit für Konsistenz mit der Notwendigkeit für Performance abwägen, um die beste Isolationsstufe für jeden Vorgang zu ermitteln.

Widersprüchliche Sperrenanforderungen zwischen verschiedenen Transaktionen können zu Blockierungen oder Deadlocks führen. SQL Anywhere enthält Verfahren für beide Situationen und bietet Ihnen Optionen für deren Steuerung.

Transaktionen mit höheren Isolationsstufen müssen aber nicht immer eine negative Auswirkung auf die Parallelität haben. Andere Transaktionen werden nur behindert, wenn sie einen Zugriff auf gesperrte Zeilen verlangen. Sie können die Parallelität durch eine sorgfältige Planung Ihrer Datenbank und Transaktionen verbessern. So können Sie zum Beispiel die Zeit für Sperren verkürzen, indem Sie eine Transaktion in zwei kürzere aufteilen, oder Sie stellen fest, dass durch einen Index Ihre Transaktion auf einer höheren Isolationsstufe mit weniger Sperren auskommt.

Kommentieren Sie diese Seite in DocCommentXchange.