Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung

Transkript

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

2 Transaktions-Konzept (1) Beispiel: op 1 BOT op 2 read(k 1 ) aus KONTO1 op 3 write(k 1 := K ) in KONTO1 op 4 read(k 2 ) aus KONTO2 op 5 write(k 2 := K ) in KONTO2 op 6 commit T Konsistenz: T ganz oder gar nicht ausführen!

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 T 1 T 2 t 1 read(k 1 ) t 2 write(k 1 := K ) t 3 read(k 1 ) t 4 write(k 1 := K 1 *1,04) t 5 read(k 2 ) t 6 write(k 2 := K 2 *1,04) t 7 read(k 2 ) t 8 write(k 2 := K )

6 typische Synchronisations-Probleme (2) Beispiel. [r/w-konflikt (unrepeatable read)] Zeit T 1 T 2 t 1 S := read(k 1 ) t 2 read(k 1 ) t 3 write(k 1 := K ) t 4 read(k 2 ) t 5 write(k 2 := K ) t 6 S := S+ read(k 2 ) ( Phantomproblem )

7 typische Synchronisations-Probleme (3) Beispiel. [w/w-konflikt (lost update)] Zeit T 1 T 2 t 1 read(k 1 ) t 2 read(k 1 ) t 3 write(k 1 := K ) t 4 write(k 1 := K )

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: T 1 : (r 1 (A), r 1 (C), w 1 (C)), T 2 : (r 2 (A), r 2 (B), w 2 (B)), S : (r 1 (A), r 2 (A), r 2 (B), w 2 (B), r 1 (C), w 1 (C)) DB-Anfangszustand Schedule DB-Endzustand

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 T i von S (gerichtete) Kanten: Pfeile von T i nach T j, falls A, op 1 (A) T i, op 2 (A) T j existieren wobei op 1 (A) zeitlich vor op 2 (A) liegt und (op 1 = w oder op 2 = w) ist G(S) azyklisch S (konflikt)serialisierbar

13 Konflikt-Serialisierbarkeit (2) Beispiel. T 1 : (r 1 (A), w 1 (B)), T 2 : (w 2 (A)), T 3 : (r 3 (A), r 3 (B)), S : (r 1 (A), w 2 (A), r 3 (A), r 3 (B), w 1 (B)) G(S): T 1 T 2 (zyklisch, S nicht konfliktserialisierbar) T 3

14 Konflikt-Serialisierbarkeit (3) Beispiel. T 1 : (r 1 (A), w 1 (B)), T 2 : (w 2 (A)), T 3 : (r 3 (A), r 3 (B)), S : (r 1 (A), w 2 (A), r 3 (A), w 1 (B), r 3 (B)) G(S ): T 1 T 2 (azyklisch, S serialisierbar) T 3

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)] T 1 : (X 1 (A), w 1 (A), S 1 (B), r 1 (B)), T 2 : (X 2 (B), w 2 (B), S 2 (A), r 2 (A)), S : (X 1 (A), w 1 (A), X 2 (B), w 2 (B), S 1 (B), S 2 (A),...) 2 Strategien möglich warten! 1. pessimistisch: Deadlock-Vermeidung 2. optimistisch: Deadlock-Erkennung und - Beseitigung warten!

18 Deadlock-Erkennung und -Beseitigung Wartegraph W(S) von S Knoten: alle TAs T i von S (gerichtete) Kanten: Pfeile von T i nach T j, falls T j das DB-Obj A sperrt und T i 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 Einsatz Recovery Manager 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