Kapitel 10: Fehlerbehandlung Transaktionen Flashcards
Welche Fehlerarten gibt es? (Fehlerklassifikation)
-
Lokale Fehler in einer noch nicht festgeschriebenen Transaktion (Divison:0; User bricht ab)
- Wirkung muss zurückgesetzt werden
- R1 Recovery
-
Fehler mit Hauptspeicherverlust (DB Stürzt ab, Stromausfall)
- Abgeschlossene TAs müssen erhalten bleiben (R2 Recovery) WINNER
- Noch nicht abgeschlossene TAs müssen zurückgesetzt werden (R3 Recovery) LOSER
-
Fehler mt Hintergrundspeicherverlust (Platte geht Kaputt, Partial write)
- R4 Recovery
Erkläre die zweistufige Speicherhirarchie
DBMS Puffer <–> Hintergrundspeicher (Siehe Tutorium 1)
Welche Speicherhirarchien gibt es?
- Ersetzung von Puffer Seiten:
- no Steal: Seiten die von einer noch aktiven TA verändert wurden, dürfen nicht ausgelagert werden.
- Steal: Jede nicht fixierte Seite kann jederzeit ausgelagert werden.
- Einbringung von Änderungen abgeschlossener TAs
- Force: Änderungen werden beim TA Ende festgeschrieben.
- No Force: Geänderte Seiten können im Puffer verbleiben und werden erst festgeschrieben, wenn die Seite wieder benötigt wird.
Wie sehen die Auswirkungen auf die Recovery aus?
Steal: undo (jede nicht fixierte Seite kann ausgelagert werden), daher ist undo mit steal möglich
no force: redo (auslagerung erfolgt erst, wenn Seite wieder benötigt wird), daher ist redo mit no force möglich.
Welche Einbringungsstrategien gibt es?
Update in Place (komplex, braucht aber wenig Platz):
- jede Seite hat genau eine Stelle auf dem Hintergrundspeicher
- Alte Zustand der Seite wird überschrieben
Twin-Block Verfahren:
- Jede Seite gibt es 2x. Bei jeder Änderung wird nur eine Seite geändert. Bei Final commit beide
Schattenspeicherkonzept:
- Nur geänderte Seiten werden dupliziert
- Weniger redundant als Twin-Block
Mit welcher Systemkonfiguration arbeiten wir?
- Steal
- “dreckige” Seiten können in die DB geschrieben werden
- No force
- geänderte Seiten sind möglicherweise noch nicht auf Platte
- update-in-place
- Es gibt von jeder Seite nur eine Kopie auf der Platte
- Kleine Sperrgranulate
- Auf jeder Seite können verschiedene Tupel verändert werden
Wie sieht die Struktur von Log-Einträgen aus?
[LSN, TransaktionID, PageID, Redo, Undo, PrevLSN]
[#5 ,T1 ,PB ,B+=50 ,B-=50 , #3]
LSN: Log Sequence Number
- Eindeutige Kennung des Log Eintrags
- Monoton aufsteigend vergeben
- chronologische Reihenfolge von Protokolleinträgen kann ermittelt werden
Transaktionskennung:
- Transaktionskennung TA der Transaktion, die die ÄNderung durchgeführt hat
PageID:
- Kennung der Seite, auf der Änderungen vollzogen wurden
- Wenn eine Änderung mehr als eine Seite betrifft, müssen entsprechend mehrere Log-Einträge generiert werden
Redo:
- Gibt an wie Änderung nachvollzogen werden kann
Undo:
- Gibt an wie Änderung rückgängig gemacht werden kann
PrevLSN:
- Zeiger auf vorherigen Log-Eintrag der jeweiligen Transaktion. Eintrag wird aus Effizienzgründen benötigt
Welche Arten von Protokollierung gibt es und wie kann man diese beschreiben?
Physische Protokollierung:
- Inhalte / Zustände werden protokolliert:
- before-image: enthält Zustand vor Ausführung der Operation
- A=950
- after-image: enthält Zustand nach Ausführung der Operation
- A=1000
Logische Protokollierung:
- das before-image wird durch Ausführung des Undo-Codes aus dem after-image generiert.
- A-=50
- das after-image wird durch Ausführung des redo-codes aus dem before-image berechnet
- A+=50
Speicherung der Seiten-LSN:
- LSN letzte Änderung auf dieser Seite, steht z.b. eine kleinere Nummer weiß ich ob es schon gemacht wurde, oder ob es noch nicht gemacht wurde. LSN erlaubt zu erkennen, ob Änderung schon auf seite ist oder nicht
Wie werden Log-Informationen geschrieben?
Log Datei wird 2x geschrieben:
-
Log-Datei für schnellen Zugriff
- R1, R2 und R3 Recovery
-
Log-Archiv
- R4 Recovery
Anordnung in einem Ringpuffer: Eintragen und Ausschreiben (Kreis) dabei wird in Log-Datei udn Log-Archiv geschrieben.
Erkläre das WAL-Prinzip
Write Ahead Log-Prinzip:
- Bevor eine Transaktion festgeschrieben wird (commit) müssen alle “zu ihr gehörenden” Log-Einträge ausgeschrieben werden. (Für Durability: commit wartet auf die Platte)
- Bevor eine modifizierte Seite ausgelagert werden darf, müssen alle Log-Einträge, die zu dieser Seite gehören in das temporäre und in das Log-Archiv geschrieben werden. (Force the log: Bei Steal einer geänderten Seite, muss ich sicher sein, dass Log-Eintrag auf PLatte ist. Sonst wäre kein Rollback möglich=
Warum bei Wiederanlauf zwischn Winner und Loser unterscheiden?
Winner: Wurden commitet - müssen übernommen werden.
Loser: Wurden nicht commitet, rollback zwingend notwendig.
Beschreibe die 3 Phasen des Wiederanlaufs
-
Analyse
- Die temporäre Log-Datei wird von Anfang bis zum Ende analysiert
- Ermittlung der Winner-Menge von Transaktionen
- Ermittlung der Loser-Menge von Transaktionen
-
Wiederholung der Historie (REDO WIN AND LOS)
- alle protokollierten Änderungen werden in der Reihenfolge ihrer Ausführung in die Datenbasis eingebracht
-
Undo der Loser (UNDO LOS)
- Die Änderungsoperationen der Loser-Transaktionen werden in umgekehrter Reihenfolge ihrer ursprünglichen Ausführung rückgängig gemacht
Beschreibung von Kompensationseinträgen
- Kompensationseinträge (CLR compensating log record) für rückgängig gemachte Änderungen.
Beispiel für Logeintrag nach abgeschlossenem Wiederanlauf
Aufbau, Syntax von Kompensationseinträgen (CLR). Warum kein Undo?
- CLR sind durch <> gekennzeichnet
- Aufbau:
- <lsn></lsn>
- <#4‘,T2,PC,C-=100,#7‘,#2>
- Keine Undo: Weil Roll back zwingend notwendig ist