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!