Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München.

Ähnliche Präsentationen


Präsentation zum Thema: "Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München."—  Präsentation transkript:

1 Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München

2 Transaktions-Konzept (1)
Beispiel: op1 BOT op2 read(K1) aus KONTO1 op3 write(K1 := K ) in KONTO1 op4 read(K2) aus KONTO2 op5 write(K2 := K ) in KONTO2 op6 commit Konsistenz: T ganz oder gar nicht ausführen! T

3 Transaktions-Konzept (2)
Transaktion (TA): Folge von DB-Operationen atomar konsistenzerhaltend DB-Operationen allgemein: read, write speziell: BOT, commit, abort

4 „gleichzeitige" Ausführung von TAs
 bessere Ressourcen-Nutzung (Optimierung) einige TAs lesen oder schreiben Daten andere lasten die CPU aus  höherer Durchsatz  kürzere Antwortzeiten Gleichzeitigkeit (Nebenläufigkeit) birgt Gefahren!

5 typische Synchronisations-Probleme (1)
Beispiel. [w/r-Konflikt (dirty read)] Zeit T1 T2 t1 read(K1) t2 write(K1 := K ) t read(K1) t write(K1 := K1*1,04) t read(K2) t write(K2 := K2*1,04) t7 read(K2) t8 write(K2 := K )

6 typische Synchronisations-Probleme (2)
Beispiel. [r/w-Konflikt (unrepeatable read)] Zeit T1 T2 t S := read(K1) t2 read(K1) t3 write(K1 := K ) t4 read(K2) t5 write(K2 := K ) t S := S+ read(K2) („Phantomproblem“)

7 typische Synchronisations-Probleme (3)
Beispiel. [w/w-Konflikt (lost update)] Zeit T1 T2 t1 read(K1) t read(K1) t3 write(K1 := K ) t write(K1 := K1+8000)

8 ACID-Paradigma Atomicity TAs werden ganz oder gar nicht durchgeführt
Consistency TAs sind konsistent TAs hinterlassen konsistente DB-Zustände Isolation TAs „sehen“ einander nicht Durability erfolgreiche (commit) TAs werden durchgesetzt

9 Aufgabenverteilung Konsistenz und Isolation:
Concurrency Control (Mehrbenutzer-Synchronisation) Atomarität und Dauerhaftigkeit: Logging & Recovery (Protokoll- und Wiederanlauf-Komponente)

10 Schedules Schedule: Zeitliche „Verzahnung“ der Operationen mehrerer TAs, interne Operationen-Reihenfolge jeder TA wird beibehalten. Beispiel: T1 : (r1(A), r1(C), w1(C)), T2 : (r2(A), r2(B), w2(B)), S : (r1(A), r2(A), r2(B), w2(B), r1(C), w1(C)) DB-Anfangszustand DB-Endzustand Schedule

11 „vernünftige“ Schedules ?
seriell: eine TA nach der anderen idealtypisch („isoliert“,“konsistent“), aber langsam serialisierbar: Wirkung wie serieller Schedule nicht praktikabel (exponentieller Nachprüfungs-Aufwand) konfliktserialisierbar: azyklischer Konflikt-Graph praktikabel (polynomialer Nachprüfungs-Aufwand)

12 Konflikt-Serialisierbarkeit (1)
Konfliktgraph G(S) von S Knoten: alle TAs Ti von S (gerichtete) Kanten: Pfeile von Ti nach Tj, falls A, op1(A)  Ti, op2(A)  Tj existieren wobei op1(A) zeitlich vor op2(A) liegt und (op1 = w oder op2 = w) ist G(S) azyklisch  S (konflikt)serialisierbar

13 Konflikt-Serialisierbarkeit (2)
Beispiel. T1 : (r1(A), w1(B)), T2 : (w2(A)), T3 : (r3(A), r3(B)), S : (r1(A), w2(A), r3(A), r3(B), w1(B)) T1 T2 G(S): (zyklisch, S nicht konfliktserialisierbar) T3

14 Konflikt-Serialisierbarkeit (3)
Beispiel. T1 : (r1(A), w1(B)), T2 : (w2(A)), T3 : (r3(A), r3(B)), S´: (r1(A), w2(A), r3(A), w1(B), r3(B)) T1 T2 G(S´): (azyklisch, S´ serialisierbar) T3

15 Sperrbasierte Synchronisation (1)
Scheduler setzt temporäre DB-Obj-Sperren 2 Sperrmodi: S (shared), X (exclusive) TA darf lesen nach Erhalt einer S-Sperre schreiben nach Erhalt einer X-Sperre S X Verträglichkeits-Matrix: S ja ja nein X ja nein nein

16 Sperrbasierte Synchronisation (2)
Strenges 2-Phasen-Sperrprotokoll (Strict 2PL) TA darf nur lesen nach Erhalt einer S-Sperre TA darf nur schreiben nach Erhalt einer X-Sperre „streng“: TA behält alle Sperren bis commit/abort TAs, die keine Sperre erhalten  Warteschlange Strict 2PL  Serialisierbarkeit + weitere Vorzüge (u.a. Rücksetzbarkeit)

17 Sperrbasierte Synchronisation (3)
Beispiel. [Deadlock (Verklemmung)] T1 : (X1(A), w1(A), S1(B), r1(B)), T2 : (X2(B), w2(B), S2(A), r2(A)), S : (X1(A), w1(A), X2(B), w2(B), S1(B), S2(A), ...) warten ! warten! 2 Strategien möglich 1. pessimistisch: Deadlock-Vermeidung 2. optimistisch: Deadlock-Erkennung und -Beseitigung

18 Deadlock-Erkennung und -Beseitigung
Wartegraph W(S) von S Knoten: alle TAs Ti von S (gerichtete) Kanten: Pfeile von Ti nach Tj, falls Tj das DB-Obj A sperrt und Ti auf Gewährung einer Sperre auf A wartet periodische Untersuchung von W(S) auf Zyklen Zyklus entdeckt  eine TA „abschießen“

19 Fehlerklassifikation
lokale „Fehler“ (relativ häufig) Anwendungsprogramm-Fehler, expliziter Abbruch (abort), systemgesteuerter Abbruch (z.B. Deadlock-Beseitigung) Fehler mit Hauptspeicherverlust (selten) z.B. Betriebssystem-Fehler, Hardwareausfall, Stromausfall Fehler mit Hintergrundspeicherverlust (sehr selten) z.B. bei „head crash“, Feuer/Erdbeben, Systemprogramm-Fehler (fehlerhafter Plattentreiber)

20 Seiten-Ersetzungs-Strategien
„force“: am Ende einer TA (nach commit) geänderte Seiten sofort zurückschreiben garantiert Dauerhaftigkeit aber lange Antwortzeiten „no steal“: Seite nicht zurückschreiben, solange eine der schreibenden TAs aktiv (vor commit) ist gut für Atomarität aber schlechter Durchsatz

21 steal & no force ! steal: Seite P zurückschreiben, obwohl T noch ein DB-Obj auf P sperrt! . . . und wenn dann T abgebrochen wird (abort)? undo-Information (alter Wert von P) in die Log-Datei! no force: Von T geänderte Seite P (noch) nicht zurückschreiben, trotz T´s commit! . . . und wenn nun das System „abstürzt“? redo-Information für T beim commit in die Log-Datei!

22 Logging für jede DB- Änderung ein Eintrag in die Log-Datei
sequentiell minimale Info (nur 's), viele Log-Sätze auf eine Log-Seite separater, sicherer Speicherort (Log-Puffer, Log-Archiv) Log-Datei: Liste von redo- und undo-Information <TAID,pageID,offset,length,beforeImage,afterImage> und weitere Kontroll-Information

23 Write-Ahead-Logging WAL-Protokoll
alle Log-Sätze zu einer DB-Seite permanent speichern, bevor die DB-Seite zurückgeschrieben wird! ermöglicht undo nichtabgeschlossener TAs Atomarität alle Log-Sätze zu einer TA vor deren commit schreiben! ermöglicht redo abgeschlossener TAs Dauerhaftigkeit

24 Recovery Manager Einsatz local undo, global undo/redo:
bei laufendem Betrieb: local undo bei lokalen Fehlern bei Wiederanlauf: global undo/redo nach Hauptspeicherverlust Rekonstruktion des jüngsten konsistenten DB-Zustands nach Hintergrundspeicherverlust local undo, global undo/redo: TAs ohne commit: zurücksetzen  Atomarität TAs mit commit: durchsetzen  Dauerhaftigkeit

25 Literatur [1] A. Hald, W. Nevermann: Datenbank-Engineering für Wirtschaftsinformatiker. Vieweg-Verlag [2] A. Kemper, A. Eickler: Datenbanksysteme. Oldenbourg [3] R. Ramakrishnan, J. Gehrke: Database Management Systems. McGraw-Hill [4] G. Vossen: Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme. Oldenbourg


Herunterladen ppt "Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München."

Ähnliche Präsentationen


Google-Anzeigen