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