Granularity of Locks and Degrees of Consistency in a Shared Data Base Seminar Datenbanken Granularity of Locks and Degrees of Consistency in a Shared Data Base Granularität von Sperren und Grade der Konsistenz in einer geteilten Datenbank Marc Hartmann 15. Mai 2009

Ablauf Hierarchisches Sperrsystem Verschiedene Sperrmodi Regeln für das Sperren Kompatibilität zwischen den Modi DAG (Gerichteter azyklischer Graph) Dynamischer DAG Scheduling Umwandlungen Deadlocks

Ablauf Konsistenz Transaktion Konsistenzgrade Konsistenz bei der Einplanung Auswirkungen eines Systemcrashs Kosten für Konsistenz

Hierarchie in der Datenbank Bereich Datei Datensatz Eintrag

Das Problem Wie 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? Sehr gut für gleichzeitigen Zugriff. Viel Overhead bei komplexen Transaktionen. Sperrt man den ganzen Bereich, in dem man lesen oder schreiben will? Einfacher Zugriff bei komplexen Transaktionen. Konkurrierende Transaktionen können nicht mehr zugreifen.

Verschiedene Granualitäten für Die Lösung Verschiedene Granualitäten für Sperrbare Einheiten Datenbank Datenbank Bereich Bereiche Dateien Datei Datensatz Datensätze Eintrag

X S Arten von Sperren Exklusiv Modus (exclusiv mode) Sperrt einen Knoten für exklusiven Zugang und implizit auch alle seine Nachfahren. (z.B. für Schreibzugriffe) S Geteilter Modus (share mode) Sperrt einem Knoten für teilbaren Zugriff und implizit auch alle seine Nachfahren. (z.B. für Lesezugriffe)

I IX IS Arten von Sperren Wie verhindert man, dass das Sperren eines Teilbaums nicht bereits gesperrte Nachfahren implizit überschreibt? I Absichtsmodus (intention Mode) S Datenbank Bereiche Dateien Datensätze IS S Datenbank Bereiche Dateien Datensätze Beim Sperren eines Knotens wird implizit jeder Elternknoten im I-Modus gesperrt. X IX Ein Kindknoten ist für den exklusiven Zugang gesperrt. IS Ein Kindknoten ist für einen geteilten Zugang gesperrt.

Arten von Sperren Was kann man tun, wenn eine Transaktion in einem Teilbaum große Teile lesen und einige beschreiben will? SIX X S Datenbank Bereiche Dateien Datensätze IX SIX X S Datenbank Bereiche Dateien Datensätze Alle Nachfahren werden implizit in S gesperrt und die sperrende Transaktion kann gezielt Nachfahren in X sperren.

Regeln 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. IX IS S IX Bevor eine X-, SIX- oder IX-Sperre angefordert wird, müssen alle Vorfahren in SIX- oder IX-Modus gehalten werden. SIX X

Regeln für das Sperren Sperren müssen entweder am Ende der Transaktion, in beliebiger Reihenfolge, freigegeben werden, IX SIX X oder von den Nachkommen zur Wurzel hin freigegeben werden. IX SIX X

Kompatibilität zwischen den Modi NL – Keine Sperre IS – Intention Share Mode IX – Intention Exclusive Mode S – Share Mode SIX – Intention Share And Exclusive Mode X – Exclusive Mode

Kompatibilität zwischen den Modi X Transaktion 1 X Datenbank Bereiche Dateien Datensätze NL Ja IS Nein X IX Nein S Transaktion 2 X S Nein SIX Nein X Nein

Kompatibilität zwischen den Modi NL Ja Transaktion 1 S IS Ja IX Ja IX IS IS S Ja SIX IX S Transaktion 2 SIX Ja X Nein S Transaktion 3 X S X Transaktion 4

Kompatibilität zwischen den Modi IX NL Ja IS Ja IX Ja S Nein SIX Nein S Transaktion 2 X Nein IS IX Transaktion 1 X Transaktion 3 S IS

Ordnung der Modi X SIX S IX IS Keine Sperre (NL)

Die Datenbank als gerichteter azyklischer Graph (DAG) Bereiche Datei Felder Indizes Einträge

Änderungen an den Regeln für das Sperren 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). S IS IX Bevor eine X-, SIX- oder IX-Sperre angefordert wird, müssen alle Eltern mindestens im IX-Modus gehalten werden. X IX SIX

Dynamischer Sperrgraph Datenbank Bereiche Datei Indizes Index Indervalle Nicht indizierte Felder Datensatz- kennungen indizierte Felder

Beispiel Datei Konten Indizes: Inhaber Ort Datensätze 123456 Index Ort Kontostand Index Ort Aachen 012345 356872 Kassel 256705 123456 356782 Intervall Kassel Datensatzkennung Konto Datensatz 123456 Ort: Indiziert Kassel nicht Indiziert Kontostand:

Beispiel: Ändern des Kontostandes IX Datei Konten Indizes: Inhaber Ort Datensätze 123456 Kontostand Index muss nicht gesperrt werden, da er nicht berührt wird Index Ort Aachen 012345 356872 Kassel 256705 123456 356782 IX Konto Datensatz 123456 Ort: Kassel X 15 Kontostand:

Beispiel: Ändern des Ortes IX Datei Konten Indizes: Inhaber Ort Datensätze 123456 Kontostand IX Index Ort Aachen 012345 356872 Kassel 256705 123456 356782 IX IX Konto Datensatz 123456 X Ort: Fulda Kassel Kontostand:

Scheduling IS IX IS IS IS S IS X IS IX IX IS Einfachstes Prinzip: First In First Out (FIFO) IS IX IS IS IS S IS X IS IX IX IS Bewilligte Gruppe Keine Sperre (NL) IS IX S SIX X

Scheduling IS IX IS IS IS S IS X IS IX S IS IX Einfachstes Prinzip: First In First Out (FIFO) IS IX IS IS IS S IS X IS IX S IS IX Bewilligte Gruppe Keine Sperre (NL) IS IX S SIX X

Umwandlungen Benö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.

Umwandlungen IS X IS S IS IX Bewilligte Gruppe X Umwandlung muss warten, bis die zweite Transaktion abgearbeitet wurde, da X nicht mit IS kompatibel ist. IS S Umwandlung wird gewährt, der neue Gruppenmodus ist SIX IS Bewilligte Gruppe IX SIX SIX

Deadlocks (Verklemmungen) X X Beide Transaktionen warten darauf, dass die andere fertig wird (Deadlock). IS IS IS Bewilligte Gruppe Das Schedule-System muss nach der Feststellung eines Deadlocks die Aktionen einer Transaktion zurückrollen, um der anderen Transaktion Vorrang zu geben.

Konsistenz 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.

Konsistenz 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.

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.

Transaktionen 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.

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

Konsistenzgrade 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.

Konsistenzgrade Grad 1: Eine Transaktion überschreibt keine verschmutzten Daten einer anderen Transaktion. Eine Transaktion legt ihre Daten erst bei EOT (End Of Transaction) fest. 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.

Konsistenzgrade Grad 2: Eine Transaktion überschreibt keine verschmutzten Daten einer anderen Transaktion. Eine Transaktion legt ihre Daten erst bei EOT fest. Eine Transaktion liest keine Daten, die von anderen Transaktionen verschmutzt wurden. Grad 2 isoliert eine Transaktion von den Aktionen anderer Transaktionen.

Konsistenzgrade Grad 3: Eine Transaktion überschreibt keine verschmutzten Daten einer anderen Transaktion. 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. Grad 3 isoliert eine Transaktion vor verschmutzten Beziehungen zwischen den Werten.

Sperrprotokolldefinition Grad 0: T setzt eine (kurze) exklusive Sperre auf alle Daten, die sie verschmutzt (schreibt). Grad 1: T setzt eine lange exklusive Sperre auf alle Daten, die sie verschmutzt. Grad 2: T setzt eine lange exklusive Sperre auf alle Daten, die sie verschmutzt und setzt eine (kurze) geteilte Sperre auf Daten, die sie liest. Grad 3: T setzt eine lange exklusive Sperre auf alle Daten, die sie verschmutzt und setzt eine lange geteilte Sperre auf Daten, die sie liest.

Konsistenzgrade 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.

Beispiel Prozess 1 liest sekündlich einen Pegelstand und schreibt die Werte, in einer Transaktion, jede Minute in die Datenbank. DB P1 6 7 6 3 7 8 Aus Performanzgründen erfolgt dies im Grad 0, d.h. jeder geschriebene Eintrag wird sofort bestätigt.

Beispiel Prozess 2 liest diese Daten in regelmäßigen Abständen und schreibt Mittelwert und Varianz in die Datenbank. DB P2 Diese Transaktion muss 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) 6 Mittel = 6 7 Varianz = 5 3 8

Beispiel Prozess 2 liest die Mittelwerte und gibt sie auf einem Display aus. DB P2 6 Mittel = 6 7 Diese Transaktion muss im Grad 2 laufen, um sicherzustellen, dass der Mittelwert bereits festgelegt wurde (nicht noch zurückgenommen wird). Varianz = 5 3 8

Beispiel Prozess 3 verwendet Mittelwert und Varianz zur Steuerung des eines Mischers. DB P3 6 Mittel = 6 7 Diese Transaktion muss im Grad 3 laufen, um sicherzustellen, dass Mittelwert und Varianz aus der selben Berechnung stammen. Varianz = 5 3 8

Konsistenz 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.

Auswirkungen eines Systemcrashs Systemwiederherstellung: Datenbank in konsistenten Zustand bringen t Transaktion 1 Transaktion 4 Transaktion 2 Transaktion 5 Transaktion 3 S0 S1 S2 S3 Ausgehend von S2 Nur möglich wenn alle Transaktionen mindestens Grad 2 einhalten (Der Zeitplan hat mindestens Grad 2).

Auswirkungen eines Systemcrashs Systemwiederherstellung: Datenbank in konsistenten Zustand bringen t Transaktion 1 Transaktion 4 Transaktion 2 Transaktion 2 Transaktion 5 Transaktion 5 Transaktion 3 Transaktion 3 S0 S1 S2 S3 Ausgehend von S1 Nur möglich wenn alle Transaktionen mindestens Grad 1 einhalten.

Auswirkungen eines Systemcrashs Systemwiederherstellung: Datenbank in konsistenten Zustand bringen t Transaktion 1 Transaktion 4 Transaktion 2 Transaktion 5 Transaktion 3 S0 S1 S2 S3 Ausgehend von S0 Im jedem Konsistenzgrad möglich.

Kostenvergleich CPU W+P*C*N*W*(1) W+P*C*N*W*(W) Speicher 1 W W + 1 W+R+P*C*N*W*(W+R+1) In Sperrsystem aufrufen mit Wartezeiten W+P*C*N*W*(W) W+R+P*C*N*W*(W+2*R) P – Wahrscheinlichkeit einer Kollision N – Anzahl der Transaktionen C – Wie viel mal mehr Aufwand ein Warten gegenüber einer Sperraktion benötigt Speicher 1 W W + 1 W + R In Warteschlangen Elementen W – Anzahl der Schreibaktion R – Anzahl der Leseaktion CPU W W + R In Sperrsystem aufrufen Grad 1 2 3

Kostenvergleichs 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 3 Grad Speicher CPU CPU mit Wartezeiten 1 S W+P*C*N*W*(1)  P*C*N*W = 0,000001*50*100*6 = 0,03 W+P*C*N*W*(1) = 6,03  6,00 = W

Quellen J.N. Gray, R.A. Lorie, G.R. Putzolu, I.L. Traiger (1976) Granularity of Locks and degrees of Consistency in a Shared Data Base In: Joseph M. Hellerstein, Michael Stonebraker (Hrsg.) (2005) Readings in Database Systems, 4th Edition MIT Press S. 244-273 ISBN 978-0262693141

Fragen ?