Wie funktionierten Datenbank-Undo/Redo-Logs?



  • Der grundsätzliche Aufbau ist mir klar, allerdings habe ich da noch ein Problem mit dem Verständnis.

    Log-Eintrag folgt nach der getanen Arbeit (bspw. einem UPDATE). Damit das Programm auch während des UPDATEs abstürzen kann, trägt man alle notwendigen Daten schon vorher ins Log, führt dann das Update aus, und setzt dann das Log auf "abgeschlossene Aktivität".

    Was aber wenn das DBMS zwischendurch abstürzt? Quasi mittem im Update oder aber auf jeden Fall noch vor dem Setzen des Flags "abgeschlossen"?

    Wie verhindert man da Konsistenzprobleme?

    MfG SideWinder



  • Wenn eine Änderung stattfindet werden nicht nur die Redo-Informationen (das After-Image) sondern auch die Undo (Before-Image) gespeichert. Bei einem Delete existieren die Info's im Log die notwendig sind den Datensatz wiederherzustellen (Before-Image), bei einem Insert nur das After-Image um den noch nicht (vollständig) ausgeführten Schreibbefehl erneut ausführen zu können und ein Update benötigt beide Images.
    Wenn ein Crash erfolgt muß das System beim Wiederhochfahren automatisch ein Crash-Recovery durchführen: die winner-Transaktionen (welche committed sind) müssen nachgefahren werden und die Änderungen der loser, welche es nicht zum Commit geschafft haben müssen zuvor getilgt werden. Wenn die Transaktion deines Update-Befehls nicht abgeschlossen wurde aber aufgrund der steal/not force-Straegie die Änderungen schon auf der Disk sind muß eben das Before-Image des Update-Befehles wieder eingespielt werden.


Anmelden zum Antworten