Mehrbenutzer-Synchronisation

Transkript

1 MehrbenutzerSynchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen, und T 3 : (a) im Einzelbetrieb und T 3 Zeitachse (b) im (verzahnten) Mehrbenutzerbetrieb (gestrichelte Linien repräsentieren Wartezeiten) T 3 Kapitel Fehler bei unkontrolliertem Mehrbenutzerbetrieb I Verlorengegangene Änderungen (lost update) Fehler bei unkontrolliertem Mehrbenutzerbetrieb II Abhängigkeit von nicht freigegebenen Änderungen read(a,a 1 ) read(a,a 1 ) a 1 := a a 1 := a read(a,a 2 ) write(a,a 1 ) a 2 := a 2 * 03 read(a,a 2 ) write(a,a 2 ) a 2 := a 2 * 03 write(a,a 1 ) write(a,a 2 ) read(b,b 1 ) read(b,b 1 ) b 1 := b write(b,b 1 ) abort 3 4

2 Fehler bei unkontrolliertem Mehrbenutzerbetrieb III Phantomproblem Serialisierbarkeit Historie ist äquivalent zu einer seriellen Historie dennoch parallele (verzahnte) Ausführung möglich Serialisierbare Historie von und insert into Konten values (C,1000,) select sum(kontostand) from Konten select sum(kontostand) from Konten read(c) write(c) 6 Serielle Ausführung von vor, also Nicht serialisierbare Historie 1 1 read(c) write(c) T 3 8

3 Zwei verzahnte ÜberweisungsTransaktionen Eine Überweisung ( ) und eine Zinsgutschrift (T 3 ) read(a,a 1 ) a 1 := a 1 50 write(a,a 1 ) read(b,b 1 ) b 1 := b write(b,b 1 ) T 3 read(a,a 2 ) a 2 := a write(a,a 2 ) read(b,b 2 ) b 2 := b write(b,b 2 ) Ist nicht serialisierbar, obwohl dies im konkreten Fall nicht zum Konflikt führt. Letzteres kann die DB aber nicht beurteilen read(a,a 1 ) a 1 := a 1 50 write(a,a 1 ) read(b,b 1 ) b 1 := b write(b,b 1 ) T 3 read(a,a 2 ) a 2 := a 2 * 03 write(a,a 2 ) read(b,b 2 ) b 2 := b 2 * 03 write(b,b 2 ) Dieselbe r/wkonstellation, diesmal zum Konflikt führend. Die DB greift zur Kontrolle nur auf die r/w Struktur zu, nicht auf die Semantik der Anwendung! 10 Theorie der Serialisierbarkeit Formale Definition einer Transaktion Operationen einer Transaktion T i r i (A) zum Lesen des Datenobjekts A, w i (A) zum Schreiben des Datenobjekts A, a i zur Durchführung eines aborts, c i zur Durchführung des. Theorie der Serialisierbarkeit Konsistenzanforderung einer Transaktion T i entweder abort oder aber nicht beides! Falls T i ein abort durchführt, müssen alle anderen Operationen p i (A) vor a i ausgeführt werden, also p i (A) < i a i. Analoges gilt für das, d.h. p i (A) < i c i falls T i ted. Wenn T i ein Datum A liest und auch schreibt, muss die Reihenfolge festgelegt werden, also entweder r i (A) < i w i (A) oder w i (A) < i r i (A)

4 Theorie der Serialisierbarkeit II Historie r i (A) und r j (A): In diesem Fall ist die Reihenfolge der Ausführungen irrelevant, da beide TAs in jedem Fall denselben Zustand lesen. Diese beiden Operationen stehen also nicht in Konflikt zueinander, so dass in der Historie ihre Reihenfolge zueinander irrelevant ist. r i (A) und w j (A): Hierbei handelt es sich um einen Konflikt, da T i entweder den alten oder den neuen Wert von A liest. Es muss also entweder r i (A) vor w j (A) oder w j (A) vor r i (A) spezifiziert werden. w i (A) und r j (A): analog w i (A) und w j (A): Auch in diesem Fall ist die Reihenfolge der Ausführung entscheidend für den Zustand der Datenbasis; also handelt es sich um Konfliktoperationen, für die die Reihenfolge festzulegen ist. Formale Definition einer Historie Eine Historie ist eine partiell geordnete Menge (H, < H ) mit H = T i U n i=1 < H ist verträglich mit allen < i Ordnungen, d.h.: < H Für zwei Konfliktoperationen p,q H gilt entweder p < H q oder n U i= 1 < i Die Ordnung muss nicht total sein, z.b. bei Mehrprozessorbetrieb. 13 q < H p. 14 Historie für drei Transaktionen BeispielHistorie für 3 TAs H = r 2 (A) w 2 (B) w 2 (C) c 2 r 3 (B) w 3 (A) w 3 (B) w 3 (C) c 3 r 1 (A) w 1 (A) c 1 15 Äquivalenz zweier Historien H H wenn sie die Konfliktoperationen der nicht abgebrochenen Transaktionen in derselben Reihenfolge ausführen. 1 1 read(c) write(c) (s. Folie 6) (s. Folie 7) 1 1 read(c) write(c) 16

5 read(c) Serialisierbare Historie Eine Historie ist serialisierbar, wenn sie äquivalent zu einer seriellen Historie Hs ist. write(c) Historie read(c) write(c) r 1 (A) w 1 (A) w 1 (B) c (s. Folie 6) (s. Folie 7) H = r 2 (A) w 2 (B) c 2 r 1 (A) r 2 (C) w 1 (A) w 2 (C) r 1 (B) w 1 (B) c 1 r 2 (A) w 2 (A) c 2 r 1 (A) w 1 (A) r 2 (C) w 2 (C) r 1 (B) w 1 (B) c 1 r 2 (A) w 2 (A) c 2 r 1 (A) w 1 (A) r 1 (B) r 2 (C) w 2 (C) w 1 (B) c 1 r 2 (A) w 2 (A) c 2 r 3 (A) w 3 (A) c 3 r 1 (A) w 1 (A) r 1 (B) w 1 (B) c 1 r 2 (C) w 2 (C) r 2 (A) w 2 (A) c Serialisierbarkeitsgraph und zugehöriger Serialisierbarkeitsgraph SG(H )= T 3 Serialisierbarkeitstheorem Satz: Eine Historie H ist genau dann serialisierbar, wenn der zugehörige Serialisierbarkeitsgraph SG(H) azyklisch ist. Historie H = w 1 (A) w 1 (B) c 1 r 2 (A) r 3 (B) w 2 (A) c 2 w 3 (B) c 3 w 1 (A) r 3 (A) der Historie H führt zur Kante T 3 des SG weitere Kanten analog Verdichtung der Historie 19 Serialisierbarkeitsgraph SG(H )= T 3 Topologische Ordnung(en) H H 1 s 2 s = T H 1 = T 1 H T 1 s 2 T 3 T 3 T H 2 2 s 20

6 Eigenschaften von Historien bezüglich der Recovery Terminologie Wir sagen, dass in der Historie H T i von T j liest, wenn folgendes gilt: Eigenschaften von Historien bezüglich der Recovery Rücksetzbare Historien T j schreibt mindestens ein Datum A, das T i nachfolgend liest, also: w j (A) < H r i (A) T j wird (zumindest) nicht vor dem Lesevorgang von T i zurückgesetzt, also: a j < H r i (A) Alle anderen zwischenzeitlichen Schreibvorgänge auf A durch andere Transaktionen T k werden vor dem Lesen durch T i zurückgesetzt. Falls also ein w k (A) mit w j (A) < w k (A) < r i (A) Eine Historie heißt rücksetzbar, falls immer die schreibende Transaktion (in unserer Notation T ) j vor der lesenden Transaktion (T i genannt) ihr durchführt, also: c j < H c i. Anders ausgedrückt: Eine Transaktion darf erst dann ihr durchführen, wenn alle Transaktionen, von denen sie gelesen hat, beendet sind. existiert, so muss es auch ein a < r (A) geben. k i Eigenschaften von Historien bezüglich der Recovery Strikte Historien BeispielHistorie mit kaskadierendem Rücksetzen: T 3 T 4 T w 1 (A) r 2 (A) w 2 (B) r 3 (B) w 3 (C) r 4 (C) w 4 (D) r 5 (D) a 1 (abort) Historien ohne kaskadierendes Rücksetzen Eine Historie vermeidet kaskadierendes Rücksetzen, wenn für je zwei TAs T i und T j gilt: c j < H r i (A) gilt, wann immer T i ein Datum A von T j liest. 23 Eine Historie ist strikt, wenn für je zwei TAs T i und T j gilt: Wenn w j (A) < H o i (A) (mit o i = w i oder o i = r i ), dann muss entweder a j < H o i (A) oder c j < H o i (A) gelten. 24

7 Beziehungen zwischen den Klassen von Historien Der DatenbankScheduler T 3 T n alle Historien SR RC ACA ST serielle Historien TransaktionsManager TM Scheduler DatenManager RecoveryManager PufferManager SR: RC: ACA: ST: serialisierbare Historien rücksetzbare Historien Historien ohne kaskadierendes Rücksetzen strikte Historien 25 Datenbank 26 Aufgabe des Schedulers Sperrbasierte Synchronisation Reihung der Operationen verschiedener Transaktionen, so dass die Historie mindestens serialisierbar und meistens auch ohne kaskadierendes Rollback rücksetzbar ist. Die entstehenden Historien sollten also aus dem Bereich ACA SR stammen. Verschiedene Ansätze möglich: sperrbasierte Synchronisation (wird am häufigsten verwandt) Zeitstempelbasierte Synchronisation optimistische Synchronisation (eignet sich bei vorwiegend lesenden Zugriffen) Sichert Serialisierbarkeit zu Zwei Sperrmodi S (shared, read lock, Lesesperre): X (exclusive, write lock, Schreibsperre): Verträglichkeitsmatrix (auch Kompatibilitätsmatrix genannt) S X NL S X 27 28

8 ZweiPhasenSperrprotokoll: Definition Jedes Objekt, das von einer Transaktion benutzt werden soll, muss vorher entsprechend gesperrt werden. Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an. Eine Transaktion muss die Sperren anderer Transaktionen auf dem von ihr benötigten Objekt gemäß der Verträglichkeitstabelle beachten. Wenn die Sperre nicht gewährt werden kann, wird die Transaktion in eine entsprechende Warteschlange eingereiht bis die Sperre gewährt werden kann. Jede Transaktion durchläuft zwei Phasen: Eine Wachstumsphase, in der sie Sperren anfordern, aber keine freigeben darf und eine Schrumpfphase, in der sie ihre bisher erworbenen Sperren freigibt, aber keine weiteren anfordern darf. Bei EOT (Transaktionsende) muss eine Transaktion alle ihre Sperren zurückgeben. 29 ZweiPhasen Sperrprotokoll: Grafik #Sperren Wachstum Schrumpfung Zeit 30 Verzahnung zweier TAs gemäß 2PL modifiziert nacheinander die Datenobjekte A und B (z.b. eine Überweisung) liest nacheinander dieselben Datenobjekte A und B (z.b. zur Aufsummierung der beiden Kontostände). 31 Verzahnung zweier TAs gemäß 2PL Bemerkung lockx(a) locks(a) muss warten lockx(b) unlockx(a) wecken 1 locks(b) muss warten 1 1 unlockx(b) wecken unlocks(a) 1 unlocks(b) 1 32

9 Strenges ZweiPhasen Sperrprotokoll Verklemmungen (Deadlocks) 2PL schließt kaskadierendes Rücksetzen nicht aus Erweiterung zum strengen 2PL: alle Sperren werden bis EOT gehalten damit ist kaskadierendes Rücksetzen ausgeschlossen Ein verklemmter Schedule Bemerkung #Sperren lockx(a) locks(b) Wachstumsphase EOT Zeit lockx(b) locks(a) muss warten auf muss warten auf Deadlock Verklemmungen Erkennen von Verklemmungen können entdeckt und dann aufgelöst oder gleich vermieden werden. Beides ist teuer. Mögliche Techniken: BruteForceMethode: TimeOut Nach gewisser Wartezeit (z.b. 1 sec) wird Transaktion zurückgesetzt Ad a: TimeOut Zyklenerkennung Ad b: Nachteil: Falls Zeit zu kurz, werden zu viele Transaktionen zurückgesetzt, die nur auf Resourcen (CPU etc.) warten. Falls Zeit zu lang, werden zu viele Verklemmungen geduldet. Preclaiming Zeitstempel 35 36

10 Erkennen von Verklemmungen Zyklenerkennung durch Tiefensuche im Wartegraph ist aufwendiger, aber präziser Vermeiden von Verklemmungen Preclaiming in Verbindung mit dem strengen 2 PL Protokoll Bsp.: Wartegraph mit zwei Zyklen: #Sperren T 3 T 4 T 3 T 5 T 5 T 4 T 3 Beide Zyklen können durch Rücksetzen von T 3 gelöst werden. EOT Zeit Preclaiming ist in der Praxis häufig nicht einzusetzen: Man weiss i.a. apriori nicht genau, welche Sperren benötigt werden, z.b. bei ifthenelse im Anwendungsprogramm. Daher müssen normalerweise mehr Sperren als nötig auf Verdacht reserviert werden, was zu übermäßiger Resourcenbelegung und Einschränkung der Parallelität führt. Vermeiden von Verklemmungen Verklemmungsvermeidung durch Zeitstempel Jeder Transaktion wird ein eindeutiger Zeitstempel (TS) zugeordnet ältere TAs haben einen kleineren Zeitstempel als jüngere TAs TAs dürfen nicht mehr bedingungslos auf eine Sperre warten. Zwei Varianten: woundwait Strategie will Sperre erwerben, die von gehalten wird. Wenn älter als ist, wird abgebrochen und zurückgesetzt, so dass weiterlaufen kann. Sonst wartet auf die Freigabe der Sperre durch. 39 waitdie Strategie will Sperre erwerben, die von gehalten wird. Wenn älter als ist, wartet auf die Freigabe der Sperre. Sonst wird abgebrochen und zurückgesetzt. 40

11 MGL: MultiGranularity Locking MGL: MultiGranularity Locking Hierarchische Anordnung möglicher Sperrgranulate Datenbasis Bisher haben wir Sperrungen auf derselben Granularitätsebene betrachtet. Nachteil bei kleiner Granularität: Bei TAs mit Zugriff auf viele Tupel muss viel Sperraufwand betrieben werden. Nachteil bei großer Granularität: unnötige Sperrung von Datensätzen Segmente Lösungsansatz: Sperrung auf verschiedenen Hierarchieebenen erlaubt. Sätze Seiten Bei Anforderung einer Sperre muss man überprüfen, ob weiter oben oder unten bereits Sperren gesetzt sind. zu hoher Suchaufwand! Lösungsansatz: Einführung zusätzlicher Sperrmodi MGL Erweiterte Sperrmodi NL: keine Sperrung (no lock), MultiGranularity Locking (MGL) Kompatibilitätsmatrix S: Sperrung durch Leser, X: Sperrung durch Schreiber, NL S X IS IX IS (intention share): Weiter unten in der Hierarchie ist eine S Lesesperre (S) beabsichtigt, IX (intention exclusive): Weiter unten in der Hierarchie ist eine Schreibsperre (X) beabsichtigt. X IS IX 43 44

12 MultiGranularity Locking (MGL) Sperrprotokoll des MGL Bevor ein Knoten mit S oder IS gesperrt wird, müssen alle Vorgänger in der Hierarchie vom Sperrer (also der Transaktion, die die Sperre anfordert) im IX oder ISModus gehalten werden. Bevor ein Knoten mit X oder IX gesperrt wird, müssen alle Vorgänger vom Sperrer im IXModus gehalten werden. Die Sperren werden von unten nach oben (bottom up) freigegeben, so dass bei keinem Knoten die Sperre freigegeben wird, wenn die betreffende Transaktion noch Nachfolger dieses Knotens gesperrt hat. DatenbasisHierarchie mit Sperren Datenbasis Segmente (areas) Seiten Sätze (,X) s 1 (,IX) a 1 (,IS) a 2 (T 3,X) p 1 s 2 (,IX) s 3 p 2 D s 4 (T2,IS) (T 3,IX) (,S) s 5 p 3 s DatenbasisHierarchie mit Sperren (T4 will s3 ändern, T5 will s5 lesen, was passiert?) (T2,IS) Datenbasis (,IX) D (T 3,IX) Datenbasis DatenbasisHierarchie mit blockierten Transaktionen (,IX) (T 4,IX) D (,IS) (T 3,IX) Segmente (areas) (,IX) a 1 (,IS) a 2 (T 3,X) Segmente (areas) (,IX) (,IS) a 1 (T 4,IX) a 1 (T 3,X) Seiten (,X) p 1 p 2 (,S) p 3 Seiten (,X) p 1 p 2 (,S) (T 4,IX) p 3 Sätze s 1 s 2 s 3 s 4 s 5 s 6 47 Sätze s 1 s 2 s 3 (T 4,X) s 4 s 5 s 6 48

13 Datenbasis DatenbasisHierarchie mit blockierten Transaktionen (,IX) (T 4,IX) (T 5,IS) D (,IS) (T 3,IX) DatenbasisHierarchie mit blockierten Transaktionen Segmente (areas) (,IX) (,IS) a 1 (T 4,IX) a 1 (T 3,X) (T 5,IS) die TAs T 4 und T 5 sind blockiert (warten auf Freigabe von Sperren) es gibt aber in diesem Beispiel (noch) keine Verklemmung Seiten (,X) p 1 p 2 (,S) (T 4,IX) p 3 (T 5,IS) Verklemmungen sind aber auch bei MGL möglich Sätze s 1 s 2 s 3 s 4 s 5 s 6 (T 4,X) (T 5,S) Einfüge und Löschoperationen, Phantome Phantomprobleme Vor dem Löschen eines Objekts muss die Transaktion eine X Sperre für dieses Objekt erwerben. (Man beachte aber, dass eine andere TA, die für dieses Objekt ebenfalls eine Sperre erwerben will, diese nicht mehr erhalten kann, falls die Löschtransaktion erfolgreich (mit ) abschließt.) Beim Einfügen eines neuen Objekts erwirbt die einfügende Transaktion eine XSperre. select count(*) from prüfen where Note between 1 and 2; select count(*) from prüfen where Note between 1 and 2 insert into prüfen values(19555, 5001, 2137, 1); Phantomprobleme können immer noch auftreten, hier z.b. wenn die Sperren auf SatzEbene gesetzt werden

14 Phantomprobleme Das Problem lässt sich dadurch lösen, dass man zusätzlich zu den Tupeln auch den Zugriffsweg, auf dem man zu den Objekten gelangt ist, sperrt Wenn also ein Index für das Attribut Note existiert, würde der Indexbereich [1,2] für mit einer SSperre belegt Wenn jetzt also Transaktion versucht, das Tupel [29555, 5001, 2137, 1] in prüfen einzufügen, wird die TA blockiert Zeitstempelbasierende Synchronisation Jedem Datum A in der Datenbasis werden bei diesem Synchronisationsverfahren zwei Marken zugeordnet: readts(a): writets(a): Synchronisationsverfahren T i will A lesen, also r i (A) Falls TS(T i ) < writets(a) gilt, haben wir ein Problem: Die Transaktion T i ist älter als eine andere Transaktion, die A schon geschrieben hat. Also muss T i zurückgesetzt werden. Anderenfalls, wenn also TS(T i ) writets(a) gilt, kann T i ihre Leseoperation durchführen und die Marke readts(a) wird auf max(ts(t i ), readts(a)) gesetzt Zeitstempelbasierende Synchronisation Synchronisationsverfahren T i will A schreiben, also w i (A) Falls TS(T i ) < readts(a) gilt, gab es eine jüngere Lesetransaktion, die den neuen Wert von A, den T i gerade beabsichtigt zu schreiben, hätte lesen müssen. Also muss T i zurückgesetzt werden. Falls TS(T i ) writets(a) gilt, gab es eine jüngere Schreibtransaktion. D.h. T i beabsichtigt einen Wert einer jüngeren Transaktion zu überschreiben. Das muss natürlich verhindert werden, so dass T i auch in diesem Fall zurückgesetzt werden muss. Optimistische Synchronisation Lesephase: In dieser Phase werden alle Operationen der Transaktion ausgeführt also auch die Änderungsoperationen. Die Transaktion liest (zunächst) nur, und führt alle Schreiboperationen auf lokalen Variablen aus. Validierungsphase: In dieser Phase wird entschieden, ob die Transaktion möglicherweise in Konflikt mit anderen Transaktionen geraten ist. Dies wird anhand von Zeitstempeln entschieden, die den Transaktionen in der Reihenfolge zugewiesen werden, in der sie in die Validierungsphase eintreten. Anderenfalls darf T i das Datum A schreiben und die Marke writets(a) wird auf TS(T i ) gesetzt. Schreibphase: In dieser Fassung sind alle Historien serialisierbar, schließen aber kaskadierendes Rücksetzen nicht aus. Protokoll muss geeignet erweitert werden. 55 Die Änderungen der Transaktionen, bei denen die Validierung positiv verlaufen ist, werden in dieser Phase in die Datenbank eingebracht. 56

15 Validierung bei der optimistischen Synchronisation Vereinfachende Annahme: Es ist immer nur eine TA in der Validierungsphase! Wir wollen eine Transaktion T j validieren. Die Validierung ist erfolgreich, falls für alle älteren Transaktionen T a also solche, die früher ihre Validierung abgeschlossen haben eine der beiden folgenden Bedingungen gilt: Synchronisation von Indexstrukturen B + Baum mit rechtsverweisen zur Synchronisation T a war zum Beginn der Transaktion T j schon abgeschlossen einschließlich der Schreibphase Die Menge der von T a geschriebenen Datenelemente, genannt WriteSet(T a ), enthält keine Elemente der Menge der gelesenen Datenelemente von T j, genannt ReadSet(T j ). Es muss also gelten: WriteSet(T a ) ReadSet(T j ) = D 2 D 3 D D 7 D 9 D D Synchronisation von Indexstrukturen B + Baum mit rechtsverweisen nach Einfügen von 14 Transaktionsverwaltung in SQL set transaction [read only, read write,] [isolation level read unted, read ted, repeatable read, serializable,] [diagnostic size,] D 2 D 3 D D 7 D 9 D D 14 D

16 Transaktionsverwaltung in SQL92 read unted: Dies ist die schwächste Konsistenzstufe. Sie darf auch nur für read onlytransaktionen spezifiziert werden. Eine derartige Transaktion hat Zugriff auf noch nicht festgeschriebene Daten. Zum Beispiel ist folgender Schedule möglich: rollback Macht nur Sinn zum Browsen der Datenbank. Hindert andere Transaktionen nicht, da keine Sperren gesetzt werden. 61 Transaktionsverwaltung in SQL92 read ted: Diese Transaktionen lesen nur festgeschriebene Werte. Allerdings können sie unterschiedliche Zustände der DatenbasisObjekte zu sehen bekommen: Transaktionsverwaltung in SQL92 repeatable read: Das oben aufgeführte Problem des non repeatable read wird durch diese Konsistenzstufe ausgeschlossen. Allerdings kann es hierbei noch zum Phantomproblem kommen. Dies kann z.b. dann passieren, wenn eine parallele Änderungstransaktion dazu führt, dass Tupel ein Selektionsprädikat erfüllen, das sie zuvor nicht erfüllten. serializable: Diese Konsistenzstufe fordert die Serialisierbarkeit. Dies ist der Default (in den meisten DBMS). 63