Wiederanlauf nach einem Fehler

Abbildung 14.4: Zwei Transaktionstypen bei Systemabsturz

Abbildung 14.4 zeigt die beiden Transaktionstypen, die nach einem Fehler mit Verlust des Hauptspeicherinhalts zu behandeln sind:

• Transaktion $T_1$ ist ein Winner und verlangt ein Redo.
• Transaktion $T_2$ ist ein Loser und verlangt ein Undo.

Abbildung 14.5: Wiederanlauf in drei Phasen

Der Wiederanlauf geschieht in drei Phasen (Abbildung 14.5):

1. Analyse: Die Log-Datei wird von Anfang bis Ende analysiert, um die Winner (kann commit vorweisen) und die Loser (kann kein commit vorweisen) zu ermitteln.
2. Redo: Es werden alle protokollierten Änderungen in der Reihenfolge ihrer Ausführung in die Datenbasis eingebracht, sofern sich nicht bereits das Afterimage des Protokolleintrags in der materialisierten Datenbasis befindet. Dies ist dann der Fall, wenn die LSN der betreffenden Seite gleich oder größer ist als die LSN des Protokolleintrags.
3. Undo: Die Log-Datei wird in umgekehrter Richtung, d.h. von hinten nach vorne, durchlaufen. Dabei werden die Einträge von Winner-Transaktionen übergangen. Für jeden Eintrag einer Loser-Transaktion wird die Undo-Operation durchgeführt.

Spezielle Vorkehrungen müssen getroffen werden, um auch Fehler beim Wiederanlauf kompensieren zu können. Es wird nämlich verlangt, daß die Redo- und Undo-Phasen idempotent sind, d.h. sie müssen auch nach mehrmaliger Ausführung (hintereinander) immer wieder dasselbe Ergebnis liefern:

undo(undo(...(undo(a))...)) = undo(a)
redo(redo(...(redo(a))...)) = redo(a)