19
DBS2 (Subject) / Synchronisation (Lesson)
Advertisement
- Anomalien im Mehrbenutzerbetrieb Lost Update Dirty Read / Write Phantomproblem Non-Repeatable Read
- Lost Update Ablauf: T1 read - T2 read - T2 write - T1 write Änderung von T2 geht verloren Verstoß gegen Durability
- Dirty Read / Dirty Write von T2 gelesener Wert sind nicht mehr gültig (zB T1 bricht update ab) = Dirty Read T2 arbeitet mit Wert und speichert = Dirty Write Verstoß gegen Consistency, Durability
- Non-Repeatable Read T1 liest Wert zweimal, dazwischen ändert T2 den Wert, T1 liest zwei verschiedene Werte Verstoß gegen Isolation
- Phantomproblem Spezialfall von Non-Repeatable Read T1 gibt Datensatz aus und liest danach dessen Größe dazwischen ändert T2 den Datensatz und die Größe stimmt nicht mit der Liste überein
- Allgemeiner Schedule Folge von Aktionen, die durch Mischen der Aktionen der Transaktionen Ti entsteht, wobei die Reihenfolge innerhalb der jeweiligen Transaktion beibehalten wird beliebige Verzahnung -> Performanz
- Serieller Schedule Aktionen der einzelnen Transaktionen werden nicht untereinander verzahnt sondern in Blöcken hintereinander ausgeführt
- Serialisierbarer Schedule Allgemeiner Schedule, der die selbe Wirkung hat, wie ein serieller Schedule
- Abhängigkeiten Schreib-Lese-Anhängigkeit Lese-Schreib-Abhängigkeit Schreib-Schreib-Abhängigkeit
- Konfliktäquivalenz S1, S2 besitzen gleiche Transaktions- und Aktionsmengen (auch selbe Reihenfolge) S1, S2 besitzen gleiche Abhängigkeitsmengen (wr, rw, ww) -> S1 und S2 haben gleiche Wirkung auf DB-Inhalt
- Advertisement
- Serialisierungs-Graph überprüft, ob ein Schedule {T1...Tn} serialisierbar ist = ob ein konfliktäquivalenter serieller Schedule existiert Knoten = Transaktionen gerichtete kante bei wr, rw, ww Kante beschriften mit Anhängigkeit (rwi,j (x)) i,j: Transaktionen - x: Objekt zyklenfrei -> Schedule ist serialisierbar
- Rücksetzbarer Schedule Transaktion darf erst COMMITen, wenn alle Transaktionen von denen sie gelesen hat, ebenfalls COMMITted haben
- Schedule ohne kaskadierendes Rollback um Lawine von Rollbacks zu verhindern Veränderte daten einer noch nicht abgeschlossenen Transaktion dürfen nicht gelesen werden
- Strikter Schedule veränderte Daten einer noch nicht abgeschlossenen Transaktion dürfen nicht überschrieben werden
- Legale Schedules keine Sperre anfordern, die man schon besitzt geeignete Sperre vor Zugriff auf irgendein Objekt Sperren aufheben bei Transaktionende Sperren respektieren
- 2 Phasen Sperrprotokoll Wachstumsphase (Sperren werden angefordert) Schrumpfungsphase (Sperren werden aufgehoben) strikt voneinander getrennt -> Serialisierbarkeit -> kaskadierendes Rücksetzen / kein Rücksetzen möglich Verstoß gegen Dauerhaftigkeit
- Striktes 2-Phasen-Sperrprotokoll Alle Sperren werden bis Commit gehalten
- RX-Sperrprotokoll R X R + - X - - meist in verbindung mit striktem 2PL
- Deadlocks zwei Transaktionen warten gegenseitig auf Freigabe des anderen: T1: X-Sperre auf x, fordert y T2: X-Sperre auf y, fordert x