67 lines
1.7 KiB
Markdown
67 lines
1.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
|
|
|
|
|
|
|