theo/hwr-notes

Fork 0

mirror of https://github.com/theoleuthardt/hwr-notes.git synced 2026-06-06 01:21:09 +00:00

theoleuthardt 850aa3455d docs: add obsidian hwr docs

2026-04-09 11:24:56 +02:00

11 KiB

Raw Blame History

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
Atomicity (Atomarität)	Entweder alle Befehle oder gar keine werden ausgeführt
Consistency (Konsistenz)	Transaktion hinterlässt nach Beendigung einen konsistenten Datenzustand, ansonsten komplettes Zurücksetzen
Isolation	Nebenläufige Transaktionen beeinflussen sich nicht gegenseitig; jede wird logisch so ausgeführt, als wäre sie die einzig aktive
Durability (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:

Lost Update
Dirty Read
Non-Repeatable Read
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