Wieso ist Fehlerbehandlung wichtig?
- Fehler lassen sich nie komplett ausschließen
- Wiederherstellen der Konsistenz im Fehlerfall
- selbst wenn DBMS fehlerfrei codiert -> HW immer noch anfällig
-> gewährleisten des jüngsten konsistenten zustandes
Was für fehlerklassifikationen existieren?
1. lokale fehler in einer noch nicht comitteten transaktion
2. fehler mit Hauptspeicherverlust
3. Fehler mit Hintergrundspeicherverlust
Was kann lokale fehler verursachen?
- fehler im anwendungsprogramm
- abort einer transaktion durch den benutzer (z.b. wenn gewünschtes ergebnis nicht zustande kommt)
- systemgesteuerter abbruch (z.b. bei einem deadlock)
Wie werden lokale fehler behoben?
rückgängigmachen der Transaktion (lokales undo)
-> da häufig sollte dies schnell und effizient geschehen um nicht andere TA zu blocken
Was kann fehler mit hauptspeicherverlust verursachen?
wenn z.b. änderungen im puffer(HS) vorgenommen wurden aber noch nicht in den hintergrundspeicher übertragen wurden und dann bei z.b. stromausfall der puffer geleert wird
Wie können fehler mit Hauptspeicherverlust behoben werden?
- alle in den hintergrundspeicher eingebrachten änderungen durch nicht abgeschlossene transaktionen rückgängig machen (global undo)
- alle noch nicht eingebrachten änderungen nachvollziehen (global redo)
-> recoverydauer im bereich von minuten
Wie werden Fehler mit Hintergrundspeicherverlust verursacht?
- head crash
- feuer/erdbeben
- fehler in systemprogrammen (plattentreiber...)
Wie werden fehler mit hintergrundspeicherverlust behoben?
-> auf jedenfall absichern
- archivkopie mit logdateien
Wie funktioniert die ersetzung von puffer seiten?
TA benötigt mehrere seiten die evtl bereits in puffer vorhanden
- für dauer der TA/ der zugriffes mit FIX flag fixieren(verhindert verdrängung)
- falls ändern -> dirty flag setzen
- nach TA fix flag entfernen -> kann wieder ausgelagert werden
Was für strategien gibt es für puffer ersetzungen bei noch nicht festgeschriebenen transaktionen?
- not steal -> ausschließen der auslagerung von modifizierten seiten einer nicht abgeschlossenen Transaktion (falls abbruch -> sicherstellen dass änderungen nur lokal)
- steal -> jede nicht fixierte seite prinzipiell opferkandidat (kann sein dass bei rollbacks hintergrundspeicher zurückgesetzt werden muss!)
Was für strategien gibt es bei der einbrungung von änderungen in den Hintergrundspeicher?
- force : beim commit in den Hintergrundspeicher übertragen
- not force: tut dies nicht
Welche auswirkungen können die verschiedenen Strategien beim einbringen in den Hintergrundspeicher haben?
not force: änderungen einer abgeschlossenen TA können verloren gehen
-> benötigt separate log einträge für ein redo
Welche nachteile ergit eine force not steal strategie?
- erzwungene propagierung aller änderungen teuer (was wenn danach direkt nochmal modifiziert? -> hot spot seiten)
- muss alle änderungen einer transaktion übertragen -> alles oder nichts
Was ermöglicht 1.steal und 2.force grundsätzlich?
1. steal : undo
2. not force: redo
Was sind einbringungsstrategien?
Sagt aus, wie seiten wieder in den Hintergrundspeicher eingebracht werden
wie funktioniert die update-in-place strategie?
jede seite hat eigenen platz im hintergrundspeicher -> bei update wird alte überschrieben
-> für undo werden zusätzliche protokollinformationen benötigt
=> direkte methode
Wie funktioniert die indirekte einbringungsstrategie?
geänderte seiten an einem separaten platz speichern
-> nut zu spezielen systeminitiierten zeitpunkten damit dann alte seiten überschreiben
Bsp zwei speicherorte für seite P1
ursprünglich P0 (von dort eingelagert)
nach ändern schreiben an Ort P1 und setzen des aktuell bits
=> falls wiederherstellung : p nicht aktuell (p0) immer noch vorhanden!
nachteil : verdoppelter speicherbedarf für diese seiten
- heißt twin block verfahren
Wofür benötigt man protokolle der änderungsoperationen?
datenbasis enthält meist nicht aktuellste oder konsistente zustände
-> zusatzinfos sog. Log dateien da manche daten noch nicht /nur teilweise eingebracht
Wie sind log einträge aufgebaut?
- redo informationen : getätigte änderungen nachvollziehen
- undo informationen: wie änderungen rückgängig machen?
Zusätzliche Informationen:
- LSN (Log Sequence Number)
->kennung, monoton aufsteigend um chronologie nachvollziebar zu machen
- Transaktionskennung : TA der TA die änderung durchgeführt hat
- PageID: kennung der seite auf der änderungen vorgenommen wurden (kann auch mehrere sein)
- PrevLSN zeiger auf vorherigen Log eintrag (effizienz gründe)
Wie sehen log einträge aus?
links schritte(nummerierte zeilen) und spalten als transaktionen T1,T2,...,Tn
nächste spalte als log mit [LSN, TA(s.o.), PageID, Redo(bsp. attribut + 50...), Undo (siehe redo), PrevLSN]
undo und redo jeweils schritt protokollieren seit letztem Log
Was sind before und after images?
before image: wird durch ausführen der undo teils aus dem after image generiert
after image: wird mit redo aus before image konstruiert
Wie weiß man ob das before oder das after image im hintergrundspeicher ist?
LSN wird in zurückgeschriebene seite geschrieben
-> wenn dortige LSn kleiner als aktuelle : before image
-> wenn größer gleich : after image
Was ist der unterschied zwischen logischer und physischer protokollierung?
physisch: absoluter wert angeben bsp A = 1000 ; bez. before und after image
logisch: code angeben bsp A += 50; bez. undo/redo code
Wie/wann werden loginformationen geschrieben/gespeichert?
1. anlegen : vor ausführen der operation
- > pyhsisch : before image vor ausführen; after image nach ausführen
-> logisch : man kann gleich undo und redo code reinschreiben
2. zwischenlagern im log puffer (kleiner als datenbankpuffer)
-> spätestens wenn voll in Hintergrundspeicher zurückschreiben
Was ist ein beispiel für die implementierung eines Log puffers?
Log ring puffer :
voll schreiben im ring und wenn voll : zurückschreiben und neues in freien puffer platz
-> gleichmäßige auslastung und kein burstartiges zurückschreiben
Wie werden log einträge aus dem puffer zurückgeschrieben (nicht wann!)
1. in temporäres log -> Hintergrundspeicher
2. log-archiv -> archivspeicher
=> im falle eines ausfalles des Hintergrundspeichers kann man die logs immer noch nachvollziehen!
Was beschreibt das WAL prinzip?
Write ahead log:
!nötig bei steal not force update in place!
1. vor commit alle log einträge zurückschreiben (nötig für redo)
2. vor auslagern einer modifizierten seite alle zug. log einträge in temporäres log schreiben(undo)
Wie funktioniert der wiederanlauf nach einem fehler?
annahme : T1 abgeschlossen, T2 nicht abgeschlossen
- T1 sog. winner : wird vollständig nachvollzogen
- T2 loser : rückgängig machen
Phasen:
1. Analyse (temp. log datei von anfang bis ende analysiert um winner und loser menge zu ermitteln)
2. alle protolollierten änderungen wiederholen (winner und loser)
3. änderungen der loser rückgängig machen
Wie verläuft die analyse der logs?
BOT -> übersicht aller transaktionen
commit -> übersicht aller winner
rest loser
wie funktioniert die redo phase?
log datei sequentiell durchlaufen
-> für jeden eintrag seite in DB puffer holen ; falls LSN größer gleich -> nichts ändern; falls kleiner -> redo operation ausführen + aktuelle LSN einfügen
Wie funktioniert die Undo phase?
Log datei umgekehrt durchlaufen und alle operationen der winner übergehen
-> undo auf jeden fall ausführen, egal welche LSN auf seite
Was ist eine wichtige eigenschaft der wiederherstellungs operationen?
Idempodenz -> falls absturz während recovery darf mehrmaliges ausführen nichts ändern!
Wie wird die idempodenz der recovery gewährleistet?
bei redo LSN in seite eintragen
für undo kompensations-protokolleinträge vornehmen
Wie ist ein Kompensationslogeintrag (CLR) aufgabaut?
Redo teil entspricht dem Undoteil
-> wird im wiederanlauf als redo durchgeführt -> macht den verlorenen undo erneut!
! muss im anschließenden undo teil übersprungen werden
=> um dies zu gewährleisten erhalten sie einen UndoNxtLST eintrag (effizient mit PrevLSN implementiert)
Wie läuft die kompensation ab?
1. analyse
2. redo
3. erzeugen der kompensation und ausführen dieser (undo)
4- überspringen der kompensierten undos
5. wenn am anfang -> fertig
Wie könne lokale transaktionen isoliert zurückgesetzt werden?
-> rückläufiges abarbeiten der zugehörigen log einträge + protokollieren der kompensatins einträge + UndoNxtLSN
(teilweise dann nur bis bestimmeter recovery punkt rückwärts undoen)
Was sind sicherungspunkte?
Da mit zunehmender betriebsdauer log dateien umfangreicher werden wird der recovrery prozess auch komplexer
=> einführen von sicherungspunkten die als start für wiederherstellung dienen (ältere logs können dennoch relevant sein)
Was für arten von sicherungspunkten existieren?
1. globale transaktionskonsistente Sicherungspunkte
2. aktionskonsistente sicherungspunkte
3. unscharfe (fuzzy) sicherungspunkte
Was sind transaktionskonsistente sicherungspunkte?
Erzeugen sicherungspunkte bei denen nur abgeschlossene transaktionen in der vergangenheit liegen
-> werden angemeldet und nach beenden aller aktiven transaktionen müssen neue warten bis sicherungspunkt erzeugt wurde (alles relevante in hintergrundspeicher geschrieben)
! zeitaufwendig deshalb seltenes anlegen wenn nicht viel arbeit mit DB bsp wochenende!
was sind aktionskonsistente sicherungspunkte?
Da transaktionskonsistent zu aufwendig um oft zu machen
-> garantieren nur dass elementare operationen ausgeführt wurden + alle modifizierten seiten in Hintergrundspeicher schreiben (einhalten des WAL prinzips)
was sind unscharfe (fuzzy) sicherungspunkte?
aktionskonsistente sicherungspunkte => alle logs und modifikationen müssen in hintergrundspeicher geschrieben werden => starke systembelastung
nur kennungen der modifizierten seiten in Log einträge speicher (dirty pages)
-> sog. MinDirtyPagesLSN legt beginn des recovery prozesses fest
Wie funktioniert recovery nach verlust der matrialisierten datenbasis (hinergrundspeicher)
wiederherstellen mit archivkopien da korrekte log dateien in seiten verloren !
vor.:
1. transaktionskonsistent:
kontinuierliches schreiben der log einträge auf ein archivband -> log archiv
2. aktionskonsistent:
log archiv muss auch ältere einträge beinhalten
1. schneller, bei intaktem hintergrundspeicher
2. wird bei zerstörtem hintergrundspeicher gewählt
Wie funktioniert redo undo bei erneutem ausfall (mit compensation)?
erst von vorne (BOT) redo und TID im HS aktualisieren für die winner, für looser für jedes redo compensation mit undo in redo -> undo wird auf redophase übertragen + zusätzlich undonextlsn angeben zum überspringen bei tats undo
bei erneutem ausfall wird undo im redo gemacht und beim undp übersprungen (bis undonextlsn 0 -> BOT -> fertig)
Was mus bei Kompensationseinträgen bezüglich der LID beachtet werden ?
Müssen rückwärts aufsteigen (1->2->3->4->4'->3'...)
Last changed2 years ago