. Koordination des Mehrbenutzerbetriebs

‰
‰
‰
Benutzer V
Benutzer Z
Q
ES
C
L
JD
B
DB
DBMS
SQ
L
L
Q
S
Benutzer Y
Benutzer X
Seite 321 von 344
Mehrbenutzerbetrieb:
–
Ein DBS bedient gleichzeitig mehrere Benutzer
–
Benutzer arbeiten zwar unabhängig voneinander, können aber die gleiche Relation
oder sogar den gleichen Datensatz bearbeiten!
Aktivität eines Benutzers:
– sequentieller Prozeß
Aktivitäten mehrerer Benutzer:
–
variable Menge von inneinander verzahnt ablaufenden Prozessen
–
gemeinsame Nutzung der Datenbasis
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Seite 322 von 344
Datenbanksystem
– mehrere Elementaroperationen werden miteinander zu einer Einheit verschmolzen.
Der Ablauf dieser Einheit wird eine Transaktion genannt.
–
neue Operationen zur Ablaufsteuerung von Transaktionen
‰
‰
Ein Benutzer möchte eine Buchung von einem Konto A auf ein Konto B vornehmen
können.
Folgende Anforderungen ergeben sich dabei:
–
Eine Buchung sollte nicht teilweise durchgeführt werden.
–
Alle Konsistenzbedingungen sollen nach einer Buchung gewahrt bleiben:
z. B. Kontostände dürfen nicht unter 10000,- fallen
–
Gleichzeitig ablaufende Buchungen dürfen keinen Einfluss haben auf das Ergebnis
dieser Buchung.
–
Eine erfolgreiche Buchung ist auch tatsächlich in der Datenbank wirksam
geworden.
‰
$QZHQGXQJHLQHV'%6.RQWRYHUZDOWXQJ
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
‰
‰
‰
Seite 323 von 344
Elementaroperationen, die sich auf die Datenbasis beziehen
–
Lesen des Werts eines Objekts A in eine Programmvariable a:
read(A,a)
bzw.
r(A)
–
Zuweisung eines Werts einer Programmvariable a an ein Objekt A der Datenbank
write(A, a)
bzw.
w(A)
Elementaroperationen, die keine Auswirkung auf die Datenbasis haben.
Ablaufsteuerung
Anfang einer Transaktion: BOT
Ende der Transaktion:
commit
–
alle in der Transaktion erzeugten Änderungen der Datenbasis werden
festgeschrieben.
Abbruch einer Transaktion: abort
–
alle in der Transaktion vorgenommen Änderungen der Datenbasis werden
unwirksam.
Operationen
7UDQVDNWLRQHQ
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Seite 324 von 344
Eine Transaktion (TA) ist eine Folge von Elementaroperationen. Eine TA erfüllt die
ACID-Bedingungen:
A: TA ist die kleinste, DWRPDUH Ausführungseinheit.
–
Entweder alle durch einen TA vorgenommenen Änderungen werden in der
Datenbasis wirksam oder gar keine.
C: Eine TA überführt einen konsistenten Datenbankzustand in einen anderen
NRQVLVWHQWHQ Datenbankzustand.
–
Innerhalb einer TA sind Inkonsistenzen erlaubt.
I: eine TA ist gegenüber anderen TAs LVROLHUW, d. h. das Ergebnis einer TA kann
nicht direkt durch eine andere TA beeinflusst werden.
–
Jede TA wird logisch so ausgeführt, als gäbe es keine andere TA.
D: ist eine TA einmal erfolgreich abgeschlossen, dann bleibt ihre Wirkung auf die
Datenbasis GDXHUKDIW erhalten.
–
Dies gilt auch im Fall eines Systemfehlers
(LJHQVFKDIWHQYRQ7UDQVDNWLRQHQ
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
‰
‰
Tm
Tm+1
verzahnter
Ablauf der TAs
Ÿ
Einschränkung bei den verzahnten Abläufen
Ÿ Einschränkung bei den verzahnten Abläufe
Zurücksetzen einer oder mehrerer TAs
–
Atomarität
–
Dauerhaftigkeit
Synchronisation der TAs
–
Isolation
Tn
Seite 325 von 344
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
7UDQVDNWLRQVPDQDJHPHQW
TA-Manager
wj(A)
aj
cj
2. Schreiboperation:
3. Abbruch:
4. Commit:
Seite 326 von 344
Für ein Ablauf einer TA Tj gibt es eine Ordnungsrelation <j, welche die sequentielle
Ordnung der Elementaroperationen ausdrückt:
op1 <j op2 : œ
op1 wird vor op2 ausgeführt.
Einzelne Operationen (rj, wj, aj, und cj) werden sequentiell nacheinander ausgeführt:
‰
–
Eine Transaktion Tj wird durch einen Aufruf von aj oder cj beendet:
es gibt keine weitere Operation von Tj, die danach ausgeführt wird.
‰
5. weitere Operationen, die aber auf die Datenbank keine Auswirkung haben.
rj(A)
Transaktion Tj setzt sich aus folgenden Elementaroperationen zusammen:
‰
1. Leseoperation:
Transaktionen: T1, T2, …, Tn
‰
1RWDWLRQ
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Ordnungsrelationen <j der einzelnen Transaktionsabläufe bleiben bewahrt.
‰
‰
Seite 327 von 344
Nicht alle Ausführungspläne erzeugen einen konsistenten Datenbankzustand (siehe
Beispiele)
Verzahnter Ablauf der TAs wird oft auch als parallele Ausführung bezeichnet.
Bemerkungen:
‰ Durch den Ausführungspan H ist eine Ordnungsrelation <H definiert.
–
Seien T1,…,Tn Transaktionen. Dann wird eine Folge H aller Operationen der TAs T1,…,Tn
ein Ausführungsplan genannt, falls folgende Bedingungen erfüllt sind:
–
es gibt nur Elementaroperationen vom Typ rj, wj, aj, cj,
Definition (Ausführungsplan, Historie):
$XVIKUXQJVSODQ+LVWRULH
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
7UDQVDNWLRQW
read(B, b);
b := b + 10;
write(B, b);
read(C, c);
c := c-10;
write(C, c);
commit
7UDQVDNWLRQW
read(A, a);
a := a + 10;
write(A, a);
read(B, b);
b := b-10;
write(B, b);
commit;
=HLW
write(B, b);
commit;
b := b-10;
read(B, b);
a:= a + 10;
write(A, a);
HLQ$EODXI
t1
read(A, a);
c := c-10;
write(C, c);
commit;
read(C, c);
write(B, b);
b := b + 10;
read(B, b);
t2
%HLVSLHO
w2(C);
c2;
w1(B);
c1;
w2(B);
r2(C);
w1(A);
r1(B);
$XVIKUXQJVSODQ
r1(A);
r2(B);
Seite 328 von 344
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Ein Ausführungsplan muss gewisse Kriterien erfüllen, damit die Isolationseigenschaft
garantiert ist. Sonst kann es Probleme geben:
‰ Konsistenz der DB ist i.a. nicht verletzt
‰ Resultate der Anfragen sind nicht “offenkundig falsch”
Seite 329 von 344
‰ Transaktion T1 und T2 erhöhen das Gehalt der Mitarbeiter jeweils um 100,- DM
T2
Ausführungsplan
T1
read(Gehalt, g);
r1(Gehalt);
read(Gehalt, h);
r2(Gehalt);
g := g + 100;
write(Gehalt, g);
w1(Gehalt);
commit;
c1
h := h + 100;
write(Gehalt, h);
w2(Gehalt);
commit;
c2
Problem des “lost update”
‰
6\QFKURQLVDWLRQVSUREOHPH
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Seite 330 von 344
‰ Transaktion T2 ließt somit inkonsistente Daten aus der Datenbank, obwohl die Datenbank
nach T1 wieder in einem konsistenten Zustand ist.
‰ A und B seien zwei Kontostände für die A+B=0 gelten soll.
‰ T1 und T2 sind zwei Transaktionen, wobei T1 ändert und T2 nur vom Konto ließt.
T1
T2
read(A, a);
a := a-1;
write(A, a);
read(A, c);
read(B, d);
commit;
read(B,b);
b := b+1;
write(B,b);
commit;
Problem der inkonsistenten Sicht auf die Datenbank
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
‰ A und B seien im folgenden zwei Kontostände, die stets A = B erfüllen.
T1
T2
read(A, a);
a := a + 10;
write(A, a);
read(A, c);
c := c*1.1;
write(A, c);
read(B, b);
b := b*1.1;
write(B, b);
commit;
read(B, d);
d := d +10;
write(B,d);
commit;
‰ Die Datenbank hat dauerhaft einen inkonsistenten Zustand:
Aneu = (A+10)*1.1 z B*1.1+10 = Bneu
Problem der inkonsistenten Datenbank
Seite 331 von 344
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
‰ strikte, sequentielle Ausführung der Transaktionen
–
Nachteil: schlechte Systemauslastung, lange Wartezeiten
‰ Beschränkung der “Parallelität” auf erlaubte Verarbeitungsreihenfolgen
Seite 332 von 344
Wird T2 nach Schritt 1 von T1 ausgeführt, so ist die Kalkulation von T1 veraltet.
Lösung der Synchronisationsprobleme:
–
‰ Transaktion T1
–
liest die Daten aller Angestellten,
–
berechnet, wieviel Gehaltserhöhung möglich ist,
–
und erhöht das Gehalt.
‰ Transaktion T2 fügt einen neuen Angestellten ein.
Phantom-Problem:
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
4. wi(A) <H wj(A)
2. ri(A) <H wj(A)
3. wi(A) <H rj(A)
Sei T* = {T1,…,Tn} eine Menge von Transaktionen und H ein dazugehörender
Ausführungsplan. Seien Ti und Tj zwei Transaktionen aus T*, die gemeinsam auf ein
Datenobjekt A zugreifen. Es werden nun folgende vier Fälle unterschieden:
1. ri(A) <H rj(A)
Seite 333 von 344
‰ Bemerkungen:
–
nur im 1. Fall sind die Operationen vertauschbar, ohne dass sich das Ergebnis des
Ausführungsplans ändert.
–
in allen anderen Fällen ist davon auszugehen, dass ein Vertauschen der
Ausführungsreihenfolge zu einem anderen Ergebnis führt. Man spricht dann auch
von einem Konflikt.
‰
6HULDOLVLHUXQJYRQ7$V
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
wi(A) <G wj(A)
œ
wi(A) <H wj(A)
Konflikte:
r1(A) <H w2(A)
w1(A) <H r2(A)
–
Seite 334 von 344
Ausführungsplan H = (r1(A),r2(C),w1(A),w2(C),r1(B),w1(B),c1,r2(A),w2(A),c2)
–
‰ Durch Vertauschen von zwei benachbarte Operationen, die nicht in Konflikt zueinander
stehen, kann man sich einen äquivalenten Ausführungsplan erzeugen.
‰ Beispiel:
–
zwei Relationen T1 und T2
wi(A) <G rj(A)
œ
wi(A) <H rj(A)
‰ Definition:
Sei T* = {T1,…,Tn} eine Menge von Transaktionen. Seien H und G zwei dazugehörige
Ausführungspläne. Dann sind H und G äquivalent, falls die Konflikte identisch sind, d.h.
wenn für alle Relationen Ti und Tj und einem beliebigen Datenobjekt A folgende
Bedingungen gelten:
ri(A) <H wj(A)
œ
ri(A) <G wj(A)
bTXLYDOHQ]YRQ$XVIKUXQJVSOlQHQ
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
T1
T2
Beweis: siehe Bernstein, Hadzilacos, Goodman
Seite 335 von 344
Graph G = (K,U) mit Knotenmenge K und Kantenmenge 8 Ž . u .
zu jeder TA gibt es genau einen Knoten
(T1,T2)  U g.d.w. es gibt ein Objekt O, so dass op1(O) <H op2(O) in Konflikt
zueinander stehen.
Ein Ausführungsplan ist genau dann serialisierbar, falls G zyklenfrei ist.
Satz:
–
–
–
‰ Test auf Serialisierbarkeit eines Ausführungsplans.
Serialisierbarkeitsgraph
Ein Ausführungsplan ist serialisierbar, falls es HLQHQ äquivalenten sequentiellen
Ausführungsplan gibt.
Definition (Serialisierbarkeit):
6HULDOLVLHUEDUH$XVIKUXQJVSOlQH
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
‰ bislang verwendete Verfahren:
–
Sperrverfahren
–
Zeitstempel- und Mehrversionsverfahren
Seite 336 von 344
‰ In einem DBS soll stets Serialisierbarkeit garantiert werden
‰ zwei prinzipielle Methoden:
–
verifizierende (“optimistische”) Verfahren:
Beobachte ständig die Ausführungspläne (über den Graph G). Falls
Serialisierbarkeit nicht garantiert ist, setze eine TA zurück und starte sie neu.
–
präventive Verfahren:
Verhindere nicht-serialisierbare Ausführungspläne.
6\QFKURQLVDWLRQVYHUIDKUHQ
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
‰ Jede TA sperrt den Teil der DB, auf dem sie arbeiten will.
–
Solange gesperrt ist, können keine anderen TAs zugreifen
‰ Klassifizierung der Sperrverfahren nach
–
Sperrobjekten: Datensatz, Datenseite, Relation, Datenbank
Beachte:
je feiner die Sperreinheit, desto mehr Parallelität ist möglich
je feiner die Sperreinheit, desto mehr Verwaltungsaufwand
–
Sperrmodi
lock(A)
sperrt das Datenobjekt A
unlock(A)
gibt die Sperre wieder frei
–
Sperrprotokoll
Anforderung: Gewährleistung der Serialisierbarkeit
6SHUUYHUIDKUHQ
Seite 337 von 344
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Sperren
Zeit
Freigabe
Verarbeitung
Seite 338 von 344
‰ Bevor auf ein Objekt A zugegriffen wird, muss es mit einem lock gesperrt werden.
Insbesondere muss eine Sperre direkt vor dem Lesen des Objekts gesetzt werden.
‰ Das gleiche Objekt darf während einer Transaktion bei einem 2PL nur einmal gesperrt
und freigegeben (unlock) werden.
‰ Wurde das Objekt verändert, muss es vor der Freigabe (unlock) auch geschrieben werden.
Eigenschaften:
#Sperren
‰ 2-Phasen-Sperrprotokoll:
Für jede TA darf nach dem ersten unlock kein lock mehr angefordert werden.
=ZHL3KDVHQ6SHUUSURWRNROO3/
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Wenn dieser mittels eines 2PL entstanden wäre, dann müßte es Objekte Ai1, …, Ain
geben, so dass bzgl. diesen die Transaktionen in Konflikt stehen. Somit muss also
ein unlockij(Aij) vor einem lockij(Aij+1) für j= 1, …,n-1 erfolgt sein und zusätzlich
noch ein locki1(Ain) nach dem unlock in(Ain) erfolgen.
–
Seite 339 von 344
Annahme: H ist ein Ausführungsplan mit einem Zyklus Ti1 -> … -> Tin -> Ti1
–
Beweisskizze:
Jeder durch ein 2-Phasen Sperrprotokoll erzeugte Ausführungsplan ist serialisierbar.
Satz:
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
–
–
–
–
Verarbeitung
Zeit
Freigabe
keine Verklemmung möglich
Objekte müssen bei Beginn der TA
bekannt sein
häufig wird zu viel und zu lange
gesperrt
Probleme beim Zurücksetzen einer
TA (kaskadierend)
#Sperren
‰ Preclaiming (konservatives 2PL):
–
–
–
–
Sperren
Verarbeitung
Zeit
Seite 340 von 344
Verklemmungen sind möglich
Objekte müssen beim Beginn der TA
noch nicht bekannt sein.
bei Freigabe der Sperren ist
garantiert, dass auf kein Objekt mehr
zugegriffen wird.
vermeidet Zurücksetzen von bereits
abgeschlossenen TAs
#Sperren
‰ EOT-Sperren (striktes 2PL)
9DULDQWHQGHV3/
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Seite 341 von 344
‰ Unterscheidung zwischen zwei Sperrmodi
–
S-Sperre: slockT(A)
Das Objekt A darf von der Transaktion T gelesen, aber nicht geschrieben werden.
Auf dem Objekt A sind nun mehrere S-Sperren verschiedener Transaktionen erlaubt
(S ist eine Abkürzung für 6KDUHG)
–
X-Sperre: xlockT(A)
Die Transaktion T hat nach dem Sperren des Objekts A exklusiven lesenden und
schreibenden Zugriff. Es ist somit nur eine X-Sperre auf einem Objekt A erlaubt (X
ist eine Abkürung für H;FOXVLFH)
RX-Protokoll
‰ Das bisherige Vorgehen ist zu restriktiv, da das Sperren von Objekten, die nur gelesen
werden, zu restriktiv ist.
–
Eine Transaktion T2, die ein Objekt A lesen möchte, muss warten bis die
Transaktion T1 ein unlock auf A ausführt (obwohl T1 keine Änderungen an A
vornimmt).
6SHUUPRGL
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Seite 342 von 344
‰ Motivation
–
Bisher sind wir davon ausgegangen, dass die Sperren sich auf Objekte der gleichen
Hierarchiestufe beziehen (z. B. Seiten)
–
Sperren auf einer höheren Stufe (z. B. Relation) sind dann sinnvoll, wenn bereits
viele Kindobjekte gesperrt wurden. Dadurch kann der Verwaltungsaufwand für die
Sperren erheblich reduziert werden.
‰ Multiple-granularuty Locking
–
S:
Lesesperre
–
X
Schreibesperre
–
IS
Auf Objekten in der darunterliegenden Hierarchie ist eine Lesesperre
beabsichtigt.
–
IX
Auf Objekten in der darunterliegenden Hierarchie ist eine Schreibesperre
beabsichtigt.
‰ Erwerb von Sperren
– Top-Down: Bevor ein Objekt gesperrt wird, muss zuerst das Objekt auf der
darüberliegenden Ebene gesperrt sein.
‰ Zurückgabe von Sperren
–
Bottom-up: Feingranulare Sperren werden zuerst zurückgegeben.
+LHUDUFKLVFKH6SHUUJUDQXODWH
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
d112
Sätze
d111
S11
X1
IX1
x
x
S
Seiten
Relationen
Datenbank
Beispiel:
IX
IS
X
S
‰ Kompatibilität der Sperrmodi
S12
R1
IX1
X
R2
D IS2
x
x
x
IS
S2
S31
R3 IS2
x
x
x
IX
Seite 343 von 344
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV
Seite 344 von 344
‰ In SQL’92 kann das Korrektheitskriterium für die parallele Verarbeitung von
Transaktionen durch Angabe eines Isolationslevel abgesenkt werden.
–
Erhöhung des Parallelitätsgrads
–
Gefahr einer inkonsistenten Datenbank
‰ Isolationslevel
–
read uncommited
Dies erlaubt lesenden Transaktionen den Zugriff auf noch nicht festgeschriebene
Daten (d.h. Daten können vor dem commit bereits gelesen werden.
–
read committed
Daten können nur dann gelesen werden, wenn diese tatsächlich über ein commit
festgeschrieben wurden.
–
repeatable reads
Identische Leseoperationen innerhalb der gleichen Transaktion liefern zwar das
gleiche Ergebnis. Das Phantomproblem wird jedoch nicht verhindert.
–
serializable
Dies entspricht dem in diesem Kapitel erläuterten Serializierbarkeitsbegriff. Dies ist
die Defaulteinstellung bei einem DBS.
0HKUEHQXW]HUV\QFKURQLVDWLRQLQ64/
.RRUGLQDWLRQGHV0HKUEHQXW]HUEHWULHEV