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

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

Write Ahead Log

Beispiel:

Bildschirmfoto_20240724_181411.png

Recovery-Vorgang

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:


Revision #5
Created 24 July 2024 15:57:05 by Kuchenmampfer
Updated 25 July 2024 10:20:10 by Kuchenmampfer