Post on 06-Apr-2015
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
Vorlesung #12
Mehrbenutzersynchronisation
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 2
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
„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 Ausblick Vorlesung #14
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 3
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
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
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 4
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
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?
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 5
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 6
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
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
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 7
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
Fehlerklassifizierung (2)
Es folgen die Beispiele der 3 Fehlerarten anhand der Transaktionsabarbeitung ...
I. Lost Update
II. Dirty Read
III. Phantom
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 8
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 9
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 10
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 11
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
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
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 12
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
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“
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 13
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 14
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 15
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 16
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 17
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 18
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
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) ...
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 19
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
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 HS
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
© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 20
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
Fazit Notwendigkeit der Parallelisierung Notwendigkeit der Synchronisation bei der
Fehlerarten (lost update, dirty read, phantom) Historien Serialisierbarkeit, Theorem, Graph Sperrbasierte Synchronisation (2PL),
Deadlocks (Verklemmungen) – nächstes Semester
WS 2007/08Datenbanksysteme
Mi 17:00 – 18:30R 1.007
Vorlesung #12
Ende