103 lines
2.7 KiB
Markdown
103 lines
2.7 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]]
|
|
|
|
|
|
|
|
|