Übungen zur Vorlesung. Datenbanken I

Transkript

1 Prof. Dr. S. Böttcher Adelhard Türling Übungen zur Vorlesung Datenbanken I WS 2002/2003 Blatt 6 Aufgabe 1: In der Vorlesung haben Sie für die Einbringstrategie Update in Place die Vorgehensweisen steal, steal, force und force kennen gelernt. a) Wann (spätestens) werden bei der Einbringstrategie Logbucheinträge auf Platte geschrieben? Vor dem Speichern der Daten (Seiten) auf Platte b) Tragen Sie in die folgende Tabelle ein ob bei der Kombination der jeweiligen Techniken für die Recovery Redo und/oder Undo verwendet werden muss: steal steal Force Kein Redo Kein Undo Kein Redo Undo force Redo Kein Undo Redo Undo c) Force und steal scheint die beste Lösung für das Recovery-Verhalten eines DBMS zu sein. Warum wird sie in der Regel trotzdem nicht eingesetzt? Starke Sequentialisierung und dadurch Blockierung von vielen Seiten im Speicher (Verdrängen wird stark erschwert) Viel Plattenzugriffe die unnötig sind durch force d) d) Geben Sie ein Beispiel mit zwei parallelen Transaktionen an, bei denen die Strategien force & steal nicht angewendet werden kann. T1 führt write (a) aus T2 führt write (b) aus. Nun will T1 commiten. Sind die zwei Objekt a und b zufällig auf der gleichen Seite gespeichert, so verbietet unsteal das Speichern dieser Seite auf Platte. Gleichzeitig fordert force jedoch das Speichern auf Platte für diese Seite. Also haben wir einen Konflikt im Regelwerk.

2 Aufgabe 2: Schatten Recovery a) Worin liegt der Unterschied zwischen Schatten Recovery und Update in Place Strategie Es werden Kopien der Seiten angelegt, nicht Seiten überschrieben (inplace) Dadurch mehr Plattenplatz Bedarf b) Einfache Recovery Eigenschaften (Atomität durch Umschaltbit) b) Wann wird ein zusätzliches Lockbuch benötigt? Bei parallelen Transaktionen die auf den selben Seiten arbeiten werden wieder Logbücher erforderlich. Aufgabe 3: a) Geben Sie das Logbuch zum Zeitpunkt des Crashs an. b) Welcher Zustand muss von der Recovery (wieder) hergestellt werden? Wie? T1 T3 w(a,10) w(b,2) T2 r(a) w(a,20) r(c) w(d,12) w(b,18) T4 w(d,2) Checkpoint Crash Zu a: <T1: Start> <T3: Start> <T1: a,?, 10> <T3: b,?, 2> Checkpoint <T1, T3> <T2: Start>

3 <T3: d, 2, 12> <T1: a, 2, 18> <T2: a, 10, 20> <T3: Commit> - Der letzte zugesicherte (commitete) konsistente Zustand der DB. - Undo auf T1 und T2, Redo auf T3 Aufgabe 4: Nach einem Stromausfall enthält das Logbuch auf der Platte folgende Einträge: <T100: Start> <T99: Konto1, 900, 800> <T99: Commit> <T101: Start> <T102: Start> <T101: Konto1, 800, 700> <T100: Konto2, 300, 400> <T101: Commit> Checkpoint <T100, T102> <T103: Start> <T100: Konto1, 700, 600> <T102: Konto4, 100, 200> <T100: Commit> <T103: Konto3, 600, 500> Für welche Transaktionen muss die Recovery-Komponente die Undo- bzw. Redo-Operation ausführen? Die Transaktionen T99 und T101 sind vor dem letzten Checkpoint comitted worden und müssen daher nicht weiter betrachtet werden. Die Transaktion T100 ist committed worden, allerdings nach dem letzten checkpoint. Für T100 muss die Redo-Operation ausgeführt werden.

4 Die Transaktionen T102 und T103 werden abgebrochen und ihre (mögliche) Änderungen in den Tabellen werden zurückgesetzt, d.h. die Undo-Operation wird ausgeführt. Aufgabe 5: Angenommen eine Transaktion T 1 macht zuerst ein, dann ein, dann ein und schließlich ein write(y). Transaktion T 2 macht ein und dann ein. Geben Sie parallele Abläufe der beiden Transaktionen an, die serialisierbar sind und a) wiederherstellbar (recoverable) aber nicht kaskadenfrei (cascadeless) write(y) abort Die Transaktion T2 macht ein dirty read (fett in dem obigen Plan), d.h., T2 liest Daten von T1 vor T1 bestätigt (committed) worden ist. Der Plan ist nicht kaskadenfrei. Der Plan ist wiederherstellbar, weil in dem Plan nur T2 von T1 liest und T1 als erste commit/abort ausführt. Der Plan ist serialisierbar (äquivalent dem sequentiellen Plan T1 T2). b) kaskadenfrei aber nicht strikt

5 write(y) abort Der Plan ist kaskadenfrei, weil keine Transaktion ein dirty read macht (d.h., keine der zwei Transaktionen unbestätigte Daten liest). Der Plan ist nicht strikt, weil die Transaktion T2 ein dirty write macht (d.h., unbestätigte Daten einer anderen Transaktion überschreibt). Der Plan ist serialisierbar, äquivalent dem seriellen Plan T2 (dank dem abort der Transaktion T1 muss in dem Konflikt-Graph nur die Transaktion T2 betrachtet werden). c) strikt write(y) commit commit Der obige Plan ist ein serieller Plan T1 T2. Alle serielle Pläne sind auch serialisierbar. Alle serielle Pläne sind auch strikt.