Rollback – Warum Geld auf Deinem Konto nicht verschwindet

Unser Geld wir mit Datenbanken verwaltet.

Aber warum sind Datenbanken so robust, dass wenn der Strom ausfällt, keine Transaktion verschwindet oder mehr Geld auf dem Konto ist?

Datenbanken arbeiten mit Rollbacks!

Dieser Beitrag erklärt es!

Warum brauchen wir Transaktionen und Rollbacks?

• Stromausfälle und Internetausfälle: Die Infrastruktur kann am Datenbankserver schnell zusammenbrechen. Der Strom fällt aus! Das Internet ist gestört! In allen Fällen wollen wir nicht das unser Gehalt bzw. Mietzahlung auf dem richtigen Konto ankommt ohne, dass die Euros verschwinden.
• Speicherausfälle / Hardwareausfall: Server sind robuste Hardware, die 1000nde Stunden ohne Probleme läuft – aber dann fällt doch zufällig genau der Server aus, wo mein Kontostand gespeichert ist. Wir müssen davon ausgehen, dass jede Hardware irgendwann ausfällt, egal wie gut geprüft oder hochpreisig diese ist.
• Programmierfehler: Banksysteme sind häufig Uralt-Knochen wie eine IBM System i AS/400, die mit der Programmiersprachen COBOL laufen. Auch wenn diese Programme 40+ Jahre erprobt sind, treten immer wieder Programmierfehler auf.
• Zwei Systeme Abhängigkeiten: Wenn eine Transaktion über Banken bzw. Grenzen hinweg stattfindet, nutzen wir in der Regel das SWIFT Zahlungssystem. Die Datenbanken und Programme können in beiden Banken unterschiedlich sein und diese Speicherung anders ausfallen.
• Nachvollziehbarkeit und rechtlicher Nachweis: Für den Staat / Zentralbank gibt es nichts Schlimmeres, als ein Krimineller der digital Geld produzieren oder vernichten kann. Über die Geldmenge entscheidet die Zentralbank und alle Transaktionen müssen kohärent sein. Die Bürger brauchen eine stabile Währung für den Handel. Datenbank Transaktionen gewährleisten diesen aus der technischen Sichtweise.

Was ist eine Transaktion?

Eien ACID-Datenbank bevorzugt einen konsistenten Stand statt Verfügbarkeit und Schnelligkeit von Datenbeschaffung und -änderung. ACID steht für:

• Atomic: Transaktionen sind nur als Ganzes auszuführen und nicht nur zur Hälfte. Wenn auf Konto A 100 € abgezogen werden, muss auf Konto B immer 100 € dazugerechnet werden. Transaktionen werden klein gehalten (atomisch), damit die Wahrscheinlichkeit sinkt, dass eine große Befehlskette schiefläuft und ständig Rollbacks stattfinden.
• Consistent: Datenbanken arbeiten mit Primärschlüsseln – das sind Identifikatoren für einen Datensatz. Diese müssen eindeutig und korrekt in allen anderen Tabellen referenziert werden. Wenn die Datenbank die Löschung eines Datensatzes ohne Referenzprüfung löscht, ist die Datenbank korrupt und nur manuell wiederherstellbar.
• Integrity: Die Inhalte dürfen nicht ohne einen SQL-Befehl mit den richtigen Berichtigungen abgeändert werden. Datenbank sind gekapselte verschlüsselte Systeme bei dem Datenzuflusskanal und die Datenbank selbst verschlüsselt sein sollten.
• Durable: Die Daten sind dauerhaft gespeichert. Egal ob ein Stromausfall stattfindet oder nicht. Daten können sich im Arbeitsspeicher befinden, diese sind aber noch nicht offiziell geschrieben und Teil der Datenbank. Halbfertig geschriebene Zeilen werden wieder zurückgerollt.

Was passiert im Fehlerfall?

Wenn Mitten in einer Transaktion der Strom ausfällt, dann prüft die Datenbank beim Hochfahren, ob eine Transaktion offen ist. Das geht mit dem Write-A-Head-Log. Das Logging findet vor dem Schreiben auf der Datenbank statt.

Statt den Eintrag noch fertig zu machen. Rollt die Datenbank alles zurück bis zu dem Kommando START TRANSACTION;. Der Grund ist, dass lange Schreiboperationen von langen Texten oder binären Blobs, halb fertig bearbeitete Daten zurücklassen. Die Hälfte des Textes ist geändert, während die andere Hälfte noch nicht beschrieben wurde.

Das Write-A-Head-Log überschreibt den halb-geschriebenen Datensatz, als ob nicht passiert wäre. Wenn das Write-A-Head-Log nicht vollständig geschrieben wurde, wurden die produktiven Daten noch nicht angefasst und die Datenbank blieb konsistent.

Warum sind die Daten immer konsistent?

Eine Datenbank prüft jeden neuen Datensatz oder Änderung von Daten auf Konsistenz. Wir können aus der Tabelle „Gebäude“ das „Haus A“ nicht löschen, wenn die Räume von „Haus A“ noch in der Tabelle „Räume“ nicht gelöscht wurden.

Ein DELETE CASCADE erlaubt das Löschen, aber der Löschbefehl räumt mit allen Referenzen in allen Tabellen auf. Dieser kaskadierenden Befehl kann mehr löschen als man möchte.

Praxis: Rollback auf MariaDB

Eine MariaDB läuft über automatische Transaktionen. Jeder Befehl wird mit einem START TRANSACTION und COMMIT gekapselt. Du kannst mehrere Befehle mit einem Schwung absenden, die immer in dieser Kapselung landen.

Eine START TRANSACTION und COMMIT solltest Du immer einsetzen, wenn zwei Operationen immer nur zusammen ausgeführt werden sollen: Wenn auf Konto A 100 € abgezogen werden, muss auf Konto B immer 100 € dazugerechnet werden. Eine MariaDB würde bei Aktiverung der Auto Transaktion 2 Transaktionen daraus machen.

Zuerst erstellen wir die Tabelle „Konto“

-- 1. 
CREATE TABLE Konto (
    konto_id INT PRIMARY KEY,
    kontonummer VARCHAR(20) UNIQUE NOT NULL,
    inhaber VARCHAR(100) NOT NULL,
    saldo DECIMAL(15, 2) NOT NULL DEFAULT 0.00
);

Erstellen der Tabelle „Überweisung“ zur Protokollierung von Transaktionen

CREATE TABLE Überweisung (
    ueberweisung_id INT PRIMARY KEY,
    von_kontonummer VARCHAR(20) NOT NULL,
    zu_kontonummer VARCHAR(20) NOT NULL,
    betrag DECIMAL(15, 2) NOT NULL,
    datum TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    status VARCHAR(20) NOT NULL,
    FOREIGN KEY (von_kontonummer) REFERENCES Konto(kontonummer),
    FOREIGN KEY (zu_kontonummer) REFERENCES Konto(kontonummer)
);

Einfügen von Beispieldaten in die Tabelle „Konto“

INSERT INTO Konto (konto_id, kontonummer, inhaber, saldo)
VALUES
    (1, 'DE1234567890', 'Max Mustermann', 1000.00),
    (2, 'DE0987654321', 'Erika Musterfrau', 500.00);

Jetzt folgt die Überweisung von Konto 1 auf Konto 2 mit BEGIN TRANSACTION und COMMIT und ROLLBACK. Die Programmierlogik prüft in einer IF Bedingung, ob der Kontostand auch wirklich erhöht wurde, sonst findet einen ROLLBACK statt. Das COMMIT bestätigt die Transaktion.

BEGIN TRANSACTION;

-- Prüfen, ob das abgebende Konto ausreichend Guthaben hat
IF (SELECT saldo FROM Konto WHERE kontonummer = 'DE1234567890') >= 200.00 THEN
    -- Abbuchen vom Konto 1
    UPDATE Konto
    SET saldo = saldo - 200.00
    WHERE kontonummer = 'DE1234567890';

    -- Gutschreiben auf Konto 2
    UPDATE Konto
    SET saldo = saldo + 200.00
    WHERE kontonummer = 'DE0987654321';

    -- Protokollieren der Überweisung als erfolgreich
    INSERT INTO Überweisung (ueberweisung_id, von_kontonummer, zu_kontonummer, betrag, status)
    VALUES (1, 'DE1234567890', 'DE0987654321', 200.00, 'erfolgreich');

    -- Transaktion bestätigen
    COMMIT;

    SELECT 'Überweisung erfolgreich durchgeführt.' AS ergebnis;
ELSE
    -- Protokollieren der Überweisung als fehlgeschlagen
    INSERT INTO Überweisung (ueberweisung_id, von_kontonummer, zu_kontonummer, betrag, status)
    VALUES (2, 'DE1234567890', 'DE0987654321', 200.00, 'fehlgeschlagen');

    -- Transaktion zurückrollen
    ROLLBACK;

    SELECT 'Fehler: Unzureichendes Guthaben auf dem abgebenden Konto.' AS ergebnis;
END IF;

Das Kommando ROLLBACK führt die Datenbank nur beim Fehlerfall aus. Du kannst das Kommando ROLLBACK für Lernzwecke verwenden, aber Du wirst es in Produktion weniger sehen.

Wieso haben Überweisungen früher so lange gebraucht?

Die normalen Überweisungen arbeiten wie Banken analog. Es gibt Öffnungszeiten und einen Annahmeschluss. Wer nicht zu rechten Zeit überweist, muss auf den Montag bzw. nach den Feiertagen warten. Es werden manuelle Prüfungen durchgeführt und Überweisungen dauert häufig länger als einen Tag. Die Prüfungen beziehen sich auf Betrug oder Geldwäsche.

Mit der Echtzeitüberweisung wird die Transaktion innerhalb von 10 Sekunden an jedem Tag des Jahres durchgeführt, solange Deine Online-Bank keine Wartung hat. Die Echtzeitüberweisungen sind seit Oktober 2025 nicht teurer als die normale Überweisung. Dazu mussten sich alle Banken an das Target Instant Payment System anschließen, um Echtzeitüberweisungen anzunehmen und abzusenden.

Datenbanken und die Netzwerke sind seit Jahrzehnten in der Lage in nahe zu Echtzeit Überweisungen auszuführen. Eine Schreiboperation dauert auf SSD nur wenige Nanosekunden und die Netzwerk-Pakete erreichen in wenigen Millisekunden die Zielbank.