Sie sind auf Seite 1von 69

Anwendersoftware (AS)

Datenbanken und
Informationssysteme
Kapitel 10: Synchronisation
Bernhard Mitschang
Universitt Stuttgart
Wintersemester 2013/2014
Teile zu diesem Folienskript beruhen auf einer hnlichen Vorlesung, gehalten von Prof. Dr. T. Hrder am
Fachbereich Informatik der Universitt Kaiserslautern und Prof. Dr. N. Ritter am Fachbereich Informatik der
Universitt Hamburg. Fr dieses Skriptum verbleiben alle Rechte (insbesondere fr Nachdruck) bei den
Autoren.

Synchronisation

bersicht

Einfhrung

Sperrverfahren (pessimistische Synchronisation)

Zweiphasen-Sperrprotokolle
Hierarchische Sperrverfahren
Konsistenzstufen von Transaktionen
Deadlock-Behandlung

Optimistische Synchronisation

Anomalien
Serialisierbarkeit

BOCC
FOCC
Kombination von OCC und Sperrverfahren

berblick ber weitere Konzepte

Allgemeines Mehrversionenkonzept
Zeitstempel-Verfahren
Prdikatsperren
Synchronisation bei "High Traffic"-Elementen

Synchronisation

Gefhrdung der DB-Konsistenz


Gefhrdung der DBKonsistenz durch
das
Anwendungsprogramm

das DBMS und


die Betriebsumgebung

Korrektheit der
Abbildungshierarchie

bereinstimmung zwischen
DB und Miniwelt

Mehrbenutzer-Anomalien

unzulssige nderungen

Synchronisation
(Concurrency Control)

Integrittsberwachung
des DBMS
TA-orientierte Verarbeitung

Fehler auf den Externspeichern,


Inkonsistenzen in den
Zugriffspfaden

undefinierter DB-Zustand
nach einem Systemausfall

Fehlertolerante
Implementierung
Archivkopien (Backup)

Transaktionsorientierte
Fehlerbehandlung
(Recovery)

Synchronisation

Ablaufkontrollstruktur: Transaktion (TA)


Eine Transaktion ist eine ununterbrechbare Folge von DML-Befehlen, die
die Datenbank von einem logisch konsistenten in einen (neuen) logisch
konsistenten Zustand berfhrt.
Beispiel eines TA-Programms:
BOT
UPDATE Konto
...
UPDATE Schalter
...
UPDATE Zweigstelle
...
INSERT INTO Ablage (...)
EOT

Synchronisation

ACID-Eigenschaften von Transaktionen


Atomicity (Atomaritt)
TA ist kleinste, nicht mehr weiter zerlegbare Einheit
Entweder werden alle nderungen der TA festgeschrieben oder
gar keine (alles-oder-nichts-Prinzip)
Consistency
TA hinterlsst einen konsistenten DB-Zustand, sonst wird sie komplett
(siehe Atomaritt) zurckgesetzt
Endzustand muss alle definierten Integrittsbedingungen erfllen
Zwischenzustnde whrend der TA-Bearbeitung drfen inkonsistent
sein

Synchronisation

ACID-Eigenschaften von Transaktionen


Isolation
Nebenlufig (parallel, gleichzeitig) ausgefhrte TA drfen sich nicht
gegenseitig beeinflussen
Parallele TA bzw. deren Effekte sind nicht sichtbar
(logischer Einbenutzerbetrieb)
Durability (Dauerhaftigkeit)
Wirkung erfolgreich abgeschlossener TA bleibt dauerhaft in der DB
TA-Verwaltung muss sicherstellen, das dies auch nach einem
Systemfehler (HW- oder System-SW) gewhrleistet ist
Wirkung einer erfolgreich abgeschlossenen TA kann nur durch eine
sog. kompensierende TA aufgehoben werden

Synchronisation

Schnittstelle zwischen
Anwendungsprogramm (AP) und DBS
START TRANSACTION
Kennzeichnet Beginn einer
Transaktion (BOT)
nach SQL-Standard auch implizit
mglich
COMMIT [WORK]
Kennzeichnet Ende einer
Transaktion (EOT)
nderungen der Transaktion
werden festgeschrieben
ROLLBACK [WORK]
Selbstabbruch der Transaktion
(Abort)

SAVEPOINT <name>
Definiert einen Sicherungspunkt
innerhalb der Transaktion
ROLLBACK [WORK]
TO SAVEPOINT <name>
Setzt die aktive Transaktion auf
einen Sicherungspunkt zurck

Synchronisation

Mgliche Ausgnge einer Transaktion


BOT

BOT

BOT

DML1

DML1

DML1

DML2

DML2

DML2

DML3

DML3

DML3

DMLn

DMLn

COMMIT

ROLLBACK

normales Ende

abnormales Ende

Systemausfall,
Programmfehler,
usw.
erzwungenes ROLLBACK
erzwungenes
abnormales Ende

Synchronisation

Warum Mehrbenutzerbetrieb?

CPU-Nutzung whrend TA-Unterbrechungen:


E/A
Denkzeiten bei Mehrschritt-TA
Kommunikationsvorgnge in verteilten Systemen
bei langen TA zu groe Wartezeiten fr andere TA (Scheduling-Fairne)

Anomalien im Mehrbenutzerbetrieb ohne Synchronisation


1. Abhngigkeiten von nicht freigegebenen nderungen
(dirty read, dirty overwrite)
2. Verlorengegangene nderungen (lost update)
3. Inkonsistente Analyse (non-repeatable read)
4. Phantom-Problem
nur durch nderungs-TA verursacht

Synchronisation

Lost Update

Verlorengegangene nderung
(Lost Update)
ist in jedem Fall auszuschlieen
T1

T2

READ(A);
READ(A);
A := A - 100;
WRITE(A);
COMMIT;
A := A + 100;
WRITE(A)
COMMIT;

Zeit

10

Synchronisation

Dirty Read

Abhngigkeit von nicht-freigegebenen nderungen (Dirty Read)


schmutzige Daten (dirty data):
- Genderte, aber noch nicht
freigegebene Daten
- die TA kann ihre
nderungen bis Commit
(einseitig) zurcknehmen

Schmutzige Daten drfen


von anderen TAs nicht
benutzt werden

T1

T2

READ(A);
A := A + 100;
WRITE(A);
READ(A);
READ(B);
B := B + A;
WRITE(B);
COMMIT;
ABORT;

Zeit

11

Synchronisation

Non-repeatable Read

Inkonsistente Analyse mit Dirty Read


T1

T2

Lesetransaktion

nderungstransaktion

DB-Inhalt
(PNR,Gehalt)
2345

39.000

3456

48.000

UPDATE Pers
SET Gehalt = Gehalt + 1000
WHERE Pnr = 2345;

2345

40.000

UPDATE Pers
SET Gehalt = Gehalt + 2000
WHERE Pnr = 3456;

3456

50.000

SELECT SUM(Gehalt)
INTO :summe
FROM Pers
WHERE Pnr IN (2345,3456);

COMMIT;

Zeit

Erneutes berechnen der Gehaltssumme in T1 fhrt zu anderem Ergebnis


12

Synchronisation

Non-repeatable Read

Inkonsistente Analyse ohne Dirty Read


T1

T2

Lesetransaktion

nderungstransaktion

DB-Inhalt
(PNR,Gehalt)
2345

39.000

3456

48.000

UPDATE Pers
SET Gehalt = Gehalt + 1000
WHERE Pnr = 2345;

2345

40.000

UPDATE Pers
SET Gehalt = Gehalt + 2000
WHERE Pnr = 3456;

3456

50.000

SELECT Gehalt INTO :gehalt


FROM Pers
WHERE Pnr = 2345;
summe := summe + gehalt;

COMMIT;
SELECT Gehalt INTO :gehalt
FROM Pers
WHERE Pnr = 3456;
summe := summe + gehalt

Zeit
13

Synchronisation

Phantom-Problem

Inkonsistente Analyse bei der


eine Lesetransaktion ein mengenorientiertes Lesen ber einem Suchprdikat P
durchfhrt
eine parallele nderungstransaktion die Menge der fr P qualifizierten Objekte ndert
(INSERT oder DELETE)
T1

T2

Lesetransaktion

nderungstransaktion

SELECT SUM (Gehalt) INTO :summe1


FROM Pers
WHERE Anr = 17;
INSERT INTO Pers (Pnr, Anr, Gehalt)
VALUES (4567, 17, 55.000);
COMMIT;
SELECT SUM (Gehalt) INTO :summe2
FROM Pers
WHERE Anr = 17;

Zeit

IF summe1 <> summe2 THEN <Fehler>

14

Synchronisation

Modellannahmen

Transaktion:
Ein Programm T mit DML-Anweisungen, das folgende Eigenschaft erfllt:
Wenn T allein auf einer konsistenten DB ausgefhrt wird, dann terminiert T
(irgendwann) und hinterlsst die DB in einem konsistenten Zustand.
Whrend der TA-Verarbeitung werden keine Konsistenzgarantien eingehalten.
Wenn Transaktionen seriell ausgefhrt werden, bleibt die Konsistenz der DB erhalten.

DML-Anweisungen lassen sich nachbilden durch


ri(x), d.h. Transaktion i liest Objekt x (READ)
wi(x), d.h. Transaktion i schreibt Objekt x (WRITE)

DBMS sieht eine TA wie folgt:


BOT, Folge von READ- und WRITE-Anweisungen auf Objekten, EOT

Schedule: Ablauffolge von TA mit ihren Operationen


Beispiel:
r1(x), r2(x), r3(y), w1(x), w3(y), r1(y), c1, r3(x), w2(x), a2, w3(x), c3, ...
Beispiel eines seriellen Schedules:
r1(x), w1(x), r1(y), c1, r3(y), w3(y), r3(x), c3, r2(x), w2(x), c2,...
BOT ist implizit, EOT wird durch ci oder ai dargestellt
15

Synchronisation

Serialisierbarkeit

Ziel:
logischer Einbenutzerbetrieb, d.h. Vermeidung aller Mehrbenutzeranomalien

Formales Korrektheitskriterium: Serialisierbarkeit


Die parallele Ausfhrung einer Menge von TA ist serialisierbar, wenn es eine
serielle Ausfhrung derselben TA-Menge gibt, die den gleichen DB-Zustand und
die gleichen Ausgabewerte wie die ursprngliche Ausfhrung erzielt.

Hintergrund:
Serielle Schedules sind korrekt
Jeder Schedule, der denselben Effekt wie ein serieller erzielt, ist akzeptierbar

16

Synchronisation

Beispiel

r(x)

Die Transaktionen T1-T4 mssen so


T1
synchronisiert werden, dass der
resultierende Zustand der DB gleich
T2
dem ist, der bei der seriellen Ausfhrung
in einer der folgenden Sequenzen
T3
zustande gekommen wre.
r(x)

w(y)

w(z)

r(y)
w(x)

T4

(T1, T2, T3, T4), (T2, T1, T3, T4), (T1, T2, T4, T3), (T2, T1, T4, T3),
(T1, T3, T2, T4), (T1, T3, T4, T2), , (T1, T4, T2, T3), (T1, T4, T3 ,T2)
(T4, T3, T2, T1)
Es gibt n! (hier 4! = 24) verschiedene serielle Schedules

17

Synchronisation

Nachweis der Serialisierbarkeit

Abhngigkeitsgraph: Darstellung der zeitlichen Abhngigkeiten zwischen TA.


Dieser enthlt
Knoten: Transaktionen des Schedules
gerichtete Kanten: Abhngigkeiten zwischen Transaktionen

Abhngigkeit (Konflikt) besteht, wenn


zwei TA auf dasselbe Objekt mit nicht
reihenfolgeunabhngigen Operationen
zugreifen:
Schreib-/Lese-Konfilit,
Lese-/Schreib-Konfilkt,
Schreib-/Schreib-Konflikt

w(x)

T1
T2

r(x)

r2(x) w1(x)

T1

T2

Serialisierbarkeit liegt vor, wenn der Abhngigkeitsgraph keine Zyklen enthlt.


(Konflikt-Serialisierbarkeit)

18

Synchronisation

Serialisierungsreihenfolge

Serialisierungsreihenfolge: Vollstndige Ordnung zwischen den TA. Diese ergibt


sich bei serialisierbaren Schedules aus der durch den Abhngigkeitsgraphen
beschriebenen partiellen Ordnung.
Beispiel:
r(x)

T1

w(y)

w(x)

T3
T4

T1

r(y)

T2

r(x)

w(z)

r2(y)w1(y)

T2

r1(x)w3(x)

T3

r4(x)w3(x)

T4

Serialisierungsreihenfolgen: (T4, T2, T1, T3), (T2, T4, T1, T3), (T2, T1, T4, T3)

19

Synchronisation

Serialisierungsreihenfolge

Beispiel:
T1

w(x)

T2

w(y)

T3

w3(y)w1(y)

r(x)
w(y)

T3

w1(x)r2(x)

T1

T2

Sinnvolle Einschrnkungen:
1. Reihenfolgeerhaltende Serialisierbarkeit:
jede TA sollte wenigstens alle nderungen von TA sehen, die bei ihrem
Start (BOT) bereits beendet waren
2. Chronologieerhaltende Serialisierbarkeit:
jede TA sollte stets die aktuellste Objektversion sehen

20

Synchronisation

bersicht

Einfhrung

Sperrverfahren (pessimistische Synchronisation)

Zweiphasen-Sperrprotokolle
Konsistenzstufen von Transaktionen
Hierarchische Sperrverfahren
Deadlock-Behandlung

Optimistische Synchronisation

Anomalien
Serialisierbarkeit

BOCC
FOCC
Kombination von OCC und Sperrverfahren

berblick ber weitere Konzepte

Allgemeines Mehrversionenkonzept
Zeitstempel-Verfahren
Prdikatsperren
Synchronisation bei "High Traffic"-Elementen

21

Synchronisation

Historische Entwicklung von


Synchronisationsverfahren
Exklusive Objektsperren
RX-Sperrverfahren
hierarchische Sperren

optimistische Verfahren
(BOCC, FOCC, )
Zeitmarkenverfahren

neuere Sperrverfahren
(RAX, RAC, )

Spezialverfahren
(B*-Bume,
Hot-Spot-Synchronisation, )
MehrversionenVerfahren
22

Synchronisation

Zweiphasen-Sperrprotokolle (2PL)

Einhaltung folgender Regeln gewhrleistet Serialisierbarkeit:


1. vor jedem Objektzugriff muss eine Sperre mit ausreichendem Modus
angefordert werden
2. gesetzte Sperren anderer TA sind zu beachten
3. eine TA darf nicht mehrere Sperren fr ein Objekt anfordern
4. Zweiphasigkeit:
-

Anfordern von Sperren erfolgt


in einer Wachstumsphase
Freigabe der Sperren in
Schrumpfungsphase
Sperrfreigabe kann erst beginnen,
wenn alle Sperren gehalten werden

5. Sptestens bei EOT sind alle Sperren


freizugeben

zweiphasig

#Sperren

BOT

EOT

#Sperren

strikt
zweiphasig
BOT

EOT

#Sperren

preclaiming
BOT

EOT
23

Synchronisation

RX-Sperrverfahren

Gewhrter Sperrmodus des Objekts:


NL, R, X
Sperranforderung einer Transaktion:
R, X
Kompatibilittsmatrix:
(NL (no lock) wird meist weggelassen)

aktueller
Modus
angeforderter
Modus

NL

Deadlock-Gefahr durch
Sperrkonversion
T1
T2

r(y)

w(y)
r(y)

Erweitertes Sperrverfahren
Ziel:
Verhinderung von KonversionsDeadlocks
U-Sperre fr Lesen mit
nderungsabsicht
bei nderung Konversion U X,
andernfalls U R (downgrading)
das Verfahren ist unsymmetrisch:
Was wrde eine Symmetrie bei U
bewirken?
R

w(y)

24

Synchronisation

RAX-Sperrverfahren
R

Hhere Parallelitt als beim RXVerfahren, jedoch i.A. andere


Serialisierungsreihenfolge:
RX: T1 T2
T1

nderungen erfolgen in temporrer


Objektkopie
Paralleles Lesen der gltigen Version
wird zugelassen
Schreiben wird nach wie vor
sequentialisiert (A-Sperre)
Bei EOT Konversion der A- und XSperren, ggf. auf Freigabe von
Lesesperren warten (DeadlockGefahr)

X(z)
R(z)

T2
RAX: T2 T1
T1
T2

A->X

A(z)
R(z)

starke Behinderungen von Update-TA


durch (lange) Leser mglich

25

Synchronisation

RAC-Sperrverfahren

nderungen erfolgen ebenfalls in


temporrer Objektkopie (A-Sperre
erforderlich)
bei EOT Konversion von A C
C-Sperre zeigt Existenz zweier
gltiger Objektversionen an
kein Warten auf Freigabe von
Lesesperren auf alter Version
(R- und C-Modus sind vertrglich)
maximal 2 Versionen, da C-Sperren
mit sich selbst und mit A-Sperren
unvertrglich sind

T1
T2

A(y)
R(z)

A(z) AC
R(y)

Leseanforderungen bewirken nie


Blockierung/Rcksetzung, jedoch:
Auswahl der 'richtigen' Version
erforderlich
(z.B. ber Abhngigkeitsgraphen)
nderungs-TA, die auf C-Sperre
laufen, mssen warten, bis alle Leser
der alten Version beendet sind, weil
nur 2 Versionen
ABHILFE:
allgemeines Mehrversionen-Konzept

26

Synchronisation

Implementierungsaspekte

Beispiel:
Sperrtabelle / TA-Tabelle fr RACVerfahren
Hash-Tabelle erlaubt schnellen Zugriff
auf Objektkontrollblcke (OKB)
Matrixorganisation Objekt-/TA-Tabelle
Kurzzeitsperren fr Zugriffe auf
Objekttabelle
(Semaphor pro Hashklasse reduziert
Konflikt-/Konvoi-Gefahr)

27

Synchronisation

Konsistenzebenen in SQL2

SQL2 erlaubt Wahl zwischen vier Konsistenzebenen (Isolation Level) bezglich


Synchronisation
SQL2 definiert die Konsistenzebenen ber die Anomalien, die jeweils in Kauf
genommen werden
Lost-Update muss generell vermieden werden d.h.,
Write/Write-Abhngigkeiten mssen stets beachtet werden
Zuordnung der Anomalien:
Anomalie
Konsistenzebene

Dirty
Read

NonRepeatable
Read

Phantome

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ

SERIALIZABLE

28

Synchronisation

Konsistenzebenen in SQL2

SQL-Anweisung:
SET TRANSACTION [mode] [ISOLATION LEVEL level]
START TRANSACTION [mode] [ISOLATION LEVEL level]

Transaktionsmodus: mode ::= READ WRITE | READ ONLY


Konsistenzebenen: level ::= READ UNCOMMITTED | READ COMMITTED |
REPEATABLE READ | SERIALIZABLE
Default: READ WRITE ISOLATION LEVEL SERIALIZABLE
Beispiel:
SET TRANSACTION READ ONLY,
ISOLATION LEVEL READ COMMITTED

29

Synchronisation

Konsistenzebenen von Transaktionen

Konsistenzebene 3:
Transaktion T sieht Konsistenzebene 3, wenn gilt:
a)
b)
c)
d)

T verndert keine schmutzigen Daten anderer Transaktionen


T gibt keine nderungen vor EOT frei
T liest keine schmutzigen Daten anderer Transaktionen
Von T gelesene Daten werden durch andere Transaktionen erst nach EOT
von T verndert

Konsistenzebene 2:
Transaktion T sieht Konsistenzebene 2, wenn sie die Bedingungen a, b
und c erfllt
Konsistenzebene 1:
Transaktion T sieht Konsistenzebene 1, wenn sie die Bedingungen a und
b erfllt
Konsistenzebene 0:
Transaktion T sieht Konsistenzebene 0, wenn sie nur Bedingung a erfllt
30

Synchronisation

Konsistenzebenen von Transaktionen


Konsistenzebene 3: (Serialisierbarkeit)
lange Schreib- und Lesesperren
wnschenswert, jedoch oft viele Sperrkonflikte wegen

Konsistenzebene 2:
lange Schreibsperren, jedoch kurze Lesesperren
non-repeatable read mglich

Konsistenzebene 1:
lange Schreibsperren, keine Lesesperren
dirty read (und lost update) mglich

Konsistenzebene 0:
kurze Schreibsperren (Chaos)

31

Synchronisation

Hierarchische Sperrverfahren

Sperrgranulat bestimmt
Parallelitt/Aufwand

feines Granulat reduziert


Sperrkonflikte
jedoch sind viele Sperren anzufordern
und zu verwalten

hierarchische Verfahren erlauben


Flexibilitt bei Wahl des Granulates
(multi-granularity locking)

Datenbank
Segment

z. B. Synchronisation langer TA auf


Tabellenebene
oder kurzer TA auf Zeilenebene

kommerzielle DBS untersttzen


zumeist mindestens 2-stufige
Objekthierarchie, z.B.
Seite Segment
Satztyp (Tabelle) Satzausprgung
(Tupel)

Verfahren nicht auf reine Hierarchien


beschrnkt, sondern auch auf
halbgeordnete Objektmengen
erweiterbar (siehe auch
objektorientierte DBS)

Tabelle

Index
Zeile

Verfahren erheblich komplexer als


einfache Sperrverfahren
(mehr Sperrmodi, Konversionen,
Deadlock-Behandlung, ...)
32

Synchronisation

Hierarchische Sperrverfahren

Beispiel einer Sperrhierarchie:


Datenbank

DB

Dateien (Segmente)

S1

Tabellen (Satztypen)
Tupel

S2

T21

S3

T22

t211

Aufwand fr das Sperren von


1 Satz:
3+1
k Stzen: 3 + k
1 Tabelle: 2 + 1

33

Synchronisation

Anwartschaftssperren: I

durch R- und X-Sperre werden alle


Nachfolgerknoten implizit mitgesperrt

Einsparungen mglich

T1

alle Vorgngerknoten sind ebenfalls


zu sperren, um Unvertrglichkeiten
zu vermeiden
Verwendung von Anwartschaftssperren ('intention locks')
I-Sperre : allgemeine
Anwartschaftssperre
I

Beispiel:

T2

DB

Si

Tij

(wartet)

Unvertrglichkeit von I- und RSperren zu restriktiv!

34

Synchronisation

Anwartschaftssperren: IR, IX

Lsung (?): zwei Arten von Anwartschaftssperren: IR und IX


IR-Sperre (intent read), falls auf untergeordneten Objekten nur lesend
zugegriffen wird
sonst IX-Sperre
Beispiele:
T1

T2

T1

IR

IR

DB

IR

DB

IR

Si

IR

IR

IR

Tij

IR

T2

IR

IX

IX

IR

IX

Si

IX

Tij

IX

IR

IX

X
35

Synchronisation

Anwartschaftssperren: RIX

Sperren fr den Fall, dass alle Stze eines Satztyps gelesen aber nur einige
gendert werden sollen?
Tij
X
X-Sperre auf Satztyp
ist zu restriktiv

IX-Sperre auf Satztyp


erfordert Sperren fr
jeden Satz

Tij
R

IX

weitere Verfeinerung: RIX = R + IX


sperrt das Objekt in R-Modus und verlangt
X-Sperren auf tieferer Hierarchieebene nur fr zu ndernde Objekte
Tij

RIX

X
36

Synchronisation

Anwartschaftssperren
Vollstndiges Protokoll der Anwartschaftssperren
RIX gibt ein Leserecht auf den Knoten und seine Nachfolger; weiterhin ist
damit das Recht verbunden, auf Nachfolger-Knoten IX, U und X-Sperren
anzufordern
U gewhrt ein Leserecht auf den Knoten und seine Nachfolger; dieser Modus
reprsentiert die Absicht, den Knoten in der Zukunft zu verndern; bei
nderung Konversion U X, sonst U R
IR

IX

RIX

IR

IX

RIX

RIX

IR

IX

37

Synchronisation

Anwartschaftssperren
Sperrdisziplin erforderlich
Sperranforderungen von der Wurzel zu den Blttern
bevor T eine R- oder IR-Sperre fr einen Knoten anfordert, muss sie fr alle
Vorgngerknoten IX- oder IR-Sperren besitzen
bei einer X-, U-, RIX- oder IX-Anforderung mssen alle Vorgngerknoten in
RIX oder IX gehalten werden
Sperrfreigaben von den Blttern zu der Wurzel
bei EOT sind alle Sperren freizugeben

38

Synchronisation

Deadlock-Behandlung

Voraussetzungen fr Deadlock:
paralleler Zugriff
exklusive Zugriffsanforderungen
anfordernde TA besitzt bereits
Objekte/Sperren
keine vorzeitige Freigabe von
Objekten/Sperren (non-preemption)
zyklische Wartebeziehung zwischen
zwei oder mehr TA

Lsungsmglichkeiten:
1. Timeout-Verfahren
-

TA wird nach festgelegter Wartezeit


auf Sperre zurckgesetzt
problematische Bestimmung des
Timeout-Wertes

2. Deadlock-Verhtung (Prevention)
-

keine Laufzeituntersttzung zur


Deadlock-Behandlung erforderlich
Bsp.: Preclaiming (in DBS i. A. nicht
praktikabel)

3. Deadlock-Vermeidung (Avoidance)
-

potentielle Deadlocks werden im


voraus erkannt und durch
entsprechende Manahmen
vermieden
Laufzeituntersttzung ntig

4. Deadlock-Erkennung (Detection)

39

Synchronisation

Deadlock-Erkennung

Explizites Fhren eines Wartegraphen (wait-for graph) und Zyklensuche zur


Erkennung von Verklemmungen
T3

O1

T2

O2

O4

T4
O5

O1

T5

O3

T1

Deadlock-Auflsung durch Zurcksetzen einer oder mehrerer am Zyklus


beteiligter TA (z.B. Verursacher oder billigste TA zurcksetzen)
Zyklensuche entweder
bei jedem Sperrkonflikt bzw.
verzgert (z.B. ber Timeout gesteuert)

fr zentralisierte DBS zu empfehlen


40

Synchronisation

Beispiel DB2

Sperrliste: Datenstruktur zur


Verwaltung der Sperrinformation
Seiten zu je 4KB
pro Sperre: 30 - 120 Byte

Bereich

Beschreibung

locklist

DB

Anzahl der Seiten fr


die Sperrliste

maxlocks

DB

Anteil der Sperrliste,


der von einer
Applikation belegt
sein muss, so dass
fr diese Applikation
Sperreskalation
ausgelst wird.

dlchktime

DB

Bestimmt die
Hufigkeit der
Deadlock-Erkennung

Sperreskalation: Umwandlung von


Tupelsperren in Tabellensperren.
Mgliche Auslser:
Fehlender Platz in der Sperrliste
Applikation berschreitet die durch
maxlocks begrenzte Belegung der
Sperrliste

Parameter

Sperren explizit setzen:


LOCK TABLE name IN [ SHARE | EXCLUSIVE ] MODE

41

Synchronisation

Sperrverfahren in Datenbanksystemen
Zusammenfassung:
Aufgabe von Sperrverfahren: Vermeidung von Anomalien, indem

Standardverfahren: Hierarchisches Zweiphasen-Sperrprotokoll

mehrere Sperrgranulate
Verringerung der Anzahl der Sperranforderungen

Probleme bei der Implementierung von Sperren:

zu ndernde Objekte dem Zugriff aller anderen Transaktionen entzogen werden


zu lesende Objekte vor nderungen geschtzt werden

kleine Sperreinheiten (wnschenswert) erfordern hohen Aufwand


Sperranforderung und -freigabe sollten sehr schnell erfolgen, da sie sehr hufig bentigt werden
explizite, satzweise Sperren fhren u.U. zu umfangreichen Sperrtabellen und groem Zusatzaufwand
Zweiphasigkeit der Sperren fhrt hufig zu langen Wartezeiten (starke Serialisierung)
hufig berhrte Zugriffspfade knnen zu Engpssen werden
Eigenschaften des Schemas knnen "hot spots" erzeugen

Optimierungen:

nderungen auf privaten Objektkopien (verkrzte Dauer exklusiver Sperren)


Nutzung mehrerer Objektversionen
spezialisierte Sperren (Nutzung der Semantik von nderungsoperationen)
42

Synchronisation

bersicht

Einfhrung

Sperrverfahren (pessimistische Synchronisation)

Zweiphasen-Sperrprotokolle
Konsistenzstufen von Transaktionen
Hierarchische Sperrverfahren
Deadlock-Behandlung

Optimistische Synchronisation

Anomalien
Serialisierbarkeit

BOCC
FOCC
Kombination von OCC und Sperrverfahren

berblick ber weitere Konzepte

Allgemeines Mehrversionenkonzept
Zeitstempel-Verfahren
Prdikatsperren
Synchronisation bei "High Traffic"-Elementen

43

Synchronisation

Optimistic Concurrency Control (OCC)

Motivation:
In manchen Anwendungen bentigt man fast nur Lesezugriffe
Konflikte sind selten
2PL-Aufwand erscheint deshalb unangemessen hoch
Grundannahme:
geringe Konfliktwahrscheinlichkeit
Allgemeine Eigenschaften von OCC:
+ einfache TA-Rcksetzung
+ keine Deadlocks
+ potentiell hhere Parallelitt als bei Sperrverfahren
- mehr Rcksetzungen als bei Sperrverfahren
- Gefahr des Verhungerns von TA

44

Synchronisation

OCC: Phasen einer Transaktion


Read
BOT

Validate

Write

COMMIT

Read-Phase:
Fhre TA aus, kapsele dabei WriteOperationen in einem privaten
Workspace
Validate-Phase (Certifier):
Wenn Ti Commit ausfhrt, teste mit
Hilfe von Read-Sets RS und WriteSets WS, ob Ti mit einer parallel
laufenden TA im Konflikt steht
Write-Phase:
Nach erfolgreicher Validierung wird
der (genderte) Workspace-Inhalt in
die DB (DB-Puffer) eingebracht
(deferred writes),
sonst wird Ti zurckgesetzt
(Workspace wird aufgegeben)

T1
Lesen

T2
Schreiben

Lesen

privater Puffer

Schreiben

privater Puffer

DB-Puffer

Datenbank

45

Synchronisation

OCC: Verfahren

Zur Durchfhrung der Validierungen wird pro Transaktion das Read-Set (RS) und
das Write-Set (WS) erfasst
Forderung:
eine TA kann nur erfolgreich validieren, wenn sie alle nderungen von zuvor validierten
TA gesehen hat
Validierungsreihenfolge bestimmt Serialisierungsreihenfolge

Validierungsstrategien:
Backward Oriented (BOCC): Validierung gegenber bereits beendeten (nderungs-) TA
Forward Oriented (FOCC): Validierung gegenber laufenden TA

46

Synchronisation

Backward-Oriented OCC

BOCC-Validierung von Tj:

Vergleiche Tj mit allen vorher abgeschlossenen Ti.


Akzeptiere Tj nur, wenn eine der beiden Bedingungen gilt:
- Ti war abgeschlossen, bevor Tj gestartet wurde
- RS(Tj) WS(Ti) = und Ti wurde vor Tj validiert

Read-Phase

T1

r1(x)

T2

r1(y)
r2(y)

Write-Phase
Validate
r2(z)

T3

w1(x)

Validate
r3 (x)

w2(z)

r3 (y)

T4

Validate
r 4(x)

Abort

Validate

w4(x)
47

Synchronisation

Backward-Oriented OCC

Nachteile/Probleme:
unntige Rcksetzungen wegen ungenauer Konfliktanalyse
Aufbewahren der Write-Sets beendeter TA erforderlich
hohe Anzahl von Vergleichen bei Validierung
Rcksetzung erst bei EOT
viel unntige Arbeit

es kann nur die validierende TA zurckgesetzt werden


Gefahr von Starvation

hohes Rcksetzrisiko fr lange TA und bei Hot-Spots

48

Synchronisation

Forward-Oriented OCC

FOCC-Validierung von Tj:

Vergleiche Tj mit allen aktiven Ti (die sich in ihrer Lesephase befinden mssen).
Akzeptiere Tj nur, wenn WS(Tj) RS*(Ti) = ,
wobei RS*(Ti) das momentane Read-Set von Ti ist

Vorteile:
Wahlmglichkeit des Opfers (Kill, Abort, Prioritten, ...)
keine unntigen Rcksetzungen
frhzeitige Rcksetzung mglich
Einsparen unntiger Arbeit

keine Aufbewahrung von Write-Sets,


geringerer Validierungsaufwand als bei BOCC

Probleme:
Whrend Validierungs- und Schreibphase muss WS (T) 'gesperrt werden, damit sich die
RS (Ti) nicht ndern (keine Deadlocks damit mglich)
immer noch hohe Rcksetzrate mglich
es kann immer nur einer TA Durchkommen definitiv zugesichert werden

49

Synchronisation

FOCC-Beispiel
Read-Phase

T1

T2

r1(x)

r1(y)

Write-Phase

Validate

w1(x)

r2(y)

r2(z)

T3

T4

Validate

w2 (z)

r3(z)
Abort

r4 (x) r4(y)

T5

r5(x)

Validate w 4(x)

r5(y)

50

Synchronisation

Kombination von OCC und Sperrverfahren

Ziel:
Vorteile beider Verfahrensklassen
kombinieren
geringe Rcksetzhufigkeit von
Sperrverfahren
hohe Parallelitt (weniger
Sperrwartezeiten) von OCC

Kombination kann auf verschiedenen


Ebenen realisiert werden
1. TA-Ebene:
- optimistisch und pessimistisch
synchronisierte TA
- fr lange und bereits gescheiterte TA
pessimistische Synchronisation
keine Starvation

2. Objekt-Ebene:
- optimistisch und pessimistisch
synchronisierte Datenobjekte
- pessimistische Synchronisation fr
Hot-Spot-Objekte

3. Kombination

erhhte Verfahrenskomplexitt
auch bei pessimistischer
Synchronisation nderungen in
privatem TA-Puffer
erweiterte Validierung: TA scheitert,
falls unvertrgliche Sperre gesetzt ist
(teilweise) pessimistisch
synchronisierte TA:
- bei EOT optimistische TA
zurcksetzen, die auf X-gesperrte
Objekte zugegriffen haben
- Schreibphase mit anschlieender
Sperrfreigabe
51

Synchronisation

bersicht

Einfhrung

Sperrverfahren (pessimistische Synchronisation)

Zweiphasen-Sperrprotokolle
Konsistenzstufen von Transaktionen
Hierarchische Sperrverfahren
Deadlock-Behandlung

Optimistische Synchronisation

Anomalien
Serialisierbarkeit

BOCC
FOCC
Kombination von OCC und Sperrverfahren

berblick ber weitere Konzepte

Allgemeines Mehrversionenkonzept
Zeitstempel-Verfahren
Prdikatsperren
Synchronisation bei "High Traffic"-Elementen

52

Synchronisation

Mehrversionenverfahren
Prinzip
nderungs-TA erzeugen neue Objektversionen
- es kann immer nur eine neue Version pro Objekt erzeugt werden
- sie wird bei EOT der TA freigegeben

Lese-TA sehen den bei ihrem BOT gltigen DB-Zustand


- sie greifen immer auf die jngsten Objektversionen zu, die bei ihrem BOT
freigegeben waren
- sie setzen und beachten keine Sperren

Beispiel
T1

w(A
0

A )
1

w(B
0

B )
1
w(A
1

A )
2

T2
r(B

Tr

)
0

r(A )
0

53

Synchronisation

Mehrversionenverfahren

Beispiel fr Objekt x: Zeitliche Reihenfolge der Zugriffe auf x


bj

wm(x)
wn(x)
cm

wn(x)
rj(x)
cn

Vi sei aktuelle Version bei BOT


Erzeugen Vi+1
Verzgern bis EOT von Tm
Freigeben Vi+1
Erzeugen Vi+2
Vi
Freigeben Vi+2

Vi
Vi-1

Konsequenz: deutlich weniger Synchronisationskonflikte


Lese-TA werden bei der Synchronisation nicht mehr bercksichtigt
Fr Lese-TA gibt es keine Blockierungen und Rcksetzungen,
dafr ggf. Zugriff auf veraltete Objektversionen
nderungs-TA werden untereinander ber ein allgemeines Verfahren
(Sperren, OCC, . . .) synchronisiert

54

Synchronisation

Mehrversionenverfahren
zustzlicher Speicher- und Wartungsaufwand
- Versionenpoolverwaltung, Garbage Collection
- Auffinden von Versionen
DB mit aktuellen
Versionen
T5

Versionenpool
(Teil des DB-Puffers)

Ai+2

T2

Ai

Bi
Ck

T4

Ai+1

- Speicherplatzoptimierung: Versionen auf Satzebene, Einsatz von


Komprimierungstechniken

Einsatz in einigen kommerziellen DBMS (z.B. Oracle)

55

Synchronisation

Zeitstempelverfahren

Grundstzliche Idee:
Transaktion bekommt bei BOT einen systemweit eindeutigen Zeitstempel
Transaktion hinterlsst den Wert ihres Zeitstempels (als Lese- oder
Schreibstempel RTS bzw. WTS) bei jedem Objekt Oi, auf das sie zugreift
Prfung der Serialisierbarkeit ist sehr einfach (Zeitstempelvergleich)
Prinzipielle Arbeitsweise
Eindeutige TA-IDs (Zeitstempel ts der TA) in aufsteigender Reihenfolge
Zeitstempel des Objektes O: TS(O)
Zugriffe von T auf O (rts(T)/wts(T)): TS(O) := ts(T)
Konfliktprfung: if ts(T)<TS(O) then ABORT
else verarbeite

Zugriffsfolge auf Objekt O:


TS(O)

r1

r3

w5

w4

r11

r9

11

11

kein Konflikt
bei T9!
56

Synchronisation

Zeitstempelverfahren
Verfeinerung des Zeitstempelverfahrens
2 Zeitstempel pro Objekt
- Erhhung beim Schreiben: WTS
- Erhhung beim Lesen: RTS

Regeln fr Ti und O: (Abk. ts(Ti) = i)


R1:
R2:
R3:

ri (iWTS(O)) if RTS(O) < i then RTS(O) := i;


wi (iRTS(O)) (iWTS(O)) WTS(O) := i;
wi (iRTS(O)) (i<WTS(O)) weiter

R4:
R5:

wi (i<RTS(O)) Zurcksetzen
ri (i<WTS(O)) Zurcksetzen

r5

r1

w3

w6

r4

w5

r9

r8

RTS(O)

WTS(O)

Regel

R1

R1

R4

R2

R5

R3

R1

R1

Lesen
ndern
kein Konflikt
(blind update)
keine Schreibakt.

57

Synchronisation

Zeitstempelverfahren

TA T wird zurckgesetzt, falls

bei Lesezugriff ts(T)<WTS


und bei Schreibzugriff
ts(T)<max(RTS,WTS) gilt (ohne
Bercksichtigung von blind updates)
T1

w(x)
r(x)

T2
T3

r(z)

w(z)

abort
dirty read

Vorkehrungen fr den ABORT-Fall


sofortige Zulassung aller
Schreiboperationen erzeugt
inkonsistente DB
Einfrieren der Zeitstempel bis
COMMIT der ndernden TA
Erwerb von Anwartschaften:
Prewrites
Prewrite i verzgert rj, wj mit j > i
Einfhrung von Read-queues,
Prewrite-queues und Write-queues

58

Synchronisation

Zeitstempelverfahren

Eigenschaften
Serialisierungsreihenfolge einer Transaktion wird bei BOT festgelegt
Deadlocks sind ausgeschlossen
aber: (viel) hhere Rcksetzraten als pessimistische Verfahren
ungelste Probleme, z.B. wiederholter ABORT einer Transaktion
Hauptschlicher Einsatz
Synchronisation in Verteilten DBS
lokale Prfung der Serialisierbarkeit direkt am Objekt Oi
(geringer Kommunikationsaufwand)

59

Synchronisation

Prdikatsperren

Logische Sperren
Minimaler Sperrbereich durch geeignete Wahl des Prdikats
Verhtung des Phantomproblems
Eleganz

Form:

LOCK (R, P, a), UNLOCK (R, P)


R: Relationenname; P: Prdikat; a {read, write}
Lock (R, P, write) sperrt alle mglichen Tupel von R, die Prdikat P erfllen, exklusiv
Beispiel:
T1:
LOCK(R1, P1, read)
T2:
...
LOCK(R2, P2, write)
LOCK(R2, P3, write)
LOCK(R1, P5, write)
LOCK(R1, P4, read)
...
...

Problem: Konfliktfeststellung
im allgemeinen Fall rekursiv unentscheidbar, selbst mit eingeschrnkten arithmetischen
Operatoren
entscheidbare Klasse: einfache Prdikate der Form (A Wert) {, } (. . .
Quelle: [EG+76]

60

Synchronisation

Prdikatsperren
Entscheidungsprozedur

Lock(R, P, a)

Lock(R', P', a')

Wenn R R', kein Konflikt


Wenn a = read und a' = read, kein Konflikt
Wenn P(t) P'(t) = TRUE fr irgendein t, dann besteht ein Konflikt

Beispiel
T1:
LOCK (Pers, Alter > 50, read)

T2:
LOCK (Pers, Pnr = 4711, write)

61

Synchronisation

Prdikatsperren
Nachteile
Erfllbarkeitstest: aufwendige Entscheidungsprozedur; i.d.R. mit vielen
Prdikaten (N > 100); wird in innerer Schleife des Lock-Mgr. hufig
aufgerufen)
pessimistische Entscheidungen Einschrnkung der Parallelitt (es wird auf
Erfllbarkeit getestet !)
Einsatz nur bei deskriptiven Sprachen!
Sonderfall: P=TRUE entspricht einer Relationensperre groe
Sperrgranulate, geringe Parallelitt

Effizientere Implementierung: Przisionssperren

62

Synchronisation

Przisionssperren

nur gelesene Daten werden durch Prdikate gesperrt


fr aktualisierte Tupel werden Schreibsperren gesetzt
kein Disjunktheitstest fr Prdikate mehr erforderlich, sondern lediglich zu berprfen, ob
Tupel ein Prdikat erfllt
Datenstrukturen

Prdikatliste: Lesesperren laufender TA werden durch Prdikate beschrieben


(Pers: Alter > 50 and Beruf = Prog.)
(Pers: Pname = Meier and Gehalt > 50000)
(Abt: Anr = K55)
...
Update-Liste: enthlt genderte Tupel laufender TA
(Pers: 4711, Mller, 30, Prog., 70000)
(Abt: K51, DBS, . . .)
...

Leseanforderung (Prdikat P):


fr jedes Tupel der Update-Liste ist zu prfen, ob es P erfllt
wenn ja Sperrkonflikt

Schreibanforderung (Tupel T):


fr jedes Prdikat P der Prdikatliste ist P(T) zu prfen
wenn T keines erfllt Schreibsperre wird gewhrt
Quelle: [JBB81]

63

Synchronisation

Synchronisation von High-Traffic-Objekten


High-Traffic-Objekte
meist numerische Felder mit aggregierten Informationen, z. B.
- Anzahl freier Pltze
- Summe aller Kontostnde

Behandlung
Einfachste Lsung der Sperrprobleme: Vermeidung solcher Attribute beim DBEntwurf
Alternative
- Nutzung von semantischem Wissen zur Synchronisation wie Kommutativitt von
nderungsoperationen auf solchen Feldern
- Beispiel: Inkrement/Dekrement
R

Inc/Dec

Inc/Dec

+
64

Synchronisation

Escrow-Ansatz
Deklaration von High-Traffic-Objekten als Escrow-Felder
Benutzung spezieller Operationen
Anforderung einer bestimmten Wertemenge
- IF
ESCROW (field=F1, quantity=C1, test=(condition))
THEN continue with normal processing
ELSE perform exception handling

Benutzung der reservierten Wertmengen:


- USE (field=F1, quantity=C2)

optionale Spezifikation eines Bereichstest bei Escrow-Anforderung


wenn Anforderung erfolgreich ist, kann Prdikat nicht mehr nachtrglich
invalidiert werden

Quelle: [ONe86]

65

Synchronisation

Escrow-Ansatz
aktueller Wert eines Escrow-Feldes
ist unbekannt, wenn laufende TA Reservierungen angemeldet haben
Fhren eines Werteintervalls, das alle mglichen Werte nach Abschluss der
laufenden TA umfasst
fr Wert Qk des Escrow-Feldes k gilt
- LOk INFk Qk SUPk HIk
- Anpassung von INF, Q, SUP bei Anforderung, Commit und Abort einer TA

Eigenschaften
- Durchfhrung von Bereichstests bezglich des Werteintervalls
- Minimal-/Maximalwerte (LO, HI) drfen nicht berschritten werden
- hohe Parallelitt ndernder Zugriffe mglich

Nachteile
- spezielle Programmierschnittstelle
- tatschlicher Wert ggf. nicht abrufbar

66

Synchronisation

Escrow-Ansatz
Beispiel: Zugriffe auf Feld mit LO = 0, HI = 500 (Anzahl freier Pltze)

T1

T2

T3

T4

-5
-8
+4
-3
c
c
a

INF

SUP

15

15

15

10

10

15

15

19

14

14

14

14

14

-1

67

Synchronisation

Zusammenfassung

Korrektheitskriterium der Synchronisation: Serialisierbarkeit


Sperrverfahren sind universell einsetzbar

Hierarchische Synchronisationsverfahren erlauben Begrenzung des Verwaltungsaufwands


generelle Optimierungen:

Zweiphasen-Sperrprotokolle
reine OCC- und Zeitstempelverfahren erzeugen zu viele Rcksetzungen

reduzierte Konsistenzebene
Mehrversionen-Ansatz

Harte Synchronisationsprobleme:
-

Hot Spots / High Traffic-Elemente


lange (nderung-) TA

wenn Vermeidungsstrategie nicht mglich, sind zumindest fr Hochleistungssysteme


Spezialprotokolle anzuwenden
Nutzung semantischen Wissens ber Operationen / Objekte zur Reduzierung von
Synchronisationskonfliken
allerdings
-

ggf. Erweiterung der Programmierschnittstelle


begrenzte Einsetzbarkeit
Zusatzaufwand

68

Synchronisation

Literatur zu diesem Kapitel


[EG+76]
[JBB81]
[ONe86]
[Wei94]

Kapali P. Eswaran, Jim Gray, Raymond A. Lorie, Irving L. Traiger: The


Notions of Consistency and Predicate Locks in a Database System. In:
Communications of the ACM 19:11, 1976.
J.R. Jordan, J. Banerjee, R.B. Batman: Precision
Locks, In: Proc. ACM SIGMOD, 1981.
P. ONeil: The Escrow Transactional Method, In: ACM Transations on
Database Systems 11: 4, 1986.
Weikum, G. et al.: The Comfort Automatic Tuning Project,
In: Information Systems 19:5, 1994.

69