Organisatorisches - uni-tuebingen.de · Organisatorisches 2 Termine •2. März: letzte Vorlesung...

Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen

Organisatorisches

2

Termine

• 2. März: letzte Vorlesung

• 8. März: Klausurvorbereitung (Durchgehen Klausurähnlicher Aufgaben, Fragestunde)

• 9. März: Besprechungstermin Übungsblatt 6 (Punkte bisher: siehe Aushang)

HiWi Job / Werkvertrag

• Aufsetzen einer MS Access DB für das Qatna-Projekt (Archäologie)

• Projekt mit hoher Sichtbarkeit, siehe z.B. http://www.spiegel.de/spiegel/0,1518,650267,00.html

Bachelor- / Master- / Studien- / Diplomarbeiten

• Diverse Themen im DB-Bereich an unserem Lehrstuhl

Architektur und Implementierung von Datenbanksystemen | WS 2009/10Melanie Herschel | Universität Tübingen

Kapitel 10Transaktionsmanagement

• Einführung

• Anomalien

3

• Einführung

• Anomalien

• Serialisierbarkeit

• Zwei-Phasen-Sperr-Protokoll

• Spezialisierte Locking Techniken

• Nebenläufigkeit ohne Locking


ÜberblickArchitektur eines DBMS

Web Forms Applications SQL Interface

SQL Commands

Executor Parser

Operator Evaluator Optimizer

File and Access Methods

Buffer Manager

Disk Space Manager

RecoveryManager

TransactionManager

Lock Manager

Figu

re in

spire

d by

Ram

akris

hnan

/Geh

rke:

“Dat

abas

e M

anag

emen

t Sys

tem

s”, M

cGra

w-H

ill 2

003.

DBMS

Databasedata, files, indices, ... 4

!

!

!

!

! !


EinführungDas “Hello World” des Transaktionsmanagement

5

• Meine Bank hat mir eine EC-Karte ausgestellt.

• Mit dieser Karte kann ich z.B. an Bankautomaten Bargeld abheben.

• Der Geldautomat führt eine Transaktion durch, die sicherstellt, dass mein Kontostand korrekt aktualisiert wird.

kontostand := leseKontostand(kontonum);kontostand := Kontostand - 100;schreibeKontostand(kontonum, kontostand)


EinführungNebenläufiger Zugriff (Concurrent Access)

6

• Das Problem ist: mein Mann hat ebenfalls eine EC-Karte für das selbe Konto.

• Es könnte sein, dass wir zur gleichen Zeit von verschiedenen Geldautomaten aus Geld abheben möchten. Dies bezeichnen wir als nebenläufigen Zugriff.

ich(Transaktion 1)

mein Mann(Transaktion 2)

Kontostand(DB Status)

kontostand :=leseKontostand(num) 1200


kontostand :=kontostand - 100 1200


schreibeKontostand(num, kontostand) 1100



EinführungUnterbrochene Transaktionen

7

• Nehmen wir nun an, dass ich Geld von einem Konto auf ein anderes Konto überweisen möchte.

giroKontostand := leseKontostand(giro);

giroKontostand := kontostand - 500;

schreibeKontostand(giro, giroKontostand)

sparKontostand := leseKontostand(spar);

sparKontostand := sparKontostand + 500;

Übertragung abgebrochen

• Durch die unterbrochene Transaktion (Stromausfall, Platten-Crash, Software-Bug, ...) wurde mein Geld verloren.


EinführungDie ACID Eigenschaften

8

Um diese (und andere) Effekte zu vermeiden muss ein DBMS folgende Transaktionseigenschaften gewährleisten:

1.Atomicity (A)

Entweder alle oder keine der Updates, die eine Transaktion durchführt werden auf der Datenbank angewandt.

2.Consistency (C)

Jede Transaktion bringt die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustan (während der Ausführung der Transaktion kann die Datenbank zeitweise inkonsistent sein).

3.Isolation (I)

Eine Transaktion darf keine Effekte nebenläufiger Transaktionen beobachten. Aus Sicht der Transaktion greift sie alleine auf die Datenbank zu.

4.Durability (D)

Die Effekte einer erfolgreichen Transaktion werden persistent gespeichert und können nicht durch Systemprobleme rückgängig gemacht werden.


EinführungTransaktionen

9

• Aus Sicht des DBMS ist eine Transaktion eine Sequenz von Aktionen.

• Eine Aktion wird über ein Datenbankobjekt O durchgeführt. Ein Objekt entspricht z.B. einem Attribut, einem Tupel, oder einer gesamten Tabelle. In unserer Diskussion beschränken wir uns auf Objekte, die Attributen entsprechen.

• Mögliche Aktionen einer Transaktion T über ein Datenbankobjekt O:

• Lesen " RT(O)

• Schreiben " WT(O)

• Eine Transaktion muss mit einer der folgenden Aktionen beendet werden:

• Die Transaktion wurde “erfolgreich” durchgeführt " CommitT

• Die Transaktion wurde “nicht erfolgreich” durchgeführt " AbortT

• Zwei wichtige Anahmen:

• Transaktionen interagieren ausschließlich über Lese- und Schreiboperationen auf der Datenbank miteinander (keine direkten Nachrichten zwischen Transaktionen)

• Eine Datenbank ist eine statische Menge von Datenbankobjekten. Werden Objekte eingefügt oder gelöscht entstehen weitere Probleme die wir hier nicht betrachten.


EinführungSchedules

10

• Ein Schedule ist eine Liste von Aktionen aus einer Menge von Transaktionen.

• Die Reihenfolge von Aktionen einer bestimmten Transaktion T innerhalb des Schedules stimmt mit der Reihenfolge dieser Aktionen in T überein.

• Ein Schedule beschreibt eine Ausführungssequenz von Aktionen.

• Enthält ein Schedule alle Aktionen (und nichts anderes) einer Menge von Transaktionen, so sprechen wir von einem vollständigen Schedule.

• Sind alle Aktionen jeder Transaktion im Schedule zusammenhängend, so sprechen wir von einem seriellen Schedule.

Transaktion T1 Transaktion T2R(A)W(A)

R(B)R(C)W(C)

W(B)Commit

Commit

Zeitachse

Transaktion T1 Transaktion T2

R(A)

W(A)

R(C)

W(C)

R(B)

W(B)serieller Schedule

vollständiger Schedule(Annahme: keine weiteren

Aktionen Teil von T1 und T2)



11

• Einführung

• Anomalien






Anomalien

12

• Annahmen:

• 2 Transaktionen, die die Konsistenz (consistency) der Datenbank gewährleisten.

• Ein vollständiger Schedule, der diese beiden Transaktionen beinhaltet.

• Eine Datenbank, die vor Ausführung des Schedules in einem konsistenten Zustand ist.

• Führen wir nun den Schedule aus, so beobachten wir eine Anomalie, wenn die Datenbank nach der Durchführung aller Aktionen des Schedules einen inkonsistenen Zustand aufweist.

konsistenter DB Zustand





inkonsistenter DB Zustand

Transaktion T1

Transaktion T2

vollständiger Schedule mit T1 und T2 Anomalie


Anomalien

13

• Ein Konflikt tritt zwischen zwei Transaktionen T1 und T2 innerhalb eines Schedules S auf, wenn

• beide auf das gleiche Datenbankobjekt O zugreigen und

• mindestens einer dieser Zugriffe eine Schreiboperation W(O) durchführt.

• 3 Konflikttypen, die zu Anomalien führen:

1.Write-Write (WW) Konflikt (T1, W, O) ≺S (T2, W, O):

• Der Schedule enthält [..., WT1(O), ..., WT2(O), ...]

"Lost-Update Anomalie

2.Write-Read (WR) Konflikt (T1, W, O) ≺S (T2, R, O):

• Der Schedule enthält [..., WT1(O), ..., RT2(O), ...]

"Dirty-Read Anomalie

3.Read-Write (RW) Konflikt (T1, R, O) ≺S (T2, W, O):

• Der Schedule enthält [..., RT1(O), ..., WT2(O), ...]

"Unrepeatable-Read Anomalie


AnomalienLost-Update Anomalie

14

• Wir haben bereits ein Beispiel für eine Lost-Update Anomlie auf Folie 4 gesehen (Schedule unten nochmals wiederholt).

• Der Effekt einer Transaktion geht verloren, weil die zweite Transaktion die Änderung unkontrolliert überschreibt.

ich(Transaktion 1)










AnomalienDirty-Read Anomalie

15

• Eine Transaktion liest Daten, die von der anderen Transaktion geschrieben, aber noch nicht committed wurden.

• Nehmen wir z.B. an, dass mein Mann und ich fast zeitgleich Geld von unserem Konto abheben, meine Transaktion aber abgebrochen wird.

ich(Transaktion 1)



kontostand :=leseKontostand(num);

1200

kontostand :=kontostand - 100;

1200

schreibeKontostand(num, kontostand);

1100

kontostand :=leseKontostand(num);

1100

kontostand :=kontostand - 200;

1100

schreibeKontostand(num, kontostand);

900

abort; 900


AnomalienUnrepeatable-Read Anomalie

16

• Eine Transaktion liest einen temporären, nicht konsistenten Zustand der Datenbank, da die andere Transaktion die für einen konsistenten Zustand nötigen Schreiboperationen noch nicht durchgeführt und committed hat.

• Betrachten wir nochmals das Überweisungsbeispiel von Folie 5 und nehmen wir eine zweite Transaktion an, die das Gesamtguthaben über alle Konten abfragt.

Gesamtguthaben (Transaktion 1) Überweisung (Transaktion 2)

giroKontostand := leseKontostand(giro);

giroKontostand := kontostand - 500;

schreibeKontostand(giro, giroKontostand)

giroGuthaben := leseKontostand(giro);

sparGuthaben := leseKontostand(spar);

guthaben := giroGuthaben + sparGuthaben;

sparKontostand := leseKontostand(spar);

sparKontostand := sparKontostand + 500;

schreibeKontostand(spar, sparKontostand)



17

• Einführung

• Anomalien






SerialisierbarkeitScheduler

18

• Der Scheduler entscheidet über die nebenläufige Ausführung von Transaktionen.

• Dazu legt er einen Schedule für diese Transaktionen an.

Client 1 Client 2 Client 3

Scheduler

Acces & Storage Layer

32

1

2

1

3

21

1

2

1

1

...


3

2

1

2

1

3

SerialisierbarkeitKeine Anomalien bei seriellen Schedules

19

• Ein serieller Schedule (siehe Folie 8) entspricht einer sequentiellen Ausführung der Transaktionen.

• Dadurch wird die Nebenläufigkeit von Transaktionen vermieden.

• Anomalien treten nur bei nebenläufigen Transaktionen auf.

• Somit garantiert ein serieller Schedule, dass keine Anomalien auftreten und damit ist die Ausführung eines seriellen Schedules immer korrekt.

Client 1 Client 2 Client 3

Scheduler

Acces & Storage Layer

32

1

2

13

21

2

1


SerialisierbarkeitDefinition

20

• Keine Nebenläufigkeit zuzulassen (und somit Anomalien zu vermeiden) ist nicht praktikabel.

"Wir erlauben Nebenläufigkeit, wenn garantiert werden kann, dass der Effekt der Anwendung des nicht-seriellen Schedules, für jeden möglichen konsistenten Datenbankzustand, mit dem Effekt eines beliebigen seriellen Schedules der selben Transaktionen übereinstimmt.

• Es ist möglich, Aktionen in einem Schedule S umzusortieren.

• Die Reihenfolge von Aktionen der selben Transaktion muss dabei beibehalten werden.

• Das Ergebnis des umsortierten Schedules muss dem Ergebnis des initialen Schedules S entsprechen.

• Existieren Konflikte (siehe Folie 11) zwischen Aktionen verschiedener Transaktionen, so ist deren relative Reihenfolge wichtig und diese darf demnach nicht geändert werden.

• Kann ein Schedule S mit obigen Regeln in einen Schedule S’ umgewandelt werden, so sagen wir, dass S konfliktäquivalent zu S’ ist.

• Ein Schedule S ist genau dann konfliktserialisierbar, im folgenden auch nur serialisierbar genannt, wenn S konfliktäquivalent zu einem beliebigen seriellen Schedule S’ ist.


SerialisierbarkeitBeispiel

21

Drei Schedules über Transaktionen T1 und T2 (S2 entspricht seriellem Schedule)

Konfliktrelationen in S1

(T1, R, A) ≺S1 (T2, W, A), (T1, R, B) ≺S1 (T2, W, B), (T1, W, A) ≺S1 (T2, R, A), (T1, W, B) ≺S1 (T2, R, B), (T1, W, A) ≺S1 (T2, W, A), (T1, W, B) ≺S1 (T2, W, B)

Konfliktrelationen in S2 (serieller Schedule)identisch mit Konfliktrelationen von S1

Konfliktrelationen in S3

(T1, R, A) ≺S3 (T2, W, A), (T2, R, B) ≺S3 (T1, W, B), (T1, W, A) ≺S3 (T2, R, A), (T2, W, B) ≺S3 (T1, R, B),(T1, W, A) ≺S3 (T2, W, A), (T2, W, B) ≺S3 (T1, W, B)

" S1 ist serialisierbar

T1 T2R(A)

W(A)

R(A)

W(A)

R(B)

W(B)

R(B)

W(B)

T1 T2R(A)

W(A)

R(B)

W(B)

R(A)

W(A)

R(B)

W(B)

T1 T2R(A)

W(A)

R(A)

W(A)

R(B)

W(B)

R(B)

W(B)

Schedule S1 Schedule S2 Schedule S3


SerialisierbarkeitDer Konfliktgraph

22

• Indem wir einen Konfliktgraph G(S) (auch serialization graph genannt) verwenden, können wir die Korrektheit einer Schedules S überprüfen.

• Ein Knoten von G(S) entspricht einer committeten Transaktion in S.

• Eine gerichtete Kante zwischen zwei Transaktionsknoten Ti ⟶ Tj existiert genau dann wenn S zwei Aktionen A und A’auf einem Objekt O enthält, so dass (Ti, A, O) ≺S (Tj, A’, O) (mindestens eine Aktion entspricht einer Schreiboperation).

• S ist genau dann konfliktserialisierbar, wenn G(S) azyklisch ist.

• Ein äquivalenter serieller Schedule kann in diesem Fall direkt durch eine topologische Sortierung von G(S) identifiziert werden.

Konfliktgraph für S1 und S3 (siehe Folie 19)

Konfliktgraph für S1 Konfliktgraph für S3

azyklischer Graph " serialisierbar Graph enthält einen Zyklus " nicht serialisierbar

T1 T2 T1 T2



• Einführung

• Anomalien





23


Locking

24

• Ideal wäre es, wenn der Scheduler stets serialisierbare Schedules produzieren würde.

• Die Idee, um diese Eigenschaft zu gewährleisten basiert auf der Verwendung von Sperren (Locks).

• Jede Transaktion muss ein Lock zugewiesen bekommen, bevor es auf ein Objekt O zugreift.

• Ein solches Lock garantiert exklusiven Zugriff auf ein Objekt.

• Erst wenn die Transaktion das Objekt wieder freigibt können andere Transaktionen wieder auf das Objekt zugreifen.

lock(O);.... Zugriff auf O...;unlock(O);

• Auf diese Weise wird nebenläufiger Zugriff auf O vermieden.


Locking

25

• Kann ein Lock nicht an eine Transaktion T vergeben werden (z.B. weil eine andere Transaktion T’ schon ein Lock auf das gewünschte Objekt hat) so wird T blockiert.

• Der Scheduler suspendiert die weitere Ausführung der blockierten Transaktion T.

• Wird der Lock durch T’ wieder freigegeben so kann es T zugewiesen werden. In diesem Fall wird die Ausführung von T fortgesetzt.

• Da andere Transaktionen fortgesetzt werden können während T pausiert können Locks dazu verwendet werden, die relative Reihenfolge von Aktionen zu kontrollieren.


Locking

26

Beispiel für Locking und Scheduling

T1Lock(A)

W(A)

Lock(B)

Unlock(A)

W(B)

Unlock(B)

T1 T2Lock(A)

W(A)

Lock(B)

Unlock(A)

Lock(A)

W(A)

W(B)

Unlock(B)

Lock(B)

W(B)

W(A)

Unlock(A)

Write(B)

Unlock(B)

Zwei Transaktionen

Schedule S1 Schedule S2

T2Lock(A)

W(A)

Lock(B)

W(B)

W(A)

Unlock(A)

Write(B)

Unlock(B)

Zwei Schedules, die Lock- und Unlock-Aufrufe berücksichtigen

T1 T2Lock(A)

W(A)

Lock(B)

W(B)

W(A)

Unlock(A)

Lock(A)

W(A)

Write(B)

Unlock(B)

Lock(B)

Unlock(A)

W(B)

Unlock(B)

In diesem Beispiel sind sowohl S1 also auch S2 serlialisierbar. Ist das verallgemeinerbar?


Locking

27

Beispiel, das zeigt, dass Locking noch keine Serialisierbarkeit garantiert.

T1 T2Lock(A)

Lock(C)

W(A)

W(C)

Unlock(A)

Lock(A)

W(A)

Lock(B)

Unlock(A)

W(B)

Unlock(B)

Unlock(C)

Lock(B)

W(B)

Unlock(B)

Lock(C)

W(C)

Unlock(C)

Selbst wenn wir dem lock/unlock Schema folgen, sehen wir an folgendem Schedule, dass wir immer noch nicht-serialisierbare Schedules erhalten können:

Wie sieht der Konfliktgraph in diesem Bsp. aus?


Beispiel, das zeigt, dass Locking noch keine Serialisierbarkeit garantiert (Fortsetzung Bsp. Folie 12).

Locking

28

Transaktion 1 Transaktion 2 DB Status

Lock(num) 1200

R(num)

Unlock(num)

Lock(num)

R(num)

Unlock(num)

Lock(num)

W(num) 1100

Unlock(num)

Lock(num)

W(num)

Unlock(num) 1000


Zwei-Phasen-Sperr-ProtokollAuch Two-Phase Locking, 2PL genannt

29

• Das Zwei-Phasen-Sperr-Protokoll führt eine weitere Beschränkung auf die allgemeine Struktur einer Transaktion ein:

Wenn eine Transaktion erstmal ein Lock freigegeben hat (d.h., hat sie das erste Unlock aufgerufen), so kann sie keine weiteren Locks mehr bekommen (d.h. kein Lock-Aufruf mehr danach).

• Das Zwei-Phasen-Sperr-Protokoll ist das Protokoll für die Kontrolle nebenläufiger Transaktionen, das in Datenbanksystemen heutzutage verwendet wird.

• Intuitiv werden Aktionen, zwischen denen Konflikte auftreten in serieller Reihenfolge ausgeführt.

lock phase release phase

lock point

# of locks held

time


Ein Schedule, der 2PL nicht einhält.


30


Lock(num) 1200

R(num)

Unlock(num)

Lock(num)

R(num)

Unlock(num)

Lock(num)

W(num) 1100

Unlock(num)

Lock(num)

W(num)

Unlock(num) 1000

Erster Unlock-Aufruf von T1

Erneute Lock-Anforderung

von T1#

Erster Unlock-Aufruf von T2

#Erneute Lock-Anforderung

von T2


Ein Schedule, der 2PL einhält.

In diesem Beispiel entspricht der Schedule dem seriellen Schedule. Dies ist im Allgemeinen allerdings nicht zwangsläufig der Fall (siehe nächste Folie).


31


Lock(num) 1200

R(num)

Lock(num)

W(num) 1100

Unlock(num)

Lock(num)

R(num)

W(num) 900

Unlock(num)

T2 blockiert


Ein Schedule, der 2PL einhält und keinem seriellen Schedule entspricht


32

Transaktion 1 Transaktion 2

Lock(A)

R(A)

Lock(B)

W(B)

Unlock(B)

Lock(B)

W(B)

Unlock(A)

Unlock(B)



33

• Das Zwei-Phasen-Sperr-Protokoll gibt nicht genau vor, wann Locks gesetzt und wieder freigegeben werden.

• 2 mögliche Varianten:

• Preclaiming 2PL: alle Locks werden zu Anfang der Transaktion gesetzt und nach und nach wieder freigegeben.

• Strict 2PL: Locks werden nach und nach von Transaktion T gesetzt und erst bei Beendigung von T wieder freigegeben. Bei Strict PL kann zudem eine andere Transaktion T’ erst wieder auf von T gesperrte Objekte zugreifen, wenn T committed bzw. abgebrochen wurde (duch commit bzw. abort Aktion).

“lock phase” release phase

locksheld

time

Preclaiming 2PL

lock phase “release phase”

locksheld

time

Strict 2PL

Motivation für die ein oder andere Variante?


Zwei-Phasen-Sperr-ProtokollCascading Rollbacks

34

• Betrachten wir drei Transaktionen, von denen T1 abbricht.

• Wenn T1 abbricht, haben T2 und T3 bereits von T1 geschriebene Daten gelesen (siehe dirty read, Folie 13).

• In diesem Fall muss nicht nur T1 mittles eines Rollback rückgängig gemacht werden, sonder auch T2

und T3 (cascading rollback).

• Das bedeutet letztendlich, dass T2 und T3 nicht committed werden können, bevor T1 nicht committed wurde.

• Durch die Anwendung von Strict PL wird cascading rollback komplett vermieden, da Locks (insb. Lock auf X) erst bei Commit von T1 (bzw. nach Abort + Rollback) wieder freigegeben werden.

�abort ;w(x)

r(x)

r(x)

T1

T2

T3

timet2t1


Lock-Typen

35

• Ein Konflikt tritt nur dann auf, wenn eine Schreiboperation involviert ist.

• Solange Daten nur gelesen werden, muss ein Datenbankobjekt nicht exklusiv durch eine Transaktion gelockt sein.

"DBMS verwenden üblicherweise verschiedene Lock-Typen (lock modes) um nebenläufige Leseoperationen zu erlauben.

• Read-Locks oder Shared-Locks: Lock_S(O)

• Write-Locks oder Exclusive-Locks: Lock_X(O)

• Während des 2PL kann versucht werden, einen Shared-Lock in einen Exclusive-Lock umzuwandeln (lock upgrade). Dies ermöglicht eine stärkere Nebenläufigkeit.

• Locks sind nur dann zueinander im Konflikt wenn mindestens ein Lock ein Exclusive-Lock ist und somit das Objekt für alle Transaktionen sperrt (siehe Kompatibilitätsmatrix).

shared exclusive

shared

exclusive # ##!Locks

in T1

Locks in T2


Verwendung von Shared-Locks und Exclusive-Locks

Lock-Typen

36


Lock_S(A)

R(A)

Lock_S(A)

R(A)

Lock_X(B)

R(B)

W(B)

Unlock(A)

Unlock(B)

Commit

Lock_X(C)

R(C)

W(C)

Unlock(A)

Unlock(B)

Commit


Deadlocks

37

• Wie bei vielen lock-basierten Protokollen kann es unter Verwendung des 2PL zu Deadlocks kommen.

• Im Fall eines Deadlocks würden Transaktionen unbegrenzt lange aufeinander warten.

Verwendung von Shared-Locks und Exclusive-Locks


Lock_X(A)

R(A)

Lock_X(B)

W(B)

Lock_X(B)

Lock_X(A)

...

...


DeadlocksErkennen von Deadlocks

38

Basierend auf Abhängigkeitsgraphen

• Lock Manager speichert einen Wartet-Auf-Graphen.

• Knoten entsprechen Transaktionen.

• Eine gerichtete Kante von Ti $ Tj existiert genau dann, wenn Ti durch einen Lock, den Tj hält, blockiert ist.

• Dieser Graph wird regelmäßig auf Zyklen untersucht, da ein Zyklus einem Deadlock entspricht.

• Wird ein Zyklus entdeckt, so wird der Deadlock aufgelöst, indem eine oder mehrere Transaktionen abgebrochen werden.

• Wahl der abzubrechenden Transaktion(en) ist komplex:

• Junge Transaktionen bevorzugt zu beenden kann dazu führen, dass diese stets neu gestartet und wieder abgebrochen werden.

• Alte Transaktionen abzubrechen kann dazu führen, dass tendentiell komplexere, und daher langwierige Berechnungen verworfen werden (was die Kosten der Undo-Operation, die die bisherigen Schritte rückgängig macht teuer machen kann).

Basierend auf Timeouts

• Eine Transaktion T wir nur solange blockiert, weil sie auf ein Lock wartet, bis ein Timeout stattfindet (wenn maximale Wartezeit überschritten).

• In Fall eines Timeouts wird die Transaktion T abgebrochen.



• Einführung

• Anomalien





39


Spezialisierte Locking Techniken

40

Dynamische Datenbanken und das Phantom Problem

• Bisher haben wir angenommen, dass keine Daten hinzugefügt bzw. gelöscht werden.

• Lassen wir diese Operationen zu, müssen wir mit sogenannten Phantom-Objekten umgehen.

• Phantom-Objekte entstehen, wenn eine Transaktion T1 eine Menge von Daten sperrt und annimmt, diese sei vollständig und unveränderbar.

• Währenddessen verändert eine Transaktion T2 die Menge relevanter Daten von T1, indem Sie Objekte hinzufügt oder löscht, die zur gesperrten Menge von Daten gehören sollten.

Nebenläufiger Zugriff auf B+ Bäume

• Wenden wir 2PL auf B+ und ISAM Bäume an, so haben wir das Problem, dass der Wurzelknoten, der den Einstiegspunkt in den Baum darstellt, einen Engpass bildet.

• Spezialisierte Locking-Protokolle, die die hierarchische Struktur betrachten erlauben effizientere Lösungen.

Locking verschiedener Granularität

• Bisher haben wir die Diskussion auf das Locking von Attributen beschränkt.

• Hier betrachten wir nun den Fall, wo weitere Objekte gesperrt werden können. Sperrbare Objekte bilden dabei eine Teilmengenrelation (z.B. Attribut Teil eines Tupels, Tupel Teil einer Relation, Relation Teil eines Schemas, usw. )


Dynamische DatenbankenDas Phantom-Problem

41

Beispiel von Phantom-TupelnTransaktion T1SELECT rating, max(age) AS MaxAgeFROM SailorsGROUP BY ratingHAVING rating = 1 OR rating = 2

Transaktion T1 Transaktion T2

Sperre alle Tupel mit Rating = 1;

Scan der Menge gesperrter Tupel, um max(age) zu bestimmen;

Sperre freien Speicher, um neues Tupel zu speichern;

Schreibe neues Tupel mit Rating = 1 und Age = 96;

Sperre alle Tupel mit Rating = 2 UND Age > 70;

Entferne gesperrte Tupel (beinhaltet ältesten Sailor mit Rating=2);

Gebe alle Sperren wieder frei;

Sperre alle Tupel mit Rating = 2;

Scan der Menge gesperrter Tupel, um max(age) zu bestimmen;

Gebe alle Sperren wieder frei;

Transaktion T2INSERT INTO Sailors VALUES(..., 1, ..., 96);DELETE FROM Sailors WHERE Rating = 2 AND Age > 70;

Rating MaxAge1 80

2 63

Rating MaxAge1 96

2 63

Rating MaxAge1 80

2 75

Ergebnis des obigen Schedules Ergebnis des seriellen Schedules {T1, T2} Ergebnis des seriellen Schedules {T2, T1}


Dynamische DatenbankenDas Phantom-Problem

42

• Ist eine Datenbank nicht statisch, so ist Konfliktserialisierbarkeit keine Garantie mehr für Serialisierbarkeit!

• Dieses Problem entsteht dadurch, dass T1 annimmt, stets über die korrekte Menge von Tupeln, die relevant sind zu verfügen.

• Die Menge von Tupeln, die für T1 relevant sind kann sich nun jedoch über die Zeit durch Einfügen bzw. Löschen sogenannter Phantom-Tupel durch T2 ändern.

" Die Annahme von T1 ist obsolet.

• Die Lösung des Problems besteht darin, die Annahme von T1 sicherzustellen. Zwei Alternativen:

• Bereichs-Locking

• Ohne Index: Die ganze Datei wird von T1 gesperrt, so dass keine Daten in dieser Datei durch eine andere Transaktion hinzugefügt bzw. entfernt werden können.

• Mit Index über einschänkendes Attribut: Alle Seiten, die Dateneinträge aus dem relevanten Bereich enthalten können (z.B. Rating = 1) werden im Index gesperrt. Wenn T1 versucht, die Menge der Tupel dieses Bereichs zu ändern, so muss T2 auch den Index modifizieren, was durch gezieltes Sperren der Indexseiten verhindert wird.

• Predikat-Locking

• Es ist möglich, implizit alle Records zu sperren, die einem beliebigen Prädikat entsprechen.

• Dieser allgemeiner Ansatz ist allerdings aufwendig in der Implementierung und wird daher nur selten verwendet.


2TR

TW

Nebenläufiger Zugriff auf Baum-IndizesBeispiel

43

• Eine Transaktion Tw fügt Daten auf der Blatt-Ebene eines B+ Baums ein, was zu einem Split führt.

1. Das Einfügen führt zu einem Split von Knoten 2 " Knoten 2’ wird hinzugefügt.

• Der Split wird zu Knoten 9 propagiert. Das bedeutet, dass wir einen neuen Separator in Knoten 9 einfügen.

• Wir nehmen an, dass Knoten 9 noch nicht voll ist und somit den Separator aufnehmen kann.

2. Bevor wir den Separator in Knoten 9 einfügen, versucht eine Transaktion TR Daten des ehemaligen Knoten 2 zu finden, die durch den Split auf 2’ wiederverteilt wurden.

3. Der “alte” Knoten 9 leitet die Anfrage auf Knoten 2 um, obwohl die gesuchten Daten dort nicht mehr existieren.

4. TR glaubt somit fälschlicherweise, dass es keine der Suche entsprechenden Daten mehr gibt.

14

12 13

8 9 10 11

1 2 3 4 5 6 72’21

3 #

"Nebenläufigkeit in B+ Bäumen muss unterstützt werden.


Nebenläufiger Zugriff auf Baum-IndizesVerwendung des 2PL

44

Suche in B+ Bäumen

• Wir traversieren den Baum von oben nach unten (top-down) entlang eines Pfads P.

• Basierend auf dem Inhalt eines Knoten entscheiden wir, welchen Kind-Knoten wir im nächsten Schritt besuchen.

Einfügen in B+ Bäumen

• Führe Suche aus.

• Füge Daten in den richtigen Blattknoten ein (und in die Daten-Datei, hier nicht betrachtet).

• Abhängig vom Füllgrad der Knoten auf dem Pfad P werden dort Splits von unten nach oben (bottom-up) propagiert.

Nebenläufigkeit mittels 2PL

• Shared Read-Locks auf alle Seiten auf Pfad P.

• Exclusive Write-Locks beim Einfügen von Daten auf alle Seiten auf Pfad P.

• Alle Locks werden erst wieder freigegeben, wenn die Transaktion beendet ist.


Nebenläufiger Zugriff auf Baum-IndizesVerwendung des 2PL

45

• Durch die naive Strategie, einfach 2PL zu verwenden, wird die Nebenläufigkeit stark reduziert:

• Alle Transaktionen müssen den Wurzelknoten sperren, der somit zum Flaschenhals wird.

• Effektiv wird duch Locks auf dem Wurzelknoten eine serielle Ausführung aller (Schreib-)Transaktionen durchgeführt.

"2PL ist keine praktikable Locking-Strategie für B+ Bäume.

• Verbesserung durch zwei wesentliche Beobachtungen:

1. Die inneren Knoten des Baumes werden bei der Suche nur zum Weiterleiten der Suche an das nächste Kind verwendet. Die Suche wandert niemals aufwärts, sondern immer nur abwärts.

2.Ein Lock auf einen Knoten n ist bei einer Schreiboperation nur dann nötig, wenn ein Split bis zu diesem Knoten hochpropagiert werden kann.


Nebenläufiger Zugriff auf Baum-IndizesLocking-Strategie bei Suchoperationen

46

• Suchoperationen benötigen nur Shared-Locks auf Seiten des Suchpfads P.

• Da garantiert ist, dass ein Knoten nie wieder angefasst wird, sobald sein Kindknoten betrachtet wird, können wir folgende Locking-Strategie einsetzen:

• Ein Lock auf Knoten n kann freigegeben werden, sobald ein Lock auf Kindknoten n’ gesetzt wurde " lock coupling.

TR 14

12 13

8 9 10 11

1 2 3 4 5 6 7

Transaktion TR

Lock_S(14)

Lock_S(12)

Unlock(14)

Lock_S(9)

Unlock(12)

Lock_S(2)

Unlock(9)

Unlock(2)


Nebenläufiger Zugriff auf Baum-IndizesLocking-Strategie bei Schreiboperationen

47

• Auch bei Schreiboperationen folgen wir im Baum genau einem Pfad P.

• Ein Insert kann zu einem Split auf der Blattebene führen, der sich entlang P von unten nach oben fortsetzen kann.

• Daher benötigen wir Exclusive-Locks im Fall einer Schreiboperation.

• Ein Knoten n wird nur dann gesplittet, wenn sein Kindknoten n’ auf P bereits vollständig gefüllt ist. Ansonsten kann n’ den neuen Separator aufnehmen und n bleibt unverändert.

• In diesem Fall blockiert n’ das Propagieren von Splits überhalb von n’ und wir bezeichnen n’ als sicheren (safe) Knoten.

• Daraus folgt, dass wir auf P erst ab Knoten n’ abwärts den Pfad P sperren.


TW

Nebenläufiger Zugriff auf Baum-IndizesLocking-Strategie bei Schreiboperationen

48

14

12 13

8 9 10 11

1 2 3 4 5 6 7

Transaktion TW

Lock_X(14)

Lock_X(12)

Lock_X(9)

Unlock(12)

Unlock(14)

Lock_X(2)

Unlock(2)

Unlock(9)

• Wir nehmen an, dass Knoten 2 voll ist, was dazu führt, dass Knoten 2 gesplittet wird.

• Dieser Split muss in Knoten 9 reflektiert werden.

• Wir nehmen an, Knoten 9 ist noch nicht voll. Somit ist Knoten 9 ein sicherer Knoten.

• Das bedeutet, dass Knoten 12 vom Split nicht mehr betroffen sein kann.

• Effektiv müssen wir in diesem Beispiel nur Knoten 9 und Knoten 2 Sperren.


Nebenläufiger Zugriff auf Baum-IndizesAlgorithmen

49

Lock-Coupling Protokoll für Lese-Transaktionenroot := Wurzelknoten;Setze Shared-Lock auf root;current := root;while current ist kein Blattknoten dobegin

child := Kind von current, das durch Suche als nächstes betrachtet wird;Setze Shared-Lock auf child;Gebe Shared-Lock auf current wieder frei;current := child;

end

Lock-Coupling Protokoll für Schreib-Transaktionenroot := Wurzelknoten;Setze Shared-Lock auf root;current := root;while current ist kein Blattknoten dobegin

child := Kind von current, das durch Suche als nächstes betrachtet wird;Setze Exclusive-Lock auf child;current := child;if current ist ein sicherer Knoten then

Gebe alle Locks über Vorfahren von current wieder frei;end


Nebenläufiger Zugriff auf Baum-IndizesNebenläufigkeit über Lock-Coupling hinaus verbessern

50

• Selbst unter Verwendung von Lock-Coupling werden zahlreiche Sperren auf innere Knoten gesetzt " verringert die Nebenläufigkeit.

• Die Wahrscheinlichkeit, dass ein innerer Knoten tatsächlich von einem Update betroffen ist, ist sehr gering.

• Sei z.B. der Grad eines B+ Baumes d = 50. Dann verursacht im Schnitt nur jede 50ste Einfügeoperation einen Split, was 2% der Einfügeoperationen entspricht.

"Eine Insert-Transaktion kann optimistisch annehmen, dass es zu keinem Split kommt.

• Es werden wie bei der Suche nur Shared-Locks auf innere Knoten gesetzt + Exclusive-Lock auf betroffenen Blattknoten.

• Erweist sich die Annahme als falsch und ein Split ist doch erforderlich, wird der Baum ein zweites Mal traversiert, wobei die nötigen Exclusive-Locks gesetzt werden.


Locking Verschiedener Granularität

51

geringe Nebenläufigkeit & wenig Overhead

hohe Nebenläufigkeit & hoher Overhead

Datenbank

Tablespace

Tabelle

Seite

Tupel

Attribut

Vergrösserungder

Granularität=

Erhöhung der Nebenläufigkeit & des Overheads

" Locking mit verschiedener Granularität


Locking Verschiedener Granularität

52

• Wir können für jede Transaktion entscheiden, welche Granularität Sperren haben (abhängig von den Eigenschaften der Transaktion).

Beispiel eines Tupel-Locks

SELECT * FROM SAILORSWHERE SID = 42

(SID ist Schlüsselattribut)

Beispiel eines Tabellen-Locks

SELECT *FROM SAILORS

• Wie kann man bei Locks verschiedener Granularität feststellen, ob ein Objekt bereits gesperrt ist?

• Z.B. sollte die linke Anfrage ein Tupel nur sperren können, wenn die Gesamttabelle nicht gesperrt ist.

• Das Erkennen solcher Abhängigkeiten muss effizient gelöst sein.

" Ausnutzen der hierarchischen Beziehung der sperrbaren Objekte (n Tupel ⊆ 1 Relation, n Relationen ⊆ 1 Schema, ...)


Locking Verschiedener GranularitätIntention-Locks

53

• Intuitiv werden, wenn ein Objekt O gesperrt wird, sowohl O als auch alle Kinder von O in der Objekthierarchie gesperrt.

• Zusätzlich wird eine neue Art Lock eingeführt, das sogenannte Intention-Lock, das beim Sperren von O verwendet wird, um dessen Vorfahren in der Objekthierarchie zu sperren.

• Intention-Share-Lock (IS) für Vorfahren eines in Shared-Modus gesperrten Objekts.

• Intention-Exclusive-Lock (IX) für Vorfahren eines in Exclusive-Modus gesperrten Objekts.

S X IS IX

S

X

IS

IX

# ## ## #

#

##Erweiterte Konfliktmatrix



54

Locking-Prrotokoll für Locks verschiedener Granularität

1. Bevor ein Objekt O durch ein Lock in Modus M ∈ {S, X} gesperrt werden kann, muss die Transaktion ein IM-Lock auf alle Objekte “groberer” Granularität erhalten, die O beinhalten.

2. Wenn alle Intention-Locks gewährt wurden, kann die Transaktion Objekt O in Modus M sperren.

Beispiel

Anfrage 1SELECT * FROM SAILORSWHERE SID = 42(SID ist Schlüsselattribut)

Anfrage 2SELECT *FROM SAILORS

Anfrage 1 erhält z.B.

• IS-Lock auf die Sailors-Tabelle (und auf den Tablespace und die Datenbank, die die Sailors-Tabelle enthalten).

• S-Lock auf das Tupel mit SID = 42. IS-Lock auf die Sailors-Tabelle (und auf den Tablespace und die Datenbank, die die Sailors-Tabelle enthalten). S-Lock auf das Tupel mit SID = 42.

Anfrage 2 erhält z.B.

• S-Lock auf die Sailors-Tabelle (und auf enthaltenden Tablespace und die Datenbank), da dieser S-Lock nicht in Konflikt zu den IS-Locks von Anfrage 1 steht.S-Lock auf die Sailors-Tabelle (und auf enthaltenden Tablespace und die Datenbank), da dieser S-Lock nicht in Konflikt zu den IS-Locks von Anfrage 1 steht.



55

Beispiel

Anfrage 1SELECT * FROM SAILORSWHERE SID = 42(SID ist Schlüsselattribut)

Anfrage 2SELECT *FROM SAILORS

Anfrage 3UPDATE SAILORSSET SNAME = ‘John Smith’WHERE SID = 17

Anfrage 3 versucht, folgene Locks zu erhalten:

• IX-Lock auf die Sailors-Tabelle (und auf “gröbere” Objekte)

• X-Lock auf das Tupel mit SID = 17

Anfrage 3 versucht, folgene Locks zu erhalten: IX-Lock auf die Sailors-Tabelle (und auf “gröbere” Objekte)

Somit ist Anfrage 3

• Kompatibel mit Anfrage 1, da kein Konflikt zwischen IX und IS auf der Tabellen-Ebene entsteht.

• Inkompatibel mit Anfrage 2, da S-Lock auf Sailors-Tabelle der Anfrage 2 in Anfrage 3 steht.

mit Anfrage 1, da kein Konflikt zwischen IX und IS auf der Tabellen-Ebene entsteht. mit Anfrage 2, da S-Lock auf Sailors-Tabelle der Anfrage 2 in

mit Anfrage 1, da kein Konflikt zwischen IX und IS auf der Tabellen-Ebene entsteht. mit Anfrage 2, da S-Lock auf Sailors-Tabelle der Anfrage 2 in Konflikt mit dem IX-Lock von


Transaktionscharakteristiken in SQL92Isolationslevel

56

• SERIALIZABLE: Implementiert Strict-2PL für dynamische DB

• Locks werden vor Lese- und Schreiboperationen angefordert, inkl. Locks für Mengen von Daten, die unverändert bleiben müssen (um Phantom Problem zu vermeiden, siehe Folie 40).

• Locks werden bis zur Beendigung der Transaktion gehalten.

• Andere Transaktionen können erst auf Objekte zugreifen, wenn Transaktion committet bzw. abbricht.

• REPEATABLE READ: Implementiert Strict-2PL für statische DB

• Locks auf einzelne Objekte (nicht auf Objektmengen) werden vor Lese- und Schreiboperationen angefordert.

• Locks werden bis zur Beendigung der Transaktion gehalten.

• Andere Transaktionen können erst auf Objekte zugreifen, wenn Transaktion committet bzw. abbricht.


Transaktionscharakteristiken in SQL92Isolationslevel

57

• READ COMMITTED: Implementiert Strict PL für Schreiboperationen und statische DB

• Exclusive-Locks werden vor Schreiboperation angefordert und diese werden bis zur Beendigung der Transaktion gehalten. Weitere Transaktionen können erst nach commit bzw. abort+rollback wieder auf gesperrte Objekte zugreifen.

• Shared-Locks werden vor Leseoperationen angefordert und so schnell wie möglich wieder freigegeben. Diese Locks garantieren lediglich, dass die gelesenen Daten von einer commiteten Transaktion stammen.

• READ UNCOMMITTED: Für Read-Only Transaktionen

• Es werden keine (Shared-)Locks für Leseoperationen beantragt.

• Schreiboperationen sind nicht zugelassen.

" Transaktion ohne Locks und ohne Schreiboperationen

Level Dirty Read Unrepeatable Read Phantom

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ

SERIALIZABLE #

!

# ## ##

! !! !

!



• Einführung

• Anomalien





58


Optimistic Concurrency Control

59

• Bisher war unser Ansatz, Nebenläufigkeit zu regulieren, pessimistisch:

• Wir gehen dabei davon aus, dass Transaktionen in Konflikt zueinander stehen.

• Wir vermeiden Anomalien, die durch Konflikte entstehen, durch Sperren und Sperrprotokolle.

• Im Gegensatz dazu steht der optimistische Ansatz, genannt optimistic concurrency control.

• Hier gehen wir vom besten Fall aus und führen Lese- und Schreiboperationen ohne Sperren durch.

• Bevor die Änderungen einer Transaktion commitet werden wird jedoch überprüft, ob tatsächlich keine Konflikte entstanden sind.

• Grundannahme des optimistic concurrency control ist, dass Konflikte nur selten auftreten und dass der Overhead, den Sperren und Sperrprotokolle mit sich bringen eingespart werden kann, indem man einen Mehraufwand nur in den seltenen Fällen, wo Konflikte auftreten betreibt.


Optimistic Concurrency Control

60

Unter optimistic concurrency control folgen Transaktionen drei Phasen:

1.Lesephase: Die Transaktion wird ausgeführt, indem Daten aus der DB gelesen werden und in einen privaten Workspace geschrieben werden.

2.Validierungsphase: Wenn die Transaktion committen möchte, wird überprüft, ob die Ausführung korrekt ist (also keine Konflikte aufgetreten sind). Ist dies nicht der Fall, wird die Transaktion mit abort abgebrochen.

3.Schreibphase: Wird in Phase 2 kein Konflikt festgestellt, werden die Änderungen, die im privaten Workspace der Transaktion gespeichert sind, in die Datenbank übernommen.

• Phasen 2 und 3 müssen in einer nicht-unterbrechbaren critical section ausgeführt werden (auch Val-Write-Phase genannt).


Multiversion Concurrency Control

62

• Nehmen wir folgenden Schedule an:

RT1(x), WT1(x), RT2(x), WT2(y), RT1(y), WT1(y)

Ist dieser Schedule serialisierbar?

• Nehmen wir nun an, dass zu dem Zeitpunkt, wo T1 Objekt y lesen möchte, immer noch eine Kopie des “alten” Werts von y existiert, der zum Zeitpunkt t (vor widersprüchlichem WT2(y)) galt.

• Somit könnten wir einen Schedule verwenden, der äquivalent zu folgendem serialisierbaren Schedule wäre:

RT1(x), WT1(x), RT2(x), RT1(y), WT2(y), RT1(y), WT1(y)

t


Multiversion Concurrency Control

63

•Speichern wir alte Versionen überschriebener Objekte, so müssen Leseoperationen nicht mehr blockiert werden.

•In diesem Fall können Leseoperation zwar veraltete Daten lesen, aber diese Daten entsprechen einem konsistenten Zustand.

•Problematisch bei multiversion concurrency control ist der Verwaltungsmehraufwand und der Speicherbedarf, die durch Versionierung nötig ist.

•Einige kommerzielle DBMS implementieren diese Technik, z.B., Oracle, SQL Server, PostgreSQL.


Zusammenfassung

64

Nebenläufige Transaktionen

• Transaktionen erfüllen die ACID-Eigenschaften.

• Transaktionen werden durch Scheduler in einen Schedule zusammengefasst.

• Es können im allgemeinen Anomalien auftreten.

2-Phasen-Sperr-Protokoll (2PL)

• Wichtige Konzepte: Serialisierbarkeit und Sperren verschiedener Art (Shared, Exclusive)

• 2PL, insb. Strict-2PL ist das am weitesten verbreitete Protokoll für nebenläufige Transaktionen.

Spezialisierte / erweiterte Locking Techniken

• Für dynamische Datenbanken

• Für Baum-Indizes

• Für Objekte verschiedener Granularität

Nebenläufigkeit ohne Sperren

• Optimistischer Ansatz

• Versionierung

Organisatorisches - uni-tuebingen.de · Organisatorisches 2 Termine •2. März: letzte Vorlesung...

Documents

Transcript of Organisatorisches - uni-tuebingen.de · Organisatorisches 2 Termine •2. März: letzte Vorlesung...