Transaktionen und Parallelitätskontrollen: DBMS

Transaktionen im DB Management System (DBMS)

Definition:

Eine Transaktion in einem Datenbankverwaltungssystem (DBMS) ist eine Abfolge von Vorgängen, die als eine einzige logische Arbeitseinheit ausgeführt werden. Eine Transaktion kann das Lesen, Einfügen, Aktualisieren oder Löschen von Daten in der Datenbank umfassen. Das Hauptmerkmal einer Transaktion ist, dass sie atomar ist, was bedeutet, dass alle Vorgänge innerhalb einer Transaktion erfolgreich abgeschlossen werden oder keiner von ihnen auf die Datenbank angewendet wird.

---

Schlüsseleigenschaften von Transaktionen: ACID-Eigenschaften

Transaktionen müssen den ACID-Eigenschaften entsprechen, um die Konsistenz und Zuverlässigkeit der Datenbank sicherzustellen. Diese Eigenschaften sind:

1. Atomizität:

   • Atomizität stellt sicher, dass eine Transaktion als eine einzige, unteilbare Arbeitseinheit behandelt wird. Entweder werden alle Vorgänge innerhalb der Transaktion ausgeführt oder keine. Wenn ein Teil der Transaktion fehlschlägt, wird die gesamte Transaktion zurückgesetzt, um sicherzustellen, dass die Datenbank in einem konsistenten Zustand bleibt.
   • Beispiel: Wenn bei einer Transaktion Geld von Konto A auf Konto B übertragen wird, stellt die Atomizität sicher, dass entweder die gesamte Überweisung abgeschlossen ist (Geld wird von A abgezogen und zu B hinzugefügt) oder nichts geschieht (es wird kein Geld überwiesen). wenn es einen Fehler gibt).

2. Konsistenz:

   • Konsistenz stellt sicher, dass eine Transaktion die Datenbank von einem gültigen Zustand in einen anderen verschiebt. Jede Transaktion sollte die Integritätsbeschränkungen der Datenbank (z. B. Primärschlüssel, Fremdschlüssel usw.) nicht verletzen. Nachdem die Transaktion festgeschrieben wurde, sollte sich die Datenbank immer in einem konsistenten Zustand befinden.
   • Beispiel: Nach der Überweisung von Geld zwischen zwei Bankkonten sollte die Summe der Guthaben auf beiden Konten konstant bleiben. Wenn die Datenbankkonsistenzregel verletzt wird, wird die Transaktion zurückgesetzt.

3. Isolation:

   • Durch die Isolierung wird sichergestellt, dass die Vorgänge einer Transaktion während der Ausführung vor anderen Transaktionen verborgen bleiben. Auch wenn mehrere Transaktionen gleichzeitig stattfinden, sollte jede Transaktion nichts von den Vorgängen der anderen wissen. Dies verhindert Dirty Reads, nicht wiederholbare Reads und Phantom Reads.
   • Beispiel: Wenn zwei Benutzer gleichzeitig Geld von demselben Bankkonto überweisen, stellt die Isolierung sicher, dass eine Transaktion die andere nicht beeinträchtigt, wodurch Fehler wie Doppelabhebungen vermieden werden.

4. Haltbarkeit:

   • Dauerhaftigkeit garantiert, dass die Änderungen einer einmal festgeschriebenen Transaktion auch im Falle eines Systemabsturzes dauerhaft sind. Nach einem erfolgreichen Commit werden die durch die Transaktion vorgenommenen Änderungen in der Datenbank gespeichert und gehen nicht verloren.
   • Beispiel: Wenn ein Benutzer erfolgreich eine Bestellung aufgegeben hat, sollten die Änderungen in der Datenbank (z. B. Bestandsaktualisierung und Auftragserteilung) bestehen bleiben, auch wenn es direkt nach dem Commit zu einem plötzlichen Stromausfall kommt.

---

Arten von Transaktionen

1. Einfache Transaktionen:

   • Dabei handelt es sich um einen einzigen Vorgang wie das Lesen oder Schreiben von Daten. Beispielsweise könnte eine einfache Leseabfrage oder eine Aktualisierungsabfrage Teil einer Transaktion sein.

2. Komplexe Transaktionen:

   • Dazu gehören mehrere Vorgänge, einschließlich Lesevorgänge, Aktualisierungen, Einfügungen und Löschvorgänge. Bei einer komplexen Transaktion kann es sich um eine Abfolge von Vorgängen handeln, die darauf abzielen, einen Geschäftsprozess abzuschließen, z. B. die Überweisung von Geld von einem Konto auf ein anderes, bei der der Kontostand überprüft, von einem Konto abgebucht und auf das andere Konto addiert wird.

---

Transaktionslebenszyklus

Eine typische Transaktion folgt diesen Schritten:

1. Transaktion beginnen:

   • Dies markiert den Beginn einer Transaktion. Es zeigt an, dass eine neue Transaktion durchgeführt werden soll.

2. Vorgänge ausführen:

   • Die Transaktion führt eine Reihe von Datenbankvorgängen aus, z. B. das Auswählen, Einfügen, Aktualisieren oder Löschen von Datensätzen. Diese Vorgänge werden im Rahmen der Transaktion nacheinander ausgeführt.

3. Transaktion festschreiben:

   • Nachdem alle Vorgänge abgeschlossen sind, wird die Transaktion festgeschrieben. Das bedeutet, dass alle durch die Transaktion vorgenommenen Änderungen dauerhaft in der Datenbank gespeichert werden. Sobald die Transaktion festgeschrieben wurde, kann sie nicht mehr rückgängig gemacht werden.

4. Rollback-Transaktion:

   • Wenn während der Transaktionsausführung ein Fehler auftritt (z. B. eine Verletzung einer Einschränkung), wird die Transaktion zurückgesetzt. Dies bedeutet, dass alle durch die Transaktion vorgenommenen Änderungen rückgängig gemacht werden und die Datenbank in ihren ursprünglichen Zustand zurückkehrt.

5. Transaktion beenden:

   • Nach einem Commit oder Rollback endet die Transaktion. Dies bedeutet, dass der Lebenszyklus der Transaktion abgeschlossen ist.

---

Transaktionszustände

Eine Transaktion muss sich während ihres Lebenszyklus in einem der folgenden Zustände befinden:

1. Aktiv:

   • Der Anfangszustand einer Transaktion. Die Transaktion bleibt in diesem Zustand, während sie Operationen ausführt und ausführt.

2. Teilweise engagiert:

   • Dieser Zustand tritt ein, nachdem die endgültige Abrechnung der Transaktion ausgeführt wurde. Zu diesem Zeitpunkt hat die Transaktion alle Vorgänge abgeschlossen, wurde jedoch noch nicht in die Datenbank übernommen.

3. Fehlgeschlagen:

   • Eine Transaktion wechselt in den Status fehlgeschlagen, wenn festgestellt wird, dass die normale Ausführung nicht mehr fortgesetzt werden kann, normalerweise aufgrund eines Problems wie einer Einschränkungsverletzung oder eines Systemfehlers.

4. Abgebrochen:

   • Nachdem die Transaktion zurückgesetzt wurde und die Datenbank in den Zustand vor Beginn der Transaktion zurückversetzt wurde, wechselt sie in den Status abgebrochen.

5. Engagiert:

   • Eine Transaktion wechselt in den Status festgeschrieben, nachdem alle Vorgänge erfolgreich abgeschlossen wurden und ihre Änderungen dauerhaft auf die Datenbank angewendet wurden.

6. Beendet:

   • Eine Transaktion gilt als beendet, wenn sie entweder festgeschrieben oder abgebrochen wurde. Sobald eine Transaktion den Status „Festgeschrieben“ oder „Abgebrochen“ erreicht hat, kann sie nicht neu gestartet werden.

---

Zeitpläne im DBMS

Ein Zeitplan ist eine Abfolge von Vorgängen aus mehreren Transaktionen, die in einer bestimmten Reihenfolge ausgeführt werden. Ein Zeitplan bestimmt die Ausführungsreihenfolge von Lese- und Schreibvorgängen für mehrere Transaktionen. Das Hauptziel besteht darin, zu bestimmen, wie gleichzeitige Transaktionen interagieren und sicherzustellen, dass die Datenbank in einem konsistenten Zustand bleibt.

Ein Zeitplan kann seriell oder nicht seriell sein.

---

Arten von Zeitplänen

1. Serienplan:
   • Ein serieller Zeitplan ist ein Zeitplan, bei dem Transaktionen nacheinander ohne Verschachtelung ausgeführt werden. Dies bedeutet, dass die Vorgänge einer Transaktion vollständig abgeschlossen sind, bevor die nächste Transaktion beginnt.
   • In einem seriellen Zeitplan gibt es keine Parallelität und der Zeitplan entspricht der sequentiellen Ausführung der Transaktionen.

Beispiel eines Serienplans:

• Transaktion 1: T1: Read(A); Schreiben(A); Begehen
• Transaktion 2: T2: Read(B); Schreiben(B); Begehen
• Die Transaktionen werden nacheinander ausgeführt und es gibt keine Überschneidungen in den Vorgängen.

1. Nicht-serieller Zeitplan:
   • Ein nicht serieller Zeitplan ermöglicht die Verschachtelung von Vorgängen aus mehreren Transaktionen. Bei dieser Art von Zeitplan werden Transaktionen gleichzeitig ausgeführt, was bedeutet, dass ihre Vorgänge miteinander vermischt sind.
   • Ein nicht serieller Zeitplan kann je nach der Reihenfolge, in der Vorgänge ausgeführt werden, zu unterschiedlichen Ergebnissen führen. Dies erfordert eine sorgfältige Verwaltung, um die ACID-Eigenschaften beizubehalten.

Beispiel für einen nicht-seriellen Zeitplan:

• T1: Lesen(A); Schreiben Sie(A);
• T2: Lesen(B); Schreiben Sie(B);
• T1: Commit;
• T2: Commit;
• Die Operationen der Transaktionen T1 und T2 sind verschachtelt.

---

Serialisierbarkeit

Serialisierbarkeit ist das Konzept, mit dem sichergestellt werden soll, dass das Ergebnis der gleichzeitigen Ausführung mehrerer Transaktionen dasselbe ist, als ob die Transaktionen seriell (eine nach der anderen) ausgeführt würden. Ein Zeitplan wird als serialisierbar bezeichnet, wenn er hinsichtlich seiner Auswirkung auf die Datenbank einem seriellen Zeitplan entspricht.

Wichtigkeit:

Das Ziel der Serialisierbarkeit besteht darin, sicherzustellen, dass gleichzeitige Transaktionen keine Konflikte oder Anomalien (wie schmutzige Lesevorgänge, verlorene Aktualisierungen usw.) verursachen und dass die Datenbank in einem konsistenten Zustand bleibt.

Es gibt zwei Haupttypen der Serialisierbarkeit:

1. Konfliktserialisierbarkeit:
   • Ein Zeitplan ist konfliktserialisierbar, wenn er durch Austauschen nicht widersprüchlicher Vorgänge in einen seriellen Zeitplan umgewandelt werden kann. Zwei Vorgänge gelten als widersprüchlich, wenn sie aus unterschiedlichen Transaktionen stammen, auf dasselbe Datenelement zugreifen und mindestens einer davon ein Schreibvorgang ist.
   • Konflikteinsätze:
     • Ein Lese-/Schreibkonflikt tritt auf, wenn eine Transaktion ein Datenelement liest, das eine andere Transaktion schreibt.
     • Ein Schreib-Schreib-Konflikt tritt auf, wenn zwei Transaktionen beide auf dasselbe Datenelement schreiben.

Beispiel für die Serialisierbarkeit von Konflikten:

• Zeitplan:
  • T1: Schreiben Sie (A);
  • T2: Schreiben(B);
  • T1: Lesen(B);
  • T2: Lesen(A);
• Dieser Zeitplan kann in einen seriellen Zeitplan umgewandelt werden und ist konfliktserialisierbar.

1. Serialisierungsfähigkeit anzeigen:
   • Ein Zeitplan ist ansichtsserialisierbar, wenn er hinsichtlich des Endergebnisses einem seriellen Zeitplan entspricht, d. h. die gleichen Lese- und Schreibvorgänge erfolgen und die Transaktionen korrekt serialisiert werden. Im Hinblick auf die Serialisierbarkeit müssen die Operationen jedoch nicht unbedingt wie bei der Konfliktserialisierbarkeit vertauscht werden.

---

Konfliktäquivalent, Konfliktserialisierbar

• Konfliktäquivalent:

  • Zwei Zeitpläne gelten als konfliktäquivalent, wenn sie dieselben Vorgänge enthalten, die Vorgänge in derselben Reihenfolge sind und die Reihenfolge der widersprüchlichen Vorgänge beibehalten wird. Dies bedeutet, dass die Verschachtelung von Transaktionen in beiden Zeitplänen zum gleichen Ergebnis führt und somit sichergestellt ist, dass sie konfliktäquivalent sind.

• Konflikt serialisierbar:

  • Ein Zeitplan ist konfliktserialisierbar, wenn seine Transaktionen neu angeordnet werden können, um einen seriellen Zeitplan zu bilden und dabei die Konfliktreihenfolge beizubehalten. Einfach ausgedrückt ist ein Zeitplan konfliktserialisierbar, wenn die Transaktionen serialisiert werden können, ohne die Datenkonsistenz zu verletzen, d. h. die Reihenfolge der widersprüchlichen Vorgänge beizubehalten.

---

Beispiel für Konfliktserialisierbarkeit und konfliktäquivalente Zeitpläne

Betrachten wir die folgenden Transaktionen und ihre Vorgänge:

• Transaktion T1: Read(A); Schreiben(A); Begehen
• Transaktion T2: Read(A); Schreiben(A); Begehen

Zeitplan 1:

T1: Read(A);
T2: Read(A);
T1: Write(A);
T2: Write(A);
T1: Commit;
T2: Commit;

Zeitplan 2:

T2: Read(A);
T1: Read(A);
T2: Write(A);
T1: Write(A);
T1: Commit;
T2: Commit;

Konfliktserialisierungsprüfung:

• Schedule 1 und Schedule 2 sind Konfliktäquivalent, da die Reihenfolge der widersprüchlichen Vorgänge (Lesen/Schreiben auf A) beibehalten wird. Beide Zeitpläne können in einen Serienplan umgewandelt werden:
  • T1: Lesen(A); Schreiben(A); Commit;
  • T2: Lesen(A); Schreiben(A); Commit;
• Daher sind beide Zeitpläne konfliktserialisierbar.

---

Transaktionsisolation und Atomarität

Neben den grundlegenden Eigenschaften von Transaktionen, wie z. B. ACID-Eigenschaften, ist die Verwaltung von Transaktionsfehlern ein wichtiger Aspekt bei der Aufrechterhaltung der Konsistenz und Zuverlässigkeit einer Datenbank. Wenn Transaktionen gleichzeitig ausgeführt werden, muss die Datenbank sicherstellen, dass Fehler während einer Transaktion den Datenbankstatus nicht beschädigen und die Atomizität und Konsistenz der Datenbank erhalten bleiben. In diesem Abschnitt wird erläutert, wie sich die Fehlerbehandlung auf die Transaktionsisolation und Atomizität im DBMS auswirkt.

---

Atomarität und Fehlerbehandlung

Atomizität ist die Eigenschaft einer Transaktion, die sicherstellt, dass sie als eine einzige, unteilbare Arbeitseinheit behandelt wird. Dies bedeutet, dass eine Transaktion entweder vollständig abgeschlossen oder gar nicht ausgeführt wird. Wenn ein Teil der Transaktion fehlschlägt, muss die gesamte Transaktion zurückgesetzt werden, um sicherzustellen, dass keine teilweisen Änderungen auf die Datenbank angewendet werden.

Wenn eine Transaktion fehlschlägt, müssen alle Auswirkungen, die sie möglicherweise auf die Datenbank hatte, rückgängig gemacht werden, damit die Datenbank in den Zustand vor Beginn der Transaktion zurückkehren kann. Wenn in Systemen, die die gleichzeitige Ausführung von Transaktionen zulassen, eine Transaktion T1 fehlschlägt, müssen alle Transaktionen, die von T1 abhängen (d. h. jede Transaktion T2, die von T1 betroffene Daten gelesen oder geschrieben hat), ebenfalls abgebrochen werden, um die Atomizität der Datenbank zu bewahren. Wenn eine Transaktion von einer anderen fehlgeschlagenen Transaktion abhängig ist, sollte sie keine teilweisen Änderungen oder inkonsistenten Daten hinterlassen.

Um Inkonsistenzen während der Transaktionsausführung zu verhindern, ist es wichtig, Zeitpläne zu verwalten, die die Reihenfolge der Transaktionsvorgänge vorgeben, insbesondere wenn Transaktionen fehlschlagen. Bestimmte Arten von Zeitplänen müssen eingeschränkt werden, um sicherzustellen, dass Fehler ordnungsgemäß verwaltet werden können.

---

Wiederherstellbare Zeitpläne

Ein wiederherstellbarer Zeitplan ist ein Zeitplan, bei dem eine Transaktion T2 erst dann festgeschrieben wird, nachdem die Transaktion T1, von der sie abhängt, festgeschrieben wurde. Einfacher ausgedrückt: Wenn Transaktion T2 von Transaktion T1 geschriebene Daten liest, muss T1 vor T2 einen Commit durchführen. Dadurch wird sichergestellt, dass T2 keine Änderungen auf der Grundlage einer nicht festgeschriebenen Transaktion festschreibt, wodurch das Szenario verhindert wird, in dem ein Zurücksetzen von T1 auch ein Zurücksetzen von T2 erfordern würde.

Ein Zeitplan, der gegen diese Regel verstößt, wird als nicht wiederherstellbarer Zeitplan bezeichnet. Wenn beispielsweise T2 einen Commit durchführt, nachdem von T1 geschriebene Daten gelesen wurden, T1 jedoch ausfällt und zurückgesetzt wird, kann die Datenbank nicht in einen konsistenten Zustand wiederhergestellt werden, da der Commit von T2 von den nicht festgeschriebenen Änderungen von T1 abhängt. In dieser Situation wird das Rückgängigmachen von T2 unmöglich, was zu Dateninkonsistenzen führt.

Beispiel für einen nicht wiederherstellbaren Zeitplan:
Nehmen wir in einem nicht wiederherstellbaren Zeitplan an:

• Transaktion T6 schreibt Daten in Element A.
• Transaktion T7 liest den von T6 geschriebenen Wert von A und schreibt ihn sofort fest.

Wenn T6 ausfällt, bevor es festgeschrieben wird, ist T7 auf die nicht festgeschriebenen Änderungen angewiesen, die von T6 vorgenommen werden. Da T7 bereits festgeschrieben wurde, können wir T7 nicht zurücksetzen, was zu einer Situation führt, in der eine Wiederherstellung nach dem Ausfall von T6 unmöglich ist. Dies führt zu einem nicht wiederherstellbaren Zeitplan.

Damit der Zeitplan wiederhergestellt werden kann, hätte T7 seine Festschreibung bis nach der Festschreibung von T6 verzögern sollen, um sicherzustellen, dass T7 nicht von nicht festgeschriebenen Daten von T6 abhängig ist.

---

Kaskadenlose Zeitpläne

Selbst wenn ein Zeitplan wiederherstellbar ist, kann es dennoch zu Problemen bei der Wiederherstellung nach Transaktionsfehlern kommen, insbesondere wenn es zu kaskadierenden Rollbacks kommt. Kaskadierendes Rollback bezieht sich auf eine Situation, in der der Ausfall einer Transaktion zu einer Kettenreaktion von Rollbacks für andere abhängige Transaktionen führt. Diese Situation tritt auf, wenn Transaktionen Daten lesen, die von einer anderen nicht festgeschriebenen Transaktion geschrieben wurden.

Stellen Sie sich zum Beispiel das Szenario vor, in dem:

• Transaktion T8 schreibt einen Wert in Datenelement A, der von Transaktion T9 gelesen wird.
• Transaktion T9 schreibt einen Wert in A, der dann von Transaktion T10 gelesen wird.
• Wenn T8 ausfällt, muss auch T9, das von T8 abhängt, zurückgesetzt werden. T10, das von T9 abhängt, muss ebenfalls zurückgesetzt werden. Dadurch entsteht ein kaskadierender Rollback-Effekt, der die Arbeit mehrerer Transaktionen unnötigerweise zunichte macht.

Kaskadierende Rollbacks sind unerwünscht, da sie dazu führen, dass ein erheblicher Arbeitsaufwand rückgängig gemacht wird, selbst wenn nur eine einzige Transaktion fehlschlägt. Um kaskadierende Rollbacks zu verhindern, können wir kaskadenlose Zeitpläne verwenden. Bei einem kaskadenlosen Zeitplan lesen Transaktionen keine Daten, die von einer Transaktion geschrieben wurden, die noch nicht festgeschrieben wurde.

Formal ist ein kaskadenloser Zeitplan ein Zeitplan, bei dem für zwei beliebige Transaktionen T1 und T2 T1 ein Commit durchgeführt haben muss, bevor T2 das Datenelement liest, wenn T2 ein von T1 geschriebenes Datenelement liest. Dadurch wird sichergestellt, dass keine Transaktion von nicht festgeschriebenen Daten abhängen kann und es keine kaskadierenden Rollbacks gibt.

Jeder kaskadenlose Zeitplan ist auch ein wiederherstellbarer Zeitplan. Dies bedeutet, dass kaskadenlose Zeitpläne nicht nur kaskadierende Rollbacks verhindern, sondern auch sicherstellen, dass die Datenbank im Falle eines Transaktionsfehlers korrekt wiederhergestellt werden kann.

Beispiel für einen kaskadenlosen Zeitplan:
Bedenken Sie Folgendes:

• Transaktion T8 schreibt A und T9 liest A.
• In einem kaskadenlosen Zeitplan kann T9 A erst lesen, nachdem T8 festgeschrieben hat.

Dadurch wird gewährleistet, dass T9 keine Daten von T8 liest, es sei denn, T8 wurde erfolgreich abgeschlossen. Dadurch wird sichergestellt, dass kein Rollback von T9 erforderlich ist, wenn T8 fehlschlägt.

---

Transaktionsisolationsstufen

Transaktion Isolation stellt sicher, dass gleichzeitige Transaktionen einander nicht auf eine Weise stören, die die Konsistenz der Datenbank verletzt. Die Isolationsstufe einer Transaktion definiert den Grad, in dem die Transaktion von anderen Transaktionen isoliert ist.

Es gibt verschiedene Isolationsstufen, die von niedriger bis hoher Isolation reichen:

1. Unverbindlich lesen:

   • Diese Isolationsstufe ermöglicht es einer Transaktion, Daten zu lesen, die von anderen nicht festgeschriebenen Transaktionen geschrieben wurden. Diese Ebene kann zu Problemen wie Dirty Reads führen, bei denen eine Transaktion Daten liest, die später möglicherweise zurückgesetzt werden, was zu inkonsistenten Ergebnissen führt.

2. Read Committed:

   • Eine Transaktion auf dieser Ebene kann nur Daten lesen, die von anderen Transaktionen festgeschrieben wurden. Dies verhindert zwar Dirty Reads, kann aber dennoch zu nicht wiederholbaren Lesevorgängen führen, bei denen eine Transaktion dieselben Daten zweimal liest und unterschiedliche Ergebnisse erhält, weil eine andere Transaktion die Daten in der Zwischenzeit geändert hat.

3. Wiederholbares Lesen:

   • Diese Stufe verhindert sowohl Dirty Reads als auch nicht wiederholbare Reads. Es sind jedoch weiterhin Phantom-Lesevorgänge möglich, bei denen eine Transaktion möglicherweise auf andere Zeilensätze stößt, wenn andere Transaktionen Datensätze einfügen oder löschen.

4. Serialisierbar:

   • Dies ist die höchste Isolationsstufe. Dadurch wird sichergestellt, dass das Ergebnis gleichzeitiger Transaktionen dasselbe ist, als ob die Transaktionen seriell nacheinander ausgeführt würden. Dies verhindert Dirty Reads, nicht wiederholbare Lesevorgänge und Phantom Reads, kann jedoch aufgrund seiner strengen Natur Auswirkungen auf die Leistung haben.

Die für eine Datenbank oder eine Transaktion gewählte Isolationsstufe wirkt sich auf das Gleichgewicht zwischen Datenkonsistenz und Leistung aus, wobei höhere Isolationsstufen aufgrund größerer Einschränkungen der Parallelität im Allgemeinen zu einer langsameren Leistung führen.

---

Parallelitätskontrolle im DBMS

Parallelitätskontrolle ist ein entscheidender Aspekt von Datenbankverwaltungssystemen (DBMS), der die korrekte Transaktionsausführung gewährleistet und gleichzeitig die gleichzeitige Ausführung mehrerer Transaktionen ermöglicht. Das Ziel der Parallelitätskontrolle besteht darin, die Datenbankkonsistenz und -integrität angesichts von Transaktionsverschachtelungen und Fehlerszenarien aufrechtzuerhalten. In diesem Abschnitt werden Sperrungsbasierte Protokolle behandelt, einschließlich verschiedener Sperrmodi, des Zwei-Phasen-Sperrprotokolls, der Deadlock-Behandlung-Mechanismen und Zeitstempelbasierter Protokolle .

Sperrbasierte Protokolle

Sperren ist ein grundlegender Mechanismus, der in DBMS verwendet wird, um Konflikte zwischen gleichzeitig ausgeführten Transaktionen zu verhindern. Zur Zugriffskontrolle werden Sperren auf Datenelemente angewendet, um sicherzustellen, dass mehrere Transaktionen die Integrität der Datenbank nicht verletzen. Bei der sperrenbasierten Parallelitätskontrolle erwerben Transaktionen Sperren für Datenelemente, bevor sie Vorgänge an ihnen ausführen, und geben die Sperren frei, sobald der Vorgang abgeschlossen ist.

Arten von Schlössern

Es gibt verschiedene Modi, in denen ein Datenelement gesperrt werden kann. In diesem Abschnitt beschränken wir unsere Aufmerksamkeit auf zwei grundlegende Modi:

1. Gemeinsame Sperre (S):
   • Eine Transaktion hält eine gemeinsame Sperre für ein Datenelement, wenn sie das Element nur lesen muss.
   • Mehrere Transaktionen können gleichzeitig eine gemeinsame Sperre für dasselbe Datenelement halten. Dies ermöglicht das gleichzeitige Lesen des Datenelements durch verschiedene Transaktionen.
   • Gemeinsame Sperre erlaubt einer Transaktion nicht, das Datenelement zu ändern.

Beispiel:

• Transaktion T1 hält eine gemeinsame Sperre für Element A und liest A.
• Transaktion T2 hält eine gemeinsame Sperre für Element A und liest A.
• Beide können die Daten lesen, aber nicht auf A schreiben.

1. Exklusives Schloss (X):
   • Eine Transaktion hält eine exklusive Sperre für ein Datenelement, wenn sie das Element sowohl lesen als auch schreiben muss.
   • Nur ​​eine Transaktion kann zu jedem Zeitpunkt eine exklusive Sperre für ein bestimmtes Datenelement halten. Wenn eine Transaktion über eine exklusive Sperre verfügt, kann keine andere Transaktion eine gemeinsame oder exklusive Sperre für dasselbe Datenelement erwerben.

Beispiel:

• Transaktion T1 hält eine exklusive Sperre für Element A und schreibt darauf.
• Während T1 die exklusive Sperre für A hält, kann keine andere Transaktion A lesen oder schreiben.

Gewährung von Sperren

Sperren werden basierend auf dem Protokoll gewährt, dem das System folgt, und verschiedene sperrenbasierte Protokolle können steuern, wie Sperren während der Transaktionsausführung angefordert und gewährt werden. Diese Protokolle tragen dazu bei, Konflikte wie verlorene Aktualisierungen, vorübergehende Inkonsistenzen und den Zugriff auf nicht festgeschriebene Daten durch andere Transaktionen zu vermeiden.

---

Zwei-Phasen-Verriegelungsprotokoll (2PL)

Das Two-Phase Locking Protocol ist ein weit verbreitetes Protokoll zur Gewährleistung der Serialisierung – eine Eigenschaft, die garantiert, dass Transaktionen so ausgeführt werden, dass ihre Ergebnisse einer Ausführung nacheinander entsprechen ein anderer (seriell). Die Zwei-Phasen-Sperre stellt die Serialisierbarkeit sicher, indem sie während der Transaktionsausführung zwei Phasen erzwingt:

1. Wachstumsphase:

   • In dieser Phase kann eine Transaktion Sperren erwerben, aber keine Sperren freigeben.
   • Die Transaktion kann eine beliebige Anzahl von Sperren anfordern, aber sobald sie eine Sperre aufhebt, kann sie keine neuen Sperren erwerben. Diese Phase endet, wenn der erste Entsperrvorgang durchgeführt wird.

2. Schrumpfphase:

   • In dieser Phase kann eine Transaktion Sperren freigeben, aber keine neuen Sperren erwerben.
   • Sobald eine Transaktion mit der Freigabe von Sperren beginnt, kann sie keine weiteren Datenelemente mehr sperren. Diese Phase endet, wenn die Transaktion entweder festgeschrieben oder abgebrochen wird.

Das Two-Phase Locking-Protokoll garantiert Serialisierbarkeit, da es Zyklen im Sperrdiagramm verhindert und sicherstellt, dass die Ausführungsreihenfolge einer strengen Reihenfolge folgt, die serialisierbar ist.

Beispiel:

• Die Transaktionen T1 und T2 müssen die Datenelemente A und B aktualisieren. Mit 2PL erwerben beide Transaktionen die erforderlichen Sperren in der Wachstumsphase und geben sie erst frei, nachdem sie ihre Vorgänge abgeschlossen haben (in der Schrumpfungsphase).

---

Deadlock-Behandlung

Deadlock tritt auf, wenn zwei oder mehr Transaktionen aufeinander warten, um Sperren freizugeben, was dazu führt, dass keine von ihnen fortfahren kann. Dadurch entsteht ein Zyklus wartender Transaktionen, der nicht aufgelöst werden kann, es sei denn, eine oder mehrere Transaktionen werden zurückgesetzt.

Deadlock-Prävention

Techniken zur Verhinderung von Deadlocks sollen das Auftreten von Deadlocks verhindern, indem sie das Transaktionsverhalten einschränken. Eine gängige Strategie zur Verhinderung von Deadlocks ist die Verwendung von Zeitstempeln zur Priorisierung von Transaktionen.

Zeitstempelbasierte Systeme zur Verhinderung von Deadlocks

Es gibt zwei bekannte Deadlock-Verhinderungsschemata, die Zeitstempel verwenden:

1. Das Wait-Die-Schema:
   • Dies ist eine nicht präventive Deadlock-Verhinderungstechnik.
   • Wenn die Transaktion Ti ein von Tj gehaltenes Datenelement anfordert, darf Ti nur warten, wenn sein Zeitstempel kleiner als der von Tj ist (d. h. Ti ist älter als Tj).
   • Wenn der Zeitstempel von Ti größer als der von Tj ist, wird Ti zurückgesetzt (d. h. Ti „stirbt“).

Beispiel:

• Wenn die Transaktionen T14, T15 und T16 die Zeitstempel 5, 10 bzw. 15 haben:
  • Wenn T14 ein von T15 gehaltenes Datenelement anfordert, wartet T14, da T14 älter ist.
  • Wenn T16 ein von T15 gehaltenes Datenelement anfordert, wird T16 zurückgesetzt, da T16 jünger als T15 ist.

1. Das Wund-Warte-Programm:
   • Dies ist eine präventive Technik zur Verhinderung von Deadlocks.
   • Wenn die Transaktion Ti ein von Tj gehaltenes Datenelement anfordert, darf Ti nur warten, wenn sein Zeitstempel größer als der von Tj ist (d. h. Ti ist jünger als Tj).
   • Wenn der Zeitstempel von Ti kleiner ist als der von Tj, überholt Ti Tj und Tj wird zurückgesetzt (d. h. Tj wird von Ti „verwundet“).

Beispiel:

• Wenn die Transaktionen T14, T15 und T16 die Zeitstempel 5, 10 bzw. 15 haben:
  • Wenn T14 ein von T15 gehaltenes Datenelement anfordert, wird T14 T15 zuvorkommen, wodurch T15 zurückgesetzt wird.
  • Wenn T16 ein von T15 gehaltenes Datenelement anfordert, wartet T16, da es jünger als T15 ist.

---

Zeitstempelbasierte Protokolle

Neben sperrenbasierten Protokollen verwalten auch zeitstempelbasierte Protokolle die Parallelität in Datenbanken. Diese Protokolle verwenden Zeitstempel, um Transaktionen zu ordnen und Konflikte zu lösen, um sicherzustellen, dass sich das System so verhält, als ob Transaktionen seriell ausgeführt würden.

Zeitstempel und ihre Rolle

Zeitstempel sind numerische Werte, die Transaktionen bei ihrer Erstellung zugewiesen werden. Der Zeitstempel einer Transaktion bestimmt ihre Priorität – ein niedrigerer Zeitstempelwert weist auf eine ältere Transaktion hin und ein höherer Wert weist auf eine neuere Transaktion hin.

1. W-Zeitstempel(Q):

   • Dies bezeichnet den größten Zeitstempel einer Transaktion, die erfolgreich einen Schreibvorgang für das Datenelement Q ausgeführt hat.
   • Es hilft, die letzte Transaktion zu identifizieren, die das Datenelement geändert hat.

2. R-Zeitstempel(Q):

   • Dies bezeichnet den größten Zeitstempel einer Transaktion, die einen Lesevorgang für das Datenelement Q erfolgreich ausgeführt hat.
   • Es hilft, die letzte Transaktion zu identifizieren, die das Datenelement gelesen hat.

Das Timestamp-Ordering-Protokoll

Das Timestamp-Ordering Protocol stellt die Serialisierbarkeit sicher, indem es eine Gesamtreihenfolge für die Transaktionen basierend auf ihren Zeitstempeln erzwingt. Das Protokoll erfordert Folgendes:

• Wenn eine Transaktion Ti ein Datenelement Q schreibt und eine andere Transaktion Tj Q liest oder schreibt, muss Ti einen kleineren Zeitstempel als Tj haben.
• In ähnlicher Weise muss Ti einen kleineren Zeitstempel als Tj haben, wenn Ti ein Datenelement Q liest und Tj Q schreibt.

Dieses Protokoll löst Konflikte basierend auf den Zeitstempeln von Transaktionen und nicht auf Sperren.

Beispiel:

• Transaktion T1 mit Zeitstempel 10 schreibt Datenelement A.
• Transaktion T2 mit Zeitstempel 12 liest Datenelement A.
• Das Zeitstempel-Reihenfolgeprotokoll stellt sicher, dass der Schreibvorgang von T1 vor dem Lesevorgang von T2 erfolgt, wodurch die korrekte Transaktionsreihenfolge erhalten bleibt.

Das obige ist der detaillierte Inhalt vonTransaktionen und Parallelitätskontrollen: DBMS. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!