Atomicity (Atomarität)
Eine Transaktion wird nach dem Prinzip Alles oder Nichts ausgeführt. Entweder werden alle enthaltenen Operationen erfolgreich festgeschrieben (commit) oder keine einzige wird wirksam (abort bzw. rollback). Bei einem Fehler oder Systemabsturz während einer Transaktion muss das DBMS bereits ausgeführte Teiländerungen komplett zurücknehmen. Ohne Atomarität könnten halbausgeführte Überweisungen dazu führen, dass Geld vom Konto A abgebucht, aber nicht auf Konto B gutgeschrieben wird. Realisiert wird das durch Undo-Logs und ein zentrales Log Manager Modul.
Alles oder Nichts, halbe Sachen gibt es nicht.
Consistency (Konsistenz)
Die Datenbank befindet sich vor Beginn und nach Ende jeder Transaktion in einem konsistenten Zustand. Alle Integritätsbedingungen des Schemas wie Primärschlüssel, Fremdschlüssel, CHECK-Constraints, NOT NULL und Trigger müssen erfüllt sein. Während der Transaktion darf die Konsistenz vorübergehend verletzt sein. Wird die Konsistenzbedingung durch die Transaktion final verletzt, muss das DBMS die Transaktion abbrechen. Konsistenz ist die Zusicherung an die Anwendung, dass unerlaubte Zustände niemals sichtbar werden.
Konsistenter Zustand rein, konsistenter Zustand raus.
Isolation
Jede Transaktion hat den Eindruck, allein auf der Datenbank zu arbeiten, auch wenn viele Transaktionen parallel laufen. Andere gleichzeitig laufende Transaktionen dürfen keine unerwarteten Effekte auf die eigenen Leseergebnisse haben. Wird Isolation verletzt, entstehen die klassischen Mehrbenutzer-Anomalien Dirty Read, Nonrepeatable Read, Phantom Read und Lost Update. Technisch wird Isolation durch Sperren (Locks, 2PL), Timestamps oder Multi-Version Concurrency Control umgesetzt. SQL erlaubt eine feine Abstufung über Isolationslevel von Read Uncommitted bis Serializable.
Jede Transaktion glaubt, sie sei allein im Raum.
Durability (Dauerhaftigkeit)
Nach einem erfolgreichen commit sind die Änderungen einer Transaktion dauerhaft in der Datenbank gespeichert und überleben jeden nachfolgenden Systemabsturz, Stromausfall oder Softwarefehler. Das wird durch persistente Speicherung im Log-File (Write-Ahead Logging) sichergestellt, bevor der commit dem Client bestätigt wird. Nach einem Crash kann das Recovery-Modul aus dem Log alle committeten Transaktionen wiederholen (Redo) und alle nicht committeten zurücknehmen (Undo). Durability ist die Grundlage dafür, dass ein bestätigter Buchungsvorgang wirklich verbindlich ist.
Was commit gesagt hat, bleibt für immer.
Transaktion als ACID-Klammer
Eine Transaktion ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen konsistenten (eventuell veränderten) Zustand überführt, wobei das ACID-Prinzip eingehalten werden muss. Sie startet mit begin of transaction (BOT bzw. START TRANSACTION in SQL) und endet entweder mit commit (dauerhaft) oder abort bzw. rollback (Rückabwicklung). ACID sind die vier Bedingungen, die das DBMS an jeder Transaktion garantiert.
Eine Transaktion ist die logische Einheit, in der ACID gilt.
Isolationslevel als Aufweichung von I
SET TRANSACTION ISOLATION LEVEL erlaubt vier Stufen: Read Uncommitted, Read Committed, Repeatable Read und Serializable. Je niedriger die Stufe, desto mehr Parallelität und Durchsatz, aber desto mehr Anomalien sind möglich. Serializable ist die strengste Stufe und entspricht dem idealen ACID-I. Read Uncommitted erlaubt sogar Dirty Reads. In der Klausur muss man aus einer Tabelle ableiten können, welches Level welche Probleme noch zulässt.
Niedriges Level = mehr Speed, mehr Risiko.
Serialisierbarkeit
Eine parallel (verzahnt) ausgeführte Historie mehrerer Transaktionen ist korrekt, wenn sie das gleiche Ergebnis liefert wie eine serielle Ausführung derselben Transaktionen in irgendeiner Reihenfolge. Serialisierbarkeit ist die formale Definition der Isolation. Nicht jede parallele Historie ist serialisierbar, deshalb muss der Scheduler des DBMS über Sperrverfahren wie 2PL nur serialisierbare Historien zulassen.
Korrekt = äquivalent zu einer seriellen Ausführung.
Recovery als Umsetzung von A und D
Atomicity und Durability werden gemeinsam durch das Recovery-Subsystem realisiert. Ein Log-File (Redo-Log, Undo-Log) protokolliert jede Änderung vor dem eigentlichen Schreibvorgang auf die Datenbasis. Nach einem Crash setzt Recovery alle nicht committeten Transaktionen zurück (Undo, sichert A) und wiederholt alle committeten (Redo, sichert D). Zustandsübergänge einer Transaktion sind aktiv, wartend, gescheitert, wiederholbar, abgeschlossen, persistent oder aufgegeben.
Log first, write later. Redo committed, Undo aborted.