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
Prof. Dr. Rainer Unland, Universität Duisburg-Essen, Institut für Informatik und Wirtschaftsinformatik (ICB), Datenverwaltungssysteme und Wissensrepräsentation, Schützenbahn 70, 45117 Essen
Autoreninfo