DBMS-Transaktionen

Alles Biber! Wir erweitern sozusagen aktiv unser Kursangebot und freuen uns nun, ein neues einzuführen: „Relational DBMS“ . Der Kurs wurde von einem der führenden Lehrer des Linux-Administratorkurses - Alexey Tsykunov - erstellt . Ansonsten wird alles wie gewohnt sein: Dienstprogramme und offene Lektionen , in denen Alex verschiedene Dinge teilt, die nicht im Kurs selbst enthalten sind.

Lass uns gehen!

Eine Transaktion kann als eine Reihe von Aufgaben definiert werden, deren Erfüllung eine Voraussetzung für den korrekten Abschluss der Transaktion ist. Eine einzelne Aufgabe ist der kleinste unteilbare Block der Datenänderung.

Hier ist ein Beispiel für eine einfache Transaktion. Angenommen, ein Bankangestellter überweist 500 Rupien von Konto A auf Konto B. Diese kleine und einfache Transaktion umfasst mehrere Aufgaben auf niedriger Ebene.

Konto A.

Open_Account(A) Old_Balance = A.balance New_Balance = Old_Balance - 500 A.balance = New_Balance Close_Account(A) 

Konto B.

 Open_Account(B) Old_Balance = B.balance New_Balance = Old_Balance + 500 B.balance = New_Balance Close_Account(B) 

ACID-Eigenschaften

Eine Transaktion im Datenbanksystem muss Atomizität, Konsistenz, Isolation und Haltbarkeit - kurz ACID - beibehalten, um Datengenauigkeit, Vollständigkeit und Integrität sicherzustellen:

• Atomizität - Diese Eigenschaft zeigt, dass eine Transaktion als atomare Einheit betrachtet werden sollte, dh entweder alle ihre Operationen werden ausgeführt oder nicht als eine einzige. Die Datenbank sollte keine Zustände enthalten, in denen die Transaktion teilweise abgeschlossen ist. Die Zustände müssen entweder vor dem Start der Transaktion oder nach Abschluss / Unterbrechung / Ausfall der Transaktion festgelegt werden.
• Konsistenz - Diese Eigenschaft gibt an, dass die Datenbank nach jeder Transaktion in einem konsistenten Zustand bleiben soll. Keine Transaktion sollte sich negativ auf die Daten in der Datenbank auswirken. Wenn sich die Datenbank vor Abschluss der Transaktion in einem konsistenten Zustand befand, sollte sie sich nach Abschluss der Transaktion darin befinden.
• Isolation - Im Datenbanksystem, in dem mehrere Transaktionen gleichzeitig und parallel ausgeführt werden, gibt die Isolationseigenschaft an, dass jede Transaktion so ausgeführt und ausgeführt wird, als wäre sie die einzige Transaktion im System. Keine Transaktion sollte die Existenz anderer Transaktionen beeinflussen.
• Ausfallsicherheit - Diese Eigenschaft gibt an, dass die Datenbank stabil genug sein muss, um die neuesten Aktualisierungen zu speichern, selbst wenn das System einen Fehler macht oder neu startet. Wenn die Transaktion zu einer Aktualisierung des Datenfragments in der Datenbank führt, sollten diese Änderungen weiterhin in der Datenbank gespeichert werden. Wenn die Transaktion durchgeführt wird, das System jedoch vor dem Schreiben von Daten auf die Festplatte abstürzt, sollten die Daten sofort nach dem Neustart des Systems aktualisiert werden.

Serialisierung

Wenn das Betriebssystem in einer Umgebung mit mehreren Programmen mehrere Transaktionen ausführt, werden die Anweisungen einer Transaktion wahrscheinlich mit den Anweisungen einer anderen Transaktion gemischt.

• Ein Zeitplan ist eine chronologische Ausführung einer Reihe von Transaktionen. Ein Zeitplan kann viele Transaktionen enthalten, von denen jede aus mehreren Anweisungen / Aufgaben besteht.
• Ein sequentieller Zeitplan ist ein Zeitplan, in dem Transaktionen so angeordnet sind, dass jede der Transaktionen der Reihe nach abgeschlossen wird. Ein Zeitplan wird nur aufgrund eines konsistenten Ausführungsmusters als sequentiell bezeichnet.

In einer Umgebung mit mehreren Transaktionen wird ein sequentieller Zeitplan als Benchmark betrachtet. Die Reihenfolge der Ausführung von Anweisungen in einer Transaktion kann nicht geändert werden, aber die Ausführung von Anweisungen von zwei Transaktionen kann zufällig sein. Die Ausführung ist nicht schädlich, wenn zwei Transaktionen voneinander unabhängig sind und auf unterschiedlichen Datensegmenten arbeiten. Wenn sie jedoch dieselben Daten verwenden, können die Ergebnisse unterschiedlich sein, was dazu führen kann, dass die Datenbank in einen inkonsistenten Zustand versetzt wird.

Um dieses Problem zu lösen, erlauben wir die parallele Ausführung des Transaktionsplans für den Fall, dass die Transaktionen serialisiert sind oder eine Äquivalenzbeziehung haben.

Äquivalente Zeitpläne

Es gibt folgende Arten von äquivalenten Zeitplänen:

Äquivalenz des Ergebnisses

Wenn zwei Zeitpläne nach der Ausführung dasselbe Ergebnis liefern, werden sie als gleichwertig angesehen. Die Ergebnisse können für einige Werte gleich sein und für andere Werte unterschiedlich sein. Daher wird eine solche Äquivalenz normalerweise nicht als signifikant angesehen.

Präsentationsäquivalenz

Zwei Zeitpläne werden in der Darstellung als gleichwertig angesehen, wenn die Transaktionen in jedem der Zeitpläne ähnliche Aktionen auf ähnliche Weise ausführen.

Z.B:

• Wenn T die Originaldaten in S1 liest, liest es auch die Originaldaten in S2.
• Wenn T den von J in S1 geschriebenen Wert liest, liest es auch den von J in S2 geschriebenen Wert.
• Wenn T das Schreiben von Werten in S1 beendet, beendet es auch das Schreiben von Werten in S2.

Konfliktäquivalenz

Zwei Zeitpläne stehen in Konflikt, wenn sie die folgenden Eigenschaften haben:

• Sie gehören zu verschiedenen Transaktionen.
• Sie greifen auf dieselben Daten zu.
• Mindestens eine davon ist die Schreiboperation.

Zwei Zeitpläne mit mehreren Transaktionen mit widersprüchlichen Vorgängen gelten nur dann als gleichwertig mit einem Konflikt, wenn:

• Beide Zeitpläne enthalten denselben Satz von Transaktionen.
• Die Reihenfolge widersprüchlicher Operationspaare wird in beiden Zeitplänen unterstützt.

Hinweis - In der Präsentation äquivalente Zeitpläne sind in der Präsentation serialisierbar, und konfliktäquivalente Zeitpläne sind konfliktserialisierbar. Alle konfliktserialisierbaren Zeitpläne sind präsentationsserialisierbar.

Transaktionsstatus

Eine Transaktion in einer Datenbank kann den folgenden Status haben:

• Aktiv (Aktiv) - In diesem Zustand beginnt die Ausführung der Transaktion. Dies ist der Anfangszustand jeder Transaktion.
• Teilweise festgeschrieben - Wenn eine Transaktion ihren endgültigen Vorgang abgeschlossen hat, wird davon ausgegangen, dass sie sich in einem teilweise perfekten Zustand befindet.
• Fehlgeschlagen - Eine Transaktion gilt als fehlgeschlagen, wenn eine der vom Datenbankwiederherstellungssystem durchgeführten Überprüfungen fehlgeschlagen ist. Eine solche Transaktion kann nicht fortgesetzt werden.
• Abgebrochen - Wenn eine Überprüfung fehlschlägt und die Transaktion in einen fehlgeschlagenen Zustand übergeht, setzt der Wiederherstellungsmanager alle Schreibvorgänge in der Datenbank zurück, um sie vor dem Start der Transaktion in ihren ursprünglichen Zustand zurückzusetzen.
  Transaktionen in diesem Zustand gelten als unterbrochen. Das Datenbankwiederherstellungsmodul kann nach Unterbrechung der Transaktion einen von zwei Vorgängen auswählen:
  
  
  • Starten Sie die Transaktion neu.
  • Transaktion abbrechen.
• Perfekt - Wenn die Transaktion alle Vorgänge erfolgreich abgeschlossen hat, gilt sie als perfekt. Alle seine Auswirkungen werden permanent im Datenbanksystem aufgezeichnet.

DAS ENDE

Wie immer warten wir auf Kommentare, eine Frage, die sowohl hier als auch in einer offenen Lektion mit Alexei gestellt werden kann .