ACID-Eigenschaften - DB Klausur

Zusammenfassung

Das ACID-Prinzip beschreibt die vier Grundeigenschaften jeder Datenbanktransaktion: Atomicity (Alles oder Nichts), Consistency (konsistenter Zustand vor und nach der Transaktion), Isolation (Transaktion arbeitet scheinbar allein) und Durability (committete Aenderungen ueberdauern jeden Absturz). Diese Eigenschaften garantieren, dass eine Transaktion die Datenbank sicher von einem konsistenten Zustand in einen anderen ueberfuehrt, selbst bei Mehrbenutzerbetrieb oder Systemfehlern. Verletzungen der Isolation zeigen sich in den Anomalien Dirty Read, Nonrepeatable Read, Phantom Read und Lost Update, die ueber Isolationslevel gezielt gesteuert werden koennen.

Kernkonzepte

Atomicity (Atomaritaet)

Eine Transaktion wird nach dem Prinzip Alles oder Nichts ausgefuehrt. Entweder werden alle enthaltenen Operationen erfolgreich festgeschrieben (commit) oder keine einzige wird wirksam (abort bzw. rollback). Bei einem Fehler oder Systemabsturz waehrend einer Transaktion muss das DBMS bereits ausgefuehrte Teilaenderungen komplett zuruecknehmen. Ohne Atomaritaet koennten halbausgefuehrte Ueberweisungen dazu fuehren, 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 Integritaetsbedingungen des Schemas wie Primaerschluessel, Fremdschluessel, CHECK-Constraints, NOT NULL und Trigger muessen erfuellt sein. Waehrend der Transaktion darf die Konsistenz voruebergehend 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 Zustaende 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 duerfen 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 ueber Isolationslevel von Read Uncommitted bis Serializable.

Jede Transaktion glaubt, sie sei allein im Raum.

Durability (Dauerhaftigkeit)

Nach einem erfolgreichen commit sind die Aenderungen einer Transaktion dauerhaft in der Datenbank gespeichert und ueberleben jeden nachfolgenden Systemabsturz, Stromausfall oder Softwarefehler. Das wird durch persistente Speicherung im Log-File (Write-Ahead Logging) sichergestellt, bevor der commit dem Client bestaetigt wird. Nach einem Crash kann das Recovery-Modul aus dem Log alle committeten Transaktionen wiederholen (Redo) und alle nicht committeten zuruecknehmen (Undo). Durability ist die Grundlage dafuer, dass ein bestaetigter Buchungsvorgang wirklich verbindlich ist.

Was commit gesagt hat, bleibt fuer immer.

Transaktion als ACID-Klammer

Eine Transaktion ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen konsistenten (eventuell veraenderten) Zustand ueberfuehrt, 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 (Rueckabwicklung). 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 Parallelitaet und Durchsatz, aber desto mehr Anomalien sind moeglich. 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 koennen, welches Level welche Probleme noch zulaesst.

Niedriges Level = mehr Speed, mehr Risiko.

Serialisierbarkeit

Eine parallel (verzahnt) ausgefuehrte Historie mehrerer Transaktionen ist korrekt, wenn sie das gleiche Ergebnis liefert wie eine serielle Ausfuehrung derselben Transaktionen in irgendeiner Reihenfolge. Serialisierbarkeit ist die formale Definition der Isolation. Nicht jede parallele Historie ist serialisierbar, deshalb muss der Scheduler des DBMS ueber Sperrverfahren wie 2PL nur serialisierbare Historien zulassen.

Korrekt = aequivalent zu einer seriellen Ausfuehrung.

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 Aenderung vor dem eigentlichen Schreibvorgang auf die Datenbasis. Nach einem Crash setzt Recovery alle nicht committeten Transaktionen zurueck (Undo, sichert A) und wiederholt alle committeten (Redo, sichert D). Zustandsuebergaenge einer Transaktion sind aktiv, wartend, gescheitert, wiederholbar, abgeschlossen, persistent oder aufgegeben.

Log first, write later. Redo committed, Undo aborted.

Wichtige Details

Definition Transaktion: Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen konsistenten Zustand ueberfuehrt und ACID einhaelt.
ACID-Reihenfolge auswendig: Atomicity, Consistency, Isolation, Durability.
Merksatz zu Atomicity: Alles oder Nichts. Realisiert durch Undo-Log und rollback.
Merksatz zu Consistency: Integritaetsbedingungen (PK, FK, CHECK, NOT NULL) vor und nach der Transaktion erfuellt.
Merksatz zu Isolation: Transaktion hat den Eindruck, allein zu arbeiten. Verletzung fuehrt zu Dirty Read, Nonrepeatable Read, Phantom, Lost Update.
Merksatz zu Durability: Nach commit ueberlebt jede Aenderung jeden Absturz. Realisiert durch Write-Ahead Logging und Redo.
SQL-Befehle: START TRANSACTION / BEGIN TRANSACTION, COMMIT [WORK], ROLLBACK [WORK], SAVEPOINT.
Isolationslevel-Tabelle: Read Uncommitted (alle Anomalien), Read Committed (kein Dirty Read), Repeatable Read (nur Phantom moeglich), Serializable (keine Anomalie).
Serialisierbarkeit ist die formale Definition korrekter paralleler Ausfuehrung; ein verzahnter Plan ist korrekt, wenn ein serieller mit identischem Ergebnis existiert.
Zustandsuebergaenge einer Transaktion: potentiell → aktiv → abgeschlossen → persistent, mit Seitenpfaden wartend, gescheitert, wiederholbar, aufgegeben.

Beispiele

Klassisches Bankkonto-Beispiel fuer Atomicity

Ueberweisung von 50 Euro von Konto A nach Konto B. Alle sechs Schritte muessen zusammen ausgefuehrt werden oder gar nicht, sonst geht Geld verloren.

1. read(A,a)
2. a := a - 50
3. write(A,a)
4. read(B,b)
5. b := b + 50
6. write(B,b)

Bricht das System nach Schritt 3 ab, wurden 50 Euro von A abgebucht, aber nicht auf B gutgeschrieben. Atomicity + Durability erzwingen entweder vollstaendige Ausfuehrung (commit) oder Rollback zum Ausgangszustand.

Dirty Read (Verletzung der Isolation)

T2 liest einen von T1 geschriebenen Wert, bevor T1 committet hat. T1 macht abort, T2 rechnet mit ungueltigen Daten weiter und produziert Inkonsistenz.

T1                T2
read(A,x)
x := x + 100
write(x,A)
                  read(A,x)   <- dirty!
                  read(B,y)
                  y := y + x
                  write(y,B)
                  commit
abort              

Ergebnis: B ist mit ungueltigem A-Wert aktualisiert. Erkennungsmerkmal: read einer Transaktion auf einem noch nicht committeten write einer anderen Transaktion.

Lost Update (Verletzung der Isolation)

Zwei Transaktionen lesen denselben Wert A=10, rechnen parallel und schreiben zurueck. Die Aenderung von T1 geht verloren, weil T2 sie ueberschreibt.

T1            T2            A
read(A,x)                   10
              read(A,x)     10
x := x + 5                  10
              x := x + 1    10
write(x,A)                  15
              write(x,A)    11

Erwartet waere 16 (10+5+1), Ergebnis ist 11. Aenderung von T1 ist verloren.

Serialisierbare Historie (Isolation gewahrt)

Zwei Transaktionen laufen verzahnt, aber das Ergebnis entspricht einer seriellen Ausfuehrung T1 vor T2. Die verzahnte Historie ist somit korrekt.

Schritt  T1         T2
1.       BOT
2.       read(A)
3.                  BOT
4.                  read(C)
5.       write(A)
6.                  write(C)
7.       read(B)
8.       write(B)
9.       commit
10.                 read(A)
11.                 write(A)
12.                 commit

Aeuivalent zu serieller Ausfuehrung T1 -> T2, weil T2 nur committete Aenderungen von T1 sieht.

Grafik: ACID im Ueberblick

Der Zylinder zeigt die vier ACID-Eigenschaften als vertikale Segmente. Auf der Zeitachse laufen T1 und T2 verzahnt. Ein Absturz zwingt Recovery, T1 mit Undo zurueckzuziehen (Atomicity) und T2 aus dem Log per Redo wiederherzustellen (Durability). Isolation verhindert, dass T2 die noch nicht committeten Daten von T1 sieht.

FAQ

Wofuer steht ACID?

Atomicity (Atomaritaet), Consistency (Konsistenz), Isolation und Durability (Dauerhaftigkeit). Es sind die vier Bedingungen, die eine Transaktion erfuellen muss, um die Datenbank sicher von einem konsistenten Zustand in den naechsten zu ueberfuehren.

Was bedeutet Alles oder Nichts konkret?

Die Atomicity-Eigenschaft. Entweder werden alle Operationen einer Transaktion vollstaendig ausgefuehrt und mit commit festgeschrieben, oder es wird keine einzige Operation wirksam und die Datenbank wird per rollback in den Zustand vor Transaktionsbeginn zurueckversetzt.

Warum ist Isolation notwendig, wenn Consistency schon Konsistenz sichert?

Consistency prueft nur, dass eine einzelne Transaktion die Datenbankregeln vor und nach ihrem Lauf einhaelt. Isolation stellt sicher, dass parallele Transaktionen sich gegenseitig nicht sichtbar beeinflussen. Ohne Isolation koennten mehrere Transaktionen einzeln konsistent sein, aber gemeinsam Anomalien wie Dirty Read, Lost Update oder Phantome erzeugen.

Wie unterscheiden sich Dirty Read und Nonrepeatable Read?

Beim Dirty Read liest T2 einen Wert, den T1 noch nicht committet hat (T1 kann noch abbrechen). Beim Nonrepeatable Read liest T2 zweimal denselben Datensatz und erhaelt unterschiedliche Werte, weil eine andere Transaktion zwischenzeitlich committet geaendert hat. Beide verletzen Isolation, aber auf unterschiedliche Weise.

Wie wird Durability technisch realisiert?

Durch Logging und Recovery. Aenderungen werden vor dem commit in ein Transaktionsprotokoll geschrieben (Write-Ahead Logging). Nach einem Absturz kann das DBMS committete Transaktionen aus dem Log wiederherstellen (Redo) und nicht committete zuruecksetzen (Undo).

Was ist der Zusammenhang von ACID und Isolationslevel?

Isolationslevel sind eine kontrollierte Aufweichung des Isolation-I in ACID. Zugunsten hoeherer Parallelitaet und Performance kann man niedrigere Level (Read Uncommitted, Read Committed, Repeatable Read) waehlen und akzeptiert bestimmte Anomalien. Serializable ist die strikte ACID-konforme Stufe.

Kann eine Transaktion Atomicity ohne Durability erfuellen?

Theoretisch ja, praktisch macht das keinen Sinn. Ohne Durability koennten committete Aenderungen nach einem Absturz verlorengehen, wodurch der Zustand Alles ausgefuehrt nicht garantiert waere. Atomicity und Durability werden in der Praxis gemeinsam durch Logging und Recovery umgesetzt.

Wie erkenne ich in einer Aufgabe eine Verletzung der Atomicity?

In der Ablauftabelle wird eine Transaktion nach einigen writes abgebrochen (abort) und einige Aenderungen bleiben in der Datenbasis sichtbar. Oder umgekehrt: Nach einem Systemabsturz sind committete Aenderungen verloren, dann ist Durability verletzt.

Pruefungsfragen

0 von 12 Fragen beantwortet 0%