Transaktionen

Sobald ein Benutzer (lesend oder schreibend) auf eine Datenbank zugreift, wird eine Transaktion gestartet. Eine Transaktion kann aus einem oder beliebig vielen Befehlen bestehen, die als ganzes betrachtet werden. Können alle diese Befehle erfolgreich abgearbeitet werden, so ist diese Transaktion erfolgreich. Schlägt auch nur ein einziger Befehl dieser Transaktion fehl, so ist die ganze Transaktion fehlgeschlagen. Die bereits durchgeführten änderungen müssen somit wieder rückgängig gemacht werden.

Eine Transaktion führt die Datenbank immer von einem konsistenten Zustand in einen anderen konsistenten Zustand. Startet die Transaktion aus einem inkonsistenten Zustand, so wird auch der Zustand der Datenbank nach der Transaktion inkonsistent sein. Um diese Inkonsistenzen zu vermeiden, übernimmt das Datenbanksystem die Verwaltung sämtlicher Transaktionen.

Beispiel

Es gibt zwei Konti, Konto A und Konto B. Auf Konto A befindet sich ein Betrag von 5'000 €, auf Konto B sind 2'000 € hinterlegt.

Von Konto A sollen nun 1'000 € auf Konto B überwiesen werden. Dazu sind zwei Teiloperationen notwendig:

1. Abzug von 1'000 € von Konto A
2. Gutschrift von 1'000 € auf Konto B

Die Datenbank präsentiert sich nach der ersten Operation folgendermassen:

Der Betrag von 1'000 € wurde offenbar von Konto A abgebucht.

Nun soll die Gutschrift dieser 1'000 € auf Konto B erfolgen. In diesem Moment stürzt die Anwendung jedoch ab, die zweite Operation kann also nicht durchgeführt werden. Es sind also 1'000 € verloren gegangen. Dies darf keinesfalls passieren!

Wären diese beiden Operationen zusammen in einer Transaktion ausgeführt worden, so hätte der Abzug der 1'000 € von Konto A rückgängig gemacht werden können. Die Datenbank würde sich somit selbst nach einem Absturz noch in einem konsistenten Zustand befinden, die Transaktion könnte nach dem Neustart der Anwendung erneut durchgeführt werden. Das Ergebnis sähe dann folgendermassen aus:

Die beiden Operationen wurden gemeinsam ausgeführt, die überweisung von 1'000 € hat also korrekt funktioniert.

Dieses Beispiel zeigt, wie wichtig die Verwendung von Transaktionen ist!

ACID

Eine Transaktion muss über bestimmte Eigenschaften verfügen, einige dieser Eigenschaften wurden in den bisherigen Abschnitten bereits genannt und erläutert. In der Fachliteratur fasst man diese Eigenschaften oftmals unter dem Begriff ACID zusammen.

ACID ist eine Abkürzung, die einzelnen Buchstaben bedeuten folgendes:

• Atomicity (Atomarität)
  • Eine Transaktion muss als ganzes, unteilbares betrachtet werden.
  • Es ist nicht zulässig, dass nur einige Operationen einer Transaktion erfolgreich durchgeführt werden, andere Operationen jedoch scheitern.
  • Eine Transaktion kann als Ganzes erfolgreich durchgeführt werden oder als Ganzes scheitern.
• Consistenty (Konsistenz)
  • Wird eine Transaktion aus einem konsistenten Zustand gestartet, muss sie auch einen konsistenten Zustand auf der Datenbank hinterlassen.
  • Eine Transaktion führt die Datenbank von einem konsistenten in einen anderen konsistenten Zustand über.
• Isolation (Isolation)
  • Transaktionen müssen voneinander isoliert ablaufen.
  • Gleichzeitig ablaufende Transaktionen dürfen sich gegenseitig nicht beeinflussen.
• Durability (Dauerhaftigkeit)
  • Wird eine Transaktion erfolgreich ausgeführt, müssen die vorgenommenen änderungen dauerhaft in der Datenbank abgespeichert werden.

COMMIT und ROLLBACK

SQL stellt für den Programmierer die beiden Transaktionsbefehle COMMIT und ROLLBACK zur Verfügung.

Ein Programmierer möchte beispielsweise drei SQL-Operationen durchführen. Diese Operationen bilden zusammen eine Transaktion. Sind alle diese Einzel-Operationen erfolgreich durchgeführt worden, kann die Transaktion als gesamtes mit dem COMMIT-Befehl bestätigt werden - die änderungen können in der Datenbank abgespeichert werden:

[Operation 1]
[Operation 2]
[Operation 3]
COMMIT

Tritt innerhalb einer Transaktion ein Fehler auf, so kann die gesamte Transaktion mit dem ROLLBACK-Befehl wieder rückgängig gemacht werden:

[Operation 1]
[Operation 2]
Fehler
ROLLBACK

Die dritte Operation wird nicht mehr durchgeführt, die bisherigen änderungen werden wieder rückgängig gemacht.

Das Transaktionsprotokoll

Ein Datenbanksystem muss immer wissen, welche Operationen es im Falle eines abgesetzten ROLLBACK-Befehls wieder rückgängig machen muss. Zu diesem Zweck verfügt jede Datenbank über ein Transaktionsprotokoll. In diesem werden sämtliche bisher ausgeführten Operationen festgehalten. Rein technisch wird dieses Transaktionsprotokoll als Tabelle abgespeichert. Diese kann beispielsweise folgendermassen aussehen:

Erklärung der einzelnen Spalten:

• id
  • Primärschlüssel (automatischer Zähler)
• trans_id
  • Nummer der Transaktionen
• prev und next
  • Diese beiden Felder stellen eine doppelt verkettete Liste zwischen den einzelnen Operationen einer Transaktion dar. Dabei verweist prev auf die id der vorhergehenden Operation (innerhalb der gleichen Transaktion) und next auf die id der nachfolgenden Operation.
  • Da möglicherweise mehrere Transaktionen gleichzeitig ablaufen, kann nicht garantiert werden, dass die Operationen einer Transaktion immer schön beieinander stehen. Aus diesem Grund wird diese doppelt verkettete Liste benötigt.
• operation
  • In diesem Feld steht die SQL-Operation, die innerhalb der Operation durchgeführt wurde.
• table
  • Hier steht der Name der Tabelle, welche die durch die Operation betroffen wurde
• row_id
  • Der Primärschlüssel des Datensatzes, der durch die jeweilige Operation verändert wurde.
• attribute
  • Der Name der Spalte, in der ein Wert verändert wurde.
• pre_val und post_val
  • In pre_val wird der Wert gespeichert, der das geänderte Feld vor der Operation hatte.
  • In post_val wird der Wert gespeichert, der das geänderte Feld nach der Operation hatte.

Neben den einzelnen Teiloperationen werden auch der Start und das Ende einer Transaktion im Transaktionsprotokoll festgehalten. Mithilfe dieser Angaben kann jede Teiloperation einer Transaktion wieder rückgängig gemacht werden, sodass sich die Datenbank danach wieder in einem konsistenten Zustand befindet.

Ein Transaktionsprotokoll stellt für das Datenbanksystem eine zusätzliche Verwaltungsaufgabe und somit eine Performanceeinbusse dar (Overhead). Bei der Massendatenverarbeitung sollte die Möglichkeit geprüft werden, dieses Transaktionsprotokoll zu umgehen.

Das Transaktionsprotokoll ist eine sehr kritische Komponente eines jeden Datenbanksystems. Darum sollte es keinesfalls von Hand mutiert oder sogar gelöscht werden. Da der Zugriff auf das Transaktionsprotokoll sehr schnell erfolgen muss, wird dieses oftmals im Arbeitsspeicher gehalten. Datenbankserver sind somit sehr empfindlich gegen Stromausfälle.