siehe Beispielszenarium auf folgenden Folien * d.h. Ausführung einer Transaktion nach der anderen

Transkript

1 7. Synchronisation im Mehrbenutzerbetrieb (Concurrency Control) Hintergrund/Feststellung: a) Mehrbenutzerbetrieb auf Datenbanken unbedingt erforderlich; Serialisierung* würde Durchsatz dramatisch reduzieren b) Unkontrollierter Mehrbenutzerbetrieb führt zu vielfältigen Fehlersituationen und Chaos siehe Beispielszenarium auf folgenden Folien * d.h. Ausführung einer Transaktion nach der anderen T1 T2 T3 T4 Probleme so nicht!! (wäre allenfalls denkbar bei sehr, sehr kurzen TAen aber auch dort intolerabel in Praxis) - Wartezeiten für die Ti bis Start - DBVS-Auslastung ungenügend, da keine Nutzung von Denkzeiten, E/A-Zeiten... t

2 Probleme (Fehlerklassen) bei unkontrolliertem Mehrbenutzerbetrieb 1. Lost-update-Problem Zeit t Transaktion T1 liest A=30 aus DB verändert A:=A+10 in HSP schreibt A=40 in DB Transaktion T2 liest A=30 aus DB verändert A:=A-30 in HSP schreibt A=0 in DB die von T1 durchgeführte Änderung ist verlorengegangen; bei serieller Ausführung (T1 vor T2 oder T2 vor T1) wäre Ergebnis stets A=10 gewesen! ( es ist etwas passiert, was nicht serialisierbar ist) 2. Inkonsistente Analyse Zeit t Transaktion T1 liest Fam.stand Ehefrau (verh.) verändert Fam.stand Ehefrau (gesch.) liest Fam.stand Ehemann (verh.) verändert Fam.stand Ehemann (gesch.) schreibt geänderte Fam.stände in DB zurück Transaktion T2 liest Fam.stand Ehefrau (verh.) T2 wartet (Benutzer denkt nach) verändert Fam.stand Ehemann (gesch.) Transaktion T2 sieht ( scheinbare ) Inkonsistenz, obwohl DB (nach Abschluss von T1) konsistent T2 s Analyse bezieht sich auf zwei verschiedene konsistente DB-Zustände

3 3. Phantomproblem Spezialfall der inkon. Analyse Zeit t Transaktion T1 liest Konten aller Kunden mit A liest Konten aller Kunden mit B liest Konten aller Kunden mit C liest Konten aller Kunden mit Z Transaktion T2 Annahme: #Konten immer geradzahlig als Integritätsregel fügt Konto ein für Kunde Adam fügt Konto ein für Kunde Zylinski COMMIT Transaktion T1 meldet ungeradzahlige Kontenanzahl (inkonsistente Analyse), verursacht durch Einfügeoperationen [nebenbei bemerkt: nicht ganz einfach zu lösendes Problem] Warum? Phantome nicht sperrbar Wie? Tabellensperren 4. Nicht wiederholbares Lesen Spezialfall der inkonsistenten Analyse (2) Zeit t... Transaktion T1 bestimmt Summe aller Kontenstände bestimmt Summe aller Kontenstände Transaktion T2 erhöht Kontenstand für Kunde Küspert COMMIT Transaktion T1 bekommt bei wiederholter Ausführung des Lesens verschiedene Ergebnisse geliefert TA/Benutzer merkt somit, dass nicht allein auf der DB aktiv

4 5. Abhängigkeit von nicht freigegebenen Änderungen Zeit t Transaktion T1 verändert A:=A+100 in der DB (d.h. lesen und zurückschreiben) erkennt logischen Fehler und macht ROLLBACK WORK Transaktion T2 liest A aus der DB zeigt A Benutzer am Bildschirm COMMIT WORK Benutzer von T2 hat Zustand gesehen, den es offiziell nie gab T2 ebenfalls zurücksetzen ( Kaskad.Rücksetzen )? a) hochgradig unerwünscht b) im obigen Fall nicht durchführbar, da T2 bereits commitet hat R e s ü m e e Concurrency Control Synchronisation im Mehrbenutzerbetrieb wird benötigt, Sperren (naheliegend) ist eine! Möglichkeit hierzu

5 Ziel der Transaktionsausführung ( Scheduling ) Logischer Einbenutzerbetrieb bei physischem Mehrbenutzerbetrieb d.h. Benutzer soll der Eindruck vermittelt werden, er sei allein auf der Datenbank aktiv es sollen trotz physischem Mehrbenutzerbetriebs nur solche Datenbankzustände erzeugt werden können, die auch entstehen könnten bei serieller Abarbeitung der Transaktionsmenge sog. Kriterien der Serialisierbarkeit!!! Eine Lösung: Sperren von Datenbankobjekten (z.b. Tupeln, Seiten...) vor dem Zugriff und Befolgen eines sog. Sperrprotokolls (2-Phasen-Sperr- und Freigabeprotokoll*, 2 Phase Locking, kurz 2 PL) * hat eine TA eine Sperre freigegeben, so darf sie keine weitere mehr anfordern ( Anforderungs-/Freigabephase)

6 Sperr- und Freigabestrategien Sperrstrategien a) Eine TA sperrt alle benötigten DB-Objekte gleich zu TA-Beginn (preclaiming) b) Eine TA sperrt DB-Objekte jeweils erst (spätestens) direkt vor dem Zugriff auf das Objekt (d.h. sukzessives Sperren) Freigabestrategien a) Freigabe der Sperren erst zu TA-Ende ( lange Sperren ) b) Freigabe von Sperren schon zu einem früheren Zeitpunkt, wenn nicht mehr benötigt ( kurze Sperren ) Bildlich # gesperrte Objekte Praxis wg. Preclaim BOT Fall aa EOT t # gesperrte Objekte Praxis BOT Fall ba EOT strikte Zweiphasigkeit t # gesperrte Objekte Problem: schafft Abh. von nichtfreigegeben. Änd. BOT Fall bb EOT (Praxis) für Lesesperren t # gesperrte Objekte Praxis wg. Preclaim BOT Fall ab EOT t

7 Diskussion: Sperrstrategie a (preclaiming): + - Optimales Scheduling möglich, da alle benötigten Betriebsmittel der TA vorab bekannt + - Keine Verklemmungsgefahr (Deadlocks) - - Bei DB-Einsatz jedoch i.d.r. nicht implementierbar/unrealistisch Sperrstrategie b (sukzessives Sperren): + - Es werden nicht mehr DB-Objekte gesperrt, als nötig und nicht früher, als nötig - - Übliche Strategie im DB-Einsatz Freigabestrategie a ( lange Sperren ): - Ermöglicht isoliertes Rücksetzen und repeatable read - Von der reinen Lehre her im DB-Einsatz zu verwenden, in der Praxis jedoch oft partielles Aufweichen (bei Lesesperren) zur Erhöhung der Parallelität Freigabestrategie b ( kurze Sperren ): - Höhere Parallelität möglich als bei Fr. a - In DBVSen anzutreffen

8 Sperrgranulate Frage: Was wird gesperrt?* * Sperren werden vom DBVS automatisch gesetzt (und auch wieder freigegeben, spätestens bei EOT) Benutzer braucht sich darum nicht zu kümmern! Möglichkeiten: Logische DB-Objekte - Datenelement (Attributwert) - Satz (Tupel) - Tabelle (Relation) - Datenbank Physische DB-Objekte - Seite; Seitenausschnitte ( mini pages ) - Datenbanksegment ( table space, db space ) - Datenbank Kompromiss gesucht: Aus Gründen hoher Parallelität: Kleine (logische) Sperrgranulate Aus Gründen DBVS-interner Performance /Implementierungsaufwand/ Abhängigkeiten etwa zum Thema Logging/Recovery: Gröbere (physische) Sperrgranulate Heute vorherrschend: kleinstes Granulat ist Tupel (bzw. Indexeintrag) Zusätzlich Granulathierarchie, z.b. Tupel Relation Segment DB (Details folgen!)

9 Sperrmodi Frage: Was soll eine Sperre bewirken? In den allermeisten DBVSen gibt es (zumindest) zwei Modi: Schreibsperren Write (exclusive lock (es darf nur EINER ein Objekt verändern), X-Sperre) Sperre kann nur von einer Transaktion für ein DB-Objekt gehalten werden (d.h. exklusiv), andere Transaktionen müssen (üblicherweise) warten Lesesperren Read (Shared lock (es dürfen MEHRERE ein Objekt lesen), S-Sperre) Mehrere Transaktionen können eine S-Sperre auf einem DB-Objekt besitzen, S-Sperre aber nicht mit X-Sperre verträglich Verträglichkeitsgraph S X Verträglichkeitsmatrix Ti Tj S X S + - X - - Zusätzlich bei Sperrhierarchie Intention Lock (IS, IX) drückt aus, dass auf tieferer Ebene selektiv mit S bzw. X gesperrt werden soll

10 Beispiel für Sperrhierarchie / Intention Locks Sperrgranulate seien Relation und Tupel Transaktion Ti will einige Tupel der Relation Rj ändern Was tun? - Ganze Relation (exklusiv) sperren einfach, verhindert aber jegliche Parallelität - Genau die Tupel (exklusiv) sperren, die geändert werden sollen. Was, wenn eine parallele Transaktion Tk unbemerkt Rj exklusiv sperrt? Lösung: Ti muss sich an hier. Sperrprotokoll halten Ti setzt erst IX-Sperre (Intention exclusive) auf Rj und dann X-Sperren auf die einzelnen zu verändernden Tupel Allgemein: Verträglichkeitsgraph IS S IX X Letzter Begriff: Sperreskalation Verträglichkeitsmatrix Ti Tj IS IX S X IS IX S X

11 Bemerkungen zur Synchronisationsthematik und deren Implementierungsdetails Sperrprotokoll für hierarchisches Sperren Es existieren die Sperrmodi (exclusive, Schreibsperre), S (Shared, Lesesperre) sowie IX (Intention exclusive) und IS (Intention Shared). Die Realität kennt noch weitere, schenken wir uns hier Es existiert eine Hierarchie von Sperrgranulaten, z.b. Datenbank, Table Space, Tabelle, Tupel. Weitere Ebenen/Granulate könnten existieren, etwa (Tabellen-)Fragment zwischen Tabelle und Tupel Sperren müssen hierarchisch angefordert werden (top-down) und entsprechend spätestens bei Transaktionsende wieder freigegeben werden (bottom up!) Unter einer IS-Sperre darf wiederum IS kommen oder S (auf nächsttieferer Ebene) Unter einer IX-Sperre darf wiederum IX kommen oder IS oder S oder X (auf nächsttieferer Ebene) Rechteabschwächung beim Abstieg / der Sperranforderung soll also erlaubt sein Unter einer S- oder X-Sperre kommt nichts mehr, d.h. sie stellt Ende des hierarchischen Sperranforderungspfades dar (man hat dann ja das Objekt gesperrt, muss wenn es sich um nichtatomares handelt nicht Teile weitersperren)

12 Sperreskalation Problemstellung: U.U. viele kleine Sperren - Größe der Sperrtabelle (im Hauptspeicher, virtuellen Speicher) - Vielzahl von Aufrufen an den Sperrverwalter (Lock Manager) zwecks Sperranforderung bzw. freigabe - Auch einzelner Aufruf (Lock Request, Lock Release) zunehmend teuer, aber das kann man implementierungstechnisch noch in den Griff bekommen (Hash-Tabelle mit graceful degradation ) Lösungsmöglichkeit: Sperreskalation (zur Laufzeit, Lock Escalation), z.b.: - Übergang von (vielen) z.b. Tupelsperren auf eine Tabellensperre on the fly (mit gleichzeitiger Freigabe der Tupelsperren natürlich).. - Sperrtabelle wächst an dieser Stelle nicht weiter an, es müssen keine weiteren satzweisen Lock-Mgr-Aufrufe erfolgen (man hat ja die ganze + Tabelle nun gesperrt).. toll(?) - Probleme / zu berücksichtigen aber: stärkere Behinderung nun (wegen gröberen Granulats), klar - Sperreskalation kann auch scheitern (Lock kann nicht gewährt werden) oder gar Deadlock-Verursachung Again: There s no free lunch

13 Realisierung der Sperrtabelle / des Sperrverwalters (Lock Table, Lock Manager) Request_Lock (Ressource, Modus, Transaktions-Id, RC) Release_Lock (Ressource, Transaktions-Id, RC) Ressource: bezeichnet via Id das gewünschte Objekt (die Datenbank, den Table Space i, die Tabelle j, das Fragment k, das Tupel l..) Modus: klar (S, X, IS..) Transaktions-Id: Identifikator des Requestors (wer fordert die Sperre an?) RC: Return Code (u.a.: Sperre konnte (G unten) oder konnte nicht (W unten) gewährt werden) Beispiel für Sperrtabelle im Hauptspeicher / virt. Speicher: 0 Hash h (Ressource)... G IS TA1 S TA2 Ri Sperrkontrollblöcke W TA3 X TA4 X G TA2 X Rj G = Gewährt W = Wartend TAi kann mehrere Sperren besitzen (Bsp. TA2), aber nur auf eine warten n-1 S G TA4 Rk TA1 X W IX TA2 X TA

14 Sperrgraph / Wartegraph Information darüber, wer welche Resource aktuell gesperrt hat / wer auf welche Ressource wartet (weil sie aktuell gesperrt ist) kann in Form eines Graphen aufgefasst werden (ob s auch als solcher implementiert ist oder sich der Graph als Sicht auf die Sperrtabelle oben darstellt! ist dabei zunächst unerheblich) Beispiel für Sperrgraphen: TAx R1 TAy R3 TAw R2 TAz Semantik: TAx wartet auf die Freigabe von Ressource R1 durch TAy etc. etc. Nutzung des Sperrgraphen: Vor allem auch zur Deadlock-Erkennung, Deadlocks führen nämlich zu Zyklen im Graphen (erkennbar mittels Standard-Graphenalgorithmen) Deadlock-Auflösung durch systemseitiges Abschießen (Rücksetzen, Transaction Failure) einer Transaktion Problem hierbei u.a.: Verhungern ( starvation ) einer Transaktion

15 Optimistic Concurrency Control (OCC) Bis hier betrachtet: Sperren von angefassten Datenbankobjekten, d.h. erst Sperranforderung und gewährung, dann Anfassen pessimistischer Ansatz ( es könnte ja etwas passieren, d.h. eine andere Transaktion uns in die Quere kommen), PCC (Pessimistic Concurrency Control) Nachteile/Probleme: Sperranforderungen und freigaben kosten etwas Lock-Mgr.-Aufrufe, Lock-Einträge in Lock-Tabelle (CPU, Speicher also) Transaktionen müssen u.u. warten (auf Gewährung einer Sperre) Deadlock-Gefahr (Wartezyklen) u.u. Transaktionszurücksetzen (durch DBMS) nötig zum Aufbrechen eines Deadlock Teils eigentlich unnötiges Sperren, wenn geringe Konfliktwahrscheinlichkeit Idee deshalb: Optimistischer Ansatz (OCC), d.h. Transaktionen ohne Sperren durchführen und erst bei Transaktionsende schauen, ob s gut ging (beim Commit-Processing)

16 Vorteil(e): Vermeidung der o.g. (Sperr-)Probleme, also wenig Kosten zur Laufzeit der TA, kein Warten, keine Deadlocks, keine Sperrverwalteraufrufe Nachteil: Konflikte (zwei TA s sind sich ins Gehege gekommen..) werden erst bei Transaktionsende erkannt aufwendiges Rücksetzen der soweit fertigen Transaktion, Arbeit für die Katz, muss wiederholt werden Resümee daraus: OCC wird in DBMS nicht als Standard-Concurrency-Control-Mechanismus eingesetzt, sondern doch Sperren OCC-Nutzen stark abhängig von Anwendungscharakteristika: Super für konfliktarme Anwendungen, desaströs für konfliktreiche Anwendungen Ideal: DBMS müsste sich customizen lassen ja nach Anwendung, also PCC versus OCC (meist läuft ohnehin nur eine große Anwendung auf einer DBMS-Instanz) heute aber nicht möglich OCC-Lösungen existieren, dann aber oberhalb des DBMS (viele Großanwendungen á la SAP haben ohnehin noch mal eigene Sperrverwaltung oberhalb des DBMS (Langzeit-/Vorgangssperren) und könn(t)en dort oben ihre eigene CC-Strategie realisieren anwendungscharakteristikaabhängig)

17 Sogenannte Kurzzeitsperren - und deren Abgrenzung zu herkömmlichen Sperren - Übliche Sperren im Auftrag von Datenbankoperationen/Transaktionen werden (wie oben erwähnt) über Sperrverwalter angefordert, in Sperrtabelle eingetragen, bei Nichtgewährung erfolgt Warten, ggf. Deadlock-Erkennung und Auflösung... Transaktionssperren zur Gewährleistung von I in ACID, schwergewichtige Sperren, werden auch relativ lange gehalten (Sekundenbruchteile, ggf. auch Sekunden oder länger, anwendungsabhängig Dazu im Unterschied: Kurzzeitsperren sind etwas anderes, tiefer angesiedeltes im DBMS Problem: Mehrere DBMS-Server-Prozesse oder Threads arbeiten i.d.r. gemeinsam/parallel an Abarbeitung der Datenbank-Workload, können sich dabei wechselseitig ins Gehege kommen auf gemeinsam genutzten internen Datenstrukturen (Hauptspeicher, virtueller Speicher), insb.: - Systempuffer (Datenbank-Cache) - Log-Puffer - Sperrtabelle!! (Koordinierung des parallelen Zugriffs auf Sperrtabelle also nötig, Sperren der Sperrtabelle??)

18 Und zwar sowohl bei richtiger Parallelität als auch bei Nebenläufigkeit (1 Prozessor versus mehrere Prozessoren involviert) Bsp.: Prozess x analysiert für TA1 die Sperrtabelle, Prozess y fügt parallel dazu für TA2 etwas in die Sperrtabelle ein Chaos höherer (oder tieferer?) Ordnung? Lösung: Sog. Kurzzeitsperren für Prozesse, während sie auf der jeweiligen Datenstruktur arbeiten, leichtgewichtige Sperren (wegen extrem häufigen Zugriffs auf diese Datenstrukturen wären herkömmliche Sperren viel zu aufwendig bzw. klassisch Sperren der Sperrtabelle????? wie soll das bitte gehen. Die Sperrtabelle ist ja keine normale Datenbanktabelle, sondern eine interne Datenstruktur des DBMS.) Realisierung der Kurzzeitsperren (als sog. Latches), Unterschiede zu den o.g. Langzeitsperren: - Realisierung über Variable im (gemeinsam genutzten) Hauptspeicher à la (vereinfacht):

19 if systempuffer_latch = frei then begin systempuffer_latch := P1: /* Prozess P1 jetzt exklusiver Nutzer des Sys.puffers */... Arbeiten auf Systempuffer (Suchen, Ändern..)... systempuffer_latch := frei /* P1 gibt Recht wieder ab */ end else /* anderer Prozess arbeitet aktuell auf Sys.puffer */ wat nu? Bemerkungen hierzu: - Latch = Schnappschloss - Kurzzeitsperren werden nur für sehr kurze Zeiträume gehalten, für einige Dutzend bis vielleicht wenige Hundert Maschineninstruktionen (wegen hohen Behinderungspotentials!) - Anforderung/Freigabe von Kurzzeitsperren ist billig (sehr wenige Maschineninstruktionen, einfaches Abfragen/Setzen einer Variable, viel billiger als Manipulation auf Sperrtabelle): N.B.: Sperren der Sperrtabelle muss ja billig sein

20 - if... then... muss über eine Maschineninstruktion (atomar) realisiert werden! Test and Set, Compare and Swap auch genannt je nach Maschinenbefehlssatz - Bei belegter Kurzzeitsperre u.u. busy wait (statt lazy wait bei normalen Sperren) - Es muss implementierungstechnisch sehr darauf geachtet werden, dass Kurzzeitsperre nicht versehentlich lang wird bzw. dass dies nur sehr seltenen Fällen passiert

21 Zusammenfassung / Hilites zum Thema Synchronisation Mehrbenutzerbetrieb (parallel aktive TA) auf DB unverzichtbar Chaos bei unkontrolliertem Mehrbenutzerbetrieb muss verhindert werden Mehrbenutzerkontrolle/Synchronisation Logischer Einbenutzerbetrieb bei physischem Mehrbenutzerbetrieb als Ziel Serialisierbarkeit: Ausführungsergebnis bei parallel ablaufenden TA soll dem Ergebnis entsprechen, das sich bei einer seriellen Ausführung ergäbe Lösung: Sperren (Pessimistic Concurrency Control), d.h. alles, was von TA angefasst wird, muss vorher gesperrt werden Granulate, Modi, Protokolle (Eine) Alternative zum Sperren (PCC): Optimistic Concurrency Controll (OCC) TA werden ohne Sperrren ausgeführt, erst bei TA-Ende (Commit Processing) wird automatisch überprüft, ob ein Konflikt vorliegt