seminar datenbanken 1 granularity of locks and degrees of consistency in a shared data base seminar...
TRANSCRIPT
11Seminar Datenbanken
Granularity of Locks and Granularity of Locks and Degrees of Consistency Degrees of Consistency
in a in a Shared Data BaseShared Data Base
Seminar DatenbankenSeminar Datenbanken
15. Mai 2009
Marc HartmannMarc Hartmann
Granularität von Sperren und Grade der Konsistenz in einer geteilten Datenbank
Seminar Datenbanken 22
AblaufAblauf
Hierarchisches SperrsystemHierarchisches Sperrsystem Verschiedene SperrmodiVerschiedene Sperrmodi Regeln für das SperrenRegeln für das Sperren Kompatibilität zwischen den ModiKompatibilität zwischen den Modi DAG (Gerichteter azyklischer Graph)DAG (Gerichteter azyklischer Graph) Dynamischer DAGDynamischer DAG SchedulingScheduling UmwandlungenUmwandlungen DeadlocksDeadlocks
Seminar Datenbanken 33
AblaufAblauf
KonsistenzKonsistenz TransaktionTransaktion KonsistenzgradeKonsistenzgrade Konsistenz bei der EinplanungKonsistenz bei der Einplanung Auswirkungen eines SystemcrashsAuswirkungen eines Systemcrashs Kosten für KonsistenzKosten für Konsistenz
Seminar Datenbanken 44
Hierarchie in der DatenbankHierarchie in der Datenbank
DatenbankDatenbank
Bereich
DateiDatensatz
Eintrag
Seminar Datenbanken 55
Das ProblemDas ProblemWie wählt man die richtige Größe für
sperrbare Einheiten in einer Datenbank ?
Sperrt man nur den Datensatz oder den Eintrag, den man lesen oder schreiben will?
Sperrt man den ganzen Bereich, in dem man lesen oder schreiben will?
Sehr gut für gleichzeitigen Zugriff.Viel Overhead bei komplexen Transaktionen.
Einfacher Zugriff bei komplexen Transaktionen.Konkurrierende Transaktionen können nicht mehr zugreifen.
Seminar Datenbanken 66
Die LösungDie Lösung
Verschiedene Granualitäten für Sperrbare Einheiten
DatenbankDatenbank
BereichDatei
Datensatz
Eintrag
Datenbank
Bereiche
Dateien
Datensätze
Seminar Datenbanken 77
Arten von SperrenArten von Sperren
XX Exklusiv Modus (exclusiv mode)Sperrt einen Knoten für exklusiven Zugang und implizit auch alle seine Nachfahren.
(z.B. für Schreibzugriffe)
SS Geteilter Modus (share mode)Sperrt einem Knoten für teilbaren Zugriffund implizit auch alle seine Nachfahren.
(z.B. für Lesezugriffe)
Seminar Datenbanken 88
Arten von SperrenArten von SperrenWie verhindert man, dass das Sperren eines Teilbaums nicht bereits gesperrte Nachfahren implizit überschreibt?
II Absichtsmodus (intention Mode)
Beim Sperren eines Knotens wird implizit jeder Elternknoten im I-Modus gesperrt.
IXIX Ein Kindknoten ist für den exklusiven Zugang gesperrt.
ISIS Ein Kindknoten ist für einen geteilten Zugang gesperrt.
IS
IS
IS
S
Datenbank
Bereiche
Dateien
Datensätze S
Datenbank
Bereiche
Dateien
Datensätze
X
Seminar Datenbanken 99
Arten von SperrenArten von Sperren
X
S
Datenbank
Bereiche
Dateien
Datensätze
SIXSIXAlle Nachfahren werden implizit in S gesperrt und die sperrende Transaktion kann gezielt Nachfahren in X sperren.
IX
SIX
X
S
Datenbank
Bereiche
Dateien
Datensätze
S S
SS
Was kann man tun, wenn eine Transaktion in einem Teilbaum große Teile lesen und einige beschreiben will?
Seminar Datenbanken 1010
Regeln für das SperrenRegeln für das Sperren
Es ist nicht erlaubt Sprünge in die Mitte des Baumes zu machen.
X
Bevor eine S- oder IS-Sperre angefordert wird, müssen alle Vorfahren in IX- oder IS-Modus gehalten werden.
S
IS
IX
Bevor eine X-, SIX- oder IX-Sperre angefordert wird, müssen alle Vorfahren in SIX- oder IX-Modus gehalten werden.
SIX
IX
X
Seminar Datenbanken 1111
Regeln für das SperrenRegeln für das Sperren
Sperren müssen entweder am Ende der Transaktion, in beliebiger Reihenfolge, freigegeben werden,
oder von den Nachkommen zur Wurzel hin freigegeben werden. SIX
IX
X
SIX
IX
X
Seminar Datenbanken 1212
Kompatibilität zwischen den ModiKompatibilität zwischen den Modi
NL IS IX S SIX XNL Ja Ja Ja Ja Ja JaIS Ja Ja Ja Ja Ja NeinIX Ja Ja Ja Nein Nein NeinS Ja Ja Nein Ja Nein Nein
SIX Ja Ja Nein Nein Nein NeinX Ja Nein Nein Nein Nein Nein
NL – Keine SperreIS – Intention Share ModeIX – Intention Exclusive ModeS – Share ModeSIX – Intention Share And Exclusive ModeX – Exclusive Mode
Seminar Datenbanken 1313
Datenbank
Bereiche
Dateien
Datensätze
Kompatibilität zwischen den ModiKompatibilität zwischen den Modi
XTransaktion 1X
XXX
XXX
X X X STransaktion 2 X
NL
IS
IX
S
SIX
X
Ja
Nein
Nein
Nein
Nein
Nein
X
Seminar Datenbanken 1414
Kompatibilität zwischen den ModiKompatibilität zwischen den Modi
ISTransaktion 1 S
S
STransaktion 2
S
Transaktion 3 X S
SX
SIX
IX
XTransaktion 4
SSS
S S S
ISIX
NL
IS
IX
S
SIX
X
Ja
Ja
Ja
Ja
Ja
Nein
IS
Seminar Datenbanken 1515
Kompatibilität zwischen den ModiKompatibilität zwischen den Modi
IS
Transaktion 1 X
X
IX
IX
STransaktion 2
Transaktion 3 S
S
IS
NL
IS
IX
S
SIX
X
Ja
Ja
Ja
Nein
Nein
Nein
IX
Seminar Datenbanken 1616
Ordnung der ModiOrdnung der Modi
Keine Sperre (NL)
IS
IXS
SIX
X
Seminar Datenbanken 1717
Die Datenbank als gerichteter Die Datenbank als gerichteter azyklischer Graph (DAG)azyklischer Graph (DAG)
Datenbank
Bereiche
Felder Indizes
Einträge
Datei
Seminar Datenbanken 1818
Änderungen an den Regeln für das Änderungen an den Regeln für das SperrenSperren
Bevor eine S- oder IS-Sperre angefordert wird, muss mindestens ein Elternteil mindestens im IS-Modus gehalten werden (und somit implizit ein Weg bis zur Wurzel).
Bevor eine X-, SIX- oder IX-Sperre angefordert wird, müssen alle Eltern mindestens im IX-Modus gehalten werden.
S
IS
IS
IX
X
IX IX
IX
SIX
Seminar Datenbanken 1919
Dynamischer SperrgraphDynamischer Sperrgraph
Datenbank
Bereiche
Nicht indizierteFelder
Indizes
Datensatz-kennungen
IndexIndervalle
indizierteFelder
Datei
Seminar Datenbanken 2020
BeispielBeispiel
Konto DatensatzOrt: Kassel
Kontostand: 0
Indiziert
nicht Indiziert
123456Datensatzkennung
Index OrtAachen 012345Aachen 356872
Kassel 256705Kassel 123456Kassel 356782
Intervall Kassel
Datei KontenIndizes: Inhaber
Ort
Datensätze123456
OrtInhaberKontostand
Seminar Datenbanken 2121
Beispiel: Ändern des KontostandesBeispiel: Ändern des Kontostandes
Konto DatensatzOrt: Kassel
Kontostand: 0
123456
Index OrtAachen 012345Aachen 356872
Kassel 256705Kassel 123456Kassel 356782
Datei KontenIndizes: Inhaber
Ort
Datensätze123456
OrtInhaberKontostand
15 X
IX
IXIndex muss nicht gesperrt werden,
da er nicht berührt wird
Seminar Datenbanken 2222
Beispiel: Ändern des OrtesBeispiel: Ändern des Ortes
Konto DatensatzOrt: Kassel
Kontostand: 0
123456
Index OrtAachen 012345Aachen 356872
Kassel 256705Kassel 123456Kassel 356782
Datei KontenIndizes: Inhaber
Ort
Datensätze123456
OrtInhaberKontostand
Fulda XIX
IX
IX
IX
Seminar Datenbanken 2323
SchedulingScheduling
IX SIS X
Einfachstes Prinzip: First In First Out (FIFO)
IS IS IS IS IS IX
Bewilligte Gruppe
Keine Sperre (NL)
IS
IXS
SIX
X
NL IS IX S SIX XNL Ja Ja Ja Ja Ja JaIS Ja Ja Ja Ja Ja NeinIX Ja Ja Ja Nein Nein NeinS Ja Ja Nein Ja Nein Nein
SIX Ja Ja Nein Nein Nein NeinX Ja Nein Nein Nein Nein Nein
ISIX
Seminar Datenbanken 2424
SchedulingScheduling
IX SIS XIS IS IS IS IS IX
Bewilligte Gruppe ISIXS
Keine Sperre (NL)
IS
IXS
SIX
X
NL IS IX S SIX XNL Ja Ja Ja Ja Ja JaIS Ja Ja Ja Ja Ja NeinIX Ja Ja Ja Nein Nein NeinS Ja Ja Nein Ja Nein Nein
SIX Ja Ja Nein Nein Nein NeinX Ja Nein Nein Nein Nein Nein
Einfachstes Prinzip: First In First Out (FIFO)
Seminar Datenbanken 2525
UmwandlungenUmwandlungenBenötigt nun eine Transaktion eine andere Art von Zugang zu einem Knoten, so muss der Modus umgewandelt werden.
Der neue Modus ist der höhere zwischen dem bereits bewilligten Modus und dem neuen.
Wird zusätzlich zu einer IX- ein S-Sperre angefordert, so ergibt sich als neuer Modus SIX.
Seminar Datenbanken 2626
UmwandlungenUmwandlungen
IS
IS IS
Bewilligte Gruppe
X Umwandlung muss warten, bis die zweite Transaktion abgearbeitet wurde, da X nicht mit IS kompatibel ist.
S
IS
Bewilligte Gruppe
IX
IXSIX
SIXUmwandlung wird gewährt, der neue Gruppenmodus ist SIX
Seminar Datenbanken 2727
Deadlocks (Verklemmungen)Deadlocks (Verklemmungen)
IS
IS IS
Bewilligte Gruppe
X X Beide Transaktionen warten darauf, dass die andere fertig wird (Deadlock).
Das Schedule-System muss nach der Feststellung eines Deadlocks die Aktionen einer Transaktion zurückrollen, um der anderen Transaktion Vorrang zu geben.
Seminar Datenbanken 2828
KonsistenzKonsistenz
Konsistenz bedeutet in einer Datenbank, dass alle Behauptungen über Beziehungen in einer Datenbank erfüllt sind.
Beispiel:
Es gibt in einer Datenbank Mitarbeiterdatensätze und (an anderer Stelle) einen Eintrag wie viele Mitarbeiter das Unternehmen hat.
Die Datenbank ist nur Konsistent, wenn es genau so viele Mitarbeiterdatensätze gibt, wie die Zahl der Mitarbeiter angibt.
Seminar Datenbanken 2929
KonsistenzKonsistenz
In einigen Fällen muss die Datenbank vorübergehend inkonsistent sein, z.B. kann in unserem Beispiel nicht gleichzeitig ein neuer Mitarbeiterdatensatz angelegt und die Anzahl erhöht werden.
Zur Lösung dieser temporären Inkonsistenzen werden Sequenzen von Aktionen zu Transaktionen zusammengefasst.
Seminar Datenbanken 3030
TransaktionenTransaktionen
Transaktionen sind die Einheiten der Konsistenz.
Sie überführen die Datenbank von einem konsistenten Zustand zum nächsten.
Schlägt eine Aktion einer Transaktion fehl, so muss die gesamte Transaktion ‚rückgängig‘ gemacht werden um die Konsistenz zu erhalten.
Seminar Datenbanken 3131
Transaktionen und SperrenTransaktionen und Sperren
Wird immer nur eine Transaktion nach der anderen durchgeführt, so sieht eine Transaktion immer einen konsistenten Zustand der Datenbank, der von ihrem Vorgänger zurückgelassen wurde.
Werden jedoch ‚gleichzeitig‘ mehrere Transaktionen durch das Schedule-System bearbeitet, sind Sperren notwendig um die Konsistenz für jede dieser Transaktionen zu gewährleisten.
Diese Sperren können entweder durch den Benutzer gesetzt werden, oder automatisch durch das Datenbanksystem.
Seminar Datenbanken 3232
KonsistenzgradeKonsistenzgrade
Benennungen:
Eine Ausgabe einer Transaktion nennen wir festgelegt (committed), wenn die Transaktion auf ihr Recht zum ‚Rückgängigmachen‘ verzichtet.
Eine Ausgabe, die noch nicht festgelegt wurde nennen wir verschmutzt (dirty).
Seminar Datenbanken 3333
KonsistenzgradeKonsistenzgrade
Grad 0:
Eine Transaktion überschreibt keine verschmutzten Daten einer anderen Transaktion.
Grad 0 konsistente Transaktionen sind nicht wiederherstellbar, da andere Transaktionen bereits neue Werte in geänderten Felder eingetragen haben können.
Seminar Datenbanken 3434
KonsistenzgradeKonsistenzgrade
Grad 1:
Eine Transaktion überschreibt keine verschmutzten Daten einer anderen Transaktion.
Grad 1 ermöglicht es eine gerade bearbeitete Transaktion ohne zusätzliche Sperren rückgängig zu machen (Backup). Es werden keine Änderungen anderer Transaktionen überschieben.
Eine Transaktion legt ihre Daten erst bei EOT(End Of Transaction) fest.
Seminar Datenbanken 3535
KonsistenzgradeKonsistenzgrade
Grad 2:
Eine Transaktion überschreibt keine verschmutzten Daten einer anderen Transaktion.
Grad 2 isoliert eine Transaktion von den Aktionen anderer Transaktionen.
Eine Transaktion legt ihre Daten erst bei EOT fest.
Eine Transaktion liest keine Daten, die von anderen Transaktionen verschmutzt wurden.
Seminar Datenbanken 3636
KonsistenzgradeKonsistenzgrade
Grad 3:
Eine Transaktion überschreibt keine verschmutzten Daten einer anderen Transaktion.
Grad 3 isoliert eine Transaktion vor verschmutzten Beziehungen zwischen den Werten.
Eine Transaktion legt ihre Daten erst bei EOT fest.
Eine Transaktion liest keine Daten, die von anderen Transaktionen verschmutzt wurden.Die Daten, die eine Transaktion liest werden von keiner anderen Transaktion verschmutzt.
Seminar Datenbanken 3737
SperrprotokolldefinitionSperrprotokolldefinitionGrad 0: T setzt eine (kurze) exklusive Sperre auf
alle Daten, die sie verschmutzt (schreibt).
Grad 1: T setzt eine lange exklusive Sperre aufalle Daten, die sie verschmutzt.
Grad 2: T setzt eine lange exklusive Sperre aufalle Daten, die sie verschmutzt undsetzt eine (kurze) geteilte Sperre auf Daten, die sie liest.
Grad 3: T setzt eine lange exklusive Sperre aufalle Daten, die sie verschmutzt undsetzt eine lange geteilte Sperre auf Daten, die sie liest.
Seminar Datenbanken 3838
KonsistenzgradeKonsistenzgrade
Solange alle Transaktionen mindestens Grad 0 einhalten sieht jede Transaktion den von ihr verwendeten Grad.
Solange alle Transaktionen mindestens Grad 1 einhalten ist ein Systemweites Backup (Rückgängigmachen aller aktiven Transaktionen) ohne Datenverlust möglich.
Halten alle Transaktionen mindestens den Grad 2 ein, so kann jede einzelne Transaktion rückgängig gemacht werden und das System bleibt konsistent.
Eine Grad 3 konsistente Transaktion ist wiederholbar.
Seminar Datenbanken 3939
BeispielBeispielProzess 1 liest sekündlich einen Pegelstand und schreibt die Werte, in einer Transaktion, jede Minute in die Datenbank.
6
7
3
8
6
7
Aus Performanzgründen erfolgt dies im Grad 0, d.h. jeder geschriebene Eintrag wird sofort bestätigt.
DBP1
Seminar Datenbanken 4040
BeispielBeispielProzess 2 liest diese Daten in regelmäßigen Abständen und schreibt Mittelwert und Varianz in die Datenbank.
6
7
DB
3
8
P2
Mittel = 6
Varianz = 5
Diese Transaktionmuss im Grad 1 laufen, um sicherzustellen, dass Mittelwert und Varianz aus den selben Werten berechnet wurde.(Wenn T abbricht muss ein evtl. bereits geschriebener Wert zurückgenommen werden können)
Seminar Datenbanken 4141
BeispielBeispielProzess 2 liest die Mittelwerte und gibt sie auf einem Display aus.
6
7
DB
3
8
P2
Mittel = 6
Varianz = 5Diese Transaktionmuss im Grad 2 laufen, um sicherzustellen, dass der Mittelwert bereits festgelegt wurde(nicht noch zurückgenommen wird).
Seminar Datenbanken 4242
BeispielBeispielProzess 3 verwendet Mittelwert und Varianz zur Steuerung des eines Mischers.
6
7
DB
3
8
P3
Mittel = 6
Varianz = 5Diese Transaktionmuss im Grad 3 laufen, um sicherzustellen, dass Mittelwert und Varianz aus der selben Berechnung stammen.
Seminar Datenbanken 4343
Konsistenz bei der EinplanungKonsistenz bei der Einplanung
Bei seriellen Einplanungen entstehen keine Konflikte, jede Transaktion bleibt Konsistent.
Nur wenn alle Transaktionen im Grad i laufen, sieht jede Transaktion auch diesen Grad.
Daher hat ein Zeitplan (Schedule) den selben Konsistenzgrad wie seine ‚schlechteste‘ Transaktion.
Seminar Datenbanken 4444
Auswirkungen eines SystemcrashsAuswirkungen eines Systemcrashs
t
S0
Transaktion 1
Transaktion 2
Transaktion 3
Transaktion 4
Transaktion 5
S1 S2 S3
Systemwiederherstellung: Datenbank in konsistenten Zustand bringen
Ausgehend von S2
Nur möglich wenn alle Transaktionen mindestens Grad 2 einhalten (Der Zeitplan hat mindestens Grad 2).
Seminar Datenbanken 4545
Auswirkungen eines SystemcrashsAuswirkungen eines Systemcrashs
S0
Transaktion 1
Transaktion 2
Transaktion 3
Transaktion 4
Transaktion 5
S1
Systemwiederherstellung: Datenbank in konsistenten Zustand bringen
Ausgehend von S1
t
S3
Transaktion 2
Transaktion 3
S2
Nur möglich wenn alle Transaktionen mindestens Grad 1 einhalten.
Transaktion 5
Seminar Datenbanken 4646
Auswirkungen eines SystemcrashsAuswirkungen eines Systemcrashs
t
S0
Transaktion 1
Transaktion 2
Transaktion 3
Transaktion 4
Transaktion 5
S1 S2 S3
Systemwiederherstellung: Datenbank in konsistenten Zustand bringen
Ausgehend von S0
Im jedem Konsistenzgrad möglich.
Seminar Datenbanken 4747
KostenvergleichKostenvergleich
Grad
0
1
2
CPU
W
W
W + R
W + R
In Sperrsystemaufrufen
Speicher
1
W
W + 1
W + R
In WarteschlangenElementen
W – Anzahl der SchreibaktionR – Anzahl der Leseaktion
CPU
W+P*C*N*W*(1)
W+R+P*C*N*W*(W+R+1)
In Sperrsystemaufrufen
mit Wartezeiten
W+P*C*N*W*(W)
W+R+P*C*N*W*(W+2*R)
P – Wahrscheinlichkeit einer KollisionN – Anzahl der TransaktionenC – Wie viel mal mehr Aufwand ein Warten gegenüber einer Sperraktion benötigt
3
Seminar Datenbanken 4848
Kostenvergleichs BeispielKostenvergleichs Beispiel
Bank-Transaktionen lesen 5 Mal (R = 5)und schreiben 6 Mal (W = 6).
Da es mehrere Millionen Konten gibt beträgt die Wahrscheinlichkeit einer Kollision etwa (P) 0,000001.
Es gibt (N) 100 Transaktionen pro Sekunde.
Für eine Sperre benötigt das System 100 Anweisungen, für ein Warten 5000, somit ist C = 50
P*C*N*W = 0,000001*50*100*6 = 0,03
W+P*C*N*W*(1) = 6,03 6,00 = W
3Grad Speicher CPU CPU mit Wartezeiten
0 1 S W+P*C*N*W*(1)
Seminar Datenbanken 4949
QuellenQuellen
J.N. Gray, R.A. Lorie, G.R. Putzolu, I.L. Traiger (1976)Granularity of Locks and degrees of Consistency in a Shared Data BaseIn:Joseph M. Hellerstein, Michael Stonebraker (Hrsg.) (2005)Readings in Database Systems, 4th Edition MIT PressS. 244-273ISBN 978-0262693141
Seminar Datenbanken 5050
FragenFragen
??