Rollback - LinkFang.de





Rollback


Dieser Artikel behandelt das Rollback in der EDV. Zur Strategie der USA im Kalten Krieg siehe Rollback-Politik.
Dieser Artikel oder Abschnitt ist nicht ausreichend belegt.

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)

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

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ötigt, sie kann gelöscht bzw. überschrieben werden.
Das before-image wird nur für einen Rollback benötigt.

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

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)

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.

Ursachen für den Verlust von Daten

  • 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

Kategorien: Datenbanktheorie

Quelle: Wikipedia - http://de.wikipedia.org/wiki/Rollback (Vollständige Liste der Autoren des Textes [Versionsgeschichte])    Lizenz: CC-by-sa-3.0

Änderungen: Alle Bilder mit den meisten Bildunterschriften wurden entfernt. Ebenso alle zu nicht-existierenden Artikeln/Kategorien gehenden internen Wikipedia-Links (Bsp. Portal-Links, Redlinks, Bearbeiten-Links). Entfernung von Navigationsframes, Geo & Normdaten, Mediadateien, gesprochene Versionen, z.T. ID&Class-Namen, Style von Div-Containern, Metadaten, Vorlagen, wie lesenwerte Artikel. Ansonsten sind keine Inhaltsänderungen vorgenommen worden. Weiterhin kann es durch die maschinelle Bearbeitung des Inhalts zu Fehlern gerade in der Darstellung kommen. Darum würden wir jeden Besucher unserer Seite darum bitten uns diese Fehler über den Support mittels einer Nachricht mit Link zu melden. Vielen Dank!

Stand der Informationen: August 201& - Wichtiger Hinweis: Da die Inhalte maschinell von Wikipedia übernommen wurden, ist eine manuelle Überprüfung nicht möglich. Somit garantiert LinkFang.de nicht die Richtigkeit und Aktualität der übernommenen Inhalte. Sollten die Informationen mittlerweile fehlerhaft sein, bitten wir Sie darum uns per Support oder E-Mail zu kontaktieren. Wir werden uns dann innerhalb von spätestens 10 Tagen um Ihr Anliegen kümmern. Auch ohne Anliegen erfolgt mindestens alle drei Monate ein Update der gesamten Inhalte.