WS 2007/08 Datenbanksysteme Mi 17:00 – 18:30 R 1.007 Vorlesung #12 Mehrbenutzersynchronisation.

WS 2007/08Datenbanksysteme

Mi 17:00 – 18:30R 1.007

Vorlesung #12

Mehrbenutzersynchronisation

© Bojan Milijaš, 12.12.2007 Vorlesung #12 - Mehrbenutzersynchronisation 2


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



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



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?



Mi 17:00 – 18:30R 1.007



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



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



Mi 17:00 – 18:30R 1.007



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



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“



Mi 17:00 – 18:30R 1.007



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



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



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


Mi 17:00 – 18:30R 1.007

Vorlesung #12

Ende

WS 2007/08 Datenbanksysteme Mi 17:00 – 18:30 R 1.007 Vorlesung #12 Mehrbenutzersynchronisation.

Documents

Transcript of WS 2007/08 Datenbanksysteme Mi 17:00 – 18:30 R 1.007 Vorlesung #12 Mehrbenutzersynchronisation.