Recovery

Um Durability zu gewährleisten, müssen Datenbanken so arbeiten, dass committete Änderungen auch nach einem Crash noch zuverlässig Bestand haben, andere jedoch nicht. Dies ließe sich mit der Policy

• non steal (uncommitete Änderungen dürfen nicht auf die Festplatte geschrieben werden) und
• force (commitete Änderungen müssen sofort auf die Festplatte geschrieben werden)

erreichen. Dies würde allerdings die Parallelisierbarkeit viel zu stark einschränken, so dass reale Datenbanken fast ausschließlich steal und non force verwenden. Stattdessen verwenden sie ein sogenanntes Write-Ahead-Log (WAL).

• non force macht redo notwendig
• steal macht undo notwendig

Write Ahead Log

• Speichert jede Änderung
• muss bei jedem Commit auf die Festplatte geschrieben werden
• muss bei jeder Verdrängung von Seiten auf die Festplatte geschrieben werden
• In den Seiten auf der Festplatte wird vermerkt, von welcher LSN ihr Stand ist
• Attribute
  • LSN: Fortlaufende Nummerierung der Logeinträge
  • TransaktionsID
  • PageID
  • Redo
  • Undo
  • Prev-LSN: die vorherige LSN der gleichen Transaktion

Beispiel:

Recovery-Vorgang

• Redo alle Logbucheinträge, die noch nicht in der Datenbank stehen
• Undo alle Logbucheinträge von Loser(uncommitteten)-Transaktionen
  • Schreibe hierbei für jeden Eintrag einen CLR ins Logbuch
    • Ohne Undo-Eintrag
    • Mit Undo-Next-LSN

Sollte es währenddessen zu einem erneuten Absturz kommen, sind diese CLR schon Teil der Redo-Phase und die Undo-Phase kann für jede Transaktion beim Undo-Next-LSN des letzten CLR fortgesetzt werden.