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 (Compensation Log Record) ins Logbuch
    • Ohne Undo-Eintrag
    • Mit Undo-Next-LSN
    • Mit <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.

Checkpoints

brauchen wir, damit Redo und Undo nicht beliebig weit in die Vergangenheit zurück gemacht werden müssen

Arten:

• Transaktionskonsistente Sicherungspunkte
  • Alle Transaktionen zu Ende laufen lassen
  • keine neuen beginnen
  • Vorteil: Logbuch von davor kann weg
  • Nachteil: Datenbank lange komplett geblockt
• Aktionskonsistente Sicherungspunkte
  • wartet, bis laufende Operationen abgeschlossen sind
  • speichert aktive Transaktionen und minLSN
    • nur für diese muss im WAL zurückgegangen werden
• Unscharfe Sicherungspunkte
  • asynchron, mehr Aufwand
  • speichert dirty pages und deren LSN, aktive Transaktionen und minLSN
  • keine Unterbrechung des Datenbankbetriebs