Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Heilgar Karel Geändert vor über 9 Jahren
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
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.