Rollback

Dieser Artikel ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Angaben ohne ausreichenden Beleg könnten demnächst entfernt werden. Bitte hilf Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst.

Großteil des Artikels stammt zwar aus der prä-EN Zeit, enthält jedoch nicht einmal allgemeine Belege. Zumindest etwas Literatur angeben.

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.

before-image-journal

Protokollierung des Zustands vor der Änderung für alle in einer Transaktion erfolgten Änderungen von Objekten

after-image-journal

Protokollierung des Zustands nach der Änderung für alle in einer Transaktion erfolgten Änderungen von Objekten

evtl. Checkpoints

• 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)

Das Anlegen des before-images im Logfile muss zwingend zeitlich vor der Änderung in der Datenbasis erfolgen.

Nach erfolgreichem Abschluss einer Transaktion wird die zugehörige Information im before-image-journal nicht mehr benötigt, sie kann gelöscht bzw. überschrieben werden.

Das before-image wird nur für einen Rollback benötigt.

• 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)

Nach erfolgreichem Abschluss einer Transaktion muss die zugehörige Information im after-image-journal aufbewahrt werden.

Das after-image dient der Wiederherstellung vollendeter Transaktionen nach einem Datenverlust durch Hard- oder Softwarefehler.

• Checkpointmarker
• Eintrag für jede offene, noch nicht geschriebene Datei
• Marke für jede nicht abgeschlossene Transaktion (mit T-ID)

Checkpoints werden nur für eine Systemwiederherstellung nach einem Hard- oder Softwarefehler benötigt (Desaster-Recovery)

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.

• 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