Was sind Transaktionen?
Bisher haben wir Datenbanken aus der Perspektive einzelner SQL-Befehle betrachtet – ein INSERT hier, ein UPDATE da. In der echten Welt geht das aber selten in einem einzigen Befehl. Die meisten sinnvollen Geschäftsvorfälle bestehen aus mehreren Schritten, die zusammen einen Sinn ergeben. Eine Transaktion ist genau das: eine logisch zusammengehörige Folge von Operationen, die das DBMS entweder komplett ausführt – oder gar nicht.
Diese kleine Garantie ist riesig. Sie verhindert, dass deine Datenbank in einem halben Zustand stehen bleibt, wenn mitten in einer Operation der Strom ausfällt, ein Programm abstürzt oder eine Netzwerkverbindung abbricht. Diese Lektion zeigt warum Transaktionen unverzichtbar sind und wie sie funktionieren. In Lektion 5 formalisieren wir die Garantien dann als ACID-Prinzipien.
1) Das klassische Beispiel: Banküberweisung
Wenn man jemandem das Konzept „Transaktion" erklären will, kommt unweigerlich die Banküberweisung. Das Beispiel ist so abgegriffen, weil es so klar ist: zwei Operationen, die zwingend zusammengehören.
- Vom Konto A werden 100 € abgebucht:
UPDATE konten SET saldo = saldo - 100 WHERE id = A; - Auf Konto B werden 100 € gutgeschrieben:
UPDATE konten SET saldo = saldo + 100 WHERE id = B;
Stell dir vor, der Server stürzt zwischen Schritt 1 und Schritt 2 ab. Schritt 1 ist schon in der Datenbank gespeichert, Schritt 2 nicht. Ergebnis: 100 € sind weg. Niemand hat sie. Das ist nicht nur ein Bug – das ist ein potentielles Strafverfahren. Genau dieses Szenario verhindert eine Transaktion: entweder beide Updates passieren, oder keines.
COMMIT-Markierung kam, und führt automatisch ein Rollback durch: der Stand vor BEGIN wird wiederhergestellt. Beide Konten stehen wieder bei 1000 € / 500 €. Mehr zu COMMIT und ROLLBACK in Lektion 7.2) Eine Transaktion in SQL definieren
Drei Befehle prägen das Konzept – sie umrahmen deine Operationen und sagen dem DBMS „diese Schritte gehören zusammen":
-- ... beliebig viele SQL-Befehle ...
UPDATE konten SET saldo = saldo - 100 WHERE id = 'A';
UPDATE konten SET saldo = saldo + 100 WHERE id = 'B';
INSERT INTO log (typ, betrag) VALUES ('transfer', 100);
COMMIT; -- alle Änderungen werden DAUERHAFT gespeichert
-- Alternative bei einem Problem:
ROLLBACK; -- alle Änderungen seit BEGIN werden verworfen
Zwischen BEGIN und COMMIT/ROLLBACK sind die Änderungen vorgemerkt, aber noch nicht endgültig. Sie sind für andere Sitzungen je nach Isolationsstufe sichtbar oder nicht. Erst COMMIT macht sie für alle dauerhaft sichtbar. ROLLBACK wirft alles weg.
3) Der Lebenszyklus einer Transaktion
Jede Transaktion durchläuft eine definierte Folge von Zuständen. Klick einen Zustand um zu sehen was darin passiert:
4) Das All-or-Nothing-Prinzip
Das Kern-Versprechen einer Transaktion heißt Atomarität: die ganze Folge wird wie ein einziger, unteilbarer Schritt behandelt. Es gibt nur zwei mögliche Ausgänge:
Eine Transaktion mit vier Schritten. Klick durch die drei Szenarien:
ROLLBACK macht alles rückgängig, auch die Schritte die schon erfolgreich waren. Wenn Schritt 3 scheitert, werden Schritte 1 und 2 ebenfalls verworfen – als hätten sie nie stattgefunden. Das ist die Magie der Transaktion: du musst dir nicht selbst merken was du schon getan hast und es manuell rückgängig machen. Das DBMS führt im Hintergrund ein Logbuch und kann jeden Stand wiederherstellen.5) Wann brauche ich Transaktionen?
Nicht jede SQL-Operation muss in einer expliziten Transaktion stehen. Die meisten DBMS arbeiten im Autocommit-Modus: jeder einzelne Befehl ist automatisch seine eigene Mini-Transaktion. Erst wenn du BEGIN aufrufst, beginnt eine echte mehrteilige Transaktion. Diese Übersicht hilft bei der Entscheidung:
6) Was passiert intern: das Transaktionslog
Damit Atomarität und Wiederherstellbarkeit funktionieren, führt das DBMS im Hintergrund ein Transaktionslog (auch Write-Ahead-Log, WAL). Vereinfacht läuft das so ab:
- Bei
BEGINwird ein neuer Eintrag im Log angelegt. - Jede Änderung wird zuerst ins Log geschrieben – mit alten und neuen Werten.
- Die eigentlichen Daten werden in Puffer im Speicher geändert.
- Bei
COMMITwird ein „committed"-Marker ins Log geschrieben und das Log auf die Platte gezwungen (flush). - Bei
ROLLBACKnutzt das DBMS die alten Werte im Log um die Änderungen rückgängig zu machen. - Bei einem Crash: beim Neustart geht das DBMS das Log durch. Transaktionen ohne „committed"-Marker werden zurückgerollt. Transaktionen mit Marker, deren Daten aber noch nicht auf Platte sind, werden nachgeholt.
Dieses Logbuch ist auch der Grund warum Datenbanken einen Crash überstehen können. Das Log selbst wird vor jedem Commit zwangsweise auf das Speichermedium geschrieben – die Daten in Tabellen-Dateien können später nachgezogen werden. Die Eigenschaft, dass committed Daten wirklich auf Platte sind, nennt man Durability – siehe nächste Lektion.
7) Transaktionen in Anwendungscode
Praktisch nutzt man Transaktionen selten direkt im SQL-Editor, sondern aus dem Anwendungscode heraus. Jede Datenbank-Bibliothek hat dafür eigene Wrapper. Hier in vier verbreiteten Sprachen / Frameworks – die Konzepte sind aber überall gleich:
await client.query('BEGIN');
try {
await client.query('UPDATE konten SET saldo = saldo - $1 WHERE id = $2', [100, 'A']);
await client.query('UPDATE konten SET saldo = saldo + $1 WHERE id = $2', [100, 'B']);
await client.query('COMMIT');
} catch (err) {
await client.query('ROLLBACK');
throw err;
}
# Python mit SQLAlchemy
with session.begin(): # Context Manager – automatisch COMMIT oder ROLLBACK
session.execute("UPDATE konten SET saldo = saldo - 100 WHERE id = 'A'")
session.execute("UPDATE konten SET saldo = saldo + 100 WHERE id = 'B'")
# Bei Exception: automatischer ROLLBACK, sonst COMMIT
Das Muster ist immer dasselbe: begin, eine Reihe Operationen, im Erfolgsfall commit, im Fehlerfall rollback. Moderne Frameworks bieten dafür Context-Manager / Decorator / Annotations die das Boilerplate verschwinden lassen – aber unter der Haube ist es immer dieser Ablauf.
Zusammenfassung
Eine Transaktion ist eine logisch zusammengehörige Folge von SQL-Operationen, die das DBMS entweder komplett oder gar nicht ausführt – das All-or-Nothing-Prinzip. Sie wird mit BEGIN gestartet, mit COMMIT dauerhaft gemacht oder mit ROLLBACK verworfen (Details in Lektion 7). Der Lebenszyklus geht durch Zustände Active → Partially Committed → Committed (oder Aborted). Im Hintergrund führt das DBMS ein Transaktionslog (Write-Ahead-Log), das Atomarität und Wiederherstellbarkeit nach einem Crash ermöglicht. Transaktionen sind nötig, sobald mehrere logisch zusammenhängende Operationen ausgeführt werden – klassisches Beispiel: Banküberweisung. Im Code wird das Muster begin – try – commit – catch – rollback verwendet, oft elegant verpackt in Context-Manager. Die formalen Garantien einer Transaktion fasst das Akronym ACID zusammen – Thema der nächsten Lektion.