Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 Vorlesung #12 Mehrbenutzersynchronisation.

Ähnliche Präsentationen


Präsentation zum Thema: "WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 Vorlesung #12 Mehrbenutzersynchronisation."—  Präsentation transkript:

1 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 Vorlesung #12 Mehrbenutzersynchronisation

2 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation2 Fahrplan Motivation Fehler bei unkontrolliertem Mehrbenutzerbetrieb Lost Update Dirty Read (Non-Repeatable Read) Phantom Serialisierbarkeit Transaktionshistorien, Datenbank-Scheduler Sperrbasierte Synchronisation Recovery-Fähigkeit und Verklemmungen (Deadlocks) werden nächstes Semester behandelt

3 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation3 Motivation - Mehrbenutzerbetrieb Mehrbenutzerbetrieb (Multiprogramming) – gleichzeitige (nebenläufige, parallele) Ausführung mehrerer Programme führt zu besseren Auslastung eines Computersystems als Einzelbenutzersystem Prinzip: während auf eine interaktive (aus Computer-Sicht sehr langsame) Benutzereingabe oder Freigabe einer Resource (z.B. Drucker) gewartet wird, kann der Computer rechenintensive Vorgänge anderer Programme verarbeiten Oft geht es nur in Mehrbenutzerbetrieb Beispiel: (Online-)Bestellungen bei Versand-Handel

4 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation4 Motivation – Mehrbenutzerbetrieb (2) Mehrbenutzerbetrieb hat sich bereits in der Praxis überall etabliert, nicht nur auf großen Server sondern sogar auf PCs, die als persönliche Arbeitsplatzstationen ursprünglich für den Einzelbenutzerbetrieb konzipiert waren. Beispiele: Windows2000, WindowsXP, Linux statt MS DOS und Windows3.1 Ihr Rechner (PC oder Laptop) verarbeitet bereits mehrere Tasks gleichzeitig und kann als Server im Mehrbenutzerbetrieb eingesetzt werden, sobald Sie im Netz erreichbar sind. Einzelbenutzerbetrieb ist auf der Betriebsystemebene so gut wie verschwunden! Die meisten Programme innerhalb eines Mehrbenutzersystems arbeiten aber immer noch im Einzelbenutzerbetrieb (exklusiv) mit sehr eingeschränkten Kooperationsmöglichkeiten auf der Datei-Ebene. Wie sieht es aus bei den Datenbanken?

5 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation5

6 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation6 Fehlerklassifizierung Es gibt drei Fehlerarten: 1.Lost Update – verlorengegangene Änderungen Benutzer 1 ändert etwas in File15.xls und speichert ab. Benutzer 2 ändert etwas in File15.xls und speichert ab. Die Version des Benutzer 2 ist zuletzt gespeichert, die Arbeit des Benutzers 1 geht verloren. 2.Dirty Read – Lesen von nicht freigegebenen Änderungen Das Konto wird fälschlicherweise vorübergehend mit 10000 belastet. Zinsen werden mit –10000 berechnet und abgezogen. 3.Phantom - ein neuer Wert tritt während der Abarbeitung einer langen Transaktion auf

7 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation7 Fehlerklassifizierung (2) Es folgen die Beispiele der 3 Fehlerarten anhand der Transaktionsabarbeitung... I.Lost Update II.Dirty Read III.Phantom

8 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation8

9 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation9

10 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation10

11 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation11 Mehrbenutzer- vs. Ein- Benutzerbetrieb Mehrbenutzerbetrieb Vorteile: Guter Durchsatz, Gute Systemauslastung Nachteile: Lost update, Dirty Read, Phantom Einbenutzerbetrieb Vorteile: keine Mehrbenutzer-Fehler Nachteile: schlechter Durchsatz, schlechte Systemauslastung Man soll Vorteile von beiden Betriebsarten kombinieren Serialisierbarkeit

12 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation12 Serialisierbarkeit Um das I (Isolation) aus ACID zu erreichen und dennoch einen guten Durchsatz und gute Auslastung beizubehalten, verarbeitet man die Transaktionen kontrolliert parallel - verzahnt Man lässt die Transaktionen nebenläufig ablaufen, sorgt aber mit einer Kontrollkomponente (Mehrbenutzersynchronisation) dafür, dass beobachtbare Wirkung der nebenläufigen Ausführung einer möglichen seriellen Abarbeitung (wie in Einbenutzerbetrieb) entspricht Daher serialisierbar – möglichst seriell

13 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation13

14 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation14

15 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation15

16 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation16

17 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation17

18 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation18 Theorie der Serialisierbarkeit Vorabdefinitionen bzw. Erläuterungen Transaktionen – nur Basisoperationen BOT, read(), write(), commit, abort Historie (Schedule) – zeitliche Anordnung der einzelnen verzahnt ausgeführten Elementaroperationen einer Menge von parallel laufenden Transaktionen Es muss die Reihenfolge (Ordnung) der Teiloperationen gegeben werden... weiter Kemper-Folien 10 bis 18 (Kapitel 11)...

19 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation19

20 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation20

21 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation21

22 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation22

23 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation23

24 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation24

25 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation25

26 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation26

27 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation27

28 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation28 Theorie der Serialisierbarkeit (2) Konfliktoperationen sind solche Operationen, die bei einer unkontrollierten parallelen Ausführung zu Inkonsistenzen führen können Äquivalente Historien sind Historien bei denen Konfliktoperationen der nicht abgebrochenen Transaktionen in derselben Reihenfolge ausgeführt werden Eine Historie H ist serialisierbar, wenn sie äquivalent zu einer seriellen Historie H S Serialisierbarkeitsgraph SG(H) – gerichteter Graph bei dem Kanten die Konfliktoperationen und zugehörige Abhängigkeiten repräsentieren Serialisierbarkeitstheorem – H ist serialisierbar wenn SG(H) azyklisch ist

29 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation29

30 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation30

31 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation31

32 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation32

33 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation33

34 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation34 Eigenschaften von Historien bzgl. Recovery Recovery-Komponente stellt aber zusätzliche Anforderungen an Mehrbenutzersynchronisation: 1.Jede Transaktion soll zu jedem Zeitpunkt lokales Commit durchführen können, ohne dass andere Transaktionen etwas davon merken (rücksetzbare Historien) 2.Lokales Zurücksetzen einer Transaktion soll kein kaskadierendes Zurücksetzen – d.h. Schneeball-Effekt auslösen – Performance-Anforderung. Veränderte Daten einer Transaktion dürfen nicht gelesen werden (Historien ohne kaskadierendes Rücksetzen) 3.Veränderte Daten einer Transaktion dürfen nicht überschrieben werden (strikte Historien)... weiter Kemper 11.19 – 11.23..

35 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation35

36 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation36 Datenbank-Scheduler DB-Scheduler ist eine DBMS-Komponente (siehe Architektur - Kemper 11.24) Aufgabe – lasse nur vernünftige Historien zu (was vernünftig ist, ist in der DBMS Konfiguration einstellbar). Z.B. : serialisierbar und ohne kaskadierendes Rücksetzen Realisierung des Schedulers Sperrbasiert (lock based) – in der Praxis am häufigsten Zeitstempelbasiert (time stamp based) Außer sperr- und zeitstempelbasierten Synchronisation, die als pessimistisch eingestuft werden, gibt es noch optimistische Verfahren

37 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation37 Datenbank-Scheduler (2) Der Scheduler bekommt den Ausführungsplan von Transaktionsmanager und ergänzt ihn um Sperr- oder Zeitstempel-Operationen. Beispiel mit Sperroperationen lock() SchrittT1T1 1.BOT 2.lockX(A) 3.read(A) 4.write(A) 5....

38 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation38

39 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation39

40 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation40

41 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation41

42 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation42

43 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation43

44 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation44 Sperrbasierte Synchronisation Hier Zusammenfassung (Details Kemper 11.25 – 11.30) 2 Sperrmodi S – Shared, Lesen, Read X – Exclusive, Schreiben, Write Operationen: lockS(), unlockS(), lockX(), unlockX() 2 Phasen Sperrprotokoll – 2 phase locking (2PL) Wachstumsphase (Anforderung der Sperren) Schrumpfungsphase (Freigabe der Sperren) 2PL erlaubt kaskadierendes Rollback strenges 2PL - keine Schrumpfungsphase, alle Sperren werden auf einmal freigegeben

45 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation45

46 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 © Bojan Milijaš, 15.01.2010Vorlesung #12 - Mehrbenutzersynchronisation46 Fazit Notwendigkeit der Parallelisierung Notwendigkeit der Synchronisation bei der Fehlerarten (lost update, dirty read, phantom) Historien Serialisierbarkeit, Theorem, Graph Historien & Recovery (ST, ACA, RC) Datenbank-Scheduler Sperrbasierte Synchronisation (2PL) Deadlocks (Verklemmungen) – nächstes Semester

47 WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 Vorlesung #12 Ende


Herunterladen ppt "WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R 0.006 Vorlesung #12 Mehrbenutzersynchronisation."

Ähnliche Präsentationen


Google-Anzeigen