• Transaktion
  Folge von Aktionen (read/write) die die DB von einem konsistenten Zustand in einen anderen Konsistenten Zustand überführt.
• Hauptaufgabe der Transaktionen - Verwaltung
  • Synchronisation (Koordination von mehreren Benutzerproxessen ⇒ Logische Einbenutzerbetrieb)
  • Recovery (Behebung von Fehlersituationen)
• Eigenschaften von Transaktionen (ACID-Prinzip)
  • Atomicy (Atomarität: EffektTransaktion trifft ganz oder gar icht in ???)
  • Consistency (Konsistenz/Integritätserhaltung: Konsistenter Zustand ⇒ Konsistenter Zustand)
  • Isolation (Isoliertheit: Logischer Einbenutzerbetrieb)
  • Durability (Dauerhaftigkeit, Persistenz)
• Schedule
  Folge von Aktionen (read/write) für eine Menge $\{T_1, \ldots, T_n\}$ von Transaktionen, die durch Mischen der Aktionen der Transaktionen entsteht, wobei die Reihenfolge innerhalb der Transaktionen beibehalten wird.
• Serieller Schedule
  Schedule S von $\{T_1, \ldots, T_n\}$, 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 $\{T_1, \ldots, T_n\}$, der die selbe Wirkung hat, wie ein belibiger serieller von $\{T_1, \ldots, T_n\}$ ⇒ Nur serialisierbarer Schedules dürfen zugelassen werden!

Mögliche Abhängigkeiten

• rw
• wr
• ww

Für $S_1$ $T_1$ = (r(v), w(v)) $T_2$ = (w(x), w(w), r(v)) $T_3$ = (w(z), r(y), w(x)) $T_4$ = (r(w), r(z), W(y))

⇒ Gleiche Tranasktions- & Aktionsmenge!

Abhängigkeiten:

• $S_1$: $rw_{4,2}(w), wr_{1,2}(v), wr_{3,4}(z), ww_{2,3}(x), rw_{3,4}(y)$
• $S_2$: $rw_{4,2}(w), wr_{1,2}(v), ww_{2,3}(x), rw_{4,3}(z), rw_{3,4}(y)$

⇒ $S_1$ & $S_2$ sind nicht Konfliktäquivalent!

⇒ Gleiche Tranasktions- & Aktionsmenge!

Abhängigkeiten:

• $S_1$: $rw_{4,2}(w), wr_{1,2}(v), wr_{3,4}(z), ww_{2,3}(x), rw_{3,4}(y)$
• $S_3$: $wr_{3,4}(z), wr_{1,2}(v), ww_{2,3}(x), rw_{4,2}(w), rw_{3,4}(y)$

⇒ $S_1$ & $S_2$ sind Konfliktäquivalent!

Serialisierungs-/Abhängigkeitsgraph:

• 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

• a): Lost Update $S(r_1(x), w_2(x), w_1(x))$
  ⇒ Änderungen einer Transaktion werden durch eine andere Transaktion überschrieben und gehen verloren.
• b): Dirty Read/Write: $S(w_1(x), r_2(x), w_1(x))$
  ⇒ Zugriff auf “Schmutzige” Daten ⇒ Objekte, die von einer noch nicht beendenen Transaktion geändert werden
• c): Non-Repeatable Read: $S(r_1(x). w_2(x), r_1(x)$
  ⇒ Transaktion liest unterschiedliche Werte des selben Objekts

⇒ Annomalien können nur auftreten, wenn Isolation verletzt wird!

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, die man nicht hat

• 2-Phasen-Sperrprotokoll (2PL):
  1. Wachstumsphase (lock)
  2. 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, da keine Abhängigkeiten zu T1 & T2!

S3

• Unlock von T1 nicht atomar ⇒ kein striktes 2PL
• TODO

S4

• ⇒ Legal
• ⇒ 2PL erfüllt

Verklemmung bezgl. Zugriff auf Verschiedene Objekte:

1. T1 hält x(x)
2. T1 will x(y)
3. T2 hält x(y)
4. T2 will x(x)

⇒ Verlemmung, da T1 und T2 gegenseitig warten

• DB-Anwendung
• DBS
  • DBMS
  • DB

• Integration einheitlicher Zugriff auf alle Daten einer Anwendung
• 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

• Atomic (Wenn, dann wird man als ganzes abgebrochen)
• Consistency (Konsistenter Zystand → Konsistenter Zustand)
• Isolation (Man muss sich aleine fühlen)
• Durability (Abgeschlossene Transaktionen sind von dauer)

Non-repeatable read mit Aggregiertem read

Graph Zeichen

• Knoten: Transaktionen
• Kanten: Abhängigkeiten

Kein rr(x)

Zyklenfrei? ⇒ Serialisierbar durch topologisches sorieren

• Pessimistische Ablaufsteuerung (Locking)
• Optimistische Ablaufsteuerung (Zeitstempelverfahren)
  Notfalls rollback