125 lines
3.4 KiB
Markdown
125 lines
3.4 KiB
Markdown
![[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
|
|
![[Pasted image 20260723182328.png]]
|
|
|
|
#### Dirty Read
|
|
![[Pasted image 20260723182339.png]]
|
|
|
|
#### Non-Repeatable Read
|
|
![[Pasted image 20260723182355.png]]
|
|
|
|
#### Phantom Read
|
|
![[Pasted image 20260723182412.png]]
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
![[Pasted image 20260723183028.png]]
|
|
|
|
## Konfliktserialisierbarkeit
|
|
|
|
Kritische Operationen heißen Konflikte
|
|
Operationen pi(x) und qj(y) stehen in Konflikt wenn:
|
|
1. i $\not =$ j
|
|
2. x = y
|
|
3. mindestens eine Operation schreibt
|
|
![[Pasted image 20260723183301.png]]
|
|
![[Pasted image 20260723183353.png]]
|
|
![[Pasted image 20260723183402.png]]
|
|
![[Pasted image 20260723183537.png]]
|
|
|
|
|
|
## 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
|
|
![[Pasted image 20260723185054.png]]
|
|
|
|
### Sperren
|
|
![[Pasted image 20260723185118.png]]
|
|
![[Pasted image 20260723185131.png]]
|
|
|
|
#### 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
|
|
![[Pasted image 20260723185542.png]]
|
|
![[Pasted image 20260723185549.png]]
|
|
![[Pasted image 20260723185557.png]]
|
|
|
|
|
|
|
|
## Recovery Grundlagen
|
|
|
|
Recovery-relevante Aktion sequentiell append-only auf stabilem Speicher protokollieren!!
|
|
|
|
Committed vor dem Crash: REDO subaruuuuuuu
|
|
Noch aktiv beim Crash: UNDO
|
|
|
|
![[Pasted image 20260723185939.png]]
|
|
|
|
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
|
|
|
|
1. Analyse - Scanne ab checkpoint - aktive Transaktionen = loser - REDO start bestimmen
|
|
2. REDO - Scanne Log - Wende After Images an - Wiederhole auch loser Effekte
|
|
3. UNDO - Scanne rückwärts nach losern - Updates rückgängig machen - UNDO protokollieren
|
|
|
|
|
|
|