3.4 KiB
!7-TM.pdf
Wie macht ein DBMS aus mehreren Operationen eine verlässliche Arbeitseinheit?
Concurrency Control für parallelismus Recovery für fehlerbehebung durch revert
Transaktion ist eine Folge von Operationen die als logische Einheit behandelt wird Nach außen zählen keine Zwischenschritte! Entweder gelingt Transaktion oder sie wird verworfen!
ACID Eigenschaften
A - Atomicity
Transaktion wird vollständig durchgeführt oder verworfen
C - Consistency
Transaktion führt von konsistentem Zustand wieder in konsistenten Zustand!
I - Isolation
Jede Transaktion erscheint als laufe sie alleine im System
D - Durability
Commit speichert dauerhaft und ist resistent gegen Systemfehler
Anomalien
Lost update
!
Dirty Read
!
Non-Repeatable Read
!
Phantom Read
!
Schedules und Serialisierbarkeit
Schedule ist globale Reihenfolge von Read, Write, Commit, Abort Serialisierbar ist wenn eine Schedule äquivalent zu einer seriellen (hintereinanderausführung) ist. Serialisierbarkeit fragt, ob ein möglicherweise verzahnter Schedule dieselbe Wirkung hat wie einer der seriellen Referenzabläufe.
!
Konfliktserialisierbarkeit
Kritische Operationen heißen Konflikte Operationen pi(x) und qj(y) stehen in Konflikt wenn:
- i
\not =j - x = y
- mindestens eine Operation schreibt
!
!
!
!
Fehlersicherheit und Recoverability
Eine Transaktion soll nicht committen, solange sie von noch unbestätigten Daten abhängt!
RC - Recoverable
Wenn Ti von Tj liest und Ti committed, MUSS Tj vorher committen!
ACA - Avoiding Cascading Aborts
Die Quelle eines gelesenen Werts MUSS VOR DEM LESEN bereits committed haben.
ST - Striktheit
Nach einem Schreibzugriff von Tj darf Ti erst lesen oder schreiben, wenn Tj beendet ist!
Scheduler & Sperrprotokolle
!
Sperren
!
!
2-Phasen-Sperrprotokoll 2PL
Nach der ersten Freigabe dürfen KEINE NEUEN Sperren angefordert werden!!!
C2PL Konservatives 2PL
Alle benötigten Sperren müssen VOR der ersten Operation auf Daten angefordert werden!
S2PL / SS2PL Strenges 2PL
- S2PL = Alle SCHREIBSPERREN erst NACH Commit/Abort freigeben!!!
- SS2PL = ALLE SPERREN erst NACH Commit/Abort freigeben!!!
SQL - Isolationsebene
!
!
!
Recovery Grundlagen
Recovery-relevante Aktion sequentiell append-only auf stabilem Speicher protokollieren!!
Committed vor dem Crash: REDO subaruuuuuuu Noch aktiv beim Crash: UNDO
!
Das Log muss FRÜHER dauerhaft speichern als Datenbank
Checkpoints im Log um suche zu verkürzen!
ARIES
Algorithm for Recovery and Isolation Exploiting Semantics
- Analyse - Scanne ab checkpoint - aktive Transaktionen = loser - REDO start bestimmen
- REDO - Scanne Log - Wende After Images an - Wiederhole auch loser Effekte
- UNDO - Scanne rückwärts nach losern - Updates rückgängig machen - UNDO protokollieren