10. Fehlerbehandlung_alt

Datenbasis hat hohen wert für unternehmen -> wichtig dass im Fehlerfall daten wiederhergestellt werden

Fehler lassen sich nie vermeiden, sei es in dem Programm oder in der Hardware oder auch durch umwelteinflüsse bedingte Fehler

1. lokale fehler in noch nicht festgerschriebener TA

2. Fehler mit Hauptspeicherverlust

3. Fehler mit Hintergrundspeicherverlust

• Fehler im Anwendungsprogramm

• expliziter abbruch (abort) durch Benutzer

• systemgesteuerter abbruch (e.g. deadlock)

Local Undo

-> alle Änderungen die die TA an der Datenbasis vorgenommen hat zurücksetzen

-> muss schnell und effizient erfolgen

Einlagern von Hintergrundspeicher in Hauptspeicher

-> organisiert in Seiten (segmenten)

-> mögliches Auslagern in Hintergrundspeicher

Beispielsweise ein Stromausfall, da danach der Arbeitsspeicher leer ist

Muss erfüllen:

• alle änderungen durch nicht abgeschlossene TA die schon im Hintergrundspeicher sind rückgängig machen

  • global undo

• alle noch nicht in Hintergrundspeicher übertragenen Änderungen abgeschlossener TA wiederholen

  • global redo

Es muss eine Log-Datei vorhanden sein, mithilfe derer man nachvollziehen kann, was man re un was undoen muss

Einige Minuten

• Head Crash

• Naturkatastrophe

• Fehler in systemprogrammen (bsp. plattentreiber) der zu datenverlust führt

Archivkopie der materialisierten Datenbasis mit zugehörigem Log-Archiv

1. Pufferspeicher (Hauptspeicher)

2. Hintergrundspeicher mit materialisierter Datenbasis

Mehrere

Durch setzen des FIX flags

Durch setzen des dirty flags

Nach beendigung einer Operation auf der Seite

• steal

• not steal

Bei der steal strategie dürfen alle nicht fixierten seiten prinzipiell ersetzt werden

Bei der not steal strategie dürfen nur seiten ersetzt werden, die nicht mehr von einer aktiven TA modifiziert werden

Dass änderungen einer nicht festgeschriebenen TA im Hintergrundspeicher landen

• force

• not force

Bei der force strategie werden alle Änderungen einer abgeschlossenen Transaktion nach beenden in den Hintergrundspeicher geschrieben, bei der nor force stragegie muss das nicht sein

Man benötigt keine Log dateien für ein Redo, da nach beenden alle änderungen in den Hintergrundspeicher geschrieben werden und so im falle einer Fehlers mit Hauptspeicherverlust keine Daten verloren gehen (im hinblick auf abgeschlossene TA)

Man muss kein redo machen und es werden keine änderungen noch nicht abgeschlossener TA durch einen steal in den Hintergrundspeicher geschrieben

Dadurch hat man zu keinem Zeitpunkt unvollständige änderungen im Hintergrundspeicher oder fehlende änderungen abgeschlossener Transaktionen im Hintergrundspeicher

Der nachteil ist, dass diese strategie nicht sehr performant ist

• erzwungenes zurückschreiben aller änderungen am ende der TA sehr teuer (alles auf einmal)

• falls TA seiten exkulsiv sperren können ist die strategie nicht möglich

Die methodik, nach der Änderungen in den Hintergrundspeicher propagiert werden

->zuordnung von puffer seiten zu hintergrundspeicher seiten

jede seite im puffer wird genau einer seite im Hintergrundspeicher zugeordnet

d.H. beim zurückschreiben wird die ursprüngliche seite überschrieben

-> direkte einbringungsstrategie

Bei einem undo benötigt man zusätzliche log informationen, da die alten daten “verloren” sind

Seiten werden in einen anderen bestimmten Speicherplatz im Hintergrundspeicher zurückgeschrieben und nur zu vordefinierten zeitpunkten in die ursprünglichen speicherplätze übertragen

Man hat je zwei plätze für eine puffer seite

PA0 und PA1

es gbt ein bit das angibt, welche davon das aktuelle datum enthält

-> bei einem fehler kann das system performant die alten (nicht aktuell) daten wiederherstellen

Twin Block verfahren

Der Speicherbedarf verdoppelt sich

Twin block verfahren in dem nur twinblöcke für modifizierte seiten existieren

-> nachteile deshalb keine anwendung in der praxis

• steal

• not force

• update-in--place

• kleine sperrgranulate

Anstatt eine ganze seite zu sperren, können TA auch kleinere Teile davon sperren

->verschiedene TA können daten auf der gleichen seite modifizieren

Da die materialisierte datenbasis meistens nicht den aktuellen oder nichtmal einen konsistenten zustand enthält

im falle eines fehlers müssen die änderungen nachvollzogen werden können um die konsistenz wieder herzustellen

• Redo informationen

• Undo informationen

• Log Sequence Number (LSN)

  -> eindeutige kennung des Log eintrags; monoton aufsteigend um eine chronologie zu schaffen

• Transaktionskennung TA

  -> Kennung der TA die die änderung verursacht hat

• PageID

  -> identifier der seite auf der daten modifiziert wurden

• PrevLSN

  -> zeiger auf vorherigen Log eintrag; Effizienzgründe

• logische protokollierung

• physische protokollierung

Art, wie redo und undo informationen angegeben werden

logisch: angabe der operationen (bsp. a + 3)

physisch: absolute angabe der daten (a = 4)

Der werd vor und nach einer änderung

Bei anlegen eines Log eintrages wird die LSN in der modifizierten seite gespeichert

-> dadurch weiß man, dass falls die LSN auf der seite größer ist, ein after image gespeichert ist

falls sie kleiner ist, ist ein before image gespeichert

(deshalb die chronologische nummerierung der LSN)

VOR ausfühern einer Änderungsoperation

Im log-puffer im hauptspeicher

Spätestens sobald er voll ist

Als ringpuffer

d.H. es wird kontinuierlich auf einer seite zurückgeschrieben wähernd auf er anderen seite die Einträge ersetzt werden können

Man muss nicht alle einträge auf einmal zurückschrieben,

Durch kontinuierliches Zurückschreiben geschieht dies um einigers performanter (gleichmäßige auslastung)

Auf das temporäre log im hintergrundpeicher und in das log archiv

-> temp. online/plattenspeicher

-> archiv: magnetband (Im falle des verlusts des Hintergrundspeichers)

Write ahead log

Prinzip, wie mit log einträgen umgegangen wird

In besonderem maße bei einer steal nor force strategie wie wir sie in der VL behandeln

1. Vor commit einer TA müssen die log einträge zurückgeschrieben werden

2. vor auslagern einer modifizierten seite müssen alle log einträge zurückgeschrieben werden die zu dieser seite gehören

1. Ausschreiben vor commit -> benötigt für redo informationen da TA abgeschlossen

2. Ausschreiben vor zurückschreiben einer modifizierten seite -> benötigt für undo, da informationen nicht abgeschlossener TA in die materialiseirte Datenbasis übernommen worden sein können

1. Schauen nach allen TA, die vor dem Fehler abgeschlossen waren (winner) -> müssen nachvollzogen (redo) werden

2. Schauen nach allen TA, die während dem Fehler noch nicht abgeschlossen waren (loser) -> müssen rückgängig gemacht werden

1. Analyse (winner und loser ermitteln)

2. Wiederholung der Historie: Alle protokollierten änderungen in der reihenfolge der ausführung in die datenbasis einbringen

3. Undo der loser: rückgängigmachen aller protokollierten änderungen der loser in UMGEKEHRTER reihenfolge

BOT als beginn aller TA

-> falls ein commit vorhanden, dann winner; sonst loser

1. Durchlaufen des Logs

2. Jeweils einlagern der Page nach ID in Puffer

3. Falls seiten LSN größer als Log eintrag, nichts machen

4. Falls LSN auf page kleiner als Log eintrag, Redo operation ausführen

5. LSN auf Page durch LSN in Log-eintrag ersetzen

Im falle eines erneuten fehlers muss man diesen Redo nicht erneut ausführen (falls zurückgeschrieben)

1. Log datei rückwärts durchgehen

2. Übergehen der Log einträge der winner Transaktionen

3. Undo operationen aller loser TA durchführen; egal welche LSN darauf steht

4. Erstellen der Kompensationseinträge

Man muss mit erneuten Fehlern während einem Wiederanlauf umgehen können

Die Idempodenz der redo und undo operationen

-> mehrmaliges redo oder undo führt zu gleichem Ergebnis

Durch eintragen der aktuellen LSN in der Page kann man bei erneutem Fehler einfach dort weitermachen, wo man zuvor aufgehört hat

Durch sogenannte Kompensations-Protokolleinträge CLR (Compensation Log Record)

1. LSN

2. Transaktions-ID

3. Page-ID

4. Redo Information

5. PrevLSN

6. UndoNxtLSN

• Nach einem Undo fügt man einen CLR zu den Logeinträgen hinzu

• Der CLR enthält als redo die undo information

• DIe LSN des CLR wird bei zurückschreiben einer undo änderung in die Seite geschrieben

• Damit wird sichergestellt, dass die undo änderung nicht erneut im redo ausgeführt wird, falls sie in die materialisierte Datenbasis eingebracht wurde

• Und falls sie nicht in die materialisierte Datenbasis eingebracht wurde, wird der CLR ausgeführt

• Bei der Undo phase wird sich die UndoNextLSN der jeweiligen letzen CLR einer TA angeschaut und dann dort mit dem Undo fortgefahren

• Falls UndoNextLSN 0 ist, weiß man, dass die TA vollständig zurückgesetzt wurde

• CLR erzeugen

• LSN des CLR in Page in materialisierter Datenbasis schreiben

• UndoNxtLSN auf vorherige LSN setzen

Indem man die Log-Einträge rückwärts durchläuft und undo operationen ausführt

Für jede Unto operaiton wird ein CLR erstellt

Auf den nächsten vorausgegangenen Log-Eintrag DER GLEICHEN TRANSAKTION

Da meistens die Log Einträge aktiver TA noch im Log Puffer vorhanden sind

Die sperren dieser TA auf einer seite müssen aufgegeben werden

Normales Undo mit CLR bis zu dem Punkt an den man zurücksetzen möchte

Je länger die Log-Einträge werden (je länger die Betriebszeit), desto langwieriger ist der WIederanlauf!

Mit sog. Sicherungspunkten

Sicherungspunkte sind eine Markierung im Log, über die man beim Wiederanlauf nicht hinaus gehen muss

!!bei einigen Sicherungspunkten (arten) muss man aber auch ältere Log Einträge beachten!!

1. (globale) Transaktionskonsistente Sicherungspunkte

2. aktionskonsistente Sicherungspunkte

3. unscharfe (fuzzy) Sicherungspunkte

Sicherungspunkte an denen sichergestellt wird, dass

• die materialisierte Datenbasis in einem Konsistenten zustand ist

• keine Informaitonen nicht abgeschlossener Transaktionen enthält

• alle abgeschlossenen Transaktionen zurückgeschrieben wurden

1. Transaktionskonsistente Sicherung anmelden (z.B. zu bestimmten Zeitpunkten)

2. DBMS in “Ruhezustand” überführen

3. Alle neu ankommenden TA müssen warten

4. Laufende TA abschließen

5. alle modifizierten Seiten zurückschreiben

6. Log-Datei von neuem beginnen (Sicherungspunkt erstellen)

Sehr Zeitaufwändig, da das DBMS in ruhezustand und TA warten / alle seiten Zurückgeschrieben werden

-> nur in ausnahmefällen z.B. am Wochenende

Sie stellen sicher, dass alle aktuellen Änderungsoperationen abgeschlossen und zurück geschrieben worden sind

Bis zum Sicherungspunkt wird gesichert, dass alle Änderungen in die materilaisierte Datenbasis übernommen worden

-> erst ab dem Punkt mit redo phase beginnen

Die Undophase geht über den Sicherungspunkt hinaus, da änderungen nicht abgeschlossener TA in die materialisierte Datenbasis übernommen worden sein können

Man ermittelt die kleinste LSN der aktuell aktiven Transaktionen. Damit ist sichergestellt, das alle vorherigen log-einträge zu abgeschlossenen TA gehören und somit konsistent in der Materialisierten Datenbasis vorliegen

-> bez. MinLSN

Nach dem WAL prinzip muss vor jedem Zurückschreiben des Puffers zuerst der Log Puffer zurückgeschrieben werden

Eine Liste aller aktiven TA

Das benötigt man, um die Loser in der Analyse phase festzustellen, da das BOT der aktiven TA vor dem Sicherungspunkt liegt

-> vergleichen für welche aktiven TA (in der Liste) ein commit und für welche keiner vorliegt!!!

Anstatt modifizierte seiten auszuschreiben, markiert man alle aktuell modifizierten, nicht ausgeschriebenen seiten als Dirty Page. Damit fuzzy sicherungspunkte funktionieren, muss man sich noch die minimale LSN aller noch nicht ausgeschriebenen Seiten im Puffer merken. Das ist die MinDirtyLSN

Die MinDirtyLSN bildet den Punkt, an dem die Redo-Phase beginnt

Die Undophase wird wie bei Aktionskonsistenten Sicherungspunkten bis zur MinLSN (aktuell kleinste LSN der aktiven TA) durchgeführt

Dadurch dass man die kleinste LSN der dirty pages weiß, muss man von anlauf redo bis zum tatsächlichen sicherungspunkt nur die Redo Informationen von Dirty Pages ausführen

-> dirty pages noch nicht sicher zurückgeschrieben und deshalb redo; falls ziwschenzeitlich zurückgeschrieben, LSN auf page größer

-> andere zwischen MinDirtyLSN und sicherungspunkt nicht nötig, da Änderungen für die nicht dirty log einträge bereits zurückgeschrieben wurden

Man muss nicht die gesamten Log Einträge auf einmal ausschreiben, wie dies bei den Aktionskonsistenten Sicherungspunkten der Fall wäre

Falls es einige sog. Hot Spot seiten im Puffer gibt die ständig benötigt werden und somit selten ausgeschrieben werden. Dadruch bleiben diese die MinDirtyPageLSN und bedingen so eine lange Redo phase.

Indem das system sicherstellt, dass im folgenden fuzzy sicherungspunkt alle dirty seiten, die seit dem letzen fuzzy sicherungspuntk nicht ausgeschrieben wurden, ausgeschrieben werden

1. Intakte materialisierte Datenbasis (Hintergrundspeicher) -> materialisierte Datenbasis + temp. Log Datei

2. Hintergrundspeicher kaputt -> Datenbasis Archiv + Log Archiv