# Transaktionen – Zusammenfassung
**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–31**

---

## 1. Definition (Folien 1–2)

### Integrität und Transaktionen

**Integrität (Konsistenz)** der Datenbank = Zustand der Daten, in dem sie **korrekt, vollständig und widerspruchsfrei** sind.

**Transaktion** = Mehrere Operationen, die:
- Entweder **alle erfolgreich** durchgeführt werden
- Oder, falls ein Fehler vorliegt, die schon durchgeführten **rückgängig gemacht** werden müssen

### Eigenschaften

- Transaktionen gewährleisten einen **konsistenten Zustand** der Datenbank
- Sie versetzen den Datenbestand von einem konsistenten Zustand in einen **anderen konsistenten Zustand**
- Eine Transaktion wird als **atomare (ununterbrechbare) Operation** betrachtet
- Bei Fehlern werden Komponenten nicht rückgängig gemacht (zeitintensiv), sondern der **zuvor gespeicherte Zustand** wird wiederhergestellt

---

## 2. Beispiel (Folie 3)

Zwei ganze Zahlen A und B (Datenbestand):

```
T1 = { A=A+100; B=B+100; }
T2 = { A=A*2;   B=B*2;   }
```

- **Sequenzielle Ausführung** → Konsistenz gewährleistet
- **Gemischte Operationen** → Konsistenz **nicht** mehr gewährleistet

---

## 3. Anforderungen (Folien 4–5)

### Allgemeine Anforderungen (Folie 4)

| Anforderung | Beschreibung |
|---|---|
| Gleichzeitige Verarbeitung | Mehrere Transaktionen müssen **quasi-parallel** verarbeitet werden |
| Fehlerbehandlung | Abgeschlossene Transaktionen bleiben bestehen, offene werden rückgängig gemacht |
| Organisation | Manuell (im Source-Code) oder automatisch |
| Zwischenpunkte | Daten erfolgreich durchgeführter Operationen können gespeichert werden |
| Abschlussarten | Nur **COMMIT** (erfolgreich) oder **ROLLBACK** (erfolglos) |

**Gründe für ROLLBACK:** Systemfehler, Integritätsverletzungen, Deadlock, Benutzeranweisung.

### ACID-Eigenschaften (Folie 5)

| Eigenschaft | Beschreibung |
|---|---|
| **A**tomicity (Atomarität) | Entweder **alle** Befehle oder **gar keine** werden ausgeführt |
| **C**onsistency (Konsistenz) | Transaktion hinterlässt nach Beendigung einen **konsistenten Datenzustand**, ansonsten komplettes Zurücksetzen |
| **I**solation | Nebenläufige Transaktionen beeinflussen sich **nicht gegenseitig**; jede wird logisch so ausgeführt, als wäre sie die einzig aktive |
| **D**urability (Dauerhaftigkeit) | Wirkung einer erfolgreich abgeschlossenen Transaktion bleibt **dauerhaft** erhalten, auch nach Systemfehler |

---

## 4. Zustände einer Transaktion (Folie 6)

```
BoT → Active → Committing → Änderungen festgeschrieben → EoT
         ↓          ↓
    Waiting for   ERROR
    resources       ↓
         ↓      Rolling back → Änderungen rückgängig gemacht → EoT
      DEADLOCK
         ↓
    ROLLBACK → Rolling back
```

| Zustand | Beschreibung |
|---|---|
| **BoT** | Begin of Transaction |
| **Active** | Transaktion führt Operationen aus |
| **Waiting for resources** | Wartet auf gesperrte Ressourcen |
| **DEADLOCK** | Gegenseitige Blockierung erkannt |
| **Committing** | Änderungen werden festgeschrieben (COMMIT) |
| **Rolling back** | Änderungen werden rückgängig gemacht (ROLLBACK) |
| **EoT** | End of Transaction |

---

## 5. Synchronisation (Folien 7–8)

### Definition

**Synchronisation (Mehrbenutzersynchronisation)** = Koordinierung von mehreren Benutzerprozessen, eng verbunden mit der Ausführung der Transaktionen.

### Ausführungsarten

| Art | Beschreibung | Eigenschaft |
|---|---|---|
| **Seriell** | Transaktionen nacheinander | Absolut sicher, aber **langsam**; blockiert nachfolgende Transaktionen |
| **Parallel** | Transaktionen gleichzeitig | Nutzt Ressourcen **besser** aus |
| **Serialisierung** | Anordnung paralleler Operationen | Entspricht in der Wirkung der seriellen Ausführung, garantiert Konsistenz |

---

## 6. Probleme bei paralleler Ausführung (Folien 9–26)

### Übersicht (Folie 10)

Bei Zugriff auf **denselben Datenbestand** können folgende Probleme entstehen:
1. **Lost Update**
2. **Dirty Read**
3. **Non-Repeatable Read**
4. **Phantom Read**

Diese Probleme können durch **Isolation** (verschiedene Sicherheitsstufen) vermieden werden.

### Isolationsstufen – allgemein (Folie 11)

- Die Isolationsstufe betrifft den **Schreibvorgang nicht** – eine Transaktion bekommt immer eine **exklusive Sperre** für alle zu ändernden Daten
- Die Isolationsstufe wirkt auf die **Lesevorgänge** – definiert, wie Lesevorgänge von anderen Transaktionen abhängig sind

### 6.1 Lost Update (Folien 12–17)

**Problem:** Die von einer Transaktion geänderten Daten werden von einer anderen Transaktion überschrieben.

**Variante 1 – Direkt (Folie 12):**
```
T1: update TabX set V=42;       T2: ...
T1: ...                          T2: update TabX set V=53;
T1: ...                          T2: commit;
T1: commit;                      T2: ...
```
→ Update von T2 geht verloren. Kommt in Datenbanken **nicht vor**, da T2 auf Freigabe wartet.

**Variante 2 – Über lokale Variable (Folie 13):**
```
T1: select V from TabX into W;  T2: ...
T1: W := W+1;                   T2: update TabX set V=53;
T1: update TabX set V=W;        T2: commit;
T1: commit;                     T2: ...
```
→ Update von T2 geht verloren. Kann durch **höhere Isolationsstufe** vermieden werden.

**Lösung:** `SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;`
- Die Transaktion merkt sich die Daten, die zum **Start der Transaktion** festgeschrieben waren
- Ändert eine andere Transaktion diese Daten, bricht die erste ab
- Fehler: `ORA-08177: can't serialize access for this transaction`

### 6.2 Dirty Read (Folien 18–19)

**Problem:** Eine Transaktion liest Daten, die eine andere Transaktion geändert, aber **noch nicht festgeschrieben** hat.

```
T1: ...                          T2: update TabX set V=42;
T1: select V from TabX;          T2: ...        ← T1 liest V=42
T1: ...                          T2: rollback;  ← V=42 war ungültig!
```

**Lösung:** Standard-Isolationsstufe in Oracle ist **READ COMMITTED** → verhindert Dirty Read automatisch.

Dirty Read ist nur möglich mit `READ UNCOMMITTED` (in Oracle nicht verfügbar).

### 6.3 Non-Repeatable Read (Folien 20–21)

**Problem:** Eine Transaktion liest **zweimal dieselben Daten** und bekommt **unterschiedliche Ergebnisse**.

```
T1: select V from TabX;         T2: ...
T1: ...                          T2: update TabX set V=42;
T1: ...                          T2: commit;
T1: select V from TabX;          T2: ...        ← anderer Wert!
```

**Lösung:** Isolationsstufe **SERIALIZABLE** (Standard READ COMMITTED lässt dies zu).

### 6.4 Phantom Read (Folie 22–23)

**Problem:** Ähnlich Non-Repeatable Read, aber mit **Anzahl der Zeilen** statt Werten.

```
T1: select count(*) from TabX;  T2: ...
T1: ...                          T2: insert into TabX ...;
T1: ...                          T2: commit;
T1: select count(*) from TabX;   T2: ...        ← anderer Count!
```

**Lösung:** Isolationsstufe **SERIALIZABLE** löst auch dieses Problem in Oracle.

### Trade-off der Isolationsstufen (Folie 24)

| Niedrigere Stufe | Höhere Stufe |
|---|---|
| Erlaubt gleichzeitigen Zugriff | Vermindert Probleme |
| Mehr mögliche Nebenwirkungen | Mehr Systemressourcen |
| Höhere Performance | Höhere Blockierungswahrscheinlichkeit |

### Isolationsstufen nach ANSI/ISO SQL92 (Folien 25–26)

| Isolationsstufe | Verhindert | Besonderheit |
|---|---|---|
| **READ UNCOMMITTED** | — | Dirty Read erlaubt; **fehlt in Oracle** |
| **READ COMMITTED** | Dirty Read | Standard in Oracle; Lesesperren werden kurz gesetzt und aufgehoben |
| **REPEATABLE READ** | Dirty Read, Non-Repeatable Read | Sperren für gesamte Transaktion; **fehlt in Oracle** |
| **SERIALIZABLE** | Dirty Read, Non-Repeatable Read, Phantom Read, Lost Update | Höchste Stufe; keine weiteren schreibenden Transaktionen auf dieselben Daten |

**Hinweis:** Der SQL-Standard schreibt diese Stufen vor, aber konkrete Datenbanken unterstützen sie **unterschiedlich**.

---

## 7. Synchronisationsstrategien (Folie 27)

Der **Scheduler** steuert die Ausführungsreihenfolge von Operationen verschiedener Transaktionen.

| Strategie | Beschreibung |
|---|---|
| **Pessimistisch** | Scheduler **verzögert** Operationen, legt optimale Reihenfolge fest |
| **Optimistisch** | Scheduler schickt Operationen **sofort** zur Ausführung |

---

## 8. Synchronisationsverfahren (Folien 28–30)

### 8.1 Sperrbasierte Synchronisation (Folie 28)

Wird **oft eingesetzt**. Idee:

| Regel | Beschreibung |
|---|---|
| Jedes Datenobjekt hat eine Sperre | Tabelle, Datensatz, Attribut, Index, View |
| Sperren vor Benutzung | Jedes Objekt muss vor Zugriff gesperrt werden |
| Warten bei Sperre | Ist Objekt schon gesperrt, muss die Transaktion warten |
| Exklusivität | Nur **eine** Transaktion kann die Sperre halten |
| **Lesesperre** (shared lock) | Andere Transaktionen dürfen die Daten **lesen** |
| **Schreibsperre** (exclusive lock) | Andere Transaktionen dürfen Daten **weder lesen noch ändern** |
| Sperren aufheben | Am Ende der Transaktion werden **alle Sperren** aufgehoben |

**Löst:** Alle Probleme **außer Phantom Read**.

### 2-Phasen-Sperrprotokoll – 2PL (Folie 29)

| Phase | Beschreibung | Sicherste Variante |
|---|---|---|
| **Wachstumsphase** | Viele Sperren werden **angefordert**, wenige freigegeben | Sperren werden nur **gesetzt**, nicht aufgehoben |
| **Minderungsphase** (Schrumpfphase) | Viele Sperren werden **freigegeben**, wenige angefordert | Sperren werden nur **aufgehoben**, nicht gesetzt |

### 8.2 Zeitstempelbasierte Synchronisation (Folie 30)

Wird **selten eingesetzt**. Idee:

| Regel | Beschreibung |
|---|---|
| Eindeutiger Zeitstempel | Jede Transaktion bekommt einen eindeutigen Zeitstempel |
| Ordnung | Scheduler ordnet konkurrierende Operationen nach Zeitstempel |
| Objektstempel | Zu jedem Datenobjekt wird der Zeitstempel der letzten Operation gespeichert |
| Abweisung | Operation mit **früherem** Zeitstempel als der des Objektes wird **abgewiesen** |
| Reihenfolge | Transaktionen müssen laut Zeitstempelreihenfolge beendet werden |

**Löst:** Alle Probleme **außer Phantom Read**.

---

## Zusammenfassung

| Konzept | Beschreibung |
|---|---|
| **Transaktion** | Atomare Operation: alles oder nichts (COMMIT/ROLLBACK) |
| **ACID** | Atomicity, Consistency, Isolation, Durability |
| **Lost Update** | Überschreiben von Änderungen → SERIALIZABLE |
| **Dirty Read** | Lesen nicht festgeschriebener Daten → READ COMMITTED |
| **Non-Repeatable Read** | Unterschiedliche Leseergebnisse → SERIALIZABLE |
| **Phantom Read** | Geänderte Zeilenanzahl → SERIALIZABLE |
| **Sperrbasiert (2PL)** | Wachstums- und Schrumpfphase, shared/exclusive locks |
| **Zeitstempelbasiert** | Ordnung nach Transaktions-Zeitstempeln |