uni:8:dbs2:start
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
uni:8:dbs2:start [2015-06-09 16:24] – [Anforderungen] skrupellos | uni:8:dbs2:start [2020-11-18 18:11] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Datenbanksysteme II ====== | ====== Datenbanksysteme II ====== | ||
- | ===== Übung 1 ===== | + | |
- | | + | * [[zusammenfassung]] |
- | * **Hauptaufgabe der Transaktionen - Verwaltung** | + | |
- | * Synchronisation (Koordination von mehreren Benutzerproxessen => Logische Einbenutzerbetrieb) | + | |
- | * Recovery (Behebung von Fehlersituationen) | + | |
- | * **Eigenschaften von Transaktionen (ACID-Prinzip)** | + | |
- | * **A**tomicy (Atomarität: | + | |
- | * **C**onsistency (Konsistenz/ | + | |
- | * **I**solation (Isoliertheit: | + | |
- | * **D**urability (Dauerhaftigkeit, | + | |
- | * **Schedule** \\ Folge von Aktionen (read/ | + | |
- | * **Serieller Schedule** \\ Schedule S von {T1,…,Tn}, in dem die Aktionen der einzelnen Transaktionen nicht unter einander verzahnt sind, sondern sin Blöcken hintereinander ausgeführt werden | + | |
- | * **Serialisierbarer Schedule** \\ Schedule S von {T1,…,Tn}, der die selbe Wirkung hat, wie ein belibiger serieller von {T1,…,Tn} => Nur serialisierbarer Schedules dürfen zugelassen werden! | + | |
- | ==== Aufgabe 1 ==== | ||
- | Mögliche Abhängigkeiten | ||
- | * rw | ||
- | * wr | ||
- | * ww | ||
- | |||
- | Für S1 | ||
- | T1 = (r(v), w(v)) | ||
- | T2 = (w(x), w(w), r(v)) | ||
- | T3 = (w(z), r(y), w(x)) | ||
- | T4 = (r(w), r(z), W(y)) | ||
- | |||
- | === a === | ||
- | => Gleiche Tranasktions- & Aktionsmenge! | ||
- | |||
- | Abhängigkeiten: | ||
- | * S1: rw4,2(w),wr1,2(v),wr3,4(z),ww2,3(x),rw3,4(y) | ||
- | * S2: rw4,2(w),wr1,2(v),ww2,3(x),rw4,3(z),rw3,4(y) | ||
- | => S1 & S2 sind nicht Konfliktäquivalent! | ||
- | |||
- | === b === | ||
- | => Gleiche Tranasktions- & Aktionsmenge! | ||
- | |||
- | Abhängigkeiten: | ||
- | * S1: rw4,2(w),wr1,2(v),wr3,4(z),ww2,3(x),rw3,4(y) | ||
- | * S3: wr3,4(z),wr1,2(v),ww2,3(x),rw4,2(w),rw3,4(y) | ||
- | => S1 & S2 sind Konfliktäquivalent! | ||
- | |||
- | |||
- | ==== Aufgabe 2 ==== | ||
- | Serialisierungs-/ | ||
- | * Knoten: Transaktionen | ||
- | * Kanten: Abhängigkeiten | ||
- | * Zyklenfrei: Topologische Ordnung = serielle Ausführung | ||
- | * enthält zyklen: S ist nicht seriallisierbar | ||
- | |||
- | a) T1, T2, T4, T3 oder T1, T4, T2, T3 | ||
- | b) nicht serialisierbar | ||
- | |||
- | ==== Aufgabe 3 ==== | ||
- | * a): Lost Update S(r1(x),w2(x),w1(x)) \\ => Änderungen einer Transaktion werden durch eine andere Transaktion überschrieben und gehen verloren. | ||
- | * b): Dirty Read/Write: S(w1(x),r2(x),w1(x)) \\ => Zugriff auf " | ||
- | * c): Non-Repeatable Read: S(r1(x).w2(x),r1(x) \\ => Transaktion liest unterschiedliche Werte des selben Objekts | ||
- | |||
- | => Annomalien können nur auftreten, wenn // | ||
- | |||
- | ===== Übung 2 ===== | ||
- | ==== Aufgabe 1 ==== | ||
- | Legaler Schedule | ||
- | * LOCK (L) vor jedem Zugriff | ||
- | * UNLOCK (U) spätestens bei TA=Ende | ||
- | * Keine TA fordert Sperre an, die sie bereits besitzt | ||
- | * Sperren werden respektiert | ||
- | * Man darf keine sperren zurückgeben, | ||
- | |||
- | |||
- | * 2-Phasen-Sperrprotokoll (2PL): | ||
- | - Wachstumsphase (lock) | ||
- | - Schrumpfungsphase (unlock) | ||
- | |||
- | Problem von 2PL: Kaskadierendes Rücksetzen (T1 wird nach U1(x) zurückgesetzt (ABORT) => alle T2. die nach U1(x) auf x zugegriffen haben, müssen auch zurückgesetzt werden => Durability | ||
- | |||
- | * Striktes 2PL | ||
- | * alle Sperren werden bis zum COMMIT gehalten | ||
- | * COMMIT wird atomar durchgeführt | ||
- | * | ||
- | |||
- | Es gild | ||
- | * 2PL => serialisierbar | ||
- | * serialisierbar NOT => 2PL | ||
- | * | ||
- | |||
- | S0 | ||
- | * wird nicht freigegeben vor TA ende | ||
- | * T2 gibt sperre frei, die sie nie hatte | ||
- | * => Nicht legal | ||
- | S1 | ||
- | * nicht legal, da sperre auf x doppelt vergeben wird | ||
- | * => Nicht legal | ||
- | S2 | ||
- | * => Legal | ||
- | * => Nicht 2PL, da T1 nach U1(x) noch L1(y) anfordert | ||
- | * => s2 ist serialisierbar, | ||
- | * | ||
- | S3 | ||
- | * Unlock von T1 nicht atomar => kein striktes 2PL | ||
- | * TODO | ||
- | * | ||
- | S4 | ||
- | * => Legal | ||
- | * => 2PL erfüllt | ||
- | * | ||
- | |||
- | ==== Aufgabe 2 ==== | ||
- | Verklemmung bezgl. Zugriff auf Verschiedene Objekte: | ||
- | - T1 hält x(x) | ||
- | - T1 will x(y) | ||
- | - T2 hält x(y) | ||
- | - T2 will x(x) | ||
- | => Verlemmung, da T1 und T2 gegenseitig warten | ||
- | |||
- | Verklemmung bzgl. Sperrkonversion: | ||
- | T1 und T2 warten gegenseitig, | ||
- | |||
- | Verhungern einer Transaktion auf erforderliche Sperre. | ||
- | |||
- | ^bestehend -> \\ angefordert ^ R ^ X ^ | ||
- | ^ R | (+) | (-) | | ||
- | ^ X | (-) | (-) | | ||
- | |||
- | ^bestehend -> \\ angefordert ^ R ^ U ^ X ^ | ||
- | ^ R | (+) | (-) | (-) | | ||
- | ^ U | (+) | (-) | (-) | | ||
- | ^ X | (-) | (-) | (-) | | ||
- | |||
- | ^bestehend -> \\ angefordert ^ R ^ A ^ X ^ | ||
- | ^ R | (+) | (+) | (-) | | ||
- | ^ A | (+) | (-) | (-) | | ||
- | ^ X | (-) | (-) | (-) | | ||
- | |||
- | |||
- | ^ ^ RX | RUX | RAX | | ||
- | ^ a) | (V) | (V) | (V) | | ||
- | ^ b) | (V) | (X) | (X) | | ||
- | ^ c) | (V) | (X) | (V) | | ||
- | |||
- | ==== Aufgabe 3 ==== | ||
- | ^ ^ R ^ X ^ IR ^ IX ^ RIX ^ | ||
- | ^ R | (+) | (-) | (+) | (-) | (-) | | ||
- | ^ X | (-) | (-) | (-) | (-) | (-) | | ||
- | ^ IR | (+) | (-) | (+) | (+)X| (+)X| | ||
- | ^ IX | (-) | (-) | (+)X| (+)X| (-) | | ||
- | ^ RIX | (-) | (-) | (+)X| (-) | (-) | | ||
- | |||
- | IR-Sperre: tiefere Ebene hat R-Sperre | ||
- | IX-Sperre: tiefere Ebene hat X-Sperre | ||
- | RIX-Sperre: | ||
- | |||
- | a) R-Sperre auf Tutpelebene entspricht IR-Sperre (auf Relationsebene) | ||
- | => Falls es sich um das selbe Tupel handelt, darf die Sperre nicht vergeben werden, sonst schon | ||
- | |||
- | b) | ||
- | * Phantomproblem: | ||
- | * Hierachisches Sperren: Für Aggregartfunktionen R-Sperre auf gesammter Relation anfordern, Einfügen würde IX-Sperre anfordern, die aber nicht gewährt wird. | ||
- | ==== Aufbau ==== | ||
- | * DB-Anwendung | ||
- | * DBS | ||
- | * DBMS | ||
- | * DB | ||
- | |||
- | | Anwendungen (mehrere) | ||
- | ^ | ||
- | ^ | ||
- | ^ Konzeptionelle Ebene | | | ||
- | ^ | ||
- | ^ | ||
- | ===== Probeklausur 1/2 ===== | ||
- | ==== Aufgabe 1 ==== | ||
- | * Falsch \\ Die Knoten sind die Transaktionen | ||
- | * Wahr | ||
- | * Wahr \\ mindestens alles was ich | ||
- | * Fals \\ Das währe FOCC | ||
- | |||
- | ==== Aufgabe 2 ==== | ||
- | === a) === | ||
- | Zyklus in Graph => Es liegen verklemmungen vor | ||
- | |||
- | === b) === | ||
- | * Jüngere TA hält Sperre \\ => ältere TA " | ||
- | * Ältere TA hält Sperre \\ => jüngere TA " | ||
- | |||
- | * L1(y) => T3 wird zurückgesetzt | ||
- | * L2(z) => T2 wartet | ||
- | * L1(x) => T2 wird zurückgesetzt | ||
- | * L3(x) => T3 bereits zurückgesetzt | ||
- | |||
- | => T1 kommt durch | ||
- | |||
- | === c) === | ||
- | * Jüngere TA hält Sperre \\ => ältere TA " | ||
- | * Ältere TA hält Sperre \\ => ältere TA " | ||
- | |||
- | * L1(y) => T1 wartet | ||
- | * L2(z) => T2 wird zurückgesetzt | ||
- | * L1(x) => T1 wartet bereits auf die Freigabe von y | ||
- | * L3(x) => T3 bekommt sperre, da T2 zurückgesetzt wurde und T1 noch auf die Freigabe von y wartet (nicht so weit kam sich x zu schnappen) | ||
- | |||
- | => T3 & T1 kommen durch | ||
- | |||
- | ==== Aufgabe 3 ==== | ||
- | T2,T3,T5,T4,T1 | ||
- | |||
- | ==== Anforderungen ==== | ||
- | * **Integration** // | ||
- | * **Operationen** auf den Daten (ändern, löschen, ...) | ||
- | * **Data Dictionary** Schema anschauen | ||
- | * **Benutzersicheten** views | ||
- | * **Konsistenzüberwachung** bei Änderung | ||
- | * **Zugriffskontrolle** | ||
- | * **Transaktionen** | ||
- | * **Synchronisation** (Mehrbenutzersystem) | ||
- | * **Datensicherung** | ||
- | |||
- | * Datensystem (deskriptive Anfragen, Mengenzugriffe) | ||
- | * Zugriffssystem (Satzzugriffe) | ||
- | * Speichersystem (Seitenzugriffe) | ||
- | * DB (Blocktransfer) | ||
- | |||
- | Neben an: | ||
- | * Transfermanagement??? | ||
- | * Metadatenverwaltung | ||
- | |||
- | Drüber: | ||
- | * Anwendung | ||
- | * | ||
- | |||
- | ===== Übung 4 ===== | ||
- | ==== Aufgabe 1 ==== | ||
- | === a) === | ||
- | Loggranulat <= Sperrgranulat, | ||
- | === b) === | ||
- | Einbringstrategien | ||
- | * direktes Einbringne (??? | ||
- | * Geänderte Werte werden auf ihre ursprüngliche Position zurückgeschrieben. d.h. Schreibe ist gleichzeitig Einbringen i.d. DB | ||
- | * | ||
===== ACID ===== | ===== ACID ===== | ||
* Atomic (Wenn, dann wird man als ganzes abgebrochen) | * Atomic (Wenn, dann wird man als ganzes abgebrochen) | ||
Line 244: | Line 8: | ||
* Isolation (Man muss sich aleine fühlen) | * Isolation (Man muss sich aleine fühlen) | ||
* Durability (Abgeschlossene Transaktionen sind von dauer) | * Durability (Abgeschlossene Transaktionen sind von dauer) | ||
- | * | ||
- | |||
uni/8/dbs2/start.1433859843.txt.gz · Last modified: 2020-11-18 18:10 (external edit)