Ubungsblatt 3 - Fakultät für Mathematik und Informatik
Werbung
Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Prof. Dr. Klaus Küspert Dipl.-Inf. B. Pietsch Datenbanksysteme 2 Übungsblatt 3 SS 2014 Ausgabe: Besprechung: 20.05.2014 Aufgabe 1 Sperreskalation Gegeben seien die in Abbildung 1 dargestellte (verkürzte) Sperrgranulathierarchie und die zwei Transaktionen T1 und T2 mit den ebenfalls dargestellten Operationsfolgen (R=read, W=write). Wenn einer Transaktion mehr als 3 Sperren auf Tupelebene innerhalb einer Seite gewährt werden, so werden diese auf die Seitenebene eskaliert (vereinfachende Annahme, in der Realität wird natürlich nicht so ’simpel’ — und früh — eskaliert). r1 Relation p11 Seite Tupel t111 t112 t113 p12 t114 t115 t121 t122 t123 p13 t124 t125 t131 t132 t133 t134 t135 Wenn mehr als 3 Tupelsperren, dann Eskalation der Sperre auf Seitenebene T1 BOT R(t111) ... R(t114) R(t121) ... R(t124) R(t131) ... R(t134) T2 BOT R(t115) W(t135) W(t125) Abbildung 1: Hierarchie von Datenbankobjekten a) Beschreiben Sie den Vorgang der Sperreskalation am Beispiel der Transaktion T1 (ohne Berücksichtigung von T2) und erläutern Sie die Vorteile dieses Verfahrens. Zeichnen Sie die Sperranforderungen/-gewährungen in den Baum ein. Wie viele Sperren hält T1 am Ende? Wie viele wären es ohne Sperreskalation? Bemerkung •Sperren werden hierarchisch angefordert (top-down) •und wieder freigegeben (bottom-up) Legende: X = Schreibsperre (eXclusive lock), S = Lesesperre (Shared Lock), IX = auf tieferer Ebene ist eine selektive Schreibsperre (intension exclusive lock), IS = auf tieferer Ebene ist eine selektive Lesesperre (intension shared lock) Tj\Ti IS IX S X Tabelle 1: Verträglichkeit einander IS + + + der IS1 Relation Seite IS1 S1 p11 Tupel t111 t112 t113 t114 t115 S1 S1 S1 S2 S1 IX S X + + + - + verschiedenen Sperren unter- IX2 IS2 r1 IX2 IX2 IS1 S1 p12 t121 t122 t123 t124 t125 t131 t132 t133 t134 t135 S1 S1 S1 S1 X2 S1 S1 S1 S1 X2 IS2 IS1 S1 p13 Wenn mehr als 3 Tupelsperren, dann Eskalation der Sperre auf Seitenebene T1 BOT R(t111) ... R(t114) R(t121) ... R(t124) R(t131) ... R(t134) T2 BOT R(t115) W(t135) W(t125) Abbildung 2: Zustand des Sperrgraphen nach Aufgabe a) & b) Lösung •Statt 4 Lesesperren auf t111, t112, t113, t114 nur eine Lesesperre auf p11 (analog für p12, p13) •Vorteil: –weniger Sperren zu verwalten ==> kleinere Sperrtabelle (weniger Verbrauch an Hauptspeicher, virtueller Speicher) –weniger Aufrufe an Sperrverwalter (für das Anfordern/Freigeben von Sperren) •T1 hält am Ende 3 Lesesperren und 1 IS-Sperre •ohne Sperreskalation: 12 Lesesperren und 4 IS-Sperren b) Betrachten Sie nun T1 und T2 mit der gegebenen zeitlichen Operationsabfolge (Nebenläufigkeit). Zeichnen Sie wiederum die Sperranforderungen/-gewährungen in den Baum ein. Welcher schröckliche Effekt tritt dabei auf? Welche Möglichkeiten des DBMS-Verhaltens gäbe es dabei prinzipiell? Diskutieren Sie an diesem Beispiel Nachteile der Sperreskalation. Lösung •Sperreskalation von t131, t132, t133, t134 auf p13 scheitert, da T2 auf p13 eine IX-Sperre hält (S und IX sind nicht verträglich). •Sperranforderung von T2 für t125 scheitert, obwohl es ohne Sperreskalation gegangen wäre. •Nachteile: –Sperreskalation kann scheitern –Sperreskalation kann TAen behindern •prinzipielle DBMS-Verhaltensmöglichkeiten: –falls Sperreskalation nicht möglich, darauf verzichten vs. beim Scheitern TA zurücksetzen vs. warten –falls Sperranforderung scheitert, versuchen Sperreskalation rückgängig zu machen (geht nur, falls die dafür notwendigen Informationen existieren, was fraglich ist; konterkariert Sinn der Eskalation (Platz sparen)) Aufgabe 2 Transaktionen und Zweiphasensperrprotokoll (2PL) Der Mehrbenutzerbetrieb erfordert Maßnahmen zur Synchronisation von Transaktionen, um die ACID–Eigenschaften abzusichern. Prüfen Sie durch Beantwortung folgender Fragen Ihr Wissen auf diesem Gebiet. a) Was versteht man unter Serialisierbarkeit und unter dem Zweiphasensperrprotokoll? Bemerkung Synchronisation •Operationen konkurrierender Transaktionen aus Effizienzgründen verzahnt ausführbar •Synchronisation (durch Sperren) soll Consistency– und Isolation–Eigenschaften konkurrierender Transaktionen garantieren Lösung Serialisierbarkeit •Es gibt eine serielle Ausführungsreihenfolge der TAen, die zum selben Ergebnis führt •d. h. wenn TA-Schedule nicht serialisierbar ==> verzahnte Abarbeitung ergibt keinen korrekten DB-Zustand •Argumentation: einzelne Transaktion korrekt (Consistency), daher jede serielle Ausführung von Transaktionen korrekt, daher jede serialisierbare verzahnte Ausführung korrekt •jeder serielle Ablauf von TAen korret, da TAen vollständig isoliert voneinander ablaufen •eine Möglichkeit dies zu erreichen ist 2PL Zweiphasensperrprotokoll 1.Vor Zugriff auf ein Objekt muss dieses durch die Transaktion gesperrt werden. 2.Nach Aufheben einer Sperre darf eine Transaktion keine weiteren Sperren mehr anfordern. Zweiphasensperrtheorem •Halten alle betrachteten Transaktionen das Zweiphasensperrprotokoll ein, dann sind alle möglichen verzahnten Ablaufpläne dieser Transaktionen serialisierbar. Isolation Levels •Abweichen von Serialisierbarkeit aus Effizienzgründen denkbar •zu bedenken sind jedoch Verletzungen der ACID–Eigenschaften (dirty read, nonrepeatable read, phantoms) b) Wie beginnen und wie enden Transaktionen in SQL? Lösung Beginn von Transaktionen in SQL •keine explizite SQL–Anweisung verfügbar (TA beginnt implizit) •transaktionsinitiierend sind in SQL u. a. Schema–Anweisungen (create, alter, . . . ), DML– Anweisungen (select, update, . . . ) und Embedded–SQL–Anweisungen (open, execute, ...) Ende von Transaktionen in SQL •commit [ work ] macht Änderungen der Transaktion permanent und sichtbar für andere Transaktionen •rollback [ work ] hebt alle Änderungen der Transaktion auf; sie werden nie sichtbar für andere Transaktionen (Ausnahme: isolation level read uncommitted) •implizites Commit (z. B. bei autocommit on) •(einige Nicht–SQL–Anweisungen können implizit commit oder rollback ausführen (implementierungsabhängig)) c) In der Vorlesung wurden verschiedene Sperr– und Freigabestrategien des Zweiphasensperrprotokolls angesprochen. Eine davon ist im Hinblick auf die ACID–Eigenschaften bedenklich. Welche ist es und welcher Sperrmodus (S, X) bereitet Probleme? Erläutern Sie an einem Beispiel, was passieren kann. Lösung Frühe Freigabe von Schreibsperren •frühe Freigabe von Schreibsperren verletzt Isolation–Eigenschaft von Transaktionen (Stichwort: dirty read) •Mechanismen zum kaskadierenden Rücksetzen und Nachführen von Transaktionen erforderlich •Beispiel: 1.T1 ändert Wert A und gibt X–Sperre für A frei 2.T2 liest Wert A, nutzt ihn und beendet Transaktion erfolgreich 3.T1 bricht nach weiteren Arbeiten erfolglos ab und setzt Änderungen zurück Konsequenz aus Consistency und Durability ist, dass auch T2 zurückgesetzt und mit altem Wert von A nachgeführt werden müsste ==> Dies ist aber nicht möglich, da T2 bereits erfolgreich beendet wurde. ==> Dauerhaftigkeit! •Folgerung: Beschränkung früher Sperrenfreigabe auf Lesesperren Aufgabe 3 Serialisierbarkeit Die Transaktionen T1, T2 und T3 sollen auf einem Wert A in einer Datenbank folgende Operationen ausführen: T1: Addiere 1 zu A. T2: Verdopple A. T3: Gebe A aus und setze A danach auf 1. Die Transaktionen sind intern wie folgt strukturiert: R1: U1: T1 retrieve A into t1 t1 := t1 + 1 update A from t1 R2: U2: T2 retrieve A into t2 t2 := t2 ∗ 2 update A from t2 R3: U3: T3 retrieve A into t3 display t3 update A from 1 a) Angenommen, die drei Transaktionen werden konkurrierend ausgeführt, also (annähernd) gleichzeitig initiiert. A habe zu Beginn den Wert 0. Geben Sie alle möglichen korrekten Resultate der Ausführung an. (Welche Resultate ergäben sich übrigens bei einem Anfangswert von 2012?) Lösung Korrekte Ausführungspläne •korrekt sind Ergebnisse serieller Ausführung: T1–T2–T3 : A = 1 T2–T1–T3 : A = 1 T3–T1–T2 : A = 4 T1–T3–T2 : A = 2 T2–T3–T1 : A = 2 T3–T2–T1 : A = 3 •Ergebnisse sind im vorliegenden Beispiel unabhängig vom Anfangswert (wegen U3). D. h. bei dem Anfangswert des aktuellen Jahres ergeben sich dieselben Ergebnisse. •mögliche TA-Reihenfolgen: n!, wobei n die Zahl der TAen kennzeichnet b) Geben Sie eine Ausführungsreihenfolge der sechs Operationen an, die für den Anfangswert 0 ein korrektes Resultat liefert (eines der Resultate von Teilaufgabe a), aber nicht serialisierbar ist. Bemerkung Begriff der Korrektheit •mögliche Varianten des Begriffs: –Datenbankzustand nach Abarbeitung eines Ausführungsplans entspricht dem irgend einer seriellen Ausführung (übliche, auch im folgenden genutzte Interpretation) –Endzustand und alle Ausgaben (am Bildschirm) entsprechen denen einer seriellen Ausführung •wirkliche Korrektheit soll unabhängig vom Ausgangswert sein <=> Begriff der Serialisierbarkeit (Serialisierbarkeit würde bei allen möglichen Anfangswerten korrekte Ergebnisse liefern) Lösung Korrekter“ Ausführungsplan für Ausgangswert 0 ” •R3–R1–U1–R2–U3–U2 liefert A=2, also korrektes Ergebnis • Korrektheit“ ist aber nur Zufall, nämlich abhängig vom Ausgangswert; Plan daher nicht ” serialisierbar •Gegenbeispiel: Ausgangswert 5 führt zu Ergebnis 12; R1: t3=5, R1: t1=5+1=6, U1: A=6, R2: t2=6*2=12, U3: A=1, U2: A=12. Dies ist jedoch kein korrektes Ergebnis nach Teilaufgabe a) c) Gibt es eine Ausführungsreihenfolge, die serialisierbar ist, aber nicht gewählt werden kann, wenn alle Transaktionen dem Zweiphasensperrprotokoll genügen sollen? Erläutern Sie Ihre Antwort. Lösung Serialisierbarkeit und Zweiphasensperrprotokoll •R1–R3–U1–U3–R2–U2 ist serialisierbar und liefert für alle Ausgangswerte den gleichen Datenbankzustand wie T1–T3–T2 nämlich A=2; Aber nicht ausführbar da A von T3 gesperrt ist und somit nicht von T1 gesperrt werden kann •(Erkennung der Serialisierbarkeit erfordert Informationen zur inneren Semantik der Transaktionen (konstante Zuweisung in U3)) •(Zweiphasensperrprotokoll kann keine Rücksicht auf innere Semantik von Operationen nehmen) •Zweiphasensperrprotokoll würde S–Sperre für R3 setzen; U1 könnte nicht ändern, da Sperre erst nach U3 wieder aufhebbar ist •(Folgerung: Zweiphasensperrprotokoll impliziert Serialisierbarkeit, ist aber nicht äquivalent dazu) d) Wieviele mögliche Ausführungsreihenfolgen (schedules) der sechs Datenbankoperationen gäbe es ohne Sperren? Versuchen Sie, eine allgemeine Berechnungsvorschrift für das Problem zu finden. Was sagt deren Größenordnung über Möglichkeiten aus, Scheduling–Fragen problemabhängig zur Laufzeit zu optimieren? Lösung Zahl von Ausführungsplänen •allgemeine Formel bei n Transaktionen mit je mi Operationen: ( #schedules = n X mi )! i=1 n Y mi ! i=1 •wobei der Nenner die Zahl der möglichen Permutationen der Operationen ist; Der Zähler entfernt alle Permutationen der einzelnen Transaktionen, wie Updates vor Reads welche nicht erlaubt/möglich sind. •bei drei Transaktionen mit je zwei Operationen: 90 Pläne, bei 10 Transaktionen mit je zwei Operationen bereits 2,37*1015 Vorberechnung serialisierbarer Pläne •Ausführungspläne z. B. über Abhängigkeitsgraphen auf Serialisierbarkeit überprüfbar •Laufzeitberechnung optimaler Pläne so nicht möglich, da –Aktionsfolge einer Transaktion i. d. R. nicht im voraus bekannt –Berechnungskomplexität zu hoch (viel zu viele mögliche Ausführungspläne, wie eben gezeigt) Aufgabe 4 Sperrhierarchien In der Vorlesung wurden Sperrhierarchien und Intention Locks besprochen. Betrachten Sie die Hierarchie physischer Datenbankobjekte in Abbildung 3. Datenbank D Segmente (Table Spaces) a2 p2 p1 Seiten Saetze (Tupel) a1 s1 s2 s3 p3 s4 s5 s6 Abbildung 3: Hierarchie physischer Datenbankobjekte Wir betrachten nun die Sperranforderungen verschiedener Transaktionen. Kennzeichnen Sie in jeder Teilaufgabe die Datenbankobjekte in der Form (Ti , SP), wobei SP die Art der Sperre (z.B. IS oder X) und Ti die zugehörige Transaktion kennzeichnet. Geben Sie zusätzlich die Reihenfolge der Sperrvergabe mit an. a) T1 will die Seite p1 exklusiv sperren. b) T2 will die Seite p2 mit einer S-Sperre belegen. c) T3 will das Segment (Table Space) a2 mit X sperren. Die Sperranforderungen der beiden folgenden Transaktionen können nicht mehr vollständig erfüllt werden (warum nicht?). Kennzeichnen Sie nicht gewährte Sperren hier durch Unterstreichen. d) T4 will den Datensatz s3 exklusiv sperren. e) T5 will eine S-Sperre auf s5 erwerben. f ) Da T4 und T5 nicht alle Sperranforderungen erfüllt bekommen, sind sie blockiert. Liegt eine Verklemmung vor? g) Wenn man in Abbildung 3 noch Tabellen als weitere Objektebene aufnehmen wollte, wo müsste man diese im Baum einzeichnen? Lösung •a)-e) 1. (T1, IX) 4. (T2, IS) Datenbank 2. (T , IX) Segmente 5. (T , IS) a1 (Table Spaces) 1 2 D 7. (T3, IX) 9. (T4, IX) 12. (T5, IS) 10. (T4, IX) 8. (T3, X) 13. (T5, IS) a2 Tabellen 3. (T1, X) p1 Seiten Saetze (Tupel) 6. (T2, S) s1 s2 s3 11. (T4, X) p2 p3 s4 s5 s6 Abbildung 4: Hierarchie physischer Datenbankobjekte, Lösung •d) IX und S sind nicht verträglich (auf p2) Siehe Sperrverträglichkeitstabelle •e) IS und X sind nicht verträglich (auf a2) •f) Nein, keine Verklemmung (=kein Deadlock): T4 wartet auf Ressourcenfreigabe von T2, T5 wartet auf Ressourcenfreigabe von T3. Es existiert kein Zyklus ==> kein indirektes Warten auf sich selbst •g) zwischen Tablespaces und Seiten •h) Weitere Elemente in der Sperrhierarchie könnten sein Partition, Tabellensegmente und Extents
