Als Rollback (vom englischen „roll back“ für „zurückrollen“ oder „zurückdrehen“) bezeichnet man in EDV-Systemen das „Zurücksetzen“ der einzelnen Verarbeitungsschritte einer Transaktion. Das System wird dadurch vollständig auf den Zustand vor dem Beginn der Transaktion zurückgeführt.
Ein Rollback wird typischerweise im Fehlerfall angestoßen, falls beispielsweise ein Verarbeitungsschritt in der betreffenden Transaktion nicht korrekt durchgeführt werden kann. Im normalen Ablauf (ohne Fehlersituation) werden mit einem „Commit“ die Änderungen der Transaktion permanent gemacht.
Rollbacks spielen vor allem im Zusammenhang mit Datenbanksystemen und anderen transaktionalen Systemen eine wichtige Rolle. Eine Transaktion ist hierbei eine Folge zusammengehöriger Operationen auf einer Datenbank. Dabei kann eine Transaktion die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand überführen. Während der Transaktion können die Konsistenzregeln einer Datenbank abgeschaltet sein. Um die Konsistenz des Datenbestands zu gewährleisten, müssen Transaktionen immer vollständig oder gar nicht ausgeführt werden (vgl. ACID-Prinzip). Die unvollständige Ausführung einer Transaktion, z. B. aufgrund eines Systemfehlers, führt zum Rollback der Transaktion.
Das Rollback ist neben dem Redo eine Maßnahme zur Datensicherung („Recovery-Maßnahme“). Sie zielt auf die Vermeidung von Inkonsistenzen.
Eine umfassende Datensicherung ist nur möglich, wenn für jede Transaktion ein Protokoll geführt wird. Dieses Protokoll nennt man auch Journal, logfile oder audit trail. Wegen der sequentiellen (chronologischen) Aufzeichnung der Änderungen bietet sich hier eine sequentielle Datei an.
Inhalt der Protokoll-Datei (logfile) Bearbeiten
Struktur des before-image-journal in der Protokoll-Datei Bearbeiten
- Marke für Beginn einer Transaktion, enthält zugleich Identifikation der Transaktion
- für jedes veränderte/ gelöschte Objekt (meist: jeden Satz, Zeile, Tupel) eine Kopie des Zustands vor der Änderung, bestehend aus Identifikation und Inhalt; dazu die T-ID
- Marke für das Ende einer Transaktion (mit T-ID)
Struktur des after-image-journal in der Protokoll-Datei Bearbeiten
- Marke für Beginn einer Transaktion, enthält zugleich Identifikation der Transaktion
- für jedes veränderte/ neu eingefügte Objekt eine Kopie des Zustands nach der Änderung, bestehend aus Identifikation und Inhalt; dazu die T-ID
- Marke für das Ende einer Transaktion (mit T-ID)
Struktur der Checkpoints in der Protokoll-Datei Bearbeiten
- Checkpointmarker
- Eintrag für jede offene, noch nicht geschriebene Datei
- Marke für jede nicht abgeschlossene Transaktion (mit T-ID)
Wiederherstellung Bearbeiten
Bei Verlust der aktuellen Datenbasis ist eine Wiederherstellung wie folgt möglich:
- Das before-image-journal in der Protokoll-Datei wird rückwärts gelesen
- Für jedes veränderte Objekt, d. h. jeden Eintrag mit entsprechender Transaktions-Identifikation, wird der alte Inhalt vom Logfile in die Datenbank zurückgeschrieben.
Das Verfahren beendet sich durch das Lesen der Marke für den Beginn der entsprechenden Transaktion.
Bei einer Desaster-Recovery muss das System die Checkpoints ermitteln:
- Suche nach dem jüngsten Checkpoint, der nur offene Transaktionen enthält, die in einem späteren Checkpoint beendet sind
- Ermitteln aller offenen, nicht geschriebenen Dateien
- Einarbeiten aller after-images von beendeten Transaktionen, die nicht physisch geschrieben wurden
Zusammen mit Sicherungskopien können Daten auch nach einem Totalverlust wieder hergestellt werden.
Ursachen für den Verlust von Daten Bearbeiten
- Systemzusammenbrüche infolge von Hardware-Defekten
- Systemzusammenbrüche infolge von Software-Fehlern
- unerwartete Betriebsstörungen, z. B. Netzausfall
- mechanische Fehler, z. B. Kopfaufsetzer bei Magnetplattenlaufwerken
- äußere Gewalteinwirkung, z. B. Brand, Explosion, Überschwemmung
- Sabotageaktionen