chapter10.pdf

Anwendersoftware (AS) 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

2

bersicht

Einfhrung Anomalien Serialisierbarkeit

Sperrverfahren (pessimistische Synchronisation) Zweiphasen-Sperrprotokolle Hierarchische Sperrverfahren Konsistenzstufen von Transaktionen Deadlock-Behandlung

Optimistische Synchronisation BOCC FOCC Kombination von OCC und Sperrverfahren

berblick ber weitere Konzepte Allgemeines Mehrversionenkonzept Zeitstempel-Verfahren Prdikatsperren Synchronisation bei "High Traffic"-Elementen

Synchronisation

3

Gefhrdung der DB-Konsistenz

Gefhrdung der DB- Konsistenz durch

Korrektheit der Abbildungshierarchie

bereinstimmung zwischen DB und Miniwelt

das Anwendungsprogramm

Mehrbenutzer-Anomalien Synchronisation

(Concurrency Control)

unzulssige nderungen Integrittsberwachung

des DBMS TA-orientierte Verarbeitung

das DBMS und die Betriebsumgebung

Fehler auf den Externspeichern, Inkonsistenzen in den Zugriffspfaden Fehlertolerante

Implementierung Archivkopien (Backup)

undefinierter DB-Zustand nach einem Systemausfall Transaktionsorientierte

Fehlerbehandlung (Recovery)

Synchronisation

4

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

5

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

6

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

7

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)

Schnittstelle zwischen Anwendungsprogramm (AP) und DBS

SAVEPOINT Definiert einen Sicherungspunkt

innerhalb der Transaktion ROLLBACK [WORK]

TO SAVEPOINT Setzt die aktive Transaktion auf

einen Sicherungspunkt zurck

Synchronisation

8

Mgliche Ausgnge einer Transaktion

BOT BOT BOT

DML1

DML2

DML3

DMLn

COMMIT

normales Ende

DML1

DML2

DML3

DMLn

ROLLBACK

abnormales Ende

DML1

DML2

DML3

abnormales Ende

Systemausfall, Programmfehler, usw.

erzwungenes ROLLBACK

erzwungenes

Synchronisation

9

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

10

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

Synchronisation

11

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

Synchronisation

12

Non-repeatable Read

Inkonsistente Analyse mit Dirty Read Erneutes berechnen der Gehaltssumme in T1 fhrt zu anderem Ergebnis

T1 T2 DB-Inhalt

Lesetransaktion nderungstransaktion (PNR, Gehalt)

2345 39.000

3456 48.000 UPDATE Pers SET Gehalt = Gehalt + 1000 WHERE Pnr = 2345; 2345 40.000

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

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

Zeit

Synchronisation

13

Non-repeatable Read

Inkonsistente Analyse ohne Dirty Read T1 T2

DB-Inhalt

Lesetransaktion nderungstransaktion (PNR, Gehalt)

2345 39.000

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

UPDATE Pers SET Gehalt = Gehalt + 1000 WHERE Pnr = 2345; 2345 40.000 UPDATE Pers SET Gehalt = Gehalt + 2000 WHERE Pnr = 3456; 3456 50.000 COMMIT;

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

Zeit

Synchronisation

14

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;

IF summe1 summe2 THEN

Zeit

Synchronisation

15

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

Synchronisation

16

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

Synchronisation

17

Beispiel

Die Transaktionen T1-T4 mssen so synchronisiert werden, dass der resultierende Zustand der DB gleich dem ist, der bei der seriellen Ausfhrung in einer der folgenden Sequenzen zustande gekommen wre.

(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

T4 r(x)

T2 r(y)

T3 w(x)

T1 r(x) w(y) w(z)

Synchronisation

18

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

Serialisierbarkeit liegt vor, wenn der Abhngigkeitsgraph keine Zyklen enthlt. (Konflikt-Serialisierbarkeit)

T2 r(x)

T1 w(x)

T2 T1

r2(x) w1(x)

Synchronisation

19

Serialisierungsreihenfolge

Serialisierungsreihenfolge: Vollstndige Ordnung zwischen den TA. Diese ergibt sich bei serialisierbaren Schedules aus der durch den Abhngigkeitsgraphen beschriebenen partiellen Ordnung.

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

T4 r(x)

T2 r(y)

T3 w(x)

T1 r(x) w(y) w(z)

T2 T1

T4 T3 r4(x)w3(x)

r2(y)w1(y)

r1(x)w3(x)

Synchronisation

20

Beispiel:

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

Serialisierungsreihenfolge

T2 r(x)

T3 w(y)

T1 w(x) w(y)

T2 T1 T3

w3(y)w1(y) w1(x)r2(x)

Synchronisation

21

bersicht


Sperrverfahren (pessimistische Synchronisation) Zweiphasen-Sperrprotokolle Konsistenzstufen von Transaktionen Hierarchische Sperrverfahren Deadlock-Behandlung



Synchronisation

22

Historische Entwicklung von Synchronisationsverfahren

Exklusive Objektsperren

RX-Sperrverfahren

hierarchische Sperren

optimistische Verfahren (BOCC, FOCC, )

Zeitmarken- verfahren

neuere Sperrverfahren (RAX, RAC, )

Mehrversionen- Verfahren

Spezialverfahren (B*-Bume,

Hot-Spot-Synchronisation, )

Synchronisation

23

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

#Sperren

BOT EOT

#Sperren

BOT EOT

#Sperren

BOT EOT

zweiphasig

strikt zweiphasig

preclaiming

Synchronisation

24

RX-Sperrverfahren

Gewhrter Sperrmodus des Objekts: NL, R, X

Sperranforderung einer Transaktion: R, X

Kompatibilittsmatrix: (NL (no lock) wird meist weggelassen)

Deadlock-Gefahr durch Sperrkonversion

Erweitertes Sperrverfahren Ziel:

Verhinderung von Konversions-Deadlocks

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?

aktueller Modus

NL R X

angeforderter Modus

R + + -

X + - -

T1 r(y) w(y)

T2 r(y) w(y)

R U X

R + - -

U + - -

X - - -

Synchronisation

25

RAX-Sperrverfahren

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 X-Sperren, ggf. auf Freigabe von Lesesperren warten (Deadlock-Gefahr)

Hhere Parallelitt als beim RX-Verfahren, jedoch i.A. andere Serialisierungsreihenfolge: RX: T1 T2

RAX: T2 T1

starke Behinderungen von Update-TA durch (lange) Leser mglich

T1 X(z)

T2 R(z)

R A X

R + -

A - -

X - - -

T1 A(z)

T2 R(z)

A->X

Synchronisation

26

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

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

T1 A(y)

T2 R(z)

R A C

R + +

A + - -

C - -

A(z) AC

R(y)

Synchronisation

27

Implementierungsaspekte

Beispiel: Sperrtabelle / TA-Tabelle fr RAC-Verfahren Hash-Tabelle erlaubt schnellen Zugriff

auf Objektkontrollblcke (OKB) Matrixorganisation Objekt-/TA-Tabelle Kurzzeitsperren fr Zugriffe auf

Objekttabelle (Semaphor pro Hashklasse reduziert Konflikt-/Konvoi-Gefahr)

Synchronisation

28

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 Non-

Repeatable Read

Phantome

READ UNCOMMITTED + + +

READ COMMITTED - + +

REPEATABLE READ - - +

SERIALIZABLE - - -

Synchronisation

29

SQL-Anweisung: 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

SET TRANSACTION [mode] [ISOLATION LEVEL level]

Konsistenzebenen in SQL2

START TRANSACTION [mode] [ISOLATION LEVEL level]

Synchronisation

30

Konsistenzebenen von Transaktionen

Konsistenzebene 3: Transaktion T sieht Konsistenzebene 3, wenn gilt: a) T verndert keine schmutzigen Daten anderer Transaktionen b) T gibt keine nderungen vor EOT frei c) T liest keine schmutzigen Daten anderer Transaktionen d) 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

Synchronisation

31

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)

Synchronisation

32

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) 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)

Verfahren erheblich komplexer als einfache Sperrverfahren (mehr Sperrmodi, Konversionen, Deadlock-Behandlung, ...)

Datenbank

Segment

Tabelle Index

Zeile

Synchronisation

33

Hierarchische Sperrverfahren

Beispiel einer Sperrhierarchie: Datenbank Dateien (Segmente) Tabellen (Satztypen) Tupel

Aufwand fr das Sperren von 1 Satz: 3 + 1 k Stzen: 3 + k 1 Tabelle: 2 + 1

DB

S1 S2 S3

T21 T22

t211

Synchronisation

34

Anwartschaftssperren: I

durch R- und X-Sperre werden alle Nachfolgerknoten implizit mitgesperrt Einsparungen mglich

alle Vorgngerknoten sind ebenfalls zu sperren, um Unvertrglichkeiten zu vermeiden

Verwendung von Anwartschafts-sperren ('intention locks')

I-Sperre : allgemeine Anwartschaftssperre

Beispiel:

Unvertrglichkeit von I- und R-Sperren zu restriktiv!

I R X

I + - -

R - + -

X - - -

I

X

R

T1 T2

I I

I I

I R (wartet)

R

DB

S i

T ij

Synchronisation

35

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:

IR

X

R

IR IX R X

IR + + + -

IX + + - -

R + - + -

X - - - -

IX

T1 T2

IR IR

IR IR

IR R

R

T1 T2

IR IX

IR IX

IR IX

R X

DB

S i

T ij

DB

S i

T ij

Synchronisation

36

Anwartschaftssperren: RIX

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

ist zu restriktiv

IX-Sperre auf Satztyp erfordert Sperren fr jeden Satz

weitere Verfeinerung: RIX = R + IX sperrt das Objekt in R-Modus und verlangt X-Sperren auf tieferer Hierarchieebene nur fr zu ndernde Objekte

X T ij

IX T ij

R X R R

RIX T ij

X

Synchronisation

37

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 R RIX U X

IR + + + + - -

IX + + - - - -

R + - + - - -

RIX + - - - - -

U - - + - - -

X - - - - - -

IR

X

R

IX

RIX U

Synchronisation

38

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

Synchronisation

39

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)

Synchronisation

40

Deadlock-Erkennung

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

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

T1

T2

T3

T4

T5 O1 O1

O2

O5

O3 O4

Synchronisation

41

Beispiel DB2

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

Sperreskalation: Umwandlung von Tupelsperren in Tabellensperren. Mgliche Auslser: Fehlender Platz in der Sperrliste Applikation berschreitet die durch

maxlocks begrenzte Belegung der Sperrliste

Sperren explizit setzen:

Parameter 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

LOCK TABLE name IN [ SHARE | EXCLUSIVE ] MODE

Synchronisation

42

Sperrverfahren in Datenbanksystemen

Zusammenfassung: Aufgabe von Sperrverfahren: Vermeidung von Anomalien, indem

zu ndernde Objekte dem Zugriff aller anderen Transaktionen entzogen werden zu lesende Objekte vor nderungen geschtzt werden

Standardverfahren: Hierarchisches Zweiphasen-Sperrprotokoll mehrere Sperrgranulate Verringerung der Anzahl der Sperranforderungen

Probleme bei der Implementierung von Sperren: 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)

Synchronisation

43

bersicht





Synchronisation

44

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

Synchronisation

45

OCC: Phasen einer Transaktion

Read-Phase:

Fhre TA aus, kapsele dabei Write-Operationen in einem privaten Workspace

Validate-Phase (Certifier): Wenn Ti Commit ausfhrt, teste mit Hilfe von Read-Sets RS und Write-Sets 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)

Read Validate Write

BOT COMMIT

Datenbank

DB-Puffer

T1 T2

Lesen Schreiben Lesen Schreiben

privater Puffer privater Puffer

Synchronisation

46

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

Synchronisation

47

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

T 1 r 1 (x) w 1 (x) r 1 (y) Validate

Read-Phase Write-Phase

T 2 r 2 (y) w 2 (z) r 2 (z) Validate

T 3 r 3 (x) r 3 (y) Validate

T 4 r 4 (x) w 4 (x) Validate

Abort

Synchronisation

48

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

Synchronisation

49

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

Synchronisation

50

FOCC-Beispiel

T 1 r 1 (x) w 1 (x) r 1 (y) Validate

Read-Phase Write-Phase

T 2 r 2 (y) w 2 (z) r 2 (z) Validate

T 3 r 3 (z)

T 4 r 4 (x) w 4 (x) Validate

Abort

r 4 (y)

T 5 r 5 (x) r 5 (y)

Synchronisation

51

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

Synchronisation

52

bersicht





Synchronisation

53

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

w(A 0 A

1 ) w(B

0 B

1 )

w(A 1

A 2 )

r(B 0 ) r(A 0 )

T1

Tr

T2

Synchronisation

54


Beispiel fr Objekt x: Zeitliche Reihenfolge der Zugriffe auf x bj Vi sei aktuelle Version bei BOT wm(x) Erzeugen Vi+1 wn(x) Verzgern bis EOT von Tm cm Freigeben Vi+1 wn(x) Erzeugen Vi+2 rj(x) Vi cn Freigeben Vi+2

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

ViVi-1

Synchronisation

55


zustzlicher Speicher- und Wartungsaufwand - Versionenpoolverwaltung, Garbage Collection - Auffinden von Versionen

- Speicherplatzoptimierung: Versionen auf Satzebene, Einsatz von Komprimierungstechniken

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

DB mit aktuellen Versionen

Versionenpool

T5 T2

T4 B i C k

A i+2

A i+1

A i

(Teil des DB-Puffers)

Synchronisation

56

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:

Zugriffsfolge auf Objekt O:

if ts(T)

Synchronisation

57


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: ri (iWTS(O)) if RTS(O) < i then RTS(O) := i; Lesen R2: wi (iRTS(O)) (iWTS(O)) WTS(O) := i; ndern R3: wi (iRTS(O)) (i

Synchronisation

58


TA T wird zurckgesetzt, falls bei Lesezugriff ts(T)

Synchronisation

59


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)

Synchronisation

60

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]

Synchronisation

61

Prdikatsperren

Entscheidungsprozedur 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: T2: LOCK (Pers, Alter > 50, read) LOCK (Pers, Pnr = 4711, write)

Lock(R, P, a) Lock(R', P', a')

Synchronisation

62

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

Synchronisation

63

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]

Synchronisation

64

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 DB-

Entwurf Alternative

- Nutzung von semantischem Wissen zur Synchronisation wie Kommutativitt von nderungsoperationen auf solchen Feldern

- Beispiel: Inkrement/Dekrement

R X Inc/Dec

R + - -

X - - -

Inc/Dec - - +

Synchronisation

65

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]

Synchronisation

66

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

Synchronisation

67

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 Q SUP

15 15 15

10 10 15

2 2 15

2 6 19

-1

2 6 14

6 6 14

14 14 14

Synchronisation

68

Zusammenfassung

Korrektheitskriterium der Synchronisation: Serialisierbarkeit Sperrverfahren sind universell einsetzbar

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

Hierarchische Synchronisationsverfahren erlauben Begrenzung des Verwaltungsaufwands generelle Optimierungen:

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

Synchronisation

69

Literatur zu diesem Kapitel

[EG+76] 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.

[JBB81] J.R. Jordan, J. Banerjee, R.B. Batman: Precision Locks, In: Proc. ACM SIGMOD, 1981.

[ONe86] P. ONeil: The Escrow Transactional Method, In: ACM Transations on Database Systems 11: 4, 1986.

[Wei94] Weikum, G. et al.: The Comfort Automatic Tuning Project, In: Information Systems 19:5, 1994.

Datenbanken und InformationssystemebersichtGefhrdung der DB-KonsistenzAblaufkontrollstruktur: Transaktion (TA)ACID-Eigenschaften von TransaktionenACID-Eigenschaften von TransaktionenSchnittstelle zwischen Anwendungsprogramm (AP) und DBSMgliche Ausgnge einer TransaktionWarum Mehrbenutzerbetrieb?Lost UpdateDirty ReadNon-repeatable ReadNon-repeatable ReadPhantom-ProblemModellannahmenSerialisierbarkeitBeispielNachweis der SerialisierbarkeitSerialisierungsreihenfolgeSerialisierungsreihenfolgebersichtHistorische Entwicklung von SynchronisationsverfahrenZweiphasen-Sperrprotokolle (2PL)RX-SperrverfahrenRAX-SperrverfahrenRAC-SperrverfahrenImplementierungsaspekteKonsistenzebenen in SQL2Konsistenzebenen in SQL2Konsistenzebenen von TransaktionenKonsistenzebenen von TransaktionenHierarchische SperrverfahrenHierarchische SperrverfahrenAnwartschaftssperren: IAnwartschaftssperren: IR, IXAnwartschaftssperren: RIXAnwartschaftssperrenAnwartschaftssperrenDeadlock-BehandlungDeadlock-ErkennungBeispiel DB2Sperrverfahren in DatenbanksystemenbersichtOptimistic Concurrency Control (OCC)OCC: Phasen einer TransaktionOCC: VerfahrenBackward-Oriented OCCBackward-Oriented OCCForward-Oriented OCCFOCC-BeispielKombination von OCC und SperrverfahrenbersichtMehrversionenverfahrenMehrversionenverfahrenMehrversionenverfahrenZeitstempelverfahrenZeitstempelverfahrenZeitstempelverfahrenZeitstempelverfahrenPrdikatsperrenPrdikatsperrenPrdikatsperrenPrzisionssperrenSynchronisation von High-Traffic-ObjektenEscrow-AnsatzEscrow-AnsatzEscrow-AnsatzZusammenfassungLiteratur zu diesem Kapitel

chapter10.pdf

Documents

Transcript of chapter10.pdf