Rollback

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten (Unterschied zur vorletzten Version).

Dieser Artikel beschäftigt sich mit dem EDV-Begriff „Rollback“, den gleichlautenden Begriff aus der Zeit des geteilten Deutschlands findest du unter Rollback-Politik

Als Rollback bzw. Rücksatz bezeichnet man in EDV-Systemen das „Zurücksetzen“ der einzelnen Verarbeitungsschritte einer Transaktion. Das System wird dadurch vollständig auf den Zustand vor Aufruf 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.

Rollbacks spielen vor allem im Zusammenhang mit Datenbanksystemen und Dateisystemen eine wichtige Rolle. Zur Aufrechterhaltung der referenziellen Integrität wird die Gesamtheit aller Änderungsschritte als Transaktion aufgefasst, und nur im Fall einer erfolgreichen Abarbeitung aller Schritte einer Transaktion werden die Änderungen dauerhaft (persistent) gemacht, andernfalls erfolgt ein Rollback in den Zustand der Datenbank oder des Dateisystems vor Beginn der Transaktion. Diesem Ablauf liegt das ACID-Prinzip zu Grunde.

Rollback ist also eine Maßnahme zur Datensicherung (Recovery-Maßnahme). Sie zielt auf die Verhinderung von Datenverlusten und die Vermeidung von Inkosistenzen und Datenanomalien oder zumindest auf die Reduzierung der Auswirkungen ab.

Ein Rollback ist nur möglich, wenn zu Beginn jeder 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.

[Bearbeiten] Inhalt der Protokoll-Datei (logfile)

before-image-journal: Protokollierung des Zustands vor der Änderung für alle in einer Transaktion erfolgten Änderung von Objekten
after-image-journal: Protokollierung des Zustands nach der Änderung für alle in einer Transaktion erfolgten Änderung von Objekten
evtl. Checkpoints

[Bearbeiten] Struktur des before-image-journal in der Protokoll-Datei

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ötiogt, sie kann gelöscht bzw. überschrieben werden.

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

[Bearbeiten] Struktur des after-image-journal in der Protokoll-Datei

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 Softwarefehlern.

[Bearbeiten] Struktur der Checkpoints in der Protokoll-Datei

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)

[Bearbeiten] Wiederherstellung

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.