4 Recovery

Das Recovery ist der Prozess der Wiederherstellung eines konsistenten Zustands der Datenbank nach einem Fehler.

Recovery-Manager

• setzt die Recovery-Techniken um

Recovery-Senarien

1. Sekunderspeicherverlust
   • Ursaache z.B. Head-Crash, Controller-Fehler, Naturkatastrophen
   • Maßnamen:
     • Einspielen des letzten Backups
     • Nachvolziehen aller Transaktionen seit dem Backup-Zeitpunkt mit Hilfe der Log-Datei
     • wichtig ist, dass Log-Datei nicht beschädigt ist und deshalb sollten Datenbanken und Log-Datei auf einem separaten Speichermedium (Platten) gehalten werden.
2. Hauptspeicherverlust
   • Ursache z.B. Stromausfall, Speicherfehler im Haupspeicher
   • Maßnahme:
     • Nicht beendeter Transaktionen zurücksetzen und Änderungen auf Sekundärspeicher rückgängigmachen (globales UNDO)
     • Beenderter Transaktionen wiederholen, deren Änderungen noch nicht auf Sekundärspeicher geschrieben wurden. (globales REDO)
3. Transaktionsfehler
   • Usache z.B. Fehler im Anwendungsprogramm, Expliziter Abbbruch durch ROLLBACK-Anweisung oder Impliziter Abbruch durch z.B. Integritätsverletzung
   • Maßnahmen:
     • Transaktion zurücksetzen
     • Vorgenommene Änderungen auf Sekundärspeicher rückgängigmachen(lokales UNDO)

Für die Fälle 2 und 3 gibt es verschiedene Techniken, die sich darin unterscheiden, wie Aktualisierungen auf Sekundärspeicher geschrieben werden:

Deferred Update

Aktualisierungen werden nur dann in die Datenbank geschrieben, nachdem die Transaktion den COMMIT-Zeitpunkt erreicht hat.

• Vor COMMIT

  • Alle Aktualisierung werden nur in der Log-Datei protokolliert, aber nicht in den DB-Puffer oder die Datenbank geschrieben.

• Bei COMMIT

  • Ein COMMIT-Eintrag wird in die Log-Datei geschrieben
  • All Log-Informationen der aktuellen Transaktion werden aus der Log-Datei in die Datenbank geschrieben.

• Bei Transaktionsabbruch

  • Jede Transaktion mit BEGIN TRANCATION- und Abbruch-Eintrag in Log-Datei wird ignoriert.

• REDO

  • REDO kann notwendig sein, da Änderungen eventuell die Datenbank noch nicht erreicht haben.

• Fehler während der DB-Aktualisierung

  • Transaktion kann aus den Log-Informationen rekonstruiert werden.

dabei werden die Aktualisierung vor dem Commit in Log gespeichert und erst nach Commit in die Datenbank.

• CheckPoint

  • Log-Datei muss die Log-Datei ab dem letzten Checkpoint vorwärts durchgegangen werden.

  • Jede Transaktion mit BEGIN TRANSACTION- und COMMIT-Eintrag in Log-Datei wird wiederholt (REDO: Änderungen committiter Transaktion)

  • After-Image-Einräge werden in Log-Datei verwendet.

  • Wurde dieses Schreiben auch schon vor dem Fehler ausgeführt, so hat das REDO keinen Effekt

  • Jede Transaktion mit BEGIN TRANCATION- und Abbruch-Eintrag in Log-Datei wird ignoriert.

• Beispiel

  • Fehler/Abbruch vor COMMIT → keine Maßnamen notwendig.
  • Fehler nach COMMIT → zwei Senarien “Man weißt nicht genau”, ob
    1. Die Aktualisierung in den DB-Puffer geschrieben und nicht in die Datenbank übernommen wurde.
       • REDO der Transaktion ist notwendig.
    2. Die Aktualisierung in den DB-Puffer geschrieben und in die Datenbank übernommen wurden.
       • REDO der Transaktion ohne Effekt.

Immediate Update

• Aktualisierungen werden sofort in DB-Puffer bzw. in Datenbank vor Commitgeschrieben.

• REDO von Transaktionen und UNDO bis zum Fehlerzeitpunkt nicht committeter Transaktionen notwendig

• Log-Datei wird für diese Technik eingesetzt:

  • Beim Start wird BEGIN TRANCACTION-Eintrag in Log-Datei vorgenommen
  • Bei jeder Schreiboperation: Eintrag in Log-Datei vorgenommen, anschließend Schreiben in DB-Puffer
  • Annahme: Beim nächsten Durchschreiben des DB-Puffer auf Sekundärspeicher werden Aktualisierungen in DB übertragen (auch die unvollständiger Transaktionen)
  • Wird Transaktion mit COMMIT-Anweisung abgeschlossen, wird COMMIT- Eintrag in Log-Datei vorgenommen
  • Wird Transaktion abgebrochen, wird Log-Datei zum UNDO benutzt: Alle Änderungsoperationen werden in umgekehrter Reihenfolge ausgeführt

WAL-Prinzip (Write-Ahead Log Protocol):

• Einträge immer zuerst in die Log-Datei müssen geschrieben werden, bevor sie in die Datenbank bzw. Datenbank-Puffer geschrieben werden
• Vor Commit alle Log-Einträge in Log-Datei schreiben → Notwendig für REDO
• Vor Auslagern modifizierte Seite alle Log-Einträge in Log-Datei schreiben → Notwendig für UNDO

• Im Fehlerfall analysiert der Recovery-Manager die Log-Datei vorwärts und führt folgende Schritte aus:

  • Identifiziert “Gewinner”-Transaktionen (mit COMMIT-Eintrag) und “Verlierer”-Transaktionen (ohne COMMIT-Eintrag)
  • Führt REDO für Gewinner-Transaktionen durch, um sicherzustellen, dass alle ihre Änderungen in die Datenbank übernommen wurden
  • Führt UNDO für Verlierer-Transaktionen durch, um alle ihre Änderungen rückgängig zu machen.

• Beispiel

  • UNDO für abgebrochne Transaktionen
  • REDO für abgeschlossene Transaktionen

Lokales und globales UNDO

• Lokales UNDO: Rückgängigmachen der Änderungen einer einzelnen Transaktion
• Globales UNDO: Rückgängigmachen der Änderungen aller nicht committeten Transaktionen

Wann wird REDO ausgeführt

REDO wird ausgeführt, um committete Transaktionen zu wiederholen, deren Änderungen die Datenbank möglicherweise noch nicht erreicht haben. Dies ist sowohl bei Deferred Update als auch bei Immediate Update notwendig

Shadow Paging

Shadow Paging ist eine alternative Recovery-Technik zu den Log-basierten Ansätzen Deferred und Immediate Update. Anstatt Änderungen direkt in den Datenseiten zu speichern und diese Änderungen in einem Log zu protokollieren, verwendet Shadow Paging eine Kopie der Seitentabelle, die sogenannte Schattentabelle (SPT)

Funktionsweise

• Transaktionsbeginn
  • Zu Beginn einer Transaktion wird die aktuelle Seitentabelle (CPT) in die Schattentabelle (SPT) kopiert.
  • SPT bleibt während der Transaktion unverändert.
  • Bei Schreiboperationen wird eine neue Version der betroffenen Seite angelegt und der Verweis in der CPT auf diese neue Seite geändert.

• Recovery bei Fehler
  • Datenbankzustand vor Transaktion ist durch SPT vorhanden und wird dadurch wiederhergestellt
  • Modifizierten Seiten werden freigegeben und die CPT verworfen
  • SPT wird zur neuen CPT.
• Commit einer Transaktion
  • Modifizierte Seite auf Platte schreiben
  • CPT auf Platte schreiben
  • Alte, von der SPT referenzierten Seiten werden freigegeben.
  • CPT verwerfen

Vorteile

• Weniger Plattenzugriffe.
• Reduzierter Overhead: Der Overhead der Log-Datei-Verwaltung entfällt.
• Schnellere Recovery: Wiederherstellung der Datenbank im Fehlerfall ist erheblich schneller.

Nachteile

• Fragmentierung der Daten (Tabvelleninhalte verteilt, damit schlechtere Leseperformacne)
• Garbage Coolection notwendig, um die freigegebenen Seiten zu verwalten.
• Komplexität bei parallelen Transaktionen

Zusammenfassung der Reovery-Strategien

• Unterscheidung nach Schreib-Zeitpunk in Datenbanken
  • Steal: Änderungen jederzeit schreiben (auch vor COMMIT)
  • No-Steal: Änderung erst nach Transaktionsende (also nach COMMIT) schreiben
• Unterscheidung nach Auslagerung
  • Force: Änderungen sofort am Transaktionsende speichern
  • No-Force: Änderungen später speichern

• Logging/Recovery:

	No Steal	Steal
No Force	Kein UNDO, REDO	UNDO, REDO
Force	Kein UNDO, Kein REDO	UNDO, Kein REDO

• Performance (Durchsatz):

	No Steal	Steal
No Force		Schnellste
Force	Langsamste

• Verfahren:

	No Steal	Steal
No Force	Deferred Update	Immediate Update
Force	Shadow Paging