Datenbanken: Konsistenz, Transaktionen und Recovery (ACID)

Auf einer Datenbank arbeiten meist viele Benutzer oder Anwendungsprogramme gleichzeitig. Es ist deshalb eine wesentliche Aufgabe von DBMS, dafür zu sorgen, dass sich diese parallelen Vorgänge nicht wechselseitig stören oder zu Fehlern in der Datenbank führen. Das zentrale Konzept zur Sicherung der Korrektheit dieses Geschehens auf einer Datenbank ist das Transaktionskonzept.
Eine andere zentrale Aufgabe des DBMS ist es, dafür zu sorgen, dass die Datenbank nach dem Auftreten von Fehlern, nach Softwareabstürzen oder nach Speicherfehlern wieder in einen konsistenten Zustand versetzt wird. Dieser Komplex wird als Recovery (Wiederherstellung) bezeichnet.

• Beispiele von Inkonsistenzen

1. Eine Referenz ins Leere (jemand löscht ein Tupel, ohne dass die darauf verweisenden Referenzen korrigiert werden).
2. Eine Buchung X ist vom Konto A abgebucht, aber nicht dem Zielkonto B gutgeschrieben.
3. ein negatives Alter

Natürlich kann das DBMS nur in begrenztem Umfang falsche Eingabedaten, die sich aus Fehlern im Anwendungsprogramm ergeben, erkennen. Es gibt jedoch die Möglichkeit, Integritätsbedingungen zu definieren, anhand derer das DBMS Korrektheitsprüfungen vornehmen kann.
Beispielsweise könnte man dem DBMS im Schema der Datenbank mitteilen, dass das Alter einer Person nie negativ sein kann.

Anders sieht die Situation bezüglich paralleler Anwendungsabläufe aus. Da der einzelne Anwendungsprogrammierer oder Nutzer der Datenbank von den parallelen Aktivitäten nichts weiß und auf diese auch keinen Einfluss hat, erwarten wir vom DBMS:

• dass es die parallelen Abläufe so organisiert, dass sie nicht zu Inkonsistenzen führen können (Transaktionsmanagement).
• dass das System in der Lage ist, nach dem Absturz von Systemsoftware oder nach einem Plattenfehler wieder einen konsistenten Zustand der Datenbank herzustellen (Recovery).

Transaktion

Eine Transaktion ist eine Folge von Befehlen, die entweder vollständig und korrekt ausgeführt wird oder überhaupt nicht.

Falls eine Transaktion nicht vollständig ausgeführt werden kann, so bedeutet dies, dass alle schon ausgeführten Operationen rückgängig gemacht werden müssen. Im Ergebnis dürfen weder andere Transaktionen noch die Datenbank selbst in irgendeiner Weise von dieser abgebrochenen Transaktion beeinflusst worden sein, sie hat nicht existiert. Umgekehrt muss das DBMS natürlich gewährleisten, dass Ergebnisse von Transaktionen, die erfolgreich ausgeführt wurden, unter keinen Umständen verloren gehen.

Die Komponente des DBMS, die dafür zuständig ist, dass im Falle von Hardware- oder Softwarefehlern die Datenbank wieder in einen konsistenten Zustand versetzt wird, heißt Recovery-Manager. Der Recovery-Manager legt Sicherungskopien von Datenbeständen an und protokolliert Transaktionen in sog. Logfiles mit, so dass:

• Ergebnisse abgeschlossener Transaktionen nach Fehlern wieder in die Datenbank eingespielt werden können, oder
• Änderungen in der Datenbank, die durch nicht abgeschlossene Transaktionen bewirkt wurden, rückgängig gemacht werden können.

ACID-Prinzip

Abbildung: ACID-Prinzip [1]

Die Eigenschaften einer Transaktion kann man mit dem ACID-Prinzip beschreiben. ACID steht für atomicity, consistency, isolation, durability.

Unteilbarkeit (atomicity)
Eine Transaktion ist eine unteilbare Verarbeitungseinheit; sie wird entweder ganz oder überhaupt nicht ausgeführt.

Konsistenz (consistency)
Eine korrekte Ausführung der Transaktion führt die DB von einem konsistenten zu einem konsistenten Zustand.

Isolation (isolation)
Eine Transaktion muss so ablaufen, als sei sie die einzige im System. Zwischenzustände (die ja inkonsistent sein können) dürfen für andere Transaktionen nicht sichtbar sein.

Dauerhaftigkeit (durability)
Ergebnisse einer erfolgreich beendeten Transaktion sind dauerhaft, d.h. überleben jeden nachfolgenden Fehler.

Es ist Aufgabe des Transaktionsmanagement, für die Unteilbarkeit und Isolation ablaufender Transaktionen zu sorgen. In der Regel bedient sich das Transaktionsmanagement hierfür verschiedener Typen von Sperren, mittels derer Objekte für andere Transaktionen vorübergehend nicht zugreifbar gemacht werden. Es übernimmt von sich aus das Setzen und Freigeben der Sperren, der Anwendungsprogrammierer muss dies nicht programmieren.

Quellen
[1] cdn.softwaretestinghelp.com/wp-content/qa/uploads/2011/06/ACID-Properties.jpg
[2] https://pdfs.semanticscholar.org/5f5e/a0bda200b72c48219e5fda4f8df48a1d4a42.pdf