01

Transaktion = Sequenz von Operationen die als eine (atomare) Einheit ausgeführt werden

Eigenschaften: ACID

• Atomicity —> alles oder nichts

• Consistency —> Konsistenter Zustand -> wieder k. Zustand

• Isolation —> Jede Transaktion hat die DB “für sich allein”

• Durability —> Änderungen erfolgreicher Transaktionen dürfen NIE verloren gehen

• Lokaler Fehler in einer noch nicht committed Transaktion

  • Wirkung muss zurückgesetzt werden

  • R1-Recovery

• Fehler mit Hauptspeicherverlust (Stromausfall)

  • Abgeschlossene TAs müssen erhalten bleiben

  • R2-Recovery -> redo

  • Noch nicht abgeschlossene TAs müssen zurückgesetzt werden

  • R3-Recovery -> undo

• Fehler mit Hintergrundspeicherverlust

  • R4-Recovery

• Hintergrundspeicher (SSD, ect.)

• DBMS-Puffer (Hauptspeicher)

• steal: Auslagerung von noch nicht abgeschlossenen Transaktionen —> undo (loser)

• no force: Geänderte Seiten können im Puffer vebleiben —> redo (winner)

• Update in Place —> Zustand wird immer überschrieben

• Twin-Block-Verfahren —> Zustand wird doppelt gespeichert

• Schattenspeicherkonzept —> Nur neue Zustände werden extra gespeichert

[LSN, TransaktionsID, PageID, Redo, Undo, PrevLSN]

• LSN (Log Sequence Number)

  • eindeutige Kennung

  • müssen monoton aufsteigend sein —> zeitliche Reihenfolge der Einträge

• TransaktionsID

  • Key der TA, die die Änderunger hervorgerufen hat

• PageID

  • Key(s) der Seite(n) mit der Änderung

• Redo

  • wie die Änderung nachvollzogen werden kann (after image)

• Undo

  • Änderung rückgängig machen (before image)

• PrevLSN

  • Key der vorhergehenden LSN —> benötigt für Performance (R1 recorvery)

• Physisch:

  • before-image

  • after-image

• Logisch

  • Undo

  • Redo

Anhand der Seiten-LSN

Wird mindestens zweimal geschrieben:

• Log-Datei —> schneller Zugriff

  • R1-3 Recovery

• Log-Archiv

  • R4-Recovery

• commit einer TA erst wenn: alle dazugehörigen Log-Einträge ausgeschrieben sind (sicherer Hafen)

• Modifizierte Seite auslagern wenn: alle dazugehörigen Log-Einträge müssen im temporären Speicher und im Log-archiv sein

• T1 TAs (Winner) müssen vollständig nachvollzogen werden

• T2 TAs (Loser) müssen rückgängig gemacht werden

1. Analyse

   • Log-Datei durchsuchen —> T1 und T2 ermitteln

2. Wiederholung der Historie (Redo)

   • alle protokollierten Änderungen werden in der Reihenfilge ihrer Ausführung in die DB eingebracht

   • die LSN des Logs wird mit der Seiten-LSN verglichen —> redo notwendig oder nicht

   • LBS-Eintrag auf der Seite wird aktualisiert

3. Undo der Loser (Undo)

   • Änderungen der Loser-TAs werden in umgekehrter Reihenfolge rückgängig gemacht —> protokollieren

Compensation-Log-Records

-> haben spitze Klammern <…>

Aufbau:

• LSN

• TA-ID

• betroffene Seite

• Redo-Information

• PrevLSN

• UndoNxtLSN —> nächste rückgängig zu machende Änderung

—> enthalten keine Undo-Information, ein mal Loser -> immer Loser

-> Sicherungspunkt = Checkpoint —> Recovery muss nurnoch bis dahin prüfen

Qualitäten:

• no force

• no steal