WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 Vorlesung #12 Mehrbenutzersynchronisation.

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 Vorlesung #12 Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 „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 2Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 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 3Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 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? 4Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.20135Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 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 6Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 Fehlerklassifizierung (2)  Es folgen die Beispiele der 3 Fehlerarten anhand der Transaktionsabarbeitung... I.Lost Update II.Dirty Read III.Phantom 7Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 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 11Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 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“ 12Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 12.12.2013 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)... 18Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 19.12.2013 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 19Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 19.12.2013 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.. 20Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 19.12.2013 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 21Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 19.12.2013 Datenbank-Scheduler (2)  Der Scheduler bekommt den Ausführungsplan von Transaktionsmanager und ergänzt ihn um Sperr- oder Zeitstempel-Operationen.  Beispiel mit Sperroperationen lock() ... weiter Kemper 11.25 – 11.30 SchrittT1T1 1.BOT 2.lockX(A) 3.read(A) 4.write(A) 5.... 22Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 19.12.2013 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 23Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 © Bojan Milijaš, 19.12.2013 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 24Vorlesung #12 - Mehrbenutzersynchronisation

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 Vorlesung #12 Ende

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 Vorlesung #12 Mehrbenutzersynchronisation.

Ähnliche Präsentationen

Präsentation zum Thema: "WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 Vorlesung #12 Mehrbenutzersynchronisation."— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 Vorlesung #12 Mehrbenutzersynchronisation.

Ähnliche Präsentationen

Präsentation zum Thema: "WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R 1.207 Vorlesung #12 Mehrbenutzersynchronisation."— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback