ACID-Eigenschaften im Detail erklaert

1. Was ACID bedeutet und warum Transaktionen es brauchen

Die ACID-Eigenschaften sind kein akademisches Konzept, sondern das konkrete Versprechen, das eine relationale Datenbank an jede Transaktion gibt. Das Akronym steht fuer Atomicity, Consistency, Isolation und Durability und beschreibt vier voneinander unabhaengige Garantien, die zusammen dafuer sorgen, dass Daten auch unter Nebenlaeufigkeit, Fehlern und Stromausfaellen korrekt bleiben. Ohne diese Garantien muesste jede Anwendung selbst Buch fuehren, welche Aenderung schon geschrieben wurde, welche noch offen ist und welche wieder rueckgaengig gemacht werden muss.

In der Praxis begegnen einem ACID-Eigenschaften ueberall dort, wo mehrere zusammenhaengende Aenderungen als eine logische Einheit gelten muessen: eine Ueberweisung, die zwei Konten gleichzeitig aendert, eine Bestellung, die einen Lagerbestand reduziert und einen Auftrag anlegt, oder eine Registrierung, die einen Benutzer und ein Profil in getrennten Tabellen anlegt. Der SQL-Standard definiert die Transaktion als Baustein, ueber den diese vier Eigenschaften garantiert werden, und jede ernstzunehmende relationale Datenbank implementiert sie, wenn auch mit unterschiedlichen technischen Mitteln.

Die folgenden Abschnitte gehen jede einzelne der vier ACID-Eigenschaften getrennt durch, jeweils mit einem konkreten Beispiel, was ohne die jeweilige Garantie tatsaechlich passiert. Erst danach wird klar, warum ACID als Gesamtpaket und nicht als vier separate Features gedacht werden sollte.

2. Atomicity: alles oder nichts

Atomicity garantiert, dass eine Transaktion entweder vollstaendig ausgefuehrt wird oder gar keine ihrer Aenderungen sichtbar wird. Es gibt keinen Zwischenzustand, in dem nur die Haelfte der Anweisungen einer Transaktion wirksam ist. Das klassische Beispiel ist die Kontoueberweisung: Ein Betrag wird von Konto A abgebucht und auf Konto B gutgeschrieben. Beide Operationen muessen zusammen gelingen oder zusammen scheitern, sonst verschwindet Geld oder wird verdoppelt.

Ohne Atomicity koennte folgendes passieren: Die Abbuchung von Konto A wird erfolgreich geschrieben, aber vor der Gutschrift auf Konto B stuerzt der Prozess ab oder eine Netzwerkverbindung bricht ab. Ohne Rollback-Mechanismus bleibt Konto A dauerhaft belastet, waehrend Konto B nie das Geld erhaelt. Bei tausenden taeglichen Transaktionen summieren sich solche Luecken zu handfesten finanziellen Schaeden, die im Nachhinein nur mit muehsamen manuellen Abgleichen zu reparieren sind.

-- Atomicity in Aktion: beide Aenderungen gelingen oder keine
BEGIN;

UPDATE accounts SET balance = balance - 250.00 WHERE account_id = 1001;
UPDATE accounts SET balance = balance + 250.00 WHERE account_id = 2002;

-- Guard: Kontostand darf nicht negativ werden
-- Schlaegt die Bedingung fehl, wird die gesamte Transaktion verworfen
DO $$
BEGIN
  IF (SELECT balance FROM accounts WHERE account_id = 1001) < 0 THEN
    RAISE EXCEPTION 'Insufficient funds on account 1001';
  END IF;
END $$;

COMMIT;
-- Bei RAISE EXCEPTION wird implizit ROLLBACK ausgeloest,
-- beide UPDATE-Anweisungen werden dann verworfen, keine bleibt haengen

Technisch setzen Datenbanken Atomicity ueber Undo-Logs oder Multi-Version-Mechanismen um: Jede Aenderung wird zunaechst in einem Log oder einer neuen Zeilenversion festgehalten, sichtbar wird sie erst beim COMMIT. Kommt es vorher zu einem Fehler, nutzt die Datenbank dieses Log, um alle bereits geschriebenen Aenderungen der Transaktion rueckgaengig zu machen. Fuer die Anwendung bedeutet das: Ein explizites ROLLBACK im Fehlerfall ist zwar guter Stil, aber selbst ein abgebrochener Prozess ohne sauberes ROLLBACK hinterlaesst keine halb geschriebene Transaktion, weil die Datenbank beim naechsten Start unvollstaendige Transaktionen automatisch zuruecksetzt.

3. Consistency: Integritaet bleibt immer gewahrt

Consistency bedeutet, dass eine Transaktion die Datenbank nur von einem gueltigen Zustand in einen anderen gueltigen Zustand ueberfuehren darf. Gueltig heisst hier: alle definierten Constraints, Foreign Keys, Unique-Indizes und CHECK-Bedingungen sind nach dem COMMIT weiterhin erfuellt. Anders als Atomicity, Isolation und Durability, die von der Datenbank-Engine selbst garantiert werden, ist Consistency eine geteilte Verantwortung zwischen Datenbank und Anwendungsdesign: Die Datenbank erzwingt nur die Regeln, die tatsaechlich als Constraint definiert wurden.

Ein konkretes Beispiel: Eine Tabelle orders referenziert per Foreign Key eine Tabelle customers. Ohne Consistency-Garantie koennte eine Transaktion eine Bestellung mit einer Kundennummer anlegen, die gar nicht existiert, weil der zugehoerige Kunde parallel geloescht wurde. Das Ergebnis waeren verwaiste Datensaetze, die bei Reports, Exporten oder Joins zu NULL-Werten oder fehlenden Zeilen fuehren, ohne dass ein offensichtlicher Fehler auftritt. Solche Inkonsistenzen fallen oft erst Wochen spaeter auf, wenn ein Report falsche Summen zeigt.

-- Consistency durch Constraints erzwingen
CREATE TABLE customers (
  customer_id  INT PRIMARY KEY,
  email        VARCHAR(255) NOT NULL UNIQUE
);

CREATE TABLE orders (
  order_id     INT PRIMARY KEY,
  customer_id  INT NOT NULL REFERENCES customers(customer_id),
  total_amount NUMERIC(10,2) NOT NULL CHECK (total_amount >= 0)
);

-- Diese Transaktion scheitert an der Foreign-Key-Regel,
-- weil customer_id 9999 nicht existiert
BEGIN;
INSERT INTO orders (order_id, customer_id, total_amount)
VALUES (5001, 9999, 149.90);
-- ERROR: insert or update on table "orders" violates
-- foreign key constraint "orders_customer_id_fkey"
ROLLBACK;

4. Isolation: parallele Transaktionen sauber trennen

Isolation regelt, wie stark sich gleichzeitig laufende Transaktionen gegenseitig sehen duerfen, bevor sie committen. In der Theorie sollte jede Transaktion so ablaufen, als waere sie die einzige auf dem System, doch diese vollstaendige Isolation kostet Performance, weil sie im Zweifel Sperren oder Serialisierung erfordert. Der SQL-Standard definiert deshalb vier Isolation Levels als abgestufte Kompromisse zwischen Korrektheit und Nebenlaeufigkeit, von READ UNCOMMITTED bis SERIALIZABLE.

Ohne ausreichende Isolation koennen mehrere Anomalien auftreten: Eine Transaktion liest Daten, die eine andere, noch nicht committete Transaktion geschrieben hat (Dirty Read), oder eine Transaktion liest dieselbe Zeile zweimal und bekommt unterschiedliche Werte, weil eine andere Transaktion dazwischen committet hat (Non-Repeatable Read). Ein konkretes Praxisbeispiel: Zwei parallele Bestellprozesse lesen beide den aktuellen Lagerbestand von zehn Stueck, beide reduzieren ihn unabhaengig um fuenf und schreiben ihn zurueck. Ohne ausreichende Isolation landet der Lagerbestand am Ende bei fuenf statt bei null, obwohl fuenfzehn Stueck reserviert wurden. Details zu den vier Isolation Levels und den konkreten Anomalien behandelt der vertiefende Beitrag zu Isolation Levels und der Beitrag zu Dirty Read, Phantom Read und Non-Repeatable Read.

5. Durability: einmal committed, fuer immer gespeichert

Durability garantiert, dass eine erfolgreich committete Transaktion auch einen sofortigen Absturz des Servers, einen Stromausfall oder einen Kernel-Panic ueberlebt. Sobald der Client die Bestaetigung fuer ein COMMIT erhaelt, muss die Datenbank zusichern, dass diese Daten dauerhaft auf einem persistenten Speichermedium liegen, nicht nur im fluechtigen Arbeitsspeicher. Technisch wird das ueber ein Write-Ahead-Log umgesetzt: Vor dem eigentlichen Schreiben der Datenseiten wird jede Aenderung zuerst in ein sequentielles Log geschrieben und dieses Log mit einem fsync-Aufruf physisch auf die Platte gezwungen.

Ohne Durability koennte folgendes passieren: Eine E-Commerce-Anwendung zeigt dem Kunden nach dem Checkout eine Bestaetigungsseite fuer seine Bestellung, weil die Datenbank das COMMIT bestaetigt hat. Der Server stuerzt drei Sekunden spaeter ab, weil ein Betriebssystem-Fehler auftritt. Beim Neustart fehlt die Bestellung, weil sie nur im Seiten-Cache des Betriebssystems lag und nie auf die Platte geschrieben wurde. Der Kunde hat eine Bestaetigung, das System hat keine Bestellung, das Vertrauen in die Plattform ist beschaedigt.

-- Durability-relevante Einstellungen, vendor-spezifisch

-- PostgreSQL: erzwingt physisches fsync bei jedem COMMIT
-- (Standardwert "on", niemals fuer Produktionsdaten deaktivieren)
SET synchronous_commit = on;

-- MySQL/InnoDB: schreibt und leert das Redo-Log bei jedem COMMIT
-- Wert 1 ist die ACID-konforme Einstellung
SET GLOBAL innodb_flush_log_at_trx_commit = 1;

-- Wert 2 schreibt das Log, ueberlaesst das fsync aber dem Betriebssystem
-- Schneller, aber bei einem OS-Crash (nicht DB-Crash) koennen
-- die letzten ein bis zwei Sekunden committeter Transaktionen verloren gehen
-- SET GLOBAL innodb_flush_log_at_trx_commit = 2;  -- nicht ACID-konform

Diese Einstellungen zeigen einen typischen Trade-off: Volle Durability kostet Latenz, weil jedes COMMIT auf einen physischen Plattenzugriff wartet. Manche Systeme lockern diese Garantie bewusst fuer Performance, etwa bei Session-Daten oder Analytics-Events, bei denen ein Verlust weniger Sekunden akzeptabel ist. Fuer Finanztransaktionen, Bestellungen und alles, was rechtlich nachweisbar sein muss, ist die volle Durability-Einstellung nicht verhandelbar.

6. Das Zusammenspiel der vier Eigenschaften in der Praxis

Die vier ACID-Eigenschaften wirken nicht unabhaengig voneinander, sondern greifen im Lebenszyklus einer einzigen Transaktion ineinander. Atomicity sorgt dafuer, dass alle Anweisungen zwischen BEGIN und COMMIT als Einheit behandelt werden. Consistency stellt sicher, dass diese Einheit nur committet, wenn alle Constraints erfuellt sind. Isolation regelt, was parallele Transaktionen von dieser Einheit sehen, bevor sie abgeschlossen ist. Durability garantiert, dass das Ergebnis nach erfolgreichem COMMIT dauerhaft bestehen bleibt.

-- Alle vier ACID-Eigenschaften in einer Transaktion demonstriert
BEGIN;                                    -- Startpunkt der atomaren Einheit

-- Isolation: andere Transaktionen sehen diese Aenderungen
-- erst nach dem COMMIT (abhaengig vom Isolation Level)
UPDATE inventory SET stock = stock - 3
WHERE product_id = 42 AND stock >= 3;     -- Consistency: verhindert negativen Bestand

INSERT INTO order_items (order_id, product_id, quantity)
VALUES (7781, 42, 3);

-- Atomicity-Guard: wurde tatsaechlich eine Zeile aktualisiert?
-- Wenn stock < 3 war, betrifft das UPDATE 0 Zeilen, kein Fehler ausgeloest
-- Anwendungscode muss ROW_COUNT bzw. affected rows explizit pruefen

COMMIT;                                   -- Durability: ab hier fsync-gesichert
-- Erst nach diesem Punkt ist das Ergebnis garantiert absturzsicher

Dieses Zusammenspiel erklaert auch, warum man selten von "einer" ACID-Eigenschaft ohne die anderen drei spricht. Eine Datenbank, die Atomicity ohne Isolation bietet, wuerde zwar niemals eine halbe Transaktion committen, aber parallele Transaktionen koennten sich trotzdem gegenseitig inkonsistente Zwischenzustaende zeigen. Erst alle vier zusammen ergeben das Versprechen, das Entwickler von einer relationalen Datenbank normalerweise voraussetzen, ohne es explizit zu hinterfragen.

7. ACID vs. BASE: wann Konsistenz wichtiger ist als Verfuegbarkeit

Viele NoSQL-Systeme werben mit dem Gegenmodell BASE, Basically Available, Soft State, Eventually Consistent. Der Unterschied zu ACID-Eigenschaften ist kein Qualitaetsurteil, sondern ein bewusster Trade-off nach dem CAP-Theorem: Bei einer Netzwerkpartition muss ein verteiltes System entweder Konsistenz oder Verfuegbarkeit aufgeben. Relationale Datenbanken mit ACID entscheiden sich im Zweifel fuer Konsistenz, viele verteilte NoSQL-Systeme fuer Verfuegbarkeit.

Fuer Anwendungsfaelle wie Finanztransaktionen, Bestandsverwaltung, Vertragsdaten oder alles mit rechtlicher Nachweispflicht ist strenge ACID-Konformitaet praktisch alternativlos, weil ein kurzfristig inkonsistenter Kontostand echten Schaden verursacht. Fuer Anwendungsfaelle wie Social-Media-Feeds, Like-Zaehler oder Produktempfehlungen ist eventual consistency dagegen oft ausreichend, weil eine Verzoegerung von wenigen Sekunden bei der Sichtbarkeit keinen messbaren Schaden anrichtet, aber die Verfuegbarkeit des Systems bei Netzwerkproblemen erhoeht. Die Wahl zwischen ACID und BASE sollte deshalb immer aus den Konsequenzen einer Inkonsistenz abgeleitet werden, nicht aus einem generellen Trend.

8. ACID in der Praxis: Umsetzung in verschiedenen Datenbank-Engines

Nicht jede Datenbank-Engine implementiert ACID-Eigenschaften vollstaendig oder mit denselben Mitteln. Der klassische Unterschied bei MySQL zeigt das gut: Die Storage-Engine InnoDB ist voll ACID-konform inklusive Transaktionen, Foreign Keys und Crash-Recovery, waehrend die aeltere MyISAM-Engine keine Transaktionen unterstuetzt und bei einem Absturz inkonsistente Tabellen hinterlassen kann. Wer heute noch MyISAM-Tabellen im Einsatz hat, verzichtet bewusst oder unbewusst auf Atomicity und Durability.

Auch zwischen vollstaendig ACID-konformen Systemen gibt es Unterschiede in Default-Konfiguration und Implementierungsdetails, etwa beim verwendeten Isolation Level oder beim Verhalten von DDL-Anweisungen innerhalb einer Transaktion. Die folgende Tabelle zeigt die wichtigsten Unterschiede im Ueberblick.

9. Haeufige Fehler im Umgang mit Transaktionen

Der haeufigste Fehler im Umgang mit ACID-Eigenschaften ist Autocommit, das in vielen Treibern und ORMs standardmaessig aktiviert ist. Jede einzelne SQL-Anweisung wird dann als eigene Transaktion behandelt, wodurch zusammenhaengende Aenderungen ihre Atomicity verlieren, obwohl die Datenbank selbst ACID-konform ist. Ein zweiter haeufiger Fehler ist das Fehlen eines expliziten ROLLBACK im Exception-Handler: Wenn eine Anwendung nach einem Fehler einfach die Verbindung schliesst, ohne explizit zurueckzurollen, bleibt die Transaktion offen und blockiert im schlimmsten Fall Sperren fuer andere Sitzungen.

-- WRONG: Autocommit macht zwei zusammengehoerige UPDATEs
-- zu zwei unabhaengigen Mini-Transaktionen
UPDATE accounts SET balance = balance - 250 WHERE account_id = 1001;
-- Absturz genau hier: Konto 1001 bleibt belastet, Konto 2002
-- erhaelt nie die Gutschrift, weil jede Anweisung sofort committet wurde
UPDATE accounts SET balance = balance + 250 WHERE account_id = 2002;

-- RIGHT: explizite Transaktionsklammer erzwingt Atomicity
BEGIN;
UPDATE accounts SET balance = balance - 250 WHERE account_id = 1001;
UPDATE accounts SET balance = balance + 250 WHERE account_id = 2002;
COMMIT;

-- RIGHT: Exception-Handling mit explizitem ROLLBACK
-- (Pseudocode fuer Anwendungslogik, angelehnt an gaengige Treiber-APIs)
-- try {
--   connection.execute("BEGIN");
--   connection.execute(updateStatement1);
--   connection.execute(updateStatement2);
--   connection.execute("COMMIT");
-- } catch (error) {
--   connection.execute("ROLLBACK");
--   throw error;
-- }

Ein dritter Fehler betrifft lange laufende Transaktionen: Eine Transaktion, die minutenlang offen bleibt, weil sie auf eine externe API oder eine Benutzereingabe wartet, haelt in vielen Isolation Levels Sperren oder verhindert das Aufraeumen alter Zeilenversionen. Das Ergebnis sind wachsende Undo-Segmente, aufgeblaehte Tabellen und im Extremfall blockierte Transaktionen anderer Nutzer. Transaktionen sollten so kurz wie moeglich gehalten werden, mit allen langsamen, nicht-datenbankbezogenen Operationen ausserhalb von BEGIN und COMMIT.

10. Zusammenfassung

Die ACID-Eigenschaften Atomicity, Consistency, Isolation und Durability sind vier getrennte, aber zusammenwirkende Garantien, die relationale Datenbanken fuer jede Transaktion geben. Atomicity verhindert halb geschriebene Aenderungen, Consistency erzwingt Integritaetsregeln, Isolation schuetzt vor gegenseitiger Stoerung paralleler Transaktionen und Durability sichert committete Daten gegen Abstuerze ab. Jede dieser Eigenschaften loest ein konkretes, real auftretendes Problem, kein theoretisches.

In der Praxis zeigt sich der Wert von ACID vor allem dort, wo man es vergisst: Autocommit, fehlende Constraints, zu schwache Isolation Levels oder abgeschaltete Durability-Garantien fuehren still zu Dateninkonsistenzen, die oft erst Wochen spaeter als kaputte Reports oder falsche Kontostaende sichtbar werden. Wer Transaktionen explizit klammert, Constraints konsequent definiert und die Trade-offs von Isolation Levels versteht, nutzt die vollen ACID-Eigenschaften seiner Datenbank, statt sie unbewusst zu unterlaufen.

11. FAQ: ACID-Eigenschaften im Detail erklaert