Einführung - Anomalien beim ungeschützten und konkurrierenden Zugriff von Lesern und Schreibern auf gemeinsame Daten

Transkript

1 Synchronisation 0 Einführung - Anomalien beim ungeschützten und konkurrierenden Zugriff von Lesern und Schreibern auf gemeinsame Daten - Synchronisation von Transaktionen: Grundbegriffe und Modellannahmen - Serialisierbarkeit: Definition und Eigenschaften Sperrverfahren (pessimistische Synchronisation) - Zweiphasen-Sperrprotokolle (RX, RAX, RAC) - Implementierungsaspekte - Konsistenzstufen von Transaktionen - Hierarchische Sperrverfahren - Deadlock-Behandlung Optimistische Synchronisation - BOCC - FOCC Überblick über weitere Konzepte - Allgemeines Mehrversionenkonzept - Zeitstempel-Verfahren - Prädikatsperren - Synchronisation bei High Traffic-Elementen Thomasian, A.: Concurrency Control: Methods, Performance, and Analysis, in: ACM Computing Surveys 30:1, March 1998, pp Synchronisation 0

2 Gefährdung der DB-Konsistenz 1 Korrektheit der Abbildungshierarchie Mehrbenutzer- Anomalien, Synchronisation durch das Anwendungsprogramm durch das DBVS und die Betriebsumgebung Fehler auf den Externspeichern, Inkonsistenzen in den Zugriffspfaden, Fehlertolerante Implementierung Übereinstimmung zwischen DB und Miniwelt unzulässige Änderungen, Integritätsüberwachung des DBVS TAorientierte Verarbeitung undefinierter DB-Zustand nach einem Systemausfall Transaktionsorientierte Fehlerbehandlung (Recovery) Gefährdung der DB-Konsistenz 1

3 Anomalien im Mehrbenutzerbetrieb ohne Synchronisation 2 1. Verlorengegangene Änderungen (lost updates) 2. Abhängigkeiten von nicht freigegebenen Änderungen (dirty read, dirty overwrite) 3. Inkonsistente Analyse (non-repeatable read) 4. Phantom-Problem nur durch Änderungs-TA verursacht Anomalien im Mehrbenutzerbetrieb ohne Synchronisation 2

4 Anomalien im Mehrbenutzerbetrieb ohne Synchronisation 3 Anomalien im Mehrbenutzerbetrieb ohne Synchronisation 3

5 Inkonsistente Analyse (Non-repeatable Read)4 Inkonsistente Analyse (Non-repeatable Read)4

6 Phantom-Problem 5 Phantom-Problem 5

7 Synchronisation von Transaktionen: Modellannahmen 6 TRANSAKTION: Ein Programm T mit DML-Anweisungen, das folgende Eigenschaft erfüllt: Wenn T allein auf einer konsistenten DB ausgeführt wird, dann terminiert T (irgendwann) und hinterläßt die DB in einem konsistenten Zustand. (Während der TA-Verarbeitung werden keine Konsistenzgarantien eingehalten) Wenn Transaktionen seriell ausgeführt werden, dann bleibt die Konsistenz der DB erhalten. Modellbildung für die Synchronisation DML-Anweisungen lassen sich nachbilden durch Leseund Schreiboperationen auf Objekten (z. B. Seiten) - READ (O) - WRITE (O:=4) DBVS sieht eine TA wie folgt: BOT, Folge von READ- und WRITE-Anweisungen auf Objekte, EOT Ablauffolge von TA mit Operationen kann durch Plan (Schedule) beschrieben werden: Beispiel: r 1 (x), r 2 (x), r 3 (y), w 1 (x), w 3 (y), r 1 (y), c 1, r 3 (x), w 2 (x), a 2, w 3 (x), c 3,. Beispiel eines seriellen Plans: r 1 (x), w 1 (x), r 1 (y), c 1, r 3 (y), w 3 (y), r 3 (x), c 3, r 2 (x), w 2 (x), c 2,... BOT ist implizit, EOT wird durch c i (commit) oder a i (abort) dargestellt Synchronisation von Transaktionen: Modellannahmen 6

8 Korrektheitskriterium der Synchronisation 7 Ziel der Synchronisation: logischer Einbenutzerbetrieb, d. h. Vermeidung aller Mehrbenutzeranomalien Gleichbedeutend mit dem formalen Korrektheitskriterium der Serialisierbarkeit: Die parallele Ausführung einer Menge von Transaktionen ist serialisierbar, wenn es eine serielle Ausführung derselben TA-Menge gibt, die den gleichen DB-Zustand und die gleichen Ausgabewerte wie die ursprüngliche Ausführung erzielt. Hintergrund: - serielle Ablaufpläne sind korrekt - jeder Ablaufplan, der denselben Effekt wie ein serieller erzielt, ist akzeptierbar Korrektheitskriterium der Synchronisation 7

9 Korrektheitskriterium der Synchronisation 8 Nachweis der Serialisierbarkeit: - Führen von zeitlichen Abhängigkeiten zwischen TA in einem Abhängigkeitsgraphen - Abhängigkeit (Konflikt) besteht, wenn zwei TA auf dasselbe Objekt mit nicht reihenfolgeunabhängigen Operationen zugreifen (z. B. Schreib-/Lese-, Lese-/Schreib-, Schreib- /Schreib-Konflikte) - Serialisierbarkeit liegt vor, wenn der Abhängigkeitsgraph keine Zyklen enthält Abhängigkeitsgraph beschreibt partielle Ordnung zwischen TA, die sich zu einer vollständigen erweitern läßt (Serialisierungsreihenfolge) Korrektheitskriterium der Synchronisation 8

10 Historische Entwicklung von Synchronisationsverfahren 9 Historische Entwicklung von Synchronisationsverfahren 9

11 Zweiphasen-Sperrprotokolle (2PL) 10 Einhaltung folgender Regeln gewährleistet Serialisierbarkeit : 1. Vor jedem Objektzugriff muß Sperre mit ausreichendem Modus angefordert werden 2. Gesetzte Sperren anderer TA sind zu beachten 3. Eine TA darf nicht mehrere Sperren für 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. Spätestens bei EOT sind alle Sperren freizugeben Eswaran, K.P. et al.: The notions of consistency and predicate locks in a data base system. Comm. ACM 19: Zweiphasen-Sperrprotokolle (2PL) 10

12 Zweiphasen-Sperrprotokolle (2PL) 11 Zweiphasen-Sperrprotokolle (2PL) 11

13 RX - Sperrverfahren 12 - Gewährter Sperrmodus des Obj.: NL, R, X - Sperranforderung einer Transaktion: R, X - Kompatibilitätsmatrix: Deadlock-Gefahr durch Sperrkonversionen: RX - Sperrverfahren 12

14 RX - Sperrverfahren 13 Erweitertes Sperrverfahren: - Ziel: Verhinderung von Konversions-Deadlocks - U-Sperre für Lesen mit Änderungsabsicht - bei Änderung Konversion U X, andernfalls U R (downgrading) - u. a. in IBM DB2 eingesetzt - das Verfahren ist unsymmetrisch was würde eine Symmetrie bei U bewirken? RX - Sperrverfahren 13

15 RAX-Sperrverfahren 14 - Änderungen erfolgen in temporärer Objektkopie, paralleles Lesen der gültigen 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) - höhere Parallelität als beim RX-Verfahren, jedoch i. a. andere Serialisierungsreihenfolge: - starke Behinderungen von Update-TA durch (lange) Leser möglich RAX-Sperrverfahren 14

16 RAC-Sperrverfahren 15 - Änderungen erfolgen ebenfalls in temporärer Objektkopie, A-Sperre erforderlich - bei EOT Konversion von A C-Sperre - C-Sperre zeigt Existenz zweier gültiger Objektversionen an kein Warten auf Freigabe von Lesesperren auf alter Version (R- und C- Modus sind verträglich) - maximal 2 Versionen, da C-Sperren mit sich selbst und mit A-Sperren unverträglich sind RAC-Sperrverfahren 15

17 RAC-Sperrverfahren 16 - Leseanforderungen bewirken nie Blockierung/Rückse jedoch: Auswahl der richtigen Version erforderlich (z. B. über Abhängigkeitsgraphen) - Änderungs-TA, die auf C-Sperre laufen, müssen warten, bis alle Leser der alten Version beendet, weil nur 2 Versionen Abhilfe: allgemeines Mehrversionen-Konzept RAC-Sperrverfahren 16

18 Konsistenzebenen von Transaktionen 17 Ebene 3: Transaktion T sieht Konsistenzebene 3, wenn gilt: a) T verändert 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 verändert Ebene 2: Transaktion T sieht Konsistenzebene 2, wenn sie die Bedingungen a, b und c erfüllt Ebene 1: Transaktion T sieht Konsistenzebene 1, wenn sie die Bedingungen a und b erfüllt Ebene 0: Transaktion T sieht Konsistenzebene 0, wenn sie nur Bedingung a erfüllt Konsistenzebenen von Transaktionen 17

19 Konsistenzebenen 18 Konsistenzebene 3 (Serialisierbarkeit): - wünschenswert, jedoch oft viele Sperrkonflikte wegen langer Schreib- und Lesesperren Konsistenzebene 2: - nur lange Schreibsperren, jedoch kurze Lesesperren - unrepeatable read möglich Konsistenzebene 1: - lange Schreibsperren, keine Lesesperren - dirty read (und lost update) möglich Konsistenzebene 0: - kurze Schreibsperren (Chaos) Kommerzielle DBS verwenden meist Konsistenzebene 2 Wahlangebot Einige DBS (DB2, Tandem NonStop SQL,...) bieten Wahlmöglichkeit zwischen: - repeatable read (Ebene 3) und - cursor stability (Ebene 2) Einige DBS bieten auch BROWSE-Funktion, d. h. Lesen ohne Setzen von Sperren (Ebene 1) Konsistenzebenen 18

20 Konsistenzebenen in SQL SQL2 erlaubt Wahl zwischen vier Konsistenzebenen (Isolation Level) bezüglich Synchronisation SQL2 definiert die Konsistenzebenen über die Anomalien, die jeweils in Kauf genommen werden - 0 : uncommitted read - 1 : committed read - 2 : repeatable read - 3 : serializable Zuordnung der Anomalien - Lost-Update muß generell vermieden werden - SQL-Anweisung zum Setzen der Konsistenzebene: SET TRANSACTION <tx mode>, <isolation level> TA-Modus: READ WRITE (Default) o. READ ONLY Bsp.: SET TRANSACTION READ ONLY, 1 Konsistenzebenen in SQL2 19

21 Hierarchische Sperrverfahren 20 Sperrgranulat bestimmt Parallelität/Aufwand feines Granulat reduziert Sperrkonflikte, jedoch sind viele Sperren anzufordern und zu verwalten Hierarchische Verfahren erlauben Flexibilität bei Wahl des Granulates (multigranularity locking), z. B. - lange TA auf Relationenebene - kurze TA auf Tupelebene synchronisieren kommerzielle DBS unterstützen zumeist mindestens 2-stufige Objekthierarchie, z. B. Hierarchische Sperrverfahren 20

22 Hierarchische Sperrverfahren 21 Verfahren nicht auf reine Hierarchien beschränkt, sondern auch auf halbgeordnete Objektmengen erweiterbar. Verfahren erheblich komplexer als einfache Sperrverfahren (mehr Sperrmodi, Konversionen, Deadlock Behandlung,...) Hierarchische Sperrverfahren 21

23 Beispiel einer Sperrhierarchie 22 Beispiel einer Sperrhierarchie 22

24 Hierarchische Sperrverfahren: Anwartschaftssperren 23 Mit R- und X-Sperre werden alle Nachfolgerknoten implizit mitgesperrt Einsparungen möglich Alle Vorgängerknoten sind ebenfalls zu sperren, um Unverträglichkeiten zu vermeiden Verwendung von Anwartschaftssperren (intention locks) Allgemeine Anwartschaftssperre (I-Sperre) Unverträglichkeit von I- u. R-Sperren zu restriktiv zwei Arten von Anwartschaftssperren (IR und IX) Hierarchische Sperrverfahren: Anwartschaftssperren 23

25 Anwartschaftssperren 24 Anwartschaftssperren für Leser und Schreiber IR-Sperre (intent read), falls auf untergeordneten Objekten nur lesend zugegriffen wird, sonst IX-Sperre Anwartschaftssperren 24

26 Anwartschaftssperren 25 Weitere Verfeinerung sinnvoll, um den Fall zu unterstützen, wo alle Tupel eines Satztyps gelesen und nur einige davon geändert werden sollen - X-Sperre auf Satztyp sehr restriktiv - IX-Sperre auf Satztyp verlangt Sperren jedes Tupels neuer Typ von Anwartschaftssperre: RIX = R + IX - sperrt das Objekt in R-Modus und verlangt - X-Sperren auf tieferer Hierarchieebene nur für zu ändernde Objekte Anwartschaftssperren 25

27 Anwartschaftssperren 26 Vollständiges 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 gewährt ein Leserecht auf den Knoten und seine Nachfolger. Dieser Modus repräsentiert die Absicht, den Knoten in der Zukunft zu verändern. Bei Änderung Konversion U X, sonst U R. Anwartschaftssperren 26

28 Anwartschaftssperren 27 Sperrdisziplin erforderlich - Sperranforderungen von der Wurzel zu den Blättern - Bevor T eine R- oder IR-Sperre für einen Knoten anfordert, muß sie für alle Vorgängerknoten IX- oder IR-Sperren besitzen - Bei einer X-, U-, RIX- oder IX-Anforderung müssen alle Vorgängerknoten in RIX oder IX gehalten werden - Sperrfreigaben von den Blättern zu der Wurzel - Bei EOT sind alle Sperren freizugeben Anwartschaftssperren 27

29 Deadlock-Behandlung 28 Voraussetzungen für 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 Lösungsmöglichkeiten: 1. Timeout-Verfahren - TA wird nach festgelegter Wartezeit auf Sperre zurückgesetzt - problematische Bestimmung des Timeout- Wertes 2. Deadlock-Verhütung (Prevention) - keine Laufzeitunterstützung zur Deadlock- Behandlung erforderlich - Bsp.: Preclaiming (in DBS i. a. nicht praktikabel) Deadlock-Behandlung 28

30 Deadlock-Behandlung Deadlock-Vermeidung (Avoidance) - potentielle Deadlocks werden im voraus erkannt und durch entsprechende Maßnahmen vermieden Laufzeitunterstützung nötig 4. Deadlock-Erkennung (Detection) Deadlock-Behandlung 29

31 Deadlock-Erkennung 30 Explizites Führen eines Wartegraphen (waitfor graph) und Zyklensuche zur Erkennung von Verklemmungen Deadlock-Auflösung durch Zurücksetzen einer oder mehrerer am Zyklus beteiligter TA (z. B. Verursacher oder billigste TA zurücksetzen) Zyklensuche entweder - bei jedem Sperrkonflikt bzw. - verzögert (z. B. über Timeout gesteuert) Deadlock-Erkennung 30

32 Sperrverfahren in Datenbanksystemen 31 Aufgabe von Sperrverfahren: Vermeidung von Anomalien, indem - zu ändernde Objekte dem Zugriff aller anderen Transaktionen entzogen werden - zu lesende Objekte vor Änderungen geschützt werden Standardverfahren: Hierarchisches Zweiphasen- Sperrprotokoll - mehrere Sperrgranulate - Verringerung der Anzahl der Sperranforderungen Probleme bei der Implementierung von Sperren - kleine Sperreinheiten (wünschenswert) erfordern hohen Aufwand - Sperranforderung und -freigabe sollten sehr schnell erfolgen, da sie sehr häufig benötigt werden Sperrverfahren in Datenbanksystemen 31

33 Sperrverfahren in Datenbanksystemen 32 - explizite, satzweise Sperren führen u. U. zu umfangreichen Sperrtabellen und großem Zusatzaufwand - Zweiphasigkeit der Sperren führt häufig zu langen Wartezeiten (starke Serialisierung) - häufig berührte Zugriffspfade können zu Engpässen werden - Eigenschaften des Schemas können hot spots erzeugen Optimierungen: - Änderungen auf privaten Objektkopien (verkürzte Dauer exklusiver Sperren) - Nutzung mehrerer Objektversionen - spezialisierte Sperren (Nutzung der Semantik von Änderungsoperationen) Sperrverfahren in Datenbanksystemen 32

34 Optimistische Synchronisation 33 3-phasige Verarbeitung: Lesephase - eigentliche TA-Verarbeitung - Änderungen einer Transaktion werden in privatem Puffer durchgeführt Optimistische Synchronisation 33

35 Optimistische Synchronisation 34 Validierungsphase - Überprüfung, ob ein Lese-/Schreib- oder Schreib- /Schreib-Konflikt mit einer der parallel ablaufenden Transaktionen passiert ist - Konfliktauflösung durch Zurücksetzen von Transaktionen Schreibphase - nur bei positiver Validierung - Lese-Transaktion ist ohne Zusatzaufwand beendet - Schreib-Transaktion schreibt hinreichende Log- Information und propagiert ihre Änderungen Optimistische Synchronisation 34

36 Optimistische Synchronisation (OCC) 35 Grundannahme: geringe Konfliktwahrscheinlichkeit Allgemeine Eigenschaften von OCC: + einfache TA-Rücksetzung + keine Deadlocks + potentiell höhere Parallelität als bei Sperrverfahren - mehr Rücksetzungen als bei Sperrverfahren - Gefahr des Verhungerns von TA zur Durchführung der Validierungen werden pro Transaktion der - Read-Set (RS) und - Write-Set (WS) geführt 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 gegenüber bereits beendeten (Änderungs-) TA - Forward Oriented (FOCC): Validierung gegenüber laufenden TA Optimistische Synchronisation (OCC) 35

37 BOCC 36 erstes publizierte Verfahren zur optimistischen Synchronisation Validierung von Transaktion T: BOCC-Test gegenüber allen Änderungs-TA T j, die seit BOT von T erfolgreich validiert haben: IF RS(T ) W S(T j ) THEN ABORT T; ELSE SCHREIBPHASE Kung, H.T., Robinson, J.T.: On optimistic method for concurrency control. ACM Trans. on Database Systems 6: BOCC 36

38 BOCC 37 Nachteile/Probleme: - unnötige Rücksetzungen wegen ungenauer Konfliktanalyse - Aufbewahren der Write-Sets beendeter TA erforderlich - hohe Anzahl von Vergleichen bei Validierung - Rücksetzung erst bei EOT viel unnötige Arbeit - es kann nur die validierende TA zurückgesetzt werden Gefahr von starvation - hohes Rücksetzrisiko für lange TA und bei Hot-Spots BOCC 37

39 FOCC 38 nur Änderungs-TA validieren gegenüber laufenden TA T i Validierungstest: W S(T ) RS(T j ) Vorteile: - Wahlmöglichkeit des Opfers (Kill, Abort, Prioritäten,...) - keine unnötigen Rücksetzungen - frühzeitige Rücksetzung möglich Einsparen unnötiger Arbeit - keine Aufbewahrung von Write-Sets, geringerer Validierungsaufwand als bei BOCC Härder, T.: Observations on optimistic concurrency control schemes. Information Systems 9: FOCC 38

40 FOCC 39 Probleme: - Während Validierungs- und Schreibphase muß W S(T ) gesperrt sein, damit sich die RS(T i ) nicht ändern (keine Deadlocks damit möglich) - immer noch hohe Rücksetzrate möglich - es kann immer nur einer TA Durchkommen definitiv zugesichert werden FOCC 39

41 Mehrversionen-Konzept 40 - jede Änderung erzeugt neue Objektversion - Lese-TA sehen den bei ihrem BOT gültigen DB-Zustand brauchen bei Synchronisation nicht mehr berücksichtigt zu werden - keine Blockierungen und Rücksetzungen für Lese-TA, dafür ggf. Zugriff auf veraltete Objektversionen Änderungs-TA werden untereinander über ein allgemeines Verfahren (Sperren, OCC,...) synchronisiert weniger Synchronisationskonflikte zusätzlicher Speicher- und Wartungsaufwand - Versionenpoolverwaltung - Auffinden von Versionen - Garbage Collection bereits in einigen kommerziellen DBVS eingesetzt (Oracle, RDB) Mehrversionen-Konzept 40

42 Zugriff auf Objektversionen 41 Objekt O k zeitliche Reihenfolge der Zugriffe auf O k Speicherungsschema für Versionen - Versionenpool: Teil des DBS-Puffers - Speicherplatzoptimierung: Versionen auf Satzebene, Einsatz von Komprimierungstechniken Zugriff auf Objektversionen 41

43 Zeitstempel-Verfahren 42 Grundsätzliche Idee - TA bekommt bei BOT einen systemweit eindeutigen Zeitstempel - TA hinterläßt den Wert ihres Zeitstempels (als Lese- oder Schreibstempel RTS bzw. WTS) bei jedem Objekt O i, auf das sie zugreift - Prüfung der Serialisierbarkeit ist sehr einfach (Zeitstempelvergleich) Prinzipielle Arbeitsweise - Vergabe von eindeutigen TA-IDs (Zeitstempel ts der TA) in aufsteigender Reihenfolge - Zeitstempel des Objektes O: T S(O) - Zugriffe von T i auf O (r/w): T S(O) := ts(t i ) - Konfliktprüfung: if T S(T i ) < T S(O) then ABORT; else verarbeite; - Zugriffsfolge auf Objekt O: kein Konflikt bei r 9! Zeitstempel-Verfahren 42

44 Zeitstempel-Verfahren 43 Verfeinerung des Zeitstempelverfahrens - 2 Zeitstempel pro Objekt (a) Erhöhung beim Schreiben: WTS (b) Erhöhung beim Lesen: RTS - Regeln für T i und O: (Abk. ts(t i ) = i) - Zugriffsfolge auf Objekt O: Zeitstempel-Verfahren 43

45 Zeitstempel-Verfahren 44 TA T wird zurückgesetzt, falls ts(t ) < W T S - bei Lesezugriff - und bei Schreibzugriff gilt (ohne Berücksichtigung von blind updates) Vorkehrungen für den ABORT-Fall - sofortige Zulassung aller Schreiboperationen erzeugt inkonsistente DB - Einfrieren der Zeitstempel bis COMMIT der ändernden TA - Erwerb von Anwartschaften: Prewrites - Prewrite i verzögert r j, w j mit j > i - Einführung von Read-queues, Prewrite-queues und Write-queues Zeitstempel-Verfahren 44

46 Zeitstempel-Verfahren 45 Eigenschaften - Serialisierungsreihenfolge einer Transaktion wird bei BOT festgelegt - Deadlocks sind ausgeschlossen - aber: (viel) höhere Rücksetzraten als pessimistische Verfahren - ungelöste Probleme, z. B. wiederholter AB- ORT einer Transaktion Hauptsächlicher Einsatz - Synchronisation in Verteilten DBS - lokale Prüfung der Serialisierbarkeit direkt am Objekt O i (geringer Kommunikationsaufwand) Zeitstempel-Verfahren 45

47 Prädikatssperren 46 Verhütung des Phantomproblems Prädikatssperren oder Logische Sperren - minimaler Sperrbereich - Form: - Lock (R, P, write) sperrt alle möglichen Tupeln von R exklusiv, die Prädikat P erfüllen Eswaran, K.P. et al.: The notions of consistency and predicate locks in a data base system. Commm. ACM 19: Prädikatssperren 46

48 Prädikatssperren 47 Wie kann Konflikt zwischen zwei Prädikaten festgestellt werden? - im allgemeinen Fall rekursiv unentscheidbar, selbst mit eingeschränkten arithmetischen Operatoren - entscheidbare Klasse von Prädikaten: einfache Prädikate (AΘ Wert){, }(... Prädikatssperren 47

49 Prädikatssperren 48 Entscheidungsprozedur 1. Wenn R R, kein Konflikt 2. Wenn a =read und a =read, kein Konflikt 3. Wenn P (t) P (t) =TRUE für irgendein t, dann besteht ein Konflikt Prädikatssperren 48

50 Prädikatssperren 49 T1: LOCK (PERS, ALTER > 50, read) T2: LOCK (PERS, PNR = 4711, write) Entscheidung Bewertung - aufwendige Entscheidungsprozedur mit vielen Prädikaten (N > 100) (wird in innerer Schleife des Lock-Mgr. häufig aufgerufen) - pessimistische Entscheidungen Einschränkung der Parallelität (es wird auf Erfüllbarkeit getestet!) - Sonderfall: P = T RUE entspricht einer Relationensperre große Sperrgranulate, geringe Parallelität Prädikatssperren 49

51 Prädikatssperren 50 effizientere Implementierung: Präzisionssperren - nur gelesene Daten werden durch Prädikat gesperrt, Schreibsperren werden für Tupel gesetzt kein Disjunktheitstest für Prädikate mehr erforderlich, sondern lediglich zu überprüfen, ob Tupel ein Prädikat erfüllt Datenstrukturen: - Prädikatliste: pro Relation werden Lesesperren laufender TA durch Prädikate beschrieben - Update-Liste: enhält geänderte Tupel laufender TA Leseanforderung (Prädikat P): - für jedes Tupel der Update-Liste ist zu prüfen, ob es P erfüllt - wenn ja Sperrkonflikt Schreibanforderung (Tupel T): - für jedes Prädikat P der Prädikatliste ist zu prüfen, ob T es erfüllt - wenn T keines erfüllt Schreibsperre wird gewährt J.R. Jordan, J. Banerjee, R.B. Batman: Precision Locks, Proc. ACM SIGMOD, 1981, pp Prädikatssperren 50

52 Synchronisation von High-Traffic-Objekten 51 High-Traffic-Objekte: meist numerische Felder mit aggregierten Informationen z. B. - Anzahl freier Plätze - Summe aller Kontostände - einfachste Lösung der Sperrprobleme: Vermeidung solcher Felder beim DB-Entwurf - Alternative: Nutzung von semantischem Wissen zur Synchronisation wie Kommutativität von Änderungsoperationen auf solchen Feldern - Bsp.: Inkrement-/Dekrement-Operation Synchronisation von High-Traffic-Objekten 51

53 Escrow-Ansatz 52 - Deklaration von High-Traffic-Attributen als Escrow-Felder Benutzung spezieller Operationen auf Escrow- Feldern: - 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) P. ONeil: The Escrow Transactional Method. ACM Trans. on Database Systems 11: 4, 1986, Escrow-Ansatz 52

54 Escrow-Ansatz 53 - optionale Spezifizierung eines Bereichtests bei Escrow-Anforderung - wenn Anforderung erfolgreich ist, kann Prädikat nicht mehr nachträglich invalidiert werden (keine spätere Validierung/Zurücksetzung) Aktueller Wert eines Escrow-Feldes ist unbekannt, wenn laufende TA Reservierungen angemeldet haben Führen eines Werteintervalls, das alle möglichen Werte nach Abschluß der laufenden TA umfaßt - für Wert Q k des Escrow-Feldes k gilt: LO k IN k Q k SUP k HI k - Anpassung von INF, Q, SUP bei Anforderung, Commit und Abort einer TA Escrow-Ansatz 53

55 Escrow-Ansatz 54 - Beispiel: Zugriffe auf Feld mit LO = 0, HI = 500 (Anzahl freier Plätze) - Durchführung von Bereichstests bezüglich des Werteintervalls - Minimal-/Maximalwerte (LO, HI) dürfen nicht überschritten werden - hohe Parallelität ändernder Zugriffe möglich Nachteile: - spezielle Programmierschnittstelle - tatsächlicher Wert ggf. nicht abrufbar Escrow-Ansatz 54

56 Zusammenfassung 55 Korrektheitskriterium der Synchronisation: Serialisierbarkeit Sperrverfahren sind universell einsetzbar - Zweiphasen-Sperrprotokolle - reine OCC- und Zeitstempelverfahren erzeugen zuviele Rücksetzungen Hierarchische Synchronisationsverfahren - erlauben Begrenzung des Verwaltungsaufwands generelle Optimierungen: - reduzierte Konsistenzebene - Mehrversionen-Ansatz Harte Synchronisationsprobleme: (a) Hot Spots / High Traffic-Elemente (b) lange (Änderung-) TA Zusammenfassung 55

57 Zusammenfassung 56 - wenn Vermeidungsstrategie nicht möglich, sind zumindest für Hochleistungssysteme Spezialprotokolle anzuwenden - Nutzung semantischen Wissens über Operationen / Objekte zur Reduzierung von Synchronisationskonfliken - allerdings (a) ggf. Erweiterung der Programmierschnittstelle (b) begrenzte Einsetzbarkeit (c) Zusatzaufwand Zusammenfassung 56