Einführung in Datenbanksysteme, Datenbanken für die Bioinformatik Sommersemester 2009 9. Übungszettel (Abgabe Fr. 18.06.09 bis 18 Uhr) Einführung in Datenbanksysteme Datenbanken für die Bioinformatik Heinz Schweppe, Jürgen Broß, Katharina Hahn Übungsaufgaben Aufgabe 1 (Konfliktserialisierbarkeit) 9 Punkte Gegeben sind die drei Schedules für die Transaktionen T1 und T2 (sowie T3 in Aufgabenteil c). Überprüfen Sie, ob diese serialisierbar sind. Geben Sie alle Konfliktpaare an und zeichnen Sie jeweils den entsprechenden Konfliktgraphen auf. Geben Sie für jeden konflikt­ serialisierbaren Ausführungsplan (Schedule) einen äquivalenten seriellen Plan an (Bsp.: T3 ­­> T1 ­­> T2). a) r1(a), w1(a), r1(b), w1(b), r2(b), w2(b), r2(c), w1(c) Konfliktpaare: r1(b) ↔ w2(b); w1(b) ↔ r2(b); w1(b) ↔ w2(b); r2(c) ↔ w1(c) Konfliktgraph: T1 T2 nicht serialisierbar aufgrund eines Zyklus im Konflikgraphen → kein äquivalenter Ausführungsplan existent! b) r1(c), r2(b), w1(a), w2(b), r1(b), r2(c), w1(b), w2(c) Konfliktpaare: r1(c) ↔ w2(c); r2(b) ↔ w1(b); w2(b) ↔ r1(b); w2(b) ↔ w1(b) Konfliktgraph: T1 T2 Ausgabe 11.06.2009 Einführung in Datenbanksysteme, Datenbanken für die Bioinformatik Sommersemester 2009 nicht serialisierbar aufgrund eines Zyklus im Konflikgraphen → kein äquivalenter Ausführungsplan existent! c) r1(a), r2(b), r3(a), w3(a), r1(b), w1(b), r2(c), r1(c), r2(d), r1(d), w1(d), w3(c) Konfliktpaare: r1(a) ↔ w3(a); r2(b) ↔ w1(b); r2(c) ↔ w3(c); r1(c) ↔ w3(c); r2(d) ↔ w1(d) Konfliktgraph: T1 T2 T3 äquivalenter serieller Ausführungsplan: T2 → T1 → T3 Aufgabe 2 (Konfliktserialisierbarkeit) 5 Punkte Zeigen Sie, dass es serialisierbare Historien gibt, die ein Scheduler auf Basis des 2PL­ Protokolls nicht zulassen würde. Ein Beispiel reicht aus: w1(x), r2(x), r1(x) Kein Zyklus im Konfliktgraph → serialisierbar, aber lock after unlock bei r1(x) → kann nicht von 2PL Scheduler stammen Aufgabe 3 (Isolationslevel in Oracle) 16 Punkte a) Geben Sie eine Definition der Konsistenz an wie sie von Oracle aus gesehen wird (Oracle­Doku: Concepts/Introduction to Oracle Database/Overview of Concurrency Features) Was wird unter Lese­Konsistenz verstanden? Wie wird es in Oracle eingesetzt und was wird dadurch vom System garantiert? Oracle vermeidet Dirty Reads durch die Schreibsperren, die automatisch durch das System gesetzt werden, wenn Update­, Delete­ oder Insert­Statements ausgeführt werden. Oracle spricht von „Statement­Level Read Consistency“ und meint, dass ein einzelnes SQL­Statement eine konsistente Sicht der Datenbank hat. Es ist jedoch Ausgabe 11.06.2009 Einführung in Datenbanksysteme, Datenbanken für die Bioinformatik Sommersemester 2009 möglich, dass aufeinanderfolgende Statements innerhalb der gleichen Transaktion unterschiedliche Zustände sehen können. b) Welches sind die Vorteile der Konsistenz so wie sie in Oracle definiert sind? Wo liegen die Schwachstellen? Oracle's Konsistenzbegriff ist auf größtmögliche Effizienz durch maximale Parallelität von Transaktionen ausgerichtet. Deswegen wird so wenig wie möglich gesperrt. Allerdings sind Transaktionen in Oracle nicht notwendigerweise konfliktserialisierbar. c) Welche Isolationslevel werden von Oracle unterstützt? Was ist jeweils die Semantik dieser Isolationslevel? Oracle unterstützt drei Isolationslevel: Read Committed, Serializable sowie Read Only, wobei Read Committed die Standard­Einstellung ist. Es ist in keinem der Falle möglich, noch nicht committete Werte zu lesen, so dass inconsistent (dirty) reads nicht auftreten konnen. Read Committed besagt, dass nur Werte von erfolgreich beendeten Transaktionen gelesen werden. Ferner garantiert Oracle durch die "Statement­Level Read Consistency", dass für die Dauer der Ausführung des Statements der konsistente Datenbankzustand gesehen wird, der zu Beginn des Statements vorlag (so ist es zum Beispiel nicht möglich, dass ein Cursor Tupel sieht, die nach seinem Öffnen erzeugt wurden). Repeatable Read wird hingegen für die Isolationsstufe Read Committed nicht garantiert. Da Konsistenz nur bezüglich eines Statements gilt, ist es möglich, dass zwei identische Select­Anfragen derselben Transaktion unterschiedliche Werte zurückliefern. Repeatable Read kann jedoch für Nur­Lese­Transaktionen erzwungen werden, indem die Transaktion als read­only deklariert wird (SET TRANSACTION READ ONLY). Mit dem Isolationslevel Serializable schliesslich werden nur serialisierbare Schedules erlaubt. d) In der Vorlesung wurde das Problem der verloren gegangenen Änderung (lost update) vorgestellt. Untersuchen Sie anhand eines Beispiels, ob dieses Problem auch in Oracle mit der Default­Einstellung des Isolationslevels (Read Committed) möglich ist. Was kann ein Anwendungs­ bzw. SQL­Programmierer tun, um lost updates zu vermeiden? Um Mehrbenutzerbetrieb zu simulieren öffnen Sie einfach zwei SQLDeveloper­ Fenster oder zwei SQL­Plus­Konsolen. Achten Sie darauf, dass die Autocommit­ Einstellung ausgeschaltet ist. Nutzen Sie für Ihre Tests z.B. die Abwrackdatenbank. Teil der Abgabe ist eine Beschreibung Ihres Testablaufs mit den beiden offenen Fenstern/Konsolen! Ausgabe 11.06.2009 Einführung in Datenbanksysteme, Datenbanken für die Bioinformatik Sommersemester 2009 Ausgabe 11.06.2009