Probleme gleichzeitiger Transaktionen

1.1 Einleitung

Und jetzt beginnt der Spaß – die Theorie, wie Transaktionen funktionieren. Wie bleibt das System funktionsfähig, wenn Sie dieselben Daten in verschiedenen Threads ändern? Oder möchten Sie eine Transaktion in einer anderen ausführen? Wir werden beginnen, nach Antworten auf diese Fragen zu suchen, indem wir die Isolierung von Transaktionen untersuchen ...

Die Transaktionsisolationsstufe ist ein bedingter Wert, der bestimmt, inwieweit infolge der Ausführung logisch paralleler Transaktionen im DBMS inkonsistente Daten zulässig sind. Die Skala der Transaktionsisolationsstufen enthält eine Reihe von Werten, die vom niedrigsten zum höchsten Wert geordnet sind. Eine höhere Isolationsstufe entspricht einer besseren Datenkonsistenz, ihre Verwendung kann jedoch die Anzahl physisch paralleler Transaktionen verringern.

Umgekehrt ermöglicht eine niedrigere Isolationsstufe mehr parallele Transaktionen, verringert jedoch die Datengenauigkeit. Somit bietet der Entwickler des Informationssystems durch die Wahl des verwendeten Grades der Transaktionsisolation gewissermaßen die Wahl zwischen der Arbeitsgeschwindigkeit und der Gewährleistung der garantierten Konsistenz der vom System empfangenen Daten.

Probleme des gleichzeitigen Zugriffs mithilfe von Transaktionen

Bei der parallelen Ausführung von Transaktionen können folgende Probleme auftreten:

• verlorene Aktualisierung – wenn ein Datenblock gleichzeitig durch verschiedene Transaktionen geändert wird, gehen alle Änderungen außer der letzten verloren;
• „schmutziges“ Lesen (engl. Dirty Read) – Lesen von durch eine Transaktion hinzugefügten oder geänderten Daten, die anschließend nicht bestätigt (zurückgesetzt) ​​werden;
• nicht wiederholbares Lesen (dt. nicht wiederholbares Lesen) – beim erneuten Lesen innerhalb derselben Transaktion werden zuvor gelesene Daten geändert;
• Phantom-Lesevorgänge – eine Transaktion wählt während ihrer mehrmaligen Ausführung viele Zeilen nach denselben Kriterien aus. Eine weitere Transaktion zwischen diesen Abrufvorgängen fügt Zeilen hinzu oder ändert Spalten einiger der Zeilen, die in den Abrufkriterien der ersten Transaktion verwendet werden, und wird erfolgreich abgeschlossen. Als Ergebnis stellt sich heraus, dass dieselben Auswahlen in der ersten Transaktion unterschiedliche Zeilensätze ergeben.

Bedenken Sie Situationen, in denen diese Probleme auftreten können.

1.2 Update verloren

Die Situation, in der bei gleichzeitiger Änderung eines Datenblocks durch verschiedene Transaktionen eine der Änderungen verloren geht.

Angenommen, es laufen zwei Transaktionen gleichzeitig:

Bei beiden Transaktionen ändert sich der Wert des Feldes f2; nach Abschluss muss der Wert des Feldes um 45 erhöht werden. Tatsächlich kann die folgende Abfolge von Aktionen auftreten:

1. Beide Transaktionen lesen gleichzeitig den aktuellen Zustand des Feldes. Eine exakte physische Parallelität ist hier nicht erforderlich, es reicht aus, dass der zweite Lesevorgang der Reihe nach abgeschlossen ist, bevor eine andere Transaktion ihr Ergebnis schreibt.
2. Beide Transaktionen berechnen den neuen Feldwert, indem sie 20 bzw. 25 zum zuvor gelesenen Wert addieren.
3. Transaktionen versuchen, das Ergebnis der Berechnung zurück in das Feld f2 zu schreiben. Da es physikalisch unmöglich ist, zwei Schreibvorgänge gleichzeitig durchzuführen, wird in Wirklichkeit einer der Schreibvorgänge früher und der andere später ausgeführt. Der zweite Schreibvorgang überschreibt das Ergebnis des ersten.

Infolgedessen kann sich der Wert des Feldes f2 nach Abschluss beider Transaktionen nicht um 45, sondern um 20 oder 25 erhöhen, d. h. eine der datenverändernden Transaktionen wird „verschwinden“.

1.3 „Schmutzige“ Lektüre

Lesen von Daten, die durch eine Transaktion hinzugefügt oder geändert wurden, deren Festschreibung später fehlschlägt (Rollback).

Angenommen, wir haben zwei Transaktionen, die von verschiedenen Anwendungen geöffnet werden, die die folgenden SQL-Anweisungen ausführen:

In Transaktion 1 wird der Wert des Feldes f2 geändert und dann in Transaktion 2 der Wert dieses Feldes ausgewählt. Danach wird Transaktion 1 zurückgesetzt. Dadurch weicht der von der zweiten Transaktion empfangene Wert von dem in der Datenbank gespeicherten Wert ab.

1.4 Nicht wiederholbare Lesung

Die Situation, wenn sich beim erneuten Lesen innerhalb derselben Transaktion herausstellt, dass zuvor gelesene Daten geändert wurden.

Angenommen, wir haben zwei Transaktionen, die von verschiedenen Anwendungen geöffnet werden, die die folgenden SQL-Anweisungen ausführen:

In Transaktion 2 wird der Wert von Feld f2 ausgewählt, dann wird in Transaktion 1 der Wert von Feld f2 geändert. Wenn Sie in Transaktion 2 erneut versuchen, einen Wert aus Feld f2 auszuwählen, erhalten Sie ein anderes Ergebnis. Diese Situation ist insbesondere dann inakzeptabel, wenn die Daten gelesen werden, um sie teilweise zu ändern und wieder in die Datenbank zu schreiben.

1.5 „Phantome“ lesen

Die Situation, wenn beim wiederholten Lesen innerhalb derselben Transaktion dieselbe Auswahl unterschiedliche Zeilensätze ergibt.

Angenommen, es gibt zwei Transaktionen, die von verschiedenen Anwendungen geöffnet werden, die die folgenden SQL-Anweisungen ausführen:

Transaktion 2 führt eine SQL-Anweisung aus, die alle Werte des Feldes f2 verwendet. Dann wird in Transaktion 1 eine neue Zeile eingefügt, wodurch die erneute Ausführung der SQL-Anweisung in Transaktion 2 zu einem anderen Ergebnis führt. Diese Situation wird Phantomlesen (Phantomlesen) genannt. Der Unterschied zum nicht wiederholbaren Lesen besteht darin, dass sich das Ergebnis des wiederholten Datenzugriffs nicht aufgrund der Änderung/Löschung der Daten selbst, sondern aufgrund des Auftretens neuer (Phantom-)Daten geändert hat.