Folge von Datenbank-Operationen mit den Eigenschaften

Atomicity, Durability durch Recovery in DBMS.

Isolation durch Concurrency / Mehrbenutzersynchronisation in DBMS.

$\small \tt read(A, a)$$\small \tt a := A$ → wobei $\small \tt a$ eine lokale Variable ist

$\small \tt write(A, a)$$\small \tt A := a$

$\small \tt BOT$ Begin of transaction

$\small \tt commit$ Von Arbeitsspeicher zu Festspeicher

$\small \tt abort \color{grey}/ rollback$ Operationen aus Transaktion zurücksetzen aus Arbeitsspeicher

$\small \tt define ~savepoint$ ermöglicht rollback bis savepoint (zusätzlich zu vollständigem)

$\small \tt rollback~to~savepoint$

1. commit

2. abort Aufruf

3. Fehler → abort durch DBMS

Hauptspeicher / RAM schnell, aber flüchtig

Festplatte / Storage langsam, aber persistent, billiger

Einheit zum Verschieben von Datensätzen zwischen Speichern.

Datensatz kann mehrere pages umfassen.

Während page access sind sie fixiert mit fixed-bit und dürfen nicht ausgelagert werden.

Auslagern vor $\small \tt commit$

Auslagern nach $\small \tt commit$

Bei$\small \neg\text{steal + force}$muss Transaktion gesamte page sperren und nicht einzelne Datensätze.

Update-in-Place (direkte Strategie)

Twin-block-verfahren (indirekte Strategie)

Schattenspeicherkonzept (indirekte Strategie)

1. Fehler mit Verlust von Storage

   Nur mit backup / archiv wiederherstellbar

2. Fehler mit Verlust von RAM

   Abgeschlossene Transaktionen (Winner) müssen rekonstruiert werden (globales redo)

   Abgebrochene Transaktionen (Loser) müssen zurückgesetzt werden (globales undo)

3. Lokale Fehler in einer Transaktion

   Eigentlich ein Spezialfall vom oberen Fehler (lokales undo)

$\small \text{force} \rarr \text{kein redo}$

$\small \neg\text{force} \rarr \text{redo}$

$\small \text{steal} \rarr \text{undo}$

$\small \neg\text{steal} \rarr \text{kein undo}$

Auslagerungsstrategie

Write-ahead-log WAL

Kleine Sperrgranulate

LSN Log Sequence Number: ID von log

TransaktionsID ID von Transaktion

PageID ID von page die von operation betroffen ist -ein log pro page

Redo

Undo

PrevLSN Pointer zur vorherigen Log-ID vondieserTransaktion

Jede page erhält auch die LSN vom Log der jüngsten Operation die auf sie ausgeführt wurde.

Physisch

Logisch

Logs in Hauptspeicher als Ringbuffer (getrennt vom restlichen Speicherbereich).

Log-storage kann zusätzlich auch ein backup haben.

LSN

TransaktionsID

PageID

Redo Hat keine undo Information

PrevLSN Älteste LSN von Transaktion welche hiermit rückgängig gemacht wurde

UndoNxtLSN LSN welche als nächstes rückgängig gemacht werden soll (bis$\small \tt BOT$)

1. Analyse

   Aus der Log Datei Loser (ohne $\small \tt commit$ ) finden.

   Älteste LSN für alle Transaktionen finden.

2. Redo: aller Transaktionen

   alle logs werden von Anfang an inkl. CLRs durchgegangen:

   rekonstruiert wenn log-LSN > page-LSN in storage

   In der Praxis hat man mit physischen logs die after-images vom ältesten log.

3. Undo: aller Loser-Transaktionen

   zusätzlich CLR-logs machen (sollte System währenddessen nochmals abstürzen)

   Ablauf:

   In umgekehrter Reihenfolge alle Logs durchgehen.

   1. Älteste LSN der Transaktion zurücksetzen

      Bzw aus der Liste entfernen wenn die Operation $\small \tt BOT$ war.

   2. CLR erstellen mit

      CLR-PrevLSN := älteste LSN der Transaktion welche gerade zurückgesetzt wird (kann auch von einer CLR sein)

      CLR-UndoNxtLSN := entnommene Log-PrevLSN aus dem zurückgesetzten Log-Eintrag

   3. page-LSN auf CLR-LSN setzen

$\small \tt local~undo$ , $\small \tt undo~until~savepoint$

Erhöhte Effizienz, indem Log-Einträge die noch im RAM sind benutzt werden können

Ablauf:

Zeitpunkt bis zu der man lokal zurücksetzt

Zeitpunkt bei der man alle Transaktionen commited (damit die Analyse vom aller ersten log anfangen muss)

Blockiert gesamtes System.

Kein redo/undo ab checkpoint notwendig.

Ablauf:

Es werden nur alle Schreiboperationen blockiert - Leseoperationen werden zugelassen.

Undo nötig bis zur kleinsten LSN MinLSN von allen Transaktionen die während checkpoint aktiv waren.

Ablauf:

Es gibt gleichmäßig verteilte checkpoints.

Redo ab MinDirtyPageLSN

Undo nötig bis zur kleinsten LSN MinLSN von allen Transaktionen die während checkpoint aktiv waren.

Hot-Spot s können lange nicht ausgeschrieben werden da sie fixiert sind → Deshalb wird ein counter geführt um pages die mehrmals bearbeitet wurden zum Ausschreiben zu zwingen.