X - Michael Gamer

Datenbanken
Mehrbenutzerbetrieb
Michael Gamer / 2015
Mehrbenutzerbetrieb
Michael Gamer
2
getrennte Dateien
Datenbank
Kunden
oft unkritisch
Lieferanten
Michael Gamer
3
gleiche Dateien
Datenbank
Kunden
kann kritisch sein
Lieferanten
Michael Gamer
4
gleicher Datensatz
Datenbank
Kunden
Müller
sollte unkritisch sein
Maier
Schulze
Michael Gamer
kritisch!
5
Mehrbenutzerbetrieb
Heutige Datenbanken werden meist von mehreren
Anwendern (gleichzeitig) genutzt. Dies erzeugt
unterschiedliche Probleme
‣ gleichzeitiger Zugriff mehrerer Nutzer auf eine Datei
‣ gleichzeitiger Zugriff auf einen Datensatz in der Datei
Auswirkungen können sein
‣ Inkonsistenzen im Datenbestand
‣ Widersprüchliche Anforderungen an das DBMS
Zur Behandlung derartiger Probleme wird der Begriff der
Transaktion eingeführt
Michael Gamer
6
Transaktionen
Zur Beschreibung und Lösung derartiger Probleme
verwendet man den Transaktionsbegriff. Nach
Kemper versteht man unter einer Transaktion:
DieBündelungmehrererDatenbankopera5onen
dieineinemMehrbenutzersystemohne
unerwünschteEinflüßedurchandere
Transak5onenalsEinheitfehlerfrei
durchgeführtwerdensollen
Michael Gamer
7
Beispiel: Transaktion
Überweisung eines Geldbetrags (100€) von Konto A
auf Konto B. Hierzu sind folgende Schritte notwendig:
‣ Lese Kontostand von Konto A: lese(KA,A)
‣ Vermindere den Betrag um 100€: betrag:=KA-100
‣ Schreibe den neuen Kontostand auf Konto A:
schreibe(betrag,A)
‣ Lese Kontostand Konto B: lese(KB,B)
‣ Erhöhe den Betrag um 100: betrag = KB+100
‣ Schreibe neuen Kontostand auf Konto B:
schreibe(betrag,B)
Michael Gamer
8
Zeitliche Abfolge
Atomarer Vorgang
Betrag
erhöhen
Betrag
schreiben
Konto B lesen
Konto A lesen
Betrag
vermindern
Betrag
schreiben
Zeit
Im Fehlerfall müssen Transaktionen revidierbar sein!
Michael Gamer
9
Operationen auf Transaktionsebene
Eine Transaktion besteht aus einer Folge elementarer Operationen
(Lese- und Schreiboperationen). Zur Transaktionssteuerung dienen:
‣ BOT (Begin of Transaction)
• Stellt den Anfang einer neuen Transaktion dar
‣ commit
• Beendet eine Transaktion
• Änderungen an der Datenbasis werden festgeschrieben
‣ abort
• Führt zum Transaktionsabbruch
• Das DBMS stellt sicher, daß der Zustand vor BOT hergestellt
wird
Michael Gamer
10
Weitere Möglichkeiten der Transaktionssteuerung
In neueren DBMS auch Befehle die für umfangreichere
Transaktionen wichtig sind
‣ define savepoint Sicherungspunkt, auf den sich die aktuelle
Transaktion zurücksetzen läßt
• Das DBMS muß alle Aktivitäten bis zu diesem Punkt
protokollieren
• Änderungen werden nicht in die Datenbasis geschrieben
• Nach einem abort werden die Änderungen verworfen
‣ backup transaction setzt die aktuelle Transaktion auf den
jüngsten (aktiven) Sicherungspunkt zurück
‣ Diese Befehle stellen hohe Anforderungen an die
Speicherkapazität des Datenbanksystems
Michael Gamer
11
Eigenschaften von Transaktionen
Transaktionseigenschaften werden im ACID-Paradigma zusammengefaßt:
‣ Atomicity
• Transaktionen sind die kleinste nicht mehr zerlegbare Einheit
‣ Consistency
• Eine Transaktion hinterläßt einen konsistenten Datenbestand
• Zwischenzustände beim Abarbeiten einer Transaktion können
inkonsistent sein
‣ Isolation
• nebenläufige Transaktionen beeinflussen sich nicht
‣ Durability
• Änderungen einer abgeschlossenen Transaktion sind dauerhaft
• Abgeschlossene Transaktionen können nur mit einer
kompensierenden Transaktion aufgehoben werden
Michael Gamer
12
Transaktionsprotokolle
Datenbankänderungen durch Transaktionen werden
mit Hilfe von Transaktionsprotokollen aufgezeichnet
‣ Für jeden Transaktionsschritt erfolgt ein separater
Eintrag in das Protokoll
‣ Bei Fehlern während des Datenbankbetriebs
kann die Datenbank so vollständig
wiederhergestellt werden.
‣ Transaktionsprotokolle werden oft (automatisiert)
„an einem sicheren Ort“ aufbewahrt
Michael Gamer
13
Beispiel
Absturz
Transaktion 2 wird
rückgängig gemacht,
Transaktion 1 normal
abgeschlossen
Transaktion 1
Transaktion 2
Zeit
Michael Gamer
14
Zustandsübergänge
Mögliche Zustände einer Transaktion
‣ potentiell
• Eine codierte Transaktion kann in den Zustand aktiv
wechseln
‣ aktiv
• Transaktion ist aktiv
• in Konkurrenz mit anderen aktiven Transaktionen.
Konkurrenz um z.B.
Michael Gamer
๏
Speicher
๏
Rechnerkerne
๏
Drucker
15
Zustandsübergänge
wartend
‣ Die Transaktionsverwaltung kann Transaktionen in einen
Wartezustand versetzen (Grund z.B. Überlast, fehlende
Betriebsmittel...)
‣ wartende Transaktionen werden (nach und nach) wieder
aktiviert
abgeschlossen
‣ Transaktion wurde durch den commit Befehl
abgeschlossen
‣ Die Wirkung der Transaktion wird nicht sofort in der
Datenbank festgeschrieben, zuvor Prüfung auf verletzte
Konsistenzbedingungen
Michael Gamer
16
Zustandsübergänge
persistent
‣ Wirkung der Transaktion wurde in den Datenbestand
geschrieben
gescheitert
‣ Transaktion konnte nicht abgeschlossen werden
wiederholbar
‣ Bei wiederholbaren Transaktionen werden vor Start der
Wiederholung die Wirkungen auf die Datenbasis
zurückgesetzt
aufgegeben
‣ Zurücksetzung der Wirkungen der Transaktion und versetzen
der Transaktion in den Endzustand aufgegeben
Michael Gamer
17
Zustandsübergangsdiagramm
potentiell
Inkarnation
aktivieren
beenden
aktiv
wartend
verdrängen
abgeschlossen
neustarten
abbrechen
festschreiben
wiederholbar
erfolglos
zurücksetzen
persistent
abbrechen
aufgegeben
in Anlehnung an Kemper
Michael Gamer
18
Serialisierbarkeit
Aus der Forderung des ACID-Prinzips der Isoliertheit
einer Transaktion leitet sich die Anforderung der
Serialisierbarkeit von Transaktionen ab:
‣ Das Ergebnis zweier Transaktionen T1 und T2 auf
einen Datenbestand soll identisch sein,
unabhängig davon, ob die Transaktionen
gleichzeitig under hintereinander ausgeführt
werden
Michael Gamer
19
Serialisierbarkeit
Die Synchronisation von Transaktionen wird mit dem
Begriff serialisierbar beschrieben.
Dazu wird eine Menge von Transaktionen betrachtet die
(gleichzeitig) und zum Teil parallel laufen
Ein System parallel ablaufender Transaktionen heißt
serialisierbar, wenn das Ergebnis der Transaktionen äquivalent
zu einer seriellen Ausführung der Transaktionen ist
Michael Gamer
20
Beispiel
T1 : Transaktion 1
T2 : Transaktion 2
x, y, z… Datenobjekte
Operationen
r1(x):
lese x
mod1(x) ändere(x)
w2(x): schreibe x
Operationen
r2(x):
lese x
mod2(x) ändere(x)
w2(x): schreibe x
T1 : r1(x),mod1(x),w1(x)
T2 : r2(x),mod2(x),w2(x),r2(y),mod2(y),w2(y)
Michael Gamer
21
Schedules (Abläufe)
Festgelegte, geordnete Abläufe von
Datenbankoperationen (Transaktionen) werden als
Schedules bezeichnet
‣ Schedules heißen seriell, wenn die Transaktionen
hintereinander ausgeführt werden
‣ Schedules heißen serialisierbar, wenn das
Gesamtergebnis äquivalent zu einem seriellen
Ergebnis ist
Michael Gamer
22
Beispiel seriell, serialisierbar
S2
S1
T1
T1
1
r1(x)
1
2
w1(x)
2
3
r2(x)
3
4
w2(x)
4
seriell
Michael Gamer
T2
T2
r1(x)
r2(y)
w1(x)
w2(y)
serialisierbar
23
Konflikte
Datenbankoperationen stehen in Konflikt, genau
dann, wenn:
‣ sie gehören zu unterschiedlichen Transaktionen
‣ sie greifen auf das selbe Datenobjekt zu
‣ mindestens ein Zugriff erfolgt schreibend
Michael Gamer
T1
T2
1
r1(x)
r2(y)
O.K.
2
r1(x)
w2(x)
Konflikt
3
w2(x)
w2(y)
O.K.
24
Konfliktäquivalenz
Zwei Abläufe S1 und S2 heißen konfliktäquivalent,
genau dann wenn,
‣ die Reihenfolge aller in Konflikt stehenden
Aktionen ist in beiden Abläufen gleich
Michael Gamer
25
Beispiel 1
Transaktionen:
Schedules:
T1: r(x), w(x), r(y), w(y)
S1: r1(x), w1(x), r1(y), w1(y), r2(x), w2(x)
T2: r(x), w(x)
S2: r1(x), r2(x), w1(x), r1(y), w2(x), w1(y)
S3: r1(x), w1(x), r2(x), w2(x), r1(y), w1(y)
Die TransaktionenS1 und S2 sind nicht
konfliktäquivalent, da die Reihenfolge der in
Konflikt stehenden Schreiboperationen nicht
identisch ist.
Michael Gamer
26
Beispiel 2
S1
S2
1
r1(x)
r1(x)
2
w1(x)
r2(x)
3
r1(y)
w1(x)
4
w1(y)
r1(y)
5
r2(x)
w2(x)
6
w2(x)
w1(y)
Michael Gamer
Konflikte
Die TransaktionenS1
und S2 sind nicht
konfliktäquivalent, da
die Reihenfolge der in
Konflikt stehenden
Schreiboperationen
nicht identisch ist.
27
Konfliktgraphen
Sei S eine Menge von Schedules. Dann ist durch C(S),
eine Reaktion auf SxS definiert:
‣ C(S):= {(p,q) |
• (p und q stehen in Konflikt) &
• (p steht in S vor q) &
• p,q gehören nicht zu einer abgebrochenen
Transaktion}
‣ Das Paar (p,q)∈C(S) kann als Kante in einem
Graphen mit der Knotenmenge S interpretiert werden
‣ Der so entstandene Graph heißt Konfliktgraph von S
Michael Gamer
28
Aussagen über Konfliktgraphen
Für eine gegeben Menge von Transaktionen S sei
G(S) der Konfliktgraph von C(S). Dann gilt
Ein Ablauf in S ist genau dann serialisierbar, wenn der
zugehörige Konfliktgraph keinen Zyklen enthält.
Michael Gamer
29
Probleme im Mehrbenutzerbetrieb
Lost Update Problem
‣ Ursache: zwei Transaktionen greifen gleichzeitig
auf denselben Datensatz zu und aktualisieren zu
unterschiedlichen Zeitpunkten.
‣ Das Problem tritt in der Regel im
Mehrbenutzerbetrieb auf
‣ ggf. Kollision mit Benutzerrechten möglich
Michael Gamer
30
Lost Update Problem
commit
Wohnort=“Bonn“
Wohnort auslesen
Transaktion 2
commit
Wohnort=“Berlin“
Wohnort auslesen
Michael Gamer
Transaktion 1
31
Das „Dirty Read“ Problem
Sollte eine Transaktion Daten lesen, die von einer
anderen Transaktion geändert, aber nicht korrekt
abgeschlossen wurde, so kommt es zum sogenannten
„Dirty Read“
Die Transaktion nimmt dabei Änderungen an Daten vor,
die inkonsistent oder sogar nicht mehr vorhanden sind.
Lösung:
‣ Die Datenbank (bzw. das DBMS) darf nur konsistente
Daten zurückgeben
‣ Solange Daten bearbeitet werden, darf keine andere
Transaktion auf diese zugreifen
Michael Gamer
32
Dirty Read
Transaktion 1
Transaktion 2
Lese Summe
(Summe = 10000)
Summe = Summe -5000
Update Data
Lese Summe
(Summe = 5000)
⚡Crash⚡
Rollback
Lese Summe
(Summe = 0)
Michael Gamer
Summe = Summe -5000
Update Data
33
Das Phantomproblem
Das sogenannte Phantomproblem tritt auf, wenn
während der Abarbeitung einer Transaktion eine
andere Transaktion einen neuen Datensatz in die
Datenbank einfügt
Transaktion 1
Transaktion 2
Berechne Summe aller Konten
Einfügen neues Konto
Kontostand = 1000
Berechne Summe aller Konten
Michael Gamer
34
Nonrepeatable Read
Liest eine Transaktion mehrmals den gleichen
Datensatz aus und werden dabei zwischenzeitlich
Daten an diesem Datensatz geändert führen die
Lesevorgänge zu inkonsistenten Daten.
‣ Solche Probleme können im Mehrbenutzerbetrieb
immer auftreten
‣ Die Ursache liegt nicht allein in der Struktur von
Transaktionen oder der Datenbankstruktur
Michael Gamer
35
Sperrmechanismen
Zur Vermeidung der erwähnten Probleme kommen
verschiedene Sperrmechanismen für Datenbanken zur
Anwendung
‣ Sperrung auf Datenbankebene
• Wirkung: die gesamte Datenbank ist für alle anderen
Nutzer gesperrt
• Vorteil: Einfach zu realisieren
• Nachteil: Mehrbenutzerbetrieb unter Umständen kaum
noch möglich.
• Sinnvoll, falls extrem kritische Operationen
durchgeführt werden müssen (z.B. strukturelle
Anpassungen an der Datenbank)
Michael Gamer
36
Sperrmechanismen
Sperren auf Tabellenebene
‣ Sperren einer einzelnen Tabelle der Datenbank
‣ Transaktionen können nur dann gleichzeitig
ablaufen, wenn Sie nicht auf die gleiche
(gesperrte) Tabelle zugreifen müssen
‣ Nachteil: unter Umständen sind große Teile der
Datenbasis nicht zugänglich, falls „zentrale“
Tabellen gesperrt werden
‣ Vorteil: Einfach zu realisieren
Michael Gamer
37
Sperrmechanismen
Sperren auf Seitenebene (Views)
‣ Wirkung: Sperrt eine „Seite“ des durch das DBMS
verwalteten Datenbanksystems (in der Regel ein
Block von 2n kBytes)
‣ Vorteil: einfach zu realisieren
‣ Sperre wirkt „feiner“ als das Sperren einer ganzen
Tabelle
Michael Gamer
38
Sperrmechanismen
Sperren auf Datensatzebene
‣ Wirkung: sperrte genau den Datensatz, auf den eine
Transaktion zugreift
‣ Transaktionen können ablaufen, sofern diese nicht gleichzeitig
auf ein und denselben Datensatz zugreifen
‣ Nachteil: höherer Verwaltungsaufwand für das DBMS
Sperren auf Feldebene
‣ Sperrt lediglich das Datensatzfeld, welches von der
Transaktion geändert wird.
‣ Vorteil: sehr flexibel
‣ Nachteil: hoher Verwaltungsaufwand (wird in der Praxis
faktisch nicht eingesetzt)
Michael Gamer
39
Sperrtypen
Für das Sperren von Datenbeständen gibt es
unterschiedliche Strategien
‣ binäre Sperren
• besitzen zwei Zustände (offen und gesperrt)
• Nachteil: Bei gesperrten Daten ist selbst das
Lesen nicht mehr möglich, solange die Daten
von einer Transaktion gesperrt werden
Michael Gamer
40
Sperrtypen
‣ exklusive/nichtexklusive Sperren
• Derartige Sperren sind mit unterschiedlichen
Rechten versehen
• exklusive Sperre (lockX: lock exclusive)
๏
Wirkung wie eine binäre Sperre im Status gesperrt
• nicht exklusive Sperre (lockS: lock shared)
๏
lediglich Schreibzugriffe sind gesperrt
๏
das Objekt kann jedoch gelesen werden
• Problem derartiger Sperrtypen: Es können
Deadlocks auftreten
Michael Gamer
41
Deadlockproblem
Transak'on1
Transak'on2
Bemerkung
BOT
lockX(A)
BOT
lockS(B)
read(A)
read(B)
write(A)
⚡T1 wartet auf T2⚡
lockX(B)
lockS(A)
Michael Gamer
⚡T2 wartet auf T1⚡
42
Verträglichkeit von Sperren
Die Verträglichkeit der unterschiedlichen Sperrmodi
wird durch die Verträglichkeitsmatrix (auch
Kompatibilitätsmatrix) geregelt
NL
S
X
S
✓
✓
✖
X
✓
✖
✖
S: Shared, X: Exklusive, NL: offen (no lock)
Michael Gamer
43
Zwei Phasen Sperrprotokoll
Die Serialisierbarkeit von Transaktionen ist durch das Zwei-PhasenSperrprotokoll (2PL) gewährleistet:
‣ Jedes Objekt, das von einer Transaktion verwendet werden soll
muß zuvor gesperrt werden.
‣ Eine Transaktion fordert Sperren, die sie bereits besitzt nicht
nochmals an.
‣ Transaktionen beachten Sperren anderer Transaktionen gemäß
der Verträglichkeitstabelle
‣ Jede Transaktion durchläuft zwei Phasen
• Wachstumsphase: Anfordern von Sperren
• Schrumpfungsphase: Sperren werden freigegeben und keine
weiteren angefordert
‣ Am Ende einer Transaktion gibt diese alle ihre Sperren wieder frei
Michael Gamer
44