Eine Überweisung, eine Bestellung oder eine Buchung besteht selten aus nur einem einzelnen Datenbankbefehl. Fällt das System zwischen zwei Schritten aus, dürfen weder Geld noch Bestände oder Beziehungen in einem halbfertigen Zustand zurückbleiben. Genau hier setzen ACID-Transaktionen an: Sie verbinden Zuverlässigkeit, Datenintegrität und kontrollierte Nebenläufigkeit in einem klaren Modell.
ACID sorgt für verlässliche Datenbankänderungen
- Atomicity bedeutet, dass eine Transaktion ganz oder gar nicht ausgeführt wird.
- Consistency bewahrt Regeln, Schlüssel und Geschäftslogik der Datenbank.
- Isolation verhindert, dass parallele Vorgänge sich unkontrolliert beeinflussen.
- Durability stellt sicher, dass bestätigte Änderungen auch nach einem Absturz erhalten bleiben.
- Transaktionsgrenzen und das passende Isolationsniveau entscheiden in der Praxis über Sicherheit und Geschwindigkeit.
Was mit acid transactions wirklich gemeint ist
Der englische Ausdruck acid transactions bezeichnet Datenbanktransaktionen, die vier grundlegende Eigenschaften erfüllen. ACID steht für Atomicity, Consistency, Isolation und Durability, auf Deutsch also Atomarität, Konsistenz, Isolation und Dauerhaftigkeit.
Eine Transaktion ist dabei eine logische Einheit von Arbeit. Sie kann aus einem einzigen SQL-Befehl bestehen oder aus mehreren Schritten, die nur gemeinsam sinnvoll sind. Erst mit COMMIT werden die Änderungen dauerhaft bestätigt. Bei einem Fehler sorgt ROLLBACK dafür, dass die Datenbank zum vorherigen gültigen Zustand zurückkehrt.
| Eigenschaft | Praktische Bedeutung |
|---|---|
| Atomicity | Alle Änderungen werden übernommen oder keine. |
| Consistency | Regeln und Integritätsbedingungen bleiben erfüllt. |
| Isolation | Parallele Transaktionen sehen keine unkontrollierten Zwischenstände. |
| Durability | Bestätigte Daten bleiben auch nach einem Ausfall erhalten. |
Ich halte eine Unterscheidung für besonders wichtig: ACID ist keine automatische Garantie für gute Daten. Das System kann nur die Regeln schützen, die Entwickler und Datenbankadministratoren tatsächlich definiert haben. Ein falscher Lagerbestand bleibt falsch, selbst wenn er technisch sauber in einer Transaktion gespeichert wurde.
Die vier Eigenschaften anhand eines realen Beispiels
Betrachten wir eine Zahlung von Konto A nach Konto B. Die Datenbank muss den Betrag von einem Konto abziehen und dem anderen gutschreiben. Zwischen diesen beiden Vorgängen darf kein Zustand entstehen, in dem das Geld auf beiden Konten fehlt oder doppelt vorhanden ist.
Atomarität verhindert halbfertige Vorgänge
Schlägt die Gutschrift fehl, muss auch die Belastung zurückgenommen werden. Ganz oder gar nicht ist der Kern der Atomarität. Ein Serverabsturz, ein Timeout oder eine verletzte Nebenbedingung darf keine teilweise ausgeführte Überweisung hinterlassen.
Konsistenz schützt fachliche Regeln
Konsistenz bedeutet nicht nur, dass die Datenbank formal erreichbar ist. Sie muss nach dem Abschluss weiterhin gültige Zustände enthalten, etwa einen vorhandenen Fremdschlüssel, einen nicht negativen Kontostand oder eine eindeutige Bestellnummer. Solche Bedingungen werden durch Constraints, Trigger und Anwendungscode gemeinsam abgesichert.
Isolation trennt gleichzeitige Zugriffe
Wenn zwei Prozesse gleichzeitig denselben Kontostand lesen und verändern, kann ohne geeignete Isolation ein sogenannter Lost Update entstehen. Beide lesen beispielsweise 100 Euro, obwohl einer bereits 30 Euro abgezogen hat. Die Datenbank braucht deshalb Regeln dafür, welche Zwischenstände sichtbar sind und wann ein Vorgang warten oder zurückgerollt werden muss.
Lesen Sie auch: Datenbankaufbau - Mehr als nur Tabellen: Dein Leitfaden
Dauerhaftigkeit überlebt den Absturz
Nach einem erfolgreichen COMMIT darf eine Änderung nicht einfach verschwinden, nur weil der Server kurz danach ausfällt. Datenbanksysteme nutzen dafür unter anderem Transaktionsprotokolle und Wiederherstellungsmechanismen. Dauerhaftigkeit bedeutet allerdings nicht, dass Backups unnötig werden. Sie schützt den bestätigten Vorgang, ersetzt aber keine Strategie gegen versehentliches Löschen oder einen vollständigen Infrastrukturverlust.
Gerade dieses Beispiel zeigt, warum ACID mehr ist als eine theoretische Abkürzung. Die Eigenschaften greifen ineinander und sorgen dafür, dass eine fachliche Handlung auch technisch als zusammenhängender Vorgang behandelt wird.
Wie Transaktionen in der Praxis ablaufen
Ein typischer Ablauf beginnt mit dem Öffnen der Transaktion. Danach führt die Anwendung ihre Lese- und Schreiboperationen aus. Nur wenn alle Prüfungen erfolgreich sind, folgt der Commit.
- Die Transaktion wird gestartet.
- Relevante Datensätze werden gelesen und gegebenenfalls gesperrt.
- Änderungen werden geprüft und geschrieben.
- Bei Erfolg wird mit
COMMITbestätigt. - Bei einem Fehler wird mit
ROLLBACKzurückgesetzt.
Ein vereinfachtes Beispiel für eine Überweisung sieht so aus:
BEGIN;
UPDATE konto
SET saldo = saldo - 50
WHERE konto_id = 101
AND saldo >= 50;
UPDATE konto
SET saldo = saldo + 50
WHERE konto_id = 202;
COMMIT;In einer echten Anwendung reicht dieses Beispiel allein nicht aus. Sie muss prüfen, ob beide Updates tatsächlich einen Datensatz verändert haben, ob die Konten existieren und ob bei einem Fehler ein Rollback erfolgt. Die Transaktion muss so kurz wie möglich bleiben, weil lange offene Transaktionen Sperren halten, Speicher binden und andere Nutzer ausbremsen können.
Ein häufiger Fehler ist, externe Aktionen innerhalb der Transaktion auszuführen. Ein API-Aufruf, eine E-Mail oder ein Dateiupload kann hängen bleiben, während die Datenbank weiterhin gesperrte Datensätze hält. Besser ist oft ein Muster mit Outbox-Tabelle und nachgelagerter Verarbeitung: Die Datenbankänderung wird sicher gespeichert, die externe Aktion folgt anschließend nachvollziehbar.
Welches Isolationsniveau passt zur Anwendung
Isolation ist kein einfacher Ein-Aus-Schalter. Sie ist ein Kompromiss zwischen Schutz vor Nebenläufigkeitsfehlern und erzielbarer Leistung. Je strenger die Isolation, desto eher müssen Transaktionen warten oder bei Konflikten erneut ausgeführt werden.
| Isolationsniveau | Schutz | Typische Verwendung |
|---|---|---|
| Read Uncommitted | Sehr gering, unbestätigte Daten können sichtbar werden. | Seltene Sonderfälle, nicht für kritische Buchungen. |
| Read Committed | Nur bestätigte Daten werden gelesen. | Häufiger Standard für Geschäftsanwendungen. |
| Repeatable Read | Gelesene Werte bleiben innerhalb der Transaktion stabil. | Auswertungen und Vorgänge mit mehreren Prüfungen. |
| Serializable | Stärkste logische Isolation, Konflikte sind wahrscheinlicher. | Besonders kritische Geschäftsregeln und Buchungen. |
Die genaue Umsetzung unterscheidet sich zwischen PostgreSQL, MySQL und anderen Systemen. Manche Engines verwenden überwiegend MVCC, also mehrere Versionen von Datensätzen, andere kombinieren Versionierung mit Sperren. Deshalb sollte man sich nicht allein auf den Namen eines Isolationsniveaus verlassen, sondern das Verhalten mit realistischen Paralleltests prüfen.
Meine praktische Faustregel lautet, mit dem vom Datenbanksystem empfohlenen Standard zu beginnen und nur bei einem konkreten Problem davon abzuweichen. Ein unnötig strenges Niveau kann die Anwendung verlangsamen, ein zu lockeres Niveau kann dagegen unbemerkte Datenfehler erzeugen.
ACID in PostgreSQL, MySQL und verteilten Systemen
Relationale Datenbanken wie PostgreSQL oder MySQL mit der InnoDB-Engine bieten umfangreiche Transaktionsfunktionen. Dazu gehören Rollbacks, Sperrmechanismen, Protokollierung und verschiedene Isolationsstufen. Entscheidend ist aber, dass tatsächlich eine transaktionsfähige Storage-Engine und eine korrekt konfigurierte Anwendung verwendet werden.
Bei einer einzelnen Datenbank ist die Transaktionsgrenze vergleichsweise klar. Schwieriger wird es, wenn ein Vorgang mehrere Datenbanken, Dienste oder Regionen betrifft. Eine lokale Transaktion kann nicht automatisch garantieren, dass auch ein externer Zahlungsdienst oder ein zweiter Service im selben Moment erfolgreich war.
Für solche Fälle kommen Muster wie Outbox, Saga oder idempotente Verarbeitung zum Einsatz. Eine Saga zerlegt den Gesamtvorgang in mehrere lokale Transaktionen und definiert Ausgleichsaktionen. Das ist nicht dasselbe wie eine vollständig atomare globale Transaktion, lässt sich aber in verteilten Architekturen oft besser betreiben.
Auch NoSQL-Systeme können ACID-Transaktionen unterstützen, allerdings mit unterschiedlichen Grenzen bei Umfang, Dauer und Verteilung. Ich würde deshalb nie pauschal behaupten, eine bestimmte Datenbank sei einfach „ACID-konform“. Die richtige Frage lautet, für welche Daten, Operationen und Fehlerfälle die Garantien tatsächlich gelten.
Typische Fehler bei der Arbeit mit Transaktionen
Viele Probleme entstehen nicht, weil die Datenbank ACID falsch umsetzt, sondern weil die Anwendung die Grenzen schlecht festlegt. Besonders riskant ist es, mehrere voneinander abhängige Schreibvorgänge ohne gemeinsame Transaktion auszuführen.
- Zu kleine Transaktion: Ein zusammengehöriger Geschäftsprozess wird in unabhängige Einzelaktionen zerlegt.
- Zu große Transaktion: Langsame Berechnungen oder externe Netzwerkaufrufe halten Sperren unnötig lange.
- Fehlende Fehlerprüfung: Die Anwendung ignoriert, dass ein Update keine Zeile verändert hat.
- Keine Wiederholungslogik: Deadlocks oder Serialisierungsfehler werden nicht kontrolliert erneut ausgeführt.
- Falsche Erwartungen an Rollback: Eine bereits versendete E-Mail oder ausgeführte Zahlung wird durch ein Datenbank-Rollback nicht zurückgeholt.
Bei Deadlocks blockieren sich zwei Transaktionen gegenseitig, weil jede auf eine Ressource wartet, die die andere hält. Das ist in parallelen Systemen nicht immer vermeidbar. Anwendungen sollten deshalb Deadlock-Fehler erkennen, kurz warten und den Vorgang begrenzt wiederholen, statt blind endlos neue Versuche zu starten.
Für die Qualitätssicherung empfehle ich Tests mit gleichzeitigen Zugriffen, absichtlich ausgelösten Fehlern und simulierten Verbindungsabbrüchen. Erst solche Tests zeigen, ob Datenintegrität tatsächlich gewährleistet ist oder nur im störungsfreien Idealfall funktioniert.
Was eine belastbare Transaktionsstrategie ausmacht
Eine gute Lösung beginnt mit der fachlichen Frage, welche Änderungen untrennbar zusammengehören. Danach werden passende Constraints definiert, die Transaktion möglichst kurz gehalten und das Isolationsniveau anhand realer Konflikte gewählt. Die Datenbank sollte wichtige Regeln selbst erzwingen, statt sie ausschließlich dem Anwendungscode zu überlassen.
Für kritische Systeme gehören außerdem Monitoring, Backups, Wiederherstellungstests und aussagekräftige Protokolle dazu. ACID schützt einzelne bestätigte Vorgänge, aber nicht automatisch vor Bedienfehlern, falschen Geschäftsregeln oder einem komplett verlorenen Datenbestand.
Wer diese Grenzen versteht, kann Transaktionen gezielt einsetzen. Für Kontobewegungen, Bestellungen, Lagerbuchungen und Stammdatenänderungen sind sie meist unverzichtbar. Für große Analyseabfragen oder verteilte Langläufer braucht es dagegen oft eine Kombination aus geeigneten Lesemodellen, Zwischenständen und nachgelagerter Verarbeitung.
