Transaktionen – Serialisierung

In diesem Beitrag geht es um Transaktionen im Bezug auf Datenbanken. Eine Transaktion, z.B. eine Überweisung in der Datenbank, möchte man nicht in mehreren Abfragen lösen, da es zu Fehlern kommen kann, wenn der Server zwischen den Anfragen Fehler wirft.Ein gängiges Beispiel wäre,man muss von beiden Konten den Kontostand lesen und gleichzeitig wieder etwas schreiben. Wenn hier das Skript stoppt, geht bares Geld verloren (Im Bankbeispiel) und es entstehen Fehler.


Dazu einmal ein kurzes Beispiel

read(A,a);
a := a -50;
write(A,a);

// Marker 1

read(B,b);
b := b +50;
write(B, b);

Bei „// Marker 1“ ist die Datenbank kurz inkonsistent. Wenn hier abgeschaltet wird, ist das System dauerhaft inkonsistent und die 50€ die bei A schon abgezogen wurden sind verschwunden. Ziel ist es, von einen konsistenten Zustand in eine konsistenten Zustand zu kommen, ohne eine inkonsistente Datenbank zu bekommen. Außerdem ist es das Ziel, Fehler im Mehrbenutzerbetrieb zu vermeiden und es zu ermöglichen, solche Transaktionen konsistent auszuführen.

Mehrbenutzer Anomalien

Es gibt folgende Mehrbenutzer Anomalien in Datenbanken:

  • Verlorengegangene Änderungen (lost Updates)
  • Nicht wiederholbares Schreiben (non-repeatable read)
  • Phantomprobleme (inconsistent read)
  • Zugriffe auf nicht freigegebene Änderungen (dirty read)

Die Problemursache ist immer das nebenläufige Schreiben von Daten währenddessen gelesen wird.

Lösungsansatz dazu ist die Transaktion. Die Bearbeitung der Transaktion werden erst sichtbar, wenn die Transaktion komplett abgeschlossen ist. Wird die Transaktion abgebrochen, so werden alle vorherigen Schritte rückgängig gemacht und die Transaktion wurde so nie ausgeführt. Vorteil davon ist, das die Datenbank immer konsistent bleibt. Durch Transaktionen bleibt die Datenbank also immer konsistent.
Die Mehrbenutzeranomalien vermeiden wir durch Isolation. Die Transaktionen laufen nicht nebenläufig sondern verzahnt nacheinander, so gehen keine Daten verloren und nichts wird überschrieben, was nicht überschrieben werden soll. Für den Benutzer sieht es so aus, als würden alle Anfragen nacheinander ausgeführt werden.
Zuletzt gibt es auch den Dauerhaftigkeitsfaktor. Es gibt in jedem DBMS einen Recovery Manager, der dafür sorgt, das Transaktionen abgespeichert werden. Auch die alten Daten der Transaktionen sind gespeichert und können bei Bedarf wiederhergestellt werden, um die Datenbank wieder in einen richtigen, konsistenten Zustand zu versetzen, falls dies nötig ist.

Ausführung von Transaktionen

Die Ausführung von Transaktionen besteht aus drei Aktionen: Leseaktion, Schreibaktion und die Abschlussaktion („abort“ oder „commit“) Wir erstellen einen Ablaufplan für 3 Transaktionen. Ein Ablaufplan enthält eine konkrete Reihenfolge der Aktionen mehrerer Transaktionen.

Beispiel:

T1: R(a), W(a), R(b), W(b)

T2: R(c), W(c), R(a), W(a)

T3: R(b), W(b), R(a), W(a)


„T“ steht für Transaktion. „R“ ist die Funktion „Read -> Lesen“ und W ist die Funktion „Write -> Schreiben“. Die beiden Transaktionen lesen und schreiben beide auf unser Konto „a“ und überweisen Geld zwischen den Konten a,b & c hin und her.

Der Wohlgeformte-Ablaufplan (well-formed schedule) dazu wäre:

Plan: 
R->T1(a)
W->T1(a)
R->T1(b)
R->T2(c)
W->T2(c)
W->T1(b)
Commit -> T1
R->T2(a)
W->T2(a)
Commit -> T2
R->T3(b)
W->T3(b)
R->T3(a)
W->T3(a)
Commit -> T3

Hier gilt folgendes: Operation->Transaktion(Zielkonto)

Es gibt des weiteren einen Seriellen Ablaufplan, welcher den Vorteil hat, das alle Abfragen wirklich nacheinander ausgeführt werden und keine Mehrbenutzeranomalien auftreten können.

In SQL Syntax sähe das folgender maßen aus:

SQL > DELETE FROM Customers WHERE age = 25;
SQL > COMMIT;

// Alte Daten wiederherstellen
SQL > DELETE FROM Customers WHERE age = 25;
SQL > ROLLBACK;

SET TRANSACTION [READ|WRITE|READ ONLY] ISOLATION LEVEL [REPEEATABLE READ|READ COMITTED|READ UNCOMITTED|SERIAZIBLE]

// Alternativ
SAVEPOINT <Name>
ROLLBACK <Name>
RELEASE SAVEPOINT <Name> // Löscht Savepoint
Marvin Sengera

Marvin Sengera

Hey! Ich bin Marvin Sengera, Inhaber der Internetagentur "Binärfabrik" aus Paderborn. Ich habe mein Bachelorstudium Informatik mit Schwerpunkt Industriespionage an der Hochschule Hamm Lippstadt abgeschlossen und absolviere derzeit meinen Master in Fachrichtung "Technical Entrepreneurship and Innovation". Ich beschäftige mich rund um die Themen Informatik, Innovation & Unternehmensgründung.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.