Transaktion

Motivation, Einführung und Definition

Lassen Sie uns annehmen, Sie möchten über einen Online-Versand, der seinen Warenbestand über ein Datenbanksystem verwaltet, einen PC und eine externe Festplatte bestellen. Falls sie nur beide Artikel zusammen kaufen möchten, ist dies logisch gesehen als ein Kaufvorgang zu realisieren (entweder beide Artikel oder kein Kauf). Andernfalls sind es logisch gesehen zwei voneinander unabhängige Kaufvorgänge.

Sobald auf den Daten einer Datenbank gearbeitet wird, muss dies zwangsläufig innerhalb einer Transaktion geschehen. Eine Transaktion stellt aus Sicht der Außenwelt eine atomare Operation dar, die in keiner Verbindung zu irgendwelchen anderen Transaktionen auf der Datenbank steht. Dabei überführt eine Transaktion die Datenbank von einem konsistenten in einen nicht notwendigerweise unterschiedlichen konsistenten Zustand. Weiterhin wird über das Transaktionsmanagement auch die hohe Fehlertoleranz von Datenbanksystemen realisiert.

Der Definition einer Transaktion folgend, ist der beschriebene Kaufvorgang entweder durch eine oder durch zwei Transaktionen umzusetzen. Der Natur eines Datenbanksystems folgend, kann auf dem Datenbestand parallel gearbeitet werden. Da eine Transaktion aber als atomare Einheit zu sehen ist, muss ausgeschlossen werden, dass Ihre erfolgreiche Überprüfung, dass sowohl PC als auch Festplatte noch auf Lager sind, durch den parallelen Kauf der letzten Festplatte durch einen anderen Nutzer ungültig wird.

Um all diese Kriterien und noch weitere zu erfüllen, realisiert eine Transaktion das sogenannte ACID-Prinzip (atomicity, consistency, isolation, durability).

ACID-Eigenschaften

Die sogenannten ACID-Eigenschaften beschreiben, welche Leistungen eine Transaktionen abzudecken hat:

• Atomarität: Eine Transaktion ist unteilbar. Sie wird entweder ganz oder gar nicht ausgeführt. Wird eine laufende Transaktion abgebrochen, so ist die Datenbank so zu hinterlassen, als hätte es die Transaktion nie gegeben.

• Konsistenz: Unter der Annahme (als Axiom zu sehen), dass eine Transaktion die Datenbank in einem konsistenten Zustand vorfindet, hat sie so zu agieren, dass sie die Datenbank auch wieder in einem konsistenten Zustand hinterlässt. Dies ist eher ein weiches Kriterium, da diese Forderung nicht automatisch durch das DBMS garantiert werden kann. Trotz Konsistenzbedingungen, die formuliert sein können, kann nicht ausgeschlossen werden, dass ein inkorrekter Wert eingefügt wurde (z.B. der Name „Meyer“ statt „Maier“).

• Isolation: Trotz der möglicherweise existierenden Parallelarbeit vieler Benutzer auf der Datenbank muss das DBS so agieren, als würde jeder Benutzer isoliert, d.h. alleine, auf der DB arbeiten. Irgendwelche Beeinflussungen durch den Parallelbetrieb sind auszuschließen.

• Dauerhaftigkeit: Sobald eine Transaktion erfolgreich abgeschlossen ist, haben die durch die Transaktion möglicherweise ausgeführten Änderungen auf dem Datenbestand jeden nachfolgenden Fehlerfall zu überleben. Hierfür ist die sogenannte Recoverykomponente zuständig.

Die A, I und D Eigenschaften sind harte Anforderungen, die ein DBMS erfüllen muss. Isolation wird dabei durch das Synchronisationsverfahren realisiert. Es garantiert, dass eine beliebige parallele Ausführung von Aktionen paralleler Transaktionen auf der Datenbank so reguliert wird, dass derselbe Datenbankendzustand und dieselben Ausgaben erzeugt werden, als wären die Transaktionen in einer von den vielen möglichen sequentiellen Reihenfolgen ausgeführt worden (Serialisierbarkeitskriterium, siehe Abb. 1).

Abb. 1: Transaktionen

Am Markt erhältliche DBMS realisieren heutzutage das sogenannte Zweiphasensperrprotokoll, bei dem alle Daten, die von einer Transaktion genutzt werden, zunächst gesperrt werden müssen – mit einer gemeinsamen Sperre (erlaubt paralleles Lesen), falls sie nur gelesen werden, und mit einer exklusiven Sperre, falls die Daten (auch) geändert werden. Dabei besteht eine Transaktion aus zwei Phasen. In der ersten dürfen nur Sperren erworben werden, in der zweiten nur wieder freigegeben werden. Um ein fortgepflanztes Rollback zu verhindern, wird üblicherweise die strikte Zweiphasigkeit angewendet, bei der die zweite Phase nur aus einer als atomar anzusehenden Freigabe aller Sperren mit dem Transaktionsende besteht. Eine sukzessive Freigabe von geänderten Daten würde diese bereits für andere Transaktionen zugänglich machen, obwohl die ändernde Transaktion noch läuft und der Gefahr ausgesetzt ist, aufgrund des Atomaritätskriteriums noch zurückgesetzt zu werden, falls beispielsweise noch ein Fehler im Transaktionsablauf auftritt. Dann müssten auch andere Transaktionen zurückgesetzt werden, die geänderte Daten bereits gelesen hatten (siehe Abb. 2).

Abb. 2: Fortgepflanztes Rollback

Für das Zurücksetzen von Transaktionen und die Fehlertoleranz allgemein ist die Recoverykomponente zuständig. Durch ein geschicktes, redundantes Abspeichern von Informationen sorgt sie dafür, dass die Auswirkungen einer abgeschlossenen Transaktion auf der Datenbank immer wieder hergestellt werden können, unabhängig davon, welcher Fehlerfall auch auftreten mag (bis hin zum kompletten Verlust der eigentlichen Datenbank).

Literatur

Gray, Jim; Reuter, Andreas: Transaction Processing: Concepts and Techniques, Morgan Kaufmann Series in Data Management Systems, 1993

Pernul, Günther; Unland, Rainer: Datenbanken im Unternehmen, 2.te Auflage, München, Oldenbourg, 2003

Vossen, Gottfried; Weikum, Gerhard: Fundamentals of Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery, Morgan Kaufmann Series in Data Management Systems, 2001

Autor