![[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