Transaktionsisolationsstufen

2.1 Unverbindlich lesen

Die „Transaktionsisolationsstufe“ bezieht sich auf den Grad des Schutzes, den die internen Mechanismen des DBMS (d. h. keine besondere Programmierung erfordern) vor allen oder einigen der oben genannten Arten von Dateninkonsistenzen bieten, die während der parallelen Ausführung von Transaktionen auftreten. Der SQL-92-Standard definiert eine Skala von vier Isolationsstufen:

• Unverbindlich lesen
• Lesen Sie engagiert
• Wiederholbare Lektüre
• Serialisierbar

Der erste von ihnen ist der schwächste, der letzte der stärkste, jeder weitere umfasst alle vorherigen.

Die niedrigste (erste) Isolationsstufe. Wenn mehrere parallele Transaktionen versuchen, dieselbe Tabellenzeile zu ändern, hat die letzte Zeile einen Wert, der durch die gesamte Menge erfolgreich abgeschlossener Transaktionen bestimmt wird. In diesem Fall können nicht nur logisch inkonsistente Daten gelesen werden, sondern auch Daten, deren Änderungen noch nicht erfasst wurden.

Eine typische Möglichkeit, diese Isolationsstufe zu implementieren, besteht darin, Daten während der Ausführung des Änderungsbefehls zu sperren. Dadurch wird sichergestellt, dass Änderungsbefehle für dieselben parallel ausgeführten Zeilen tatsächlich sequentiell ausgeführt werden und keine Änderungen verloren gehen. Schreibgeschützte Transaktionen werden unter dieser Isolationsstufe niemals blockiert.

2.2 Lesen Sie fest

Die meisten industriellen DBMS, insbesondere Microsoft SQL Server, PostgreSQL und Oracle, verwenden diese Ebene standardmäßig. Auf dieser Ebene ist ein Schutz vor Zugluft und „schmutzigem“ Lesen gegeben. Während des Betriebs einer Transaktion kann jedoch eine andere erfolgreich abgeschlossen werden und die von ihr vorgenommenen Änderungen werden behoben. Dies führt dazu, dass die erste Transaktion mit einem anderen Datensatz funktioniert.

Die Implementierung eines vollständigen Lesevorgangs kann auf einem von zwei Ansätzen basieren: Blockierung oder Versionierung.

Blockieren lesbarer und veränderlicher Daten.

Es besteht darin, dass die Schreibtransaktion veränderliche Daten für Lesetransaktionen sperrt, die auf der Lese-Committed-Ebene oder höher ausgeführt werden, bis sie abgeschlossen ist, wodurch ein „schmutziges“ Lesen verhindert wird, und die durch die Lesetransaktion gesperrten Daten sofort nach Abschluss der Operation freigegeben werden SELECT(Daher kann bei einer gegebenen Isolationsstufe eine Situation des „nicht wiederholbaren Lesens“ auftreten.)

Speichern mehrerer Versionen von Zeilen, die sich parallel ändern.

Jedes Mal, wenn eine Zeile geändert wird, erstellt das DBMS eine neue Version dieser Zeile, mit der die Transaktion, die die Daten geändert hat, weiterhin funktioniert, während jede andere „lesende“ Transaktion die letzte festgeschriebene Version zurückgibt. Der Vorteil dieses Ansatzes besteht darin, dass er schneller ist, da er Blockierungen verhindert. Allerdings erfordert es im Vergleich zum ersten einen deutlich höheren RAM-Verbrauch, der für die Speicherung von Zeilenversionen aufgewendet wird.

Wenn mehrere Transaktionen Daten parallel ändern, kann es darüber hinaus zu einer Situation kommen, in der mehrere gleichzeitige Transaktionen inkonsistente Änderungen an denselben Daten vornehmen (da es keine Sperren gibt, kann dies nicht verhindert werden). Dann speichert die Transaktion, die zuerst festschreibt, ihre Änderungen in der Hauptdatenbank, und die verbleibenden parallelen Transaktionen können nicht festgeschrieben werden (da dies zum Verlust der Aktualisierung der ersten Transaktion führt). Das einzige, was das DBMS in einer solchen Situation tun kann, ist, die restlichen Transaktionen zurückzusetzen und eine Fehlermeldung auszugeben: „Der Datensatz wurde bereits geändert“.

Eine bestimmte Implementierungsmethode wird von den DBMS-Entwicklern ausgewählt und kann in einigen Fällen angepasst werden. Standardmäßig verwendet MS SQL also Sperren, wechselt jedoch (ab Version 2005) beim Setzen des READ_COMMITTED_SNAPSHOTDatenbankparameters zur Versionierungsstrategie, Oracle arbeitet zunächst nur nach dem versionierten Schema. In Informix können Sie Konflikte zwischen Lese- und Schreibtransaktionen verhindern, indem Sie eine Konfigurationsoption festlegen USELASTCOMMITTED(ab Version 11.1), die bewirkt, dass die Lesetransaktion die neuesten festgeschriebenen Daten empfängt.

2.3 Wiederholbares Lesen

Die Ebene, auf der eine Lesetransaktion Änderungen an den Daten, die sie zuvor gelesen hat, „nicht sieht“. Gleichzeitig kann keine andere Transaktion die von der aktuellen Transaktion gelesenen Daten ändern, bis sie endet.

Sperren im Shared-Modus werden auf alle Daten angewendet, die von einer beliebigen Anweisung in einer Transaktion gelesen werden, und werden gehalten, bis die Transaktion abgeschlossen ist. Dadurch wird verhindert, dass andere Transaktionen Zeilen ändern, die von der ausstehenden Transaktion gelesen wurden. Andere Transaktionen fügen jedoch möglicherweise Zeilenumbrüche ein, die den Suchbedingungen für Anweisungen entsprechen, die in der aktuellen Transaktion enthalten sind. Wenn die Anweisung durch die aktuelle Transaktion neu gestartet wird, werden neue Zeilen abgerufen, was zu einem Phantomlesevorgang führt.

Da gemeinsame Sperren bis zum Ende der Transaktion gehalten werden und nicht am Ende jeder Anweisung freigegeben werden, ist der Grad der Parallelität niedriger als der Isolationsgrad READ COMMITTED. Daher wird generell davon abgeraten, diese und höhere Transaktionsebenen unnötig zu verwenden.

2.4 Serialisierbar

Das höchste Maß an Isolation; Transaktionen sind vollständig voneinander isoliert, jede einzelne wird so ausgeführt, als ob es keine parallelen Transaktionen gäbe. Nur auf dieser Ebene unterliegen gleichzeitige Transaktionen nicht dem „Phantom-Read“-Effekt.

2.5 Unterstützung für Transaktionsisolation in echtem DBMS

Transaktionale DBMS unterstützen nicht immer alle vier Ebenen und führen möglicherweise auch zusätzliche Ebenen ein. Auch bei der Isolierung gibt es verschiedene Nuancen.

Daher unterstützt Oracle im Prinzip die Nullebene nicht, da seine Implementierung von Transaktionen „Dirty Reads“ ausschließt und das Festlegen der Ebene „Repeatable Read“ formal nicht zulässt, d. h. es unterstützt nur (standardmäßig) Read committedund Serializable. Gleichzeitig garantiert es auf der Ebene einzelner Befehle tatsächlich die Wiederholbarkeit des Lesens (wenn ein Befehl SELECTin der ersten Transaktion eine Reihe von Zeilen aus der Datenbank auswählt und zu diesem Zeitpunkt eine parallele zweite Transaktion einige dieser Zeilen ändert, dann Die von der ersten Transaktion empfangene Ergebnismenge enthält unveränderte Zeilen, als ob es keine zweite Transaktion gäbe. Oracle unterstützt auch sogenannte READ-ONLYTransaktionen, die zwar entsprechen Serializable, die Daten aber selbst nicht verändern können.

Und Microsoft SQL Server unterstützt alle vier standardmäßigen Transaktionsisolationsstufen und zusätzlich die SNAPSHOT-Ebene, auf der die Transaktion den Status der Daten sieht, die vor ihrem Start festgeschrieben wurden, sowie die von ihr selbst vorgenommenen Änderungen, d. h. sie verhält sich so, als ob es beim Start einen Snapshot der DB-Daten erhalten hätte und damit arbeiten würde. Der Unterschied zu „Serialized“ besteht darin, dass keine Sperren verwendet werden. Daher ist das Festschreiben von Änderungen möglicherweise nicht möglich, wenn eine gleichzeitige Transaktion zuvor dieselben Daten geändert hat. In diesem Fall wird die zweite Transaktion beim Ausführungsversuch COMMITeine Fehlermeldung auslösen und abgebrochen werden.