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: 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 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)] ZeitT 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)] ZeitT 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)] ZeitT 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-AnfangszustandDB-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 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)) T 1 T 2 G(S): (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)) T 1 T 2 G(S´): (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 -SX Verträglichkeits-Matrix: Sjajanein Xjaneinnein

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),...) 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 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 – –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 –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