02. Fehlerbehandlung

• widerherstellung des jüngsten konsistenten Datenbasiszustand

1. lokale fehler einer noch nicht festgeschriebenen Transaktion

2. fehler mit hauptspeicherverlust

3. fehler mit hintergrundspeicherverlust

• scheitern der Transaktion

• aber keine beeinflussung des restlichen systems hinsichtlich der Datenbankkonsistenz

(typische) Fehlerquellen:

• fehler im anwendungsprogramm

• expliziter abbruch (abort) der TA durch benutzer (e.g. gewünschtes ergebnis kam nicht zu stande…)

• systemgesteuerter abbruch der TA (e.g. behebung eines deadlocks)

  
  

• rückgängig machen aller änderungen an datenbasis

• die durch die jeweilige TA verursacht wurder

• -> lokales undo

• milisekunden

• da (relativ) häufig…

• sogar ohne sperren des systems für andere Transaktionen

• DMBS-puffer (teil des Hauptspeichers)

• Hintergrundspeicher (materialisierte datenbasis)

• puffer hält daten (tupel) die auf seiten (e.g. P_A) im hintergrundspeicher abgebildet sind

• seite kann mehr als ein datum halten

• Vor zugriff auf datum -> muss in puffer eingelagert werden

• darauf wird e.g. was geändert

• muss dann wieder ausgelagert (zurückgeschrieben) werden

  • kann e.g.. unterschieden werden mit C’ im Puffer und C im Hintergrundspeicher…)

• stromausfall

• -> hauptspeicher geht verloren

• => puffer geht verloren

• => änderungen im Puffer verloren die aber noch nicht in den Hintergrundspeicher ausgelagert wurden…

• alle durch nicht abgeschlossene TA eingebrachte Änderungen im Hintergrundspeicher müssen rückgängig gemacht werden

  • (globales) undo

• alle noch nicht eingebrachte änderungen abgeschlossener TA müssen nachvollzogen werden

  • (globales) redo

• zusazinformationen

  • i.e. log datei

• intervall von tagen

  • stromausfall

  • fehler im Betriebssystemcode

  • hardwareausfall

• revocery dauer im bereich von einigen minuten

• head crash

• feuer/erdbeben -> zerstört die platten

• fehler in systemprogrammen (e.g. plattentreiber) die zu einem datenverlust führen

• monate oder jahre

• archivkopien

• -> !! sollten röumlich getrennt aufbewahrt werden!!

• fixieren im puffer

• -> setzen eines FIX vermerks

• verhindert verdrängen der seite aus dem puffer

• kennzeichnen mit dirty

• => sagt aus dass puffer seite nicht mehr mit hauptspeicher üereinstimmt

• für die dauer einer operation

• -> danach wieder freigegeben

• not steal

  • -> seiten die von einer noch aktiven transaktion modifiziert wurden werden prinzipiell nicht ausgelagert

• steal

  • -> prinzipiell jede nicht fixierte seite kandidat für ersetzung falls neue seite eingelagert werden muss

• kann nicht passieren dass änderungen einer nicht abgeschlossenen TA in materialisierte datenbasis übernommen werden

• -> rollback muss sich nicht um hintergrundspeicher kümmern…

• force

  • -> nach commit werden alle von der TA modifizierte seiten in die mat. DB eingebracht

• not force

  • -> erzwingt diese einbringung nicht

• änderungen nicht direkt eingebracht

• -> Hauptspeicher verlust

• -> brauchen redo…

• => benötigen log datei…

• erzwungene propagierung aller änderungen nach beendigung der TA teuer

• hot spot seiten (seiten die längere zeit im puffer da von mehreren TA oft benötigt) -> werden nur kopiert aber nicht ersetzt…

• atomares prinzip

  • -> aufwand sicher zu stellen dass alles oder nichts eingebracht wurde… (i.e. fehler…)

• probleme wenn TA seiten sperren können (exklusive nutzung)

• methodik, nach der änderungen in die materialisierte Datenbasis propagiert werden

• direkt (update in place)

• indirekt (e.g. twin block)

• jede seite in DBMS puffer ist genau einer seite im Hintergrundspeicher zugeordnet

• -> überschreibt alte seite im Hintergrundspecher wenn ausgeschrieben wird

• für redo -> benötigen zusätzliche protokollinformationen

• geänderte seiten werden an anderer stelle in den hintergrundspeicher eingebracht/gespeichert

• zu bestimmten, vom system initiierten zeitpunkten werden die alten zustände (im hintergrundspeicher) durch die neuen (im hintergrundspeicher) ersetzt

• twin block verfahren

• jede puffer seite (PA) hat zwei seiten im Hintergrundspeicher (P_{A_aktuell}), (P_{A_nicht aktuell})

• globales “aktuell” bit gibt an welcher der blöcke die aktuelle (eingebrachte änderungen) informationen hat

• -> bei fehler kann man einfach undo in dem man die nicht aktuelle nimmt…

• 
  

• atomare propagation des puffer inhaltes

• -> kopieren aller modifizierten seiten aus puffer auf twin-blöcke

• -> wenn erfolgt -> flippen der entsprechenden aktuell bits…

• -> geht etwas schief (nicht alles eingebrahct) -> einfach altes nehmen… (nichts)

• verdoppelter speicherbedarf

• nur tatsächlich modifizierte seiten werden verdoppelt…

• => schafft etwas abhilfe im hinblick auf speicherbedarf von twin block

• aber: nachteile in praxis desewgen fast nie eingesetzt

• steal

• not force

• update-in-place

• kleine sperrgranulate

• TA können kleinere objekte als ganze seite exklusiv sperren und verändern

• -> P_A = {A, D}

• -> TA1 modifiziert A -> sperrt nur A -> TA2 kann gleichzeitig D (auf gleicher seite!) modifizieren…

• => schwierigkeit: seite kann änderungen einer bereits abgeschlossenen und einer noch nicht abgeschlossenen TA enthalten

• materialisierte datenbasis

  • enthält nicht dem aktuellsten konsistenten zustand

  • und ist i.A. nicht mal in einem konsistenten zustand

• da:

  • -> änderugen nicht abgeschlossener TA eingebracht werden können

  • -> änderungen abgeschlossener TA noch nicht eingebracht worden sein könnten

• redo-informaiton

  • wie kann die änderung nachvollzogen werden?

• undo-information

  • wie kann änderung rückgängig gemacht werden?

zusätzlich:

• LSN (log sequence number)

• Transaktionskennung (TA)

• PageID

• PrevLSN