5 Transaktionsverwaltung 81 5 Transaktionsverwaltung Jeder zugängliche Datenbankzustand soll im Sinne eines Schnappschusses“ ein kor- ” rektes Gesamtbild der modellierten Welt wiedergeben. Wir bezeichnen eine Daten- bank als konsistent, wenn alle Aussagen (über Gegenstände oder Sachverhalte), die sie vermittelt, als korrekt aufgefaßt werden. Grundsätzlich nehmen wir an, daß Anwendungen für sich allein eine konsistente Datenbank wieder in eine konsistente Datenbank überführen. Sie stützen sich dabei auf die elementaren Datenbankzugriffe, wobei wir zwischen lesenden Aktionen (Lesen eines Records) und schreibenden Aktionen (Neuzugang, Löschen und Ändern eines Records) unterscheiden. Eine Verarbeitungseinheit von Aktionen bezeichnen wir als eine Transaktion. Sie nimmt durch ihre lesenden Aktionen einen bestimmten Datenbankzustand entgegen und erzeugt mit schreibenden Aktionen einen neuen Datenbankzustand. Wir gehen grundsätzlich davon aus, daß Transaktionen (vom Anwender) so konzipiert sind, daß sie einen konsistenten Bestand wieder in einen konsistenten Zustand überführen. Eine größere Anwendung setzt sich in der Regel aus mehreren derartigen Einheiten zusammen, die dann im konkreten Einsatz nacheinander verarbeitet werden. Für eine Transaktion fordern wir, daß ihre Abwicklung atomaren Charakter besitzt: entweder soll sie vom DBMS vollständig oder überhaupt nicht ausgeführt werden. Definition 5.1 Eine Transaktion ist eine vom Benutzer spezifizierte Folge von DB- Änderungen, welche die DB von einem zulässigen Zustand wieder in einen zulässigen Zustand überführt und die nur als Einheit wirksam werden kann. Beispiel 5.2 Betrachten wir eine Transaktion, die 30 Euro von Konto 753 ab- bucht und auf das Sparbuch 333 bucht. Wir haben dabei folgende Relationen zur Verfügung: Sparbuch(SpNr, Einlage, Kunde) Konto(KtNr, KtStand) BEGIN TRANSACTION UPDATE Konto SET KtStand=KtStand-30 WHERE KtNr=753 UPDATE Sparbuch SET Einlage=Einlage+30 WHERE SpNr=333 END TRANSACTION 5.1 ACID Eigenschaften von Transaktionen 82 5.1 ACID Eigenschaften von Transaktionen Wir erwarten, daß eine Transaktion wie geplant abläuft und die vorgesehenen Schrit- te ausführt. Bei der Ausführung von einer bzw. von mehreren Transaktionen kann es aber zu Störungen bzw. Fehlern kommen, die das verhindern. Um diese Störungen auszuschließen, werden gewisse Eigenschaften von Transaktionen gefordert. Diese sind Atomarität, Konsistenzerhaltung, Isolation und Dauerhaftigkeit. Nach den An- fangsbuchstaben der englischen Bezeichnungen werden sie auch ACID Eigenschaften genannt. Wir stellen diese anhand der Umbuchungstransaktion in Beispiel 5.2 kurz vor. Atomarität (atomicity): Eine Transaktion wird entweder ganz oder gar nicht aus- geführt. Wenn nicht alle Operationen einer Transaktion ausgeführt werden können, so muß diese abgebrochen werden, und bereits ausgeführte Änderungen müssen rückgängig gemacht werden. Beispiel 5.3 Bei unserer Umbuchungstransaktion müssen wir sicherstellen, daß bei- de Aktionen durchgeführt werden, einerseits die Abbuchung vom Konto, andererseits die Buchung auf das Sparbuch. Bricht die Transaktion nach der Abbuchung und vor der Buchung ab, so wäre das eine Verletzung der Atomarität. Konsistenzerhaltung (consistency): Das Gesamtergebnis einer parallelen Aus- führung von Transaktionen entspricht irgendeiner Hintereinanderausführung dieser Transaktionen. (Da eine Transaktion alleine konsistenzerhaltend ist, ist auch eine Hintereinanderausführung konsistenzerhaltend.) Beispiel 5.4 Angenommen, neben der Umbuchungstransaktion findet eine Trans- aktion statt, die eine Geldautomatenabhebung vom Konto abbucht. Der Gesamtef- fekt ist entweder: 1. vom Konto abbuchen und beim Sparbuch buchen, 2. vom verringerten Kontostand den am Geldautomat abgehobenen Betrag ab- ziehen. oder 1. den Kontostand um den am Geldautomat abgehobenen Betrag verringern, 2. vom verringerten Kontostand abbuchen und beim Sparbuch buchen. Isolation (isolation): Teilergebnisse von Transaktionen bleiben bis zum Ende der Transaktion für alle anderen Transaktionen unsichtbar. Beispiel 5.5 Bei der Umbuchungstransaktion wird die Abbuchung vom Konto erst sichtbar, nachdem auch die Buchung auf das Sparbuch durchgeführt worden ist. 5.2 Zustandsübergänge einer Transaktion 83 Dauerhaftigkeit (durability): Die Ergebnisse einer erfolgreich durchgeführten Transaktion bleiben erhalten. Beispiel 5.6 Nach der Durchführung der Umbuchung muß der neue Kontostand sowohl auf dem Konto als auch auf dem Sparbuch erscheinen und kann nicht mehr etwa aus Systemgründen rückgängig gemacht werden. Die Gewährleistung von Atomarität und Dauerhaftigkeit wird von einer Recovery- Komponente übernommen, Konsistenzerhaltung und Isolation werden durch eine Komponente für Mehrbenutzerkontrolle (concurrency control) sichergestellt. Die Mehr- benutzerkontrolle verwendet dabei ein Verfahren, das die Serialisierbarkeit von par- allel ablaufenden Transaktionen gewährleistet. 5.2 Zustandsübergänge einer Transaktion In der folgenden Abbildung sind die möglichen Zustände und die Übergänge zwischen Zuständen für Transaktionen dargestellt. inkarnieren verdrängen potentiell aktiv wartend einbringen neu starten abbrechen ab n br nde ech e e en b zurücksetzen abgeschlossen wiederholbar gescheitert festschreiben zurücksetzen abbrechen persistent aufgegeben Eine Transaktion befindet sich in einem der folgenden Zustände: potentiell: Die Transaktion ist codiert und wartet darauf“, in den Zustand aktiv ” zu wechseln. Diesen Übergang nennt man Inkarnieren. 5.3 Fehler bei unkontrolliertem Mehrbenutzerbetrieb 84 aktiv: Die aktiven (d.h. derzeit rechnenden) Transaktionen konkurrieren unterein- ander um die Betriebsmittel, wie z.B. Hauptspeicher, Rechnerkern zur Ausführung von Operationen, etc. wartend: Bei einer Überlast des Systems kann die Transaktionsverwaltung einige aktive Transaktionen in den Zustand wartend verdrängen. Nach Behebung der Überlast werden diese wartenden Transaktionen sukzessive wieder eingebracht, d.h., wieder aktiviert. abgeschlossen: Durch den Commit-Befehl wird eine aktive Transaktion beendet. Die Wirkung abgeschlossener Transaktionen kann aber nicht gleich in der Datenbank festgeschrieben werden. Vorher müssen noch möglicherweise verletzte Konsistenzbe- dingungen überprüft werden. persistent: Die Wirkungen abgeschlossener Transaktionen werden – wenn die Kon- sistenzerhaltung sichergestellt ist – durch Festschreiben dauerhaft in eine Datenbasis eingebracht. Damit ist die Transaktion persistent. Dies ist einer von zwei möglichen Endzuständen einer Transaktionsverarbeitung. gescheitert: Transaktionen können aufgrund vielfältiger Ereignisse scheitern. Z.B. kann der Benutzer selbst durch einen Abort-Befehl eine aktive Transaktion abbre- chen. Weiterhin können Systemfehler zum Scheitern aktiver oder wartender Trans- aktionen führen. Bei abgeschlossenen Transaktionen können auch Konsistenzverlet- zungen festgestellt werden, die ein Scheitern veranlassen. wiederholbar: Einmal gescheiterte Transaktionen sind u.U. wiederholbar. Dazu muß deren Wirkung auf die Datenbasis zunächst zurückgesetzt werden. Danach können sie durch Neustarten wiederum aktiviert werden. aufgegeben: Eine gescheiterte Transaktion kann sich aber auch als hoffnungslos“ ” herausstellen. In diesem Fall wird ihre Wirkung zurückgesetzt und die Transakti- onsverarbeitung geht in den Endzustand aufgegeben über. 5.3 Fehler bei unkontrolliertem Mehrbenutzerbetrieb Wir wollen uns zunächst mit den möglichen Fehlern, die im unkontrollierten (und nicht synchronisierten) Mehrbenutzerbetrieb auftreten können, beschäftigen. Wir werden diese Fehler in drei Fehlerklassen aufteilen. 5.3 Fehler bei unkontrolliertem Mehrbenutzerbetrieb 85 5.3.1 Verlorengegangene Änderungen Dieses Problem (lost update) soll wieder anhand der folgenden zwei Transaktionen aus dem Bankenbereich demonstriert werden: • Transaktion T1 transferiert 30 EURO von Konto A nach Konto B, wobei zunächst Konto A belastet wird und danach die Gutschrift auf Konto B erfolgt. • Die gleichzeitig ablaufende Transaktion T2 schreibt dem Konto A 3% Zin- seinkünfte gut. Der Ablauf dieser beiden Transaktionen könnte wie folgt verzahnt ablaufen – wenn es keine Mehrbenutzersynchronisation gäbe: Schritt T1 T2 1 read A 2 A := A − 30 3 read A 4 A := A ∗ 1.03 5 write A 6 write A 7 read B 8 B := B + 30 9 write B Der Effekt dieser Ausführung ist, daß die in Schritt 5 dem Konto A gutgeschriebenen Zinsen verlorengehen, da der in Schritt 5 von T2 geschriebene Wert in Schritt 6 gleich wieder von T1 überschrieben wird. Deshalb geht der Effekt von Transaktion T2 verloren. 5.3.2 Abhängigkeit von nicht freigegebenen Änderungen Diese Fehlerklasse wird manchmal auch als dirty read“ bezeichnet, da ein Datum ” gelesen wird, das so niemals in einem gültigen (transaktionskonsistenten) Zustand der Datenbasis vorkommt. Wir wollen auch dies an unseren Beispieltransaktionen T1 (Überweisung) und T2 (Zinsgutschrift) demonstrieren: 5.3 Fehler bei unkontrolliertem Mehrbenutzerbetrieb 86 Schritt T1 T2 1 read A 2 A := A − 30 3 write A 4 read A 5 A := A ∗ 1.03 6 write A 7 read B 8 B := B + 30 9 abort In dieser verzahnten Ausführung liest T2 in Schritt 4 einen Wert für Konto A, von dem T1 schon 30 EURO abgebucht hat. Aber T1 wird in Schritt 9 abgebrochen, so daß die Wirkung von T1 gänzlich zurückgesetzt werden muß. Leider hat aber T2 in Schritt 5 die Zinsen basierend auf dem falschen Wert von A berechnet und in Schritt 6 dem Konto gutgeschrieben. D.h., die Transaktion T2 wurde auf der Basis inkonsistenter Daten durchgeführt. 5.3.3 Phantomproblem Das Phantomproblem taucht auf, wenn während der Abarbeitung einer Transak- tion T2 eine andere Transaktion T1 ein neues Datum generiert, das T2 eigentlich hätte mitberücksichtigen müssen. Als Beispiel betrachten wir die folgenden beiden Transaktionen: T1 T2 SELECT SUM(KtStand) FROM Konto INSERT INTO Konto VALUES (1077, 42) SELECT SUM(KtStand) FROM Konto Hierbei führt T2 (innerhalb einer Transaktion) zweimal die SQL-Anfrage aus, um die Summe aller Kontostände zu ermitteln. Das Problem besteht nun darin, daß T1 zwischenzeitlich ein neues Konto – nämlich das Konto mit der Kennung 1077 und dem Kontostand 42 EURO einfügt, das aber erst beim zweiten Durchgang der SQL- Anfrage berücksichtigt wird. Die Transaktion T2 berechnet also zwei unterschiedliche Werte, da zwischenzeitlich das Phantom 1077 eingefügt wurde. 5.4 Parallele Transaktionen 87 5.4 Parallele Transaktionen Die geschilderten Probleme ergeben sich beim Mehrbenutzerbetrieb. Mehrere Be- nutzer arbeiten gleichzeitig mit einer DB und konkurrieren teilweise um dieselben Daten. Das Ziel ist die Herstellung der Ablaufintegrität. Parallele Transaktionen sind so zu synchronisieren, daß die Äquivalenz zum Ein-Terminal-Betrieb garantiert wird (so, als ob die Transaktionen sequentiell ablaufen). Wir sprechen allgemein von zwei parallelen Transaktionen, wenn der Beginn der einen zwischen Start und Ende der anderen fällt. Parallele Transaktionen, welche gemeinsame Datenobjekte ändern, nehmen unter Umständen inkonsistente Daten- bankzustände entgegen. Das DBMS braucht bei parallelen Transaktionen dann nicht einzugreifen, wenn die Transaktionen (in einem noch zu präzisierenden Sinn) die gleiche Wirkung wie eine serielle Abarbeitung haben. Zur Beurteilung von Abwicklungen“ ist die zeitliche ” Abfolge der Datenbankzugriffe zu analysieren, wozu je Aktion noch folgende Infor- mationen benötigt werden: • die Art dieser Aktion, • die Transaktion, welche die Aktion veranlaßt hat, sowie • das Datenbankelement der Aktion. Absolute Zeitangaben oder Zeitintervalle zwischen den Zugriffen sind dabei belang- los. Definition 5.7 Es sei T = {T1 , . . . , Tn } eine Menge von Transaktionen. Jede Trans- aktion bestehe aus Einzelschritten. a) Ein Schedule für T ist eine Folge aus allen Einzelschritten der Transaktionen in T , worin die Einzelschritte jeder Transaktion Ti in der gleichen Reihenfolge wie in Ti vorkommen (1 ≤ i ≤ n). b) Ein Schedule heißt seriell, wenn die Einzelschritte jeder Transaktion Ti unmit- telbar aufeinander folgen. oder Definition 5.8 Ein Schedule S bezeichnet eine endliche Folge von Tripeln S = (T (1), a(1), e(1)), . . . , (T (m), a(m), e(m)) , wobei T (i) die Identifikation der Trans- aktion, welche die i-te Aktion auslöst, a(i) die Art dieser Aktion (W für write bzw. R für read) und e(i) die Identifikation des betreffenden Zugriffs-Objektes bedeuten. Eine Transaktion (mit der Identifikation) Tn kann als eine Teilfolge des Schedules 5.4 Parallele Transaktionen 88 interpretiert werden; dazu sind alle Tripel auszuwählen, für die T (i) = Tn gilt: {(T (i), a(i), e(i)) | T (i) = Tn }. Beispiel 5.9 Es seien die folgenden Transaktionen, welche auf die Datenbankele- mente A, B, C und D zugreifen, gegeben: T1 : ((R,A), (W,A)) T2 : ((R,C), (W,C)) T3 : ((R,B), (W,B), (R,A), (W,A)) T4 : ((R,D), (W,D)) T5 : ((R,C), (R,B), (R,A), (W,A)) T6 : ((R,A), (W,A)) Zeitliche Versetzungen sollen zu folgenden Abläufen führen: a) S1 als serieller Schedule mit der Reihenfolge T1 , T2 , T3 , T4 , T5 , T6 : S1 : ((T1 ,R,A), (T1 ,W,A), (T2 ,R,C), (T2 ,W,C), (T3 ,R,B), (T3 ,W,B), (T3 ,R,A), (T3 ,W,A), (T4 ,R,D), (T4 ,W,D), (T5 ,R,C), (T5 ,R,B), (T5 ,R,A), (T5 ,W,A), (T6 ,R,A), (T6 ,W,A)) b) S2 mit der Abfolge: T1 T2 T3 T4 T5 T6 (R, A) (R, C) (W, C) (R, B) (R, D) (W, A) (W, B) (R, C) (R, A) (R, B) (W, D) (W, A) (R, A) (W, A) (R, A) (W, A) S2 : ((T1 ,R,A), (T2 ,R,C), (T2 ,W,C), (T3 ,R,B), (T4 ,R,D), (T1 ,W,A), (T3 ,W,B), (T5 ,R,C), (T3 ,R,A), (T5 ,R,B), (T4 ,W,D), (T3 ,W,A), (T5 ,R,A), (T5 ,W,A), (T6 ,R,A), (T6 ,W,A)) 5.4 Parallele Transaktionen 89 Für einen seriellen Schedule S können die beteiligten Transaktionen auf natürliche Weise linear angeordnet werden: Wir setzen Tn < Tm , falls Tn vor Tm verarbeitet wird. Ein DBMS könnte die Datenbankkonsistenz dadurch erzwingen, daß es die parallelen Transaktionen in eine Warteschlange einreiht und nacheinander (seriell) abarbeitet. Eine derartige Strategie verbietet sich allerdings für viele Anwendungen wegen der Gefahr extrem langer Wartezeiten von selbst. Wir suchen deshalb nach weniger strengen Kriterien, so daß auch parallele Zugriffe erlaubt sind. In der Tat dürfen Transaktionen sicherlich ohne Bedenken parallel abgewickelt werden, wenn einer der folgenden Fälle vorliegt: • alle Transaktionen verwenden ausschließlich lesende Zugriffe oder • die Transaktionen greifen auf keine gemeinsamen Elemente zu. In beiden Fällen führt jede beliebige Verschiebung oder Verzahnung der Transaktio- nen zu demselben Resultat. 5.4.1 Konflikte Gefahren-Situationen können sich bei der Abwicklung paralleler Transaktionen nur dann einstellen, wenn Schreibzugriffe auf gemeinsame Elemente stattfinden. Zur Be- schreibung derartiger Zusammenhänge zwischen Transaktionen dient die folgende Klassifizierung von Konflikten. Definition 5.10 Eine Transaktion Ti steht mit einer anderen Transaktion Tj in einem (W,R)-Konflikt, wenn Ti zuerst schreibend und Tj später lesend auf ein gemein- sames Element zugreifen, (R,W)-Konflikt, wenn Ti zuerst lesend und Tj danach schreibend auf ein gemein- sames Element zugreifen, (W,W)-Konflikt, wenn zuerst Ti und später Tj schreibend auf ein gemeinsames Element zugreifen. Konflikte können offensichtlich auch in seriellen Abwicklungen auftreten. Mit Hilfe der folgenden Definition werden diejenigen Konflikte markiert, die einen unmittel- baren zeitlichen Bezug zueinander haben: Definition 5.11 Für einen Schedule S = (T (1), a(1), e(1)), . . . , (T (k), a(k), e(k)) , an welchem die Transaktionen T = {T1 , . . . , Tm } und die Elemente E = {E1 , . . . , En } beteiligt sind, ist die Abhängigkeitsrelation (dependency relation) DEP (S) ⊆ T × E × T definiert als die Menge aller Tripel (T (h), Ei , T (j)), für die gilt: a) 1 ≤ h < j ≤ k, 5.4 Parallele Transaktionen 90 b) die Transaktionen T (h) und T (j) stehen hinsichtlich Ei in einem Konflikt zueinander (d.h. auch T (h) 6= T (j)), c) zwischen T (h) und T (j) darf keine andere Transaktion schreibend auf Ei zu- greifen: Für jedes l mit h < l < j, e(l) = Ei , T (l) 6= T (h) und T (l) 6= T (j) gilt: a(l) = R. Bedingung c) berücksichtigt in DEP (S) nur unmittelbare Konflikte. Wenn nur die (W,W)-Konflikte auf einem Element Ei betrachtet werden, so gilt: Zu einem Index m, für den T (m) schreibend auf Ei zugreift, existiert eindeutig ein Index n > m, so daß (T (m), Ei , T (n)) ∈ DEP (S) einen (W,W)-Konflikt wiedergibt. T (n) ist dabei die nächste Transaktion, die auf Ei schreibend zugreift. Beispiel 5.12 Die Abhängigkeitsrelationen zu Beispiel 5.9 lauten DEP (S1 ) = DEP (S2 ) = {(T1 , A, T3 ), (T3 , A, T5 ), (T5 , A, T6 ), (T2 , C, T5 ), (T3 , B, T5 )}. Aktionspaare, welche einem Tripel aus der Abhängigkeitsrelation zugrundeliegen, dürfen nicht vertauscht werden, ohne daß sich (potentiell) ein anderer Effekt einstellt: Entweder sieht dann eine der beteiligten Transaktionen ein anderes Element (Lese- Aktion bei einem (W,R)- oder (R,W)-Konflikt), oder es liegt danach ein anderer Datenbankzustand vor. Sofern eine Transaktion an keinem Konflikt beteiligt ist, taucht sie in DEP (S) nicht auf. 5.4.2 Serialisierbarkeit Zu einer konkreten Abwicklung von Transaktionen – dargestellt durch den Schedu- le S – notiert die Abhängigkeitsrelation DEP (S) alle Transaktionspaare, die sich gegenseitig unmittelbar beeinflussen. Sie gestattet uns, ein genaues Kriterium zur Beurteilung von Konsistenzgefährdungen herzuleiten. Serielle Abwicklungen nehmen dabei eine Musterrolle ein. Definition 5.13 Zwei Schedules S1 und S2 heißen äquivalent, falls die beiden fol- genden Bedingungen erfüllt sind: a) In S1 und S2 sind dieselben Transaktionen vorhanden, b) S1 und S2 besitzen die gleiche Abhängigkeitsrelation: DEP (S1 ) = DEP (S2 ). Definition 5.14 Ein Schedule S heißt konflikt-serialisierbar, falls zu S ein äqui- valenter serieller Schedule S ∗ existiert. 5.4 Parallele Transaktionen 91 In einem konflikt-serialisierbaren Schedule treten zwei Transaktionen Tm und Tn bei allen Konflikten in derselben zeitlichen Abfolge auf: Auf alle Elemente, die in einen Konflikt zwischen Tm und Tn verstrickt sind, greift Tm entweder immer vor Tn oder immer nach Tn zu. Aus der Sicht einer Transaktion Tn finden deshalb alle ande- ren Transaktionen, mit denen sie in einem mittelbaren oder unmittelbaren Konflikt steht, entweder vollständig vorher oder vollständig nachher statt. Die Datenbank- zustände, die jede Transaktion wahrnimmt oder an ihrem Ende erzeugt, verhalten sich deshalb so, als ob sie in einer seriellen Abwicklung entstanden wären. Beispiel 5.15 Schedule S2 aus Beispiel 5.9 ist konflikt-serialisierbar, da DEP (S1 ) = DEP (S2 ) gilt. Dagegen kann die Abfolge T1 T2 T3 T4 T5 T6 (R, A) (R, C) (W, C) (R, B) (R, D) (W, A) (W, B) (R, C) (R, B) (W, D) (R, A) (W, A) (R, A) (W, A) (R, A) (W, A) mit dem Schedule S3 : ((T1 ,R,A), (T2 ,R,C), (T2 ,W,C), (T3 ,R,B), (T4 ,R,D), (T1 ,W,A), (T3 ,W,B), (T5 ,R,C), (T5 ,R,B), (T4 ,W,D), (T5 ,R,A), (T5 ,W,A), (T6 ,R,A), (T6 ,W,A), (T3 ,R,A), (T3 ,W,A)) und der Abhängigkeitsrelation DEP (S3 ) = {(T1 , A, T5 ), (T5 , A, T6 ), (T6 , A, T3 ), (T2 , C, T5 ), (T3 , B, T5 )} 5.4 Parallele Transaktionen 92 nicht konflikt-serialisierbar sein: Für das Element A gilt T5 vor T6 vor T3“, für B ” jedoch T3 vor T5 “, was offensichtlich im Widerspruch zueinander steht. ” Die lineare (irreflexive) Ordnung auf einem seriellen Schedule spiegelt sich zum Teil in der Abhängigkeitsrelation eines konflikt-serialisierbaren Schedules wider. Dazu er- klären wir auf einem Schedule S, bei dem die Elemente E = {E1 , . . . , En } einbezogen sind, die Relation <∗“ zwischen Transaktionen durch ” Tm <∗ Tn , falls (Tm , Ei , Tn ) ∈ DEP (S) für ein Ei ∈ E. Man beachte, daß <∗“ im allgemeinen keine (totale) Ordnung mehr festlegt. Aller- ” dings verträgt sich <∗“ für konflikt-serialisierbare Schedules mit der totalen linearen ” Ordnung <“, die auf dem äquivalenten seriellen Schedule erklärt ist: ” Korollar 5.16 Für einen konflikt-serialisierbaren Schedule S mit den Transaktio- nen T = {T1 , . . . , Tk } gilt: Mit Tm <∗ Tn folgt auch Tm < Tn in jedem äquivalenten seriellen Schedule. Die Relation <∗“ enthält in der Regel weniger Beziehungspaare als <“. Sie kann ” ” allerdings durch transitive Erweiterung zu einer totalen Ordnungsrelation erweitert werden. Satz 5.17 Für den konflikt-serialisierbaren Schedule S mit den Transaktionen T = {T1 , . . . , Tn } erzeugt <∗“ mit ihrer transitiven Erweiterung eine strikte Ordnung ” auf T . Beweis Die Transitivität gilt laut Konstruktion, die Asymmetrie ist nach Korol- lar 5.16 erfüllt. Definition 5.18 Für einen Schedule S mit den Transaktionen T = {T1 , . . . , Tn }, der Elementenmenge E und der Abhängigkeitsrelation DEP (S) ist der Präzedenz- Graph P G(S) definiert durch (Tm , Tn ) ∈ P G(S), falls (Tm , Ei , Tn ) ∈ DEP (S) für ein Ei ∈ E. Ein Präzedenz-Graph P G(S) charakterisiert genau wie DEP (S) die Konflikte in ei- ner Abfolge von Transaktionen. Im Unterschied zur Abhängigkeitsrelation DEP (S) treten die Elemente (Ei ) dabei jedoch hier nicht mehr in Erscheinung. Es wird allein die Reihenfolge zweier in Konflikt stehender Transaktionen mit der Kante verdeutlicht. Für konflikt-serialisierbare Schedules wurde diese Richtung“ zwischen ” Transaktionen mit Hilfe der Ordnung <∗“ schon als eindeutig festgelegt erkannt – ” mithin ist auch die Einbeziehung des Elementes irrelevant. 5.4 Parallele Transaktionen 93 Beispiel 5.19 Die Präzedenz-Graphen zu den Beispielen 5.9 und 5.15 sind: zu S1 und S2 : zu S3 : T1 T1 T6 T3 T5 T5 T6 T2 T2 T3 Satz 5.20 Ist S konflikt-serialisierbar, so ist P G(S) azyklisch. Beweis Es sei angenommen, daß ein zyklischer Graph P G(S) vorliege. Dann gibt es in P G(S) Kanten (Ti1 , Ti2 ), (Ti2 , Ti3 ), . . . , (Tik , Ti1 ), was auch folgendermaßen dar- stellbar ist: Ti1 −→ Ti2 −→ · · · −→ Tik −→ Ti1 . −→“ gibt die zeitliche Reihenfolge für Zugriffe der Transaktionen auf beliebige ” Elemente wieder. Wegen der blockweisen Abarbeitung ist für einen seriellen Schedule eine Anordnung Ti1 vor Ti2 . . . vor Tik vor Ti1“ jedoch nicht möglich. Also kann S ” nicht konflikt-serialisierbar sein. Falls noch die Umkehrung des letzten Satzes (Zyklenfreiheit gewährleistet Konflikt- Serialisierbarkeit) nachgewiesen werden kann, verfügen wir über ein exaktes Krite- rium zur Beurteilung von Abfolgen. Dazu suchen wir ein Verfahren, das aus einem azyklischen Präzedenz-Graphen einen seriellen Schedule konstruiert. Die Knoten eines beliebigen azyklisch gerichteten Graphen können durch die fol- gende Prozedur, die als topologisches Sortieren bezeichnet wird, in einer linearen Reihenfolge angeordnet werden: Zyklenfreiheit garantiert mindestens einen Knoten, der nicht als Nachfolger eines anderen auftritt. Wir wählen aus diesen Kandidaten willkürlich einen ersten Knoten als Startpunkt aus und eliminieren ihn samt allen Kanten, die von ihm ausgehen. Mit dem Restgraphen verfahren wir auf die gleiche Weise, was uns sukzessiv das zweite Element etc. liefert. Die erzeugte Anordnung kann als eine lineare totale Ordnung auf der Menge der Transaktionen aufgefaßt werden, die uns gleichzeitig einen seriellen Schedule S ∗ liefert. 5.4 Parallele Transaktionen 94 Lemma 5.21 Für einen Schedule S mit azyklischem Präzedenz-Graphen P G(S) gilt: Falls (Tm , Ei , Tn ) ∈ DEP (S)(bzw. Tm <∗ Tn ) besteht, so gilt auch für jeden, durch topologisches Sortieren erzeugten seriellen Schedule S ∗ : Tm < Tn . Beweis (Tm , Ei , Tn ) ∈ DEP (S) führt zu (Tm , Tn ) ∈ P G(S). Da topologisches Sortieren die Auswahl eines Nachfolgerknotens im (Rest-)Graphen verbietet, gilt in S ∗ : Tm < Tn . Zwischen einem Schedule S mit azyklischem Präzedenz-Graphen und dem durch topologischen Sortieren erzeugten S ∗ besteht folgende Verwandtschaft: Lemma 5.22 Aus dem Schedule S mit einem azyklischen Präzedenz-Graphen P G(S) sei S ∗ durch topologisches Sortieren erzeugt. Dann sind S und S ∗ äquivalent: DEP (S) = DEP (S ∗ ). Beweis Zum Nachweis der Aussage zeigen wir zuerst a) S und S ∗ besitzen dieselben unmittelbaren (W, W )-Konflikte: Die Schreibzu- griffe auf ein beliebig gewähltes Element Ei induzieren bei zyklenfreiem P G(S) dort eine lineare totale Ordnung der Transaktionen: Ti1 <∗ Ti2 <∗ · · · <∗ Tik . Nach Lemma 5.21 überträgt sich diese Anordnung auch auf S ∗ : Ti1 < Ti2 < · · · < Tik . Dies zeigt, daß S ∗ dieselben unmittelbaren (W, W )-Konflikte besitzt wie S. b) S und S ∗ besitzen dieselben unmittelbaren (W, R)- und (R, W )-Konflikte: Zwischen den Schreibzugriffen aus zwei Transaktionen Tm und Tn , die in ei- nem unmittelbaren (W, W )-Konflikt bzgl. Ei zueinander stehen, nehmen wir nun eine Transaktion Tk mit einem Lesezugriff auf Ei an. Wir finden deshalb (Tm , Ei , Tk ) ∈ DEP (S) und (Tk , Ei , Tn ) ∈ DEP (S). Wieder führt uns Lem- ma 5.21 hinsichtlich S ∗ zu Tm < Tk < Tn . Auch diese Anordnung zeigt, daß S ∗ dieselben unmittelbaren (W, R)- und (R, W )-Konflikte besitzt wie S. Aus dem letzten Lemma folgt unmittelbar Korollar 5.23 Ein Schedule S mit azyklischem Präzedenz-Graphen P G(S) ist kon- flikt-serialisierbar. 5.5 Synchronisationsverfahren 95 Beispiel 5.24 Aufgrund der Präzedenz-Graphen gilt für die Schedules aus den Bei- spielen 5.9 und 5.15: S1 : seriell, S2 : konflikt-serialisierbar, S3 : nicht konflikt-serialisierbar. Mit Hilfe des letzten Satzes läßt sich auch die Umkehrung von Satz 5.17 nachweisen. Satz 5.25 Läßt sich die Relation <∗“ (abgeleitet aus einem Schedule S) durch ” transitive Ergänzung zu einer totalen Ordnung auf der Menge der beteiligten Trans- aktionen erweitern, so ist S konflikt-serialisierbar. Beweis Ist S nicht konflikt-serialisierbar, so finden wir mit Korollar 5.23 in P G(S) einen Zyklus Ti1 → Ti2 → Ti3 → · · · → Tik → Ti1 , der mit Blick auf DEP (S) Ti1 <∗ Ti2 <∗ Ti3 <∗ · · · <∗ Tik <∗ Ti1 ergibt. Dann kann aber <∗“ zu keiner ” totalen Ordnung führen. 5.5 Synchronisationsverfahren Datenbankmanagementsysteme können unterschiedliche Strategien anwenden, um für Transaktionen (konflikt-)serialisierbare Schedules zu erzeugen. Mit Hilfe von Sperrmechanismen können Transaktionen Elemente für sich reservieren und vor kon- kurrierenden Zugriffen schützen. Andere Konzepte verzichten auf Sperren und bre- chen Transaktionen bei drohender Inkonsistenz ab bzw. überprüfen erst am Schluß, vor der definitiven Eintragung der vorgenommenen Datenbankänderungen, ob die Aktionen der Transaktion im Einklang mit der Serialisierbarkeit stehen. 5.5.1 Sperr-Verfahren Konflikt-Serialisierbarkeit kann mit Hilfe von Elementsperren erzwungen werden. Ei- ne Transaktion darf bei diesem Vorgehen ein Datenbankelement für eine bestimmte Zeit für sich reservieren. Wir gehen grundsätzlich davon aus, daß das Zusammenspiel zwischen Transaktionen und DBMS auf folgende Weise geregelt ist: Vor dem Zugriff einer Transaktion auf ein Datenbankelement wird eine Sperre (lock) des Elementes (durch eine explizite Sperranforderung oder implizit durch eine andere Anweisung) veranlaßt. Eine Komponente des DBMS, der Lockmanager, verwaltet die Sperren und unterbindet die Zugriffe anderer Transaktionen auf bereits gesperrte Elemente. Die Freigabe erfolgt aufgrund von Anweisungen der Transaktion oder nach deren Ende. 5.5 Synchronisationsverfahren 96 Die unterschiedlichen Konfliktarten legen es nahe, unterschiedlich restriktive Sperr- modi ins Auge zu fassen. Während wir gestatten, daß Transaktionen, die ausschließ- lich Lesezugriffe vollziehen, ungehindert parallel abgearbeitet werden dürfen, sollen bei (W,R)-, (R,W)- oder (W,W)-Konflikten Sperren wirksam werden: • READ-Lock (auch: shared lock; RLOCK): Transaktion T darf nach einer Anfor- derung eines READ-Locks nur lesend auf das betreffende Element E zugreifen. Anderen Transaktionen erlaubt das DBMS ebenfalls lesende Zugriffe bzw. die Vereinbarung eines READ-Locks auf E. • WRITE-Lock (auch: exclusive lock; WLOCK): Transaktion T darf schreibend oder lesend auf E zugreifen. Während der WRITE-Locks untersagt das DBMS anderen Transaktionen jeglichen Zugriff auf E. Andererseits wird ein WRITE- Lock zurückgewiesen, wenn das Element bereits mit einerm READ-Lock ge- sperrt ist. Transaktionen, die vor einem Lesezugriff einen READ-Lock bzw. für Lese- und Schreibzugriffe einen WRITE-Lock anfordern, die nur Elemente freigeben, die sie auch zuvor gesperrt haben, und die keine Sperren anfordern, die sie schon besitzen, werden als wohlgeformt (well-formed) bezeichnet. Sofern das DBMS konkurrieren- de Zugriffe nur gemäß den obigen Regeln ausführt, sprechen wir auch von legalen Abfolgen. Die gesperrten Elemente können vom Lockmanager in einer Sperrtabelle mit den Eintragungen (Element-ID, Transaktions-ID, Modus) verwaltet werden. Transaktio- nen, die in kollidierender Weise auf ein Element zugreifen möchten, werden vom Lockmanager unterbrochen und in eine Warteschlange eingereiht. In der Sprache ESQL werden Sperren implizit mit den entsprechenden Anweisungen für die Daten- bankzugriffe vermittelt. Transaktionen, die ausschließlich lesend zugreifen, können in beliebiger Verzahnung parallel abgearbeitet werden. Wie man aus dem folgenden Beispiel ablesen kann, genügt es allerdings nicht, daß Transaktionen nur wohlgeformt sind. (Um das Sper- ren und die Freigabe eines Elementes E zu verdeutlichen, verwenden wir die Anwei- sungen RLOCK(E), WLOCK(E) sowie UNLOCK(E).) Beispiel 5.26 In der folgenden Abfolge soll Transaktion T1 eine Umbuchung von einem Girokonto (GK) auf ein Sparkonto (SK) vornehmen. T1 ist offensichtlich wohl- geformt. Gleichzeitig ermittelt eine Transaktion T2 das Guthaben des Kunden. (Es werden nur die Datenbankanweisungen gezeigt.) 5.5 Synchronisationsverfahren 97 T1 T2 WLOCK(GK) read GK write GK UNLOCK(GK) RLOCK(SK) RLOCK(GK) read GK read SK UNLOCK(GK) UNLOCK(SK) WLOCK(SK) read SK write SK UNLOCK(SK) Die Abhängigkeitsrelation lautet DEP (S) = {(T1 , GK, T2 ), (T2 , SK, T1 )}. Demnach ist der zugrundeliegende Schedule nicht serialisierbar, weil T2 einen inkonsistenten Zustand der Datenbank sieht. 5.5.2 Zwei-Phasen-Sperrprotokoll Eine serielle Abfolge von Transaktionen läßt sich vor diesem Hintergrund derart interpretieren, daß jeder Transaktion der gesamte Bestand vom Start bis zu ihrem Ende exklusiv zur Verfügung steht. Das DBMS kann die Konflikt-Serialisierbarkeit erzeugen, indem eine ähnliche Wirkung mit dem Zwei-Phasen-Sperrprotokoll erzielt wird. Eine Transaktion T genügt dem Zwei-Phasen-Sperrprotokoll, wenn sich Sperren und Freigaben der Elemente zeitlich voneinander trennen lassen: T läßt eine Aufteilung in drei Abschnitte zu, wobei im ersten Abschnitt (in der Wachstumsphase (growing phase)) alle Sperren erfolgen und im dritten Abschnitt (in der Schrumpfungsphase (shrinking phase)) alle Freigaben vorgenommen werden. Der mittlere Abschnitt dient allein der Verarbeitung und ist für die Transaktionssteuerung nicht von Interesse. Man beachte, daß innerhalb der Schrumpfungsphase kein expliziter Abbruch mehr durch den Benutzer vorgenommen werden darf. Satz 5.27 Transaktionen, die dem Zwei-Phasen-Sperrprotokoll gehorchen, werden vom DBMS mit einem konflikt-serialisierbaren Schedule abgewickelt. Beweis Zu einem Schedule S, welcher nicht konflikt-serialisierbar ist, existiert im Präzedenz-Graphen P G(S) ein Zyklus Ti1 −→ Ti2 −→ · · · −→ Tik −→ Ti1 . Aus 5.5 Synchronisationsverfahren 98 Tm −→ Tn folgt, daß mindestens eine dieser Transaktionen einen Schreibzugriff auf ein gemeinsames Element vornimmt. Unabhängig von der Konfliktart muß deshalb Tm das betreffende Element freigeben, bevor Tn seine Sperre realisieren kann. Im obigen Zyklus gibt daher Ti1 zuerst ein Element frei, bevor Ti2 darauf zugreift. Später fordert allerdings Ti1 wieder eine Sperre an, die nach der Freigabe durch Tik wirksam wird. Dies widerspricht aber der Voraussetzung des Satzes. Beispiel 5.28 Die Transaktionen aus Beispiel 5.15 sollen jetzt nach dem Zwei- Phasen-Sperrprotokoll abgewickelt werden. Jede Transaktion möge unmittelbar nach ihrem Start alle betroffenen Elemente sperren und nach dem letzten Datenbankzu- griff wieder freigeben. Das DBMS steuert dann die Transaktionen, die sich in der Reihenfolge wie in S3 anmelden, zu folgender Abwicklung (die Sperren sind nicht aufgeführt): T1 T2 T3 T4 T5 T6 (R, A) (R, C) (W, C) (R, D) (W, A) (R, B) (W, B) (W, D) (R, A) (W, A) (R, C) (R, B) (R, A) (W, A) (R, A) (W, A) So sperrt etwa T1 im ersten Schritt das Element A mit einem WRITE-Lock (wegen Schritt 6). Da T1 noch nicht beendet ist, wird T3 in Schritt 4 der Zugriff auf B untersagt. Erst nach Abschluß von T1 wird T3 fortgesetzt etc. Die Sperrmechanismen führen zum Schedule S4 : ((T1 ,R,A), (T2 ,R,C), (T2 ,W,C), (T4 ,R,D), (T1 ,W,A), (T3 ,R,B), (T3 ,W,B), (T4 ,W,D), (T3 ,R,A), (T3 ,W,A), (T5 ,R,C), (T5 ,R,B), (T5 ,R,A), (T5 ,W,A), (T6 ,R,A), (T6 ,W,A)) mit der Abhängigkeitsrelation 5.5 Synchronisationsverfahren 99 DEP (S4) = {(T1 , A, T3 ), (T3 , A, T5 ), (T5 , A, T6 ), (T2 , C, T5 ), (T3 , B, T5 )} und dem Präzedenz-Graphen T1 T2 T3 T4 T5 T6 S4 ist konflikt-serialisierbar. 5.5.3 Verklemmungen Zwei Transaktonen T1 und T2 können sich gegenseitig blockieren, wie die folgende Abfolge zeigt: T1 T2 Kommentar WLOCK(A) WLOCK(B) WLOCK(B) T1 wartet auf die Freigabe von B WLOCK(A) T2 wartet auf die Freigabe von A Eine Situation, in der sich zwei Transaktionen wie oben gegenseitig in den War- testatus versetzen, wird als Verklemmung (deadlock) bezeichnet. Ein DBMS, das Sperrmechanismen anwendet, muß Verklemmungen sofort erkennen und auflösen. Eine der beteiligten Transaktionen muß dazu vom DBMS zurückgesetzt werden. Je nach Strategie wird hier die älteste oder die jüngste Transaktion ausgewählt. Das DBMS nimmt dann ggf. einen Neustart der Transaktion vor, oder es teilt den Mißerfolg über eine Fehlermeldung mit. Zur Aufdeckung einer Verklemmung kann der Wartegraph W G ⊆ T × T herangezo- gen werden. (Tm , Tn ) ∈ W G dokumentiert, daß Tn auf die Freigabe eines Objektes durch Tm wartet. Nach der Freigabe wird die Kante wieder aus W G entfernt. Eine Verklemmung liegt genau dann vor, wenn W G einen Zyklus enthält. Transaktionen mit sehr kurzer Aufbauphase verringern die Gefahr einer Verklem- mung. Deshalb sollten die Transaktionen alle aufzugreifenden Elemente möglichst unmittelbar nach dem Start sperren. Allerdings verringert dieses Vorgehen wegen der längeren Sperren die Parallelität des Datenbankbetriebs. 5.5 Synchronisationsverfahren 100 5.5.4 Hierarchische Sperrprotokolle Bislang haben wir nur die zwei Sperrmodi READ und WRITE betrachtet. Weiterhin waren wir bislang davon ausgegangen, daß alle Sperren auf derselben Granularität“ ” erworben werden. Mögliche Sperrgranulate sind: Datensätze: Ein Datensatz (Tupel) ist i.a. die kleinste Sperreinheit, die in einem Datensystem angeboten wird. Transaktionen, die auf sehr viele Datensätze zugreifen, müssen bei dieser Sperrgranularität einen hohen Sperraufwand in Kauf nehmen. Seiten: In diesem Fall werden durch Vergabe einer Sperre implizit alle auf der Seite gespeicherten Datensätze gesperrt. Segmente: Ein Segment ist eine logische Einheit von mehreren (i.a. vielen) Seiten. Werden Segmente als Sperreinheit gewählt, wird natürlich die Parallelität drastisch eingeschränkt, da bei einer WRITE-Sperrung implizit alle Seiten innerhalb des be- treffenden Segments exklusiv gesperrt werden. Datenbasis: Dies ist der Extremfall, da dadurch die serielle Abarbeitung aller Ände- rungstransaktionen erzwungen wird. In der folgenden Abbildung sind diese hierarchisch miteinander in Beziehung ste- henden Sperrgranulate graphisch dargestellt. Datenbasis Segmente Seiten Sätze Bezogen auf die Abbildung waren wir bislang davon ausgegangen, daß alle Trans- aktionen ihre Sperren auf derselben Hierarchiestufe – also auf der Ebene der Sätze, Seiten, Segmente oder Datenbasis – anfordern. Überlegen wir uns, welche Auswir- kungen die Vermischung der Sperrgranulate hätte: Nehmen wir an, Transaktion T1 will das linke“ Segment exklusiv sperren. Dann müßte man alle Sperren auf Seite- ” nebene durchsuchen, um zu überprüfen, ob nicht irgendeine andere Transaktion eine in dem Segment enthaltene Seite gesperrt hat. Gleichfalls muß man alle Sperren auf 5.5 Synchronisationsverfahren 101 der Satzebene durchsuchen, ob nicht ein Satz, der in einer Seite des Segments steht, von einer anderen Transaktion gesperrt ist. Dieser Suchaufwand ist so immens, daß sich diese einfache Vermischung von Sperrgranulaten verbietet. Andererseits hat die Beschränkung auf nur eine Sperrgranularität für alle Transaktionen auch entschei- dende Nachteile: • Bei zu kleiner Granularität werden Transaktionen mit hohem Datenzugriff stark belastet, da sie viele Sperren anfordern müssen. • Bei zu großer Granularität wird der Parallelitätsgrad des Systems unnötig ein- geschränkt, da implizit zu viele Datenobjekte unnötigerweise gesperrt werden – es werden also Datenobjekte implizit gesperrt, die gar nicht benötigt werden. Die Lösung des Problems besteht in der Einführung zusätzlicher Sperrmodi, wodurch die flexible Auswahl eines bestimmten Sperrgranulats pro Transaktion ermöglicht wird. Dieses Verfahren wird wegen der flexiblen Wahl der Sperrgranularität in der englischsprachigen Literatur als multiple-granularity locking (MGL) bezeichnet. Die zusätzlichen Sperrmodi bezeichnet man als Intentionssperren, da dadurch auf höheren Ebenen der Sperrgranulatshierarchie die Absicht einer weiter unten in der Hierarchie gesetzten Sperre angezeigt wird. Die Sperrmodi sind: • N L: keine Sperrung (no lock), • S: Sperrung durch Leser (READ-lock), • X: Sperrung durch Schreiber (WRITE-lock), • IS: weiter unten in der Hierarchie ist eine Lesesperre (S) beabsichtigt (inten- tion share), • IX: weiter unten in der Hierarchie ist eine Schreibsperre (X) beabsichtigt (intention exclusive). Die Kompatibilität dieser Sperrmodi zueinander ist in der folgenden Kompatibi- litätsmatrix aufgeführt (in der Horizontalen ist die derzeitige Sperre eines Objekts angegeben, in der Vertikalen die – von einer anderen Transaktion – angeforderte Sperre): NL S X IS IX S X X − X − X X − − − − IS X X − X X IX X − − X X Die Sperrung eines Datenobjekts muß dann so durchgeführt werden, daß erst ge- eignete Sperren in allen übergeordneten Knoten in der Hierarchie erworben werden. 5.5 Synchronisationsverfahren 102 D.h. die Sperrung verläuft top-down“ und die Freigabe bottom-up“ nach folgenden ” ” Regeln: a) Bevor ein Knoten mit S oder IS gesperrt wird, müssen alle Vorgänger in der Hierarchie vom Sperrer (also der Transaktion, die die Sperre anfordert) im IX- oder IS-Modus gehalten werden. b) Bevor ein Knoten mit X oder IX gesperrt wird, müssen alle Vorgänger vom Sperrer im IX-Modus gehalten werden. c) Die Sperren werden von unten nach oben (bottom-up) freigegeben, so daß bei keinem Knoten die Sperre freigegeben wird, wenn die betreffende Transaktion noch Nachfolger dieses Knotens gesperrt hat. Anhand der folgenden Abbildung soll das Sperrprotokoll verdeutlicht werden. (T2 , IS ) Datenbasis (T1 , IX ) D (T3 , IX ) Segmente (T1 , IX ) a1 (T2 , IS ) a2 (T3 , X) Seiten (T1 , X) p1 p2 (T2 , S) p3 Sätze s1 s2 s3 s4 s5 s6 Sperren sind hier mit (Ti , M ) bezeichnet, wobei Ti die Transaktion und M den Sperrmodus darstellt. Dazu betrachten wir drei Transaktionen: • T1 will die Seite p1 exklusiv sperren und muß dazu zunächst IX-Sperren auf der Datenbasis D und auf a1 (den beiden Vorgängern von p1 ) besitzen. • T2 will die Seite p2 mit einer S-Sperre belegen, wozu T2 erst IS-Sperren oder IX-Sperren auf den beiden Vorgängerknoten D und a1 anfordert. Da IS mit den an T1 vergebenen IX-Sperren kompatibel ist, können diese Sper- ren gewährt werden. • T3 will das Segment a2 mit X sperren und fordert IX für D an, um danach die X-Sperre auf a2 zu bekommen. Damit hat T3 dann alle Objekte unterhalb von a2 – hier die Seite p3 mit den Datensätzen s5 und s6 – implizit mit X gesperrt. Die obige Abbildung zeigt den Zustand zu diesem Zeitpunkt – nachdem alle Sperran- forderungen der drei Transaktionen erfüllt wurden. 5.5 Synchronisationsverfahren 103 Wir wollen nun noch zwei weitere Transaktionen T4 (Schreiber) und T5 (Leser) betrachten, deren Sperranforderungen in dem aktuell herrschenden Zustand nicht gewährt werden können. • T4 will den Datensatz s3 exklusiv sperren. Dazu wird T4 zunächst IX-Sperren für D, a1 und p2 – in dieser Reihenfolge – anfordern. Die IX-Sperren für D und a1 können gewährt werden, da sie mit den dort existierenden Sperren IX und IS kompatibel sind. Aber die IX-Sperre auf p2 kann nicht gewährt werden, da IX nicht mit S verträglich ist. • T5 will eine S-Sperre auf s5 erwerben. Dazu wird T5 IS-Sperren auf D, a2 und p3 erwerben müssen. Nur die IS-Sperre auf D ist mit den existierenden Sperren verträglich, wohingegen die auf a2 benötigte IS-Sperre nicht mit der von T3 gesetzten X-Sperre kompatibel ist. Die folgende Abbildung zeigt den Zustand nach den oben beschriebenen erfüllten Sperranforderungen. (T5 , IS ) (T1 , IX ) (T2 , IS ) Datenbasis D (T4 , IX ) (T3 , IX ) (T2 , IS ) (T3 , X ) Segmente (T1 , IX ) a1 a2 (T4 , IX ) (T5 , IS ) (T2 , S ) Seiten (T1 , X) p1 p2 p3 (T5 , IS ) (T4 , IX ) Sätze s1 s2 s3 s4 s5 s6 (T4 , X ) (T5 , S ) Die noch ausstehenden Sperren sind durch die Durchstreichung gekennzeichnet. Die Transaktionen T4 und T5 sind blockiert, aber nicht verklemmt und müssen auf die Freigabe der Sperren (T2 , S) auf p2 bzw. (T3 , X) auf a2 warten. Erst danach können die beiden Transaktionen T4 und T5 mit ihren Sperranforderungen von oben nach unten fortfahren und sukzessive die durchgestrichenen“ Sperren erwerben. Beim ” MGL-Sperrverfahren können – obwohl das in diesem Beispiel nicht der Fall ist – durchaus Verklemmungen auftreten. Aus den Beispielen sollte deutlich geworden sein, daß man zu einem gegebenen Knoten in der Datenbasis-Hierarchie alle Sperren verwalten muß. Wenn z.B. T1 die IX-Sperre auf a1 freigibt, muß der Knoten weiterhin im IS-Modus für T2 gesperrt 5.5 Synchronisationsverfahren 104 bleiben. Deshalb muß man bei einer Sperranforderung im Prinzip die angeforderte Sperre mit allen am Knoten gesetzten Sperren hinsichtlich Kompatibilität über- prüfen. Man kann dies aber beschleunigen, indem jedem Knoten ein Gruppenmodus zugewiesen wird. Dazu werden die zueinander kompatiblen Sperren geordnet. Es gilt: S > IS und IX > IS. Alle anderen Sperrmodi können laut Kompatibilitätsmatrix nicht gleichzeitig an demselben Knoten gehalten werden – und brauchen demnach auch nicht geordnet zu werden. Der Gruppenmodus stellt dann die größte (d.h. schärfste) am Knoten gehaltene Sperre dar, und neu eintreffende Sperranforderungen brauchen nur gegen diesen Gruppenmodus auf Verträglichkeit geprüft zu werden. Zusammenfassend erlaubt das MGL-Sperrverfahren den Transaktionen mit gerin- gem Datenaufkommen auf niedriger Hierarchieebene – also in kleiner Granularität – zu sperren, um dadurch die Parallelität zu erhöhen. Transaktionen mit großem Da- tenvolumen erwerben ihre Sperren auf entsprechend höherer Hierarchieebene – also in größerer Granularität –, um dadurch den Sperraufwand zu reduzieren. Bei einigen Systemen wird automatisch von einer niedrigen Granularität auf die nächsthöhere Granularität umgeschaltet, sobald eine bestimmte Anzahl von Sperren in der klei- neren Granularität erworben wurde. 5.5.5 Einfüge- und Löschoperationen, Phantome Es ist klar, daß man auch Einfüge- und Löschoperationen in die Mehrbenutzer- synchronisation einbeziehen muß. Die naheliegende Methode besteht in folgendem Vorgehen: • Vor dem Löschen eines Objekts muß die Transaktion eine X-Sperre für dieses Objekt erwerben. Man beachte aber, daß eine andere Transaktion, die für dieses Objekt ebenfalls eine Sperre erwerben will, diese nicht mehr erhalten kann, falls die Löschtransaktion erfolgreich (mit commit) abschließt. • Beim Einfügen eines neuen Objekts erwirbt die einfügende Transaktion eine X-Sperre. In beiden Fällen muß die Sperre gemäß des Zwei-Phasen-Sperrprotokolls bis zum Ende der Transaktion gehalten werden. Diese einfache Erweiterung des Synchroni- sationsverfahrens schützt Transaktionen leider nicht gegen das Phantomproblem. Das Problem läßt sich dadurch lösen, daß man zusätzlich zu den Tupeln auch den Zugriffsweg, auf dem man zu den Objekten gelangt ist, sperrt. Wenn man z.B. über einen Index die Objekte gefunden hat, muß man zusätzlich zu den Tupelsperren noch Indexbereichssperren setzen. Indexe müssen im Zuge von Einfüge- und Ände- rungsoperationen natürlich fortgeschrieben werden. 5.5 Synchronisationsverfahren 105 5.5.6 Zeitstempel-Verfahren Präventive Synchronisationsstrategien wollen Verklemmungssituationen durch eine andere Zugriffskontolle von vornherein verhindern. Anstelle der Sperren wird ei- ne Transaktion, die mit ihrem Zugriff das Serialisierbarkeitskriterium zu verletzen droht, vom DBMS abgebrochen und wieder neu gestartet. Derartige Verfahren wer- den vor allem bei verteilten Datenbanken angewendet. Das Zeitstempel-Verfahren ordnet jeder Transaktion T einen (eindeutigen) Zeitstem- pel (time stamp) T S(T ) zu (z.B. die Uhrzeit der ersten Aktion oder eine fortlaufen- de Nummer). Die damit erzeugte Transaktions-Identifikation liefert gleichzeitig eine (zeitliche) lineare Anordnung T S(T1 ) < T S(T2 ) < · · · bzw. einen seriellen (Vorbild- )Schedule S + . Der tatsächliche entstehende Schedule wird dann Zugriff für Zugriff daraufhin überprüft, ob er hinsichtlich der Konflikte mit S + verwandt ist: Erzeugt ein Zugriff einer Transaktion T einen unmittelbaren Konflikt, welcher der aus S + abgeleiteten Ordnung widerspricht, so wird T abgebrochen und vom System neu gestartet. Zur Überwachung der richtigen“ zeitlichen Reihenfolge, wie sie S + vermittelt, muß ” das DBMS noch zu jedem Datenbankelement E gewisse Informationen führen, und zwar • eine Lese-Information T R(E) als den Zeitstempel der jüngsten Transaktion, welche E gelesen hat, • eine Schreib-Information T W (E) als den Zeitstempel derjenigen Transaktion, welche zuletzt auf E schreibend zugegriffen hat. Um feststellen zu können, ob S und S + äquivalent sind, betrachten wir die Abhängig- keitsrelation DEP (S) bzw. die darin dokumentierten Konflikte. Je nach Zugriffsart kann eine momentane Aktion aus T einen der folgenden Konflikte hervorrufen: • einen (W,R)-Konflikt, dokumentiert durch (T W (E), E, T S(T )) ∈ DEP (S), wenn T das Element E liest, • einen (W,W)-Konflikt, (T W (E), E, T S(T )) ∈ DEP (S), sowie unter anderem den (R,W)-Konflikt (T R(E), E, T S(T )) ∈ DEP (S), falls T auf E schreibend zugreift. Damit S und S + als äquivalent beurteilt werden können, muß das DBMS folgende Zeitbeziehungen überprüfen: • T lesend: T W (E) < T S(T ) • T schreibend: T R(E) < T S(T ) und gleichzeitig T W (E) < T S(T ) Die erste Bedingung besagt, daß nach dem letzten Schreibzugriff nur noch jüngere Transaktionen E lesen dürfen. Die zweite Bedingung fordert, daß E nur von einer 5.5 Synchronisationsverfahren 106 jüngeren als der in T W (E) vermerkten Transaktion überschrieben werden darf. T (schreibend!) muß zugleich auch noch jünger als die jüngste der bisher lesenden Transaktionen sein. Im Falle einer Verletzung der obigen Kriterien können S und S + nicht äquivalent sein. Das DBMS bricht dann Transaktion T ab und startet sie erneut mit einem jüngeren Zeitstempel. Im erfolgreichen Fall wird andernfalls bei lesendem Zugriff T R(E) = max{T S(T ), T R(E)} und bei schreibendem Zugriff T W (E) = T S(T ) gesetzt. Das Zeitstempel-Verfahren liefert einen konflikt-serialisierbaren Schedule. Wir haben oben bei einer Schreibaktion einige (R,W)-Konflikte eventuell nicht berücksichtigt, die allerdings übergangen werden dürfen: T R(E) hält stets die jüngste Transaktion fest, die jemals auf E lesend zugegriffen hat. Mit T R(E) < T S(T ) sind deshalb auch alle anderen Transaktionen, die in einem unmittelbaren (R,W)-Konflikt zu T stehen, älter als T . 5.5.7 Optimistische Verfahren Der sinnvolle Einsatz optimistischer Verfahren setzt – wie die Bezeichnung verrät – voraus, daß parallele, konsistenzgefährdende Transaktionen nur selten auftreten. Erst am Ende der Transaktion nimmt hier das DBMS eine Serialisierbarkeitsüber- prüfung, die Validierung der Transaktion, vor. Im Falle einer Verletzung der zugrundegelegten Serialisierbarkeitskriterien erfolgt der Abbruch der Transaktion mit anschließendem Neustart durch das DBMS. Um ne- gative Auswirkungen eines Abbruchs zu verhindern, nehmen die Transaktionen ihre Änderungen zunächst nur auf lokalen Kopien der Datenbankelemente vor. Erst nach der erfolgreichen Validierung wird der Originalbestand aktualisiert. (Das Verfahren setzt somit voraus, daß eine Transaktion mit Schreibzugriff zuvor das betreffende Element liest.) Um das mehrfache Auftreten desselben Mißerfolges zu verhindern, kann nach einer festgelegten Anzahl von Fehlversuchen die Datenbank für die be- treffende Transaktion kurzzeitig exklusiv gesperrt werden. Die Verarbeitung einer Transaktion T gliedert sich bei den optimistischen Verfahren in drei Etappen: • Lesephase: T übernimmt die Kopien der Datenbankelemente und nimmt dort seine Änderungen vor. • Validierungsphase: Anhand einer hinreichenden Serialisierbarkeitsbedingung überprüft das DBMS, ob eine Konsistenzgefährdung durch T mit Sicherheit ausgeschlossen werden kann. • Schreibphase: Bei positivem Validierungsergebnis überträgt das DBMS alle geänderten Kopien in den Originalbestand. Die Schreibphase ist losgelöst von der Anwendung, sie wird ausschließlich vom DBMS verarbeitet. 5.5 Synchronisationsverfahren 107 Das DBMS muß über Regeln verfügen, nach denen es potentielle Konsistenzgefähr- dungen erkennen kann. Beim Zeitstempel-Verfahren wurde jede einzelne Aktion einer Transaktion auf ihr mögliches Konfliktpotential hin überprüft. Dagegen untersuchen wir jetzt, ob sich Transaktionen als Ganzes in einen konflikt-serialisierbaren Schedule eingliedern lassen. Es wird davon ausgegangen, daß die Transaktionen nacheinander, ohne Überschnei- dungen (seriell) validiert werden. Eine Transaktion T muß dann mit denjenigen Transaktionen abgeglichen werden, deren erfolgreiche Beendigung genau zwischen dem Start von T und dem Beginn der Validierungsphase von T liegt. Diese paral- lelen Transaktionen können leicht mit Hilfe eines Transaktionszählers tnc bestimmt werden: tnc wird im Falle einer erfolgreich validierten Transaktion erhöht und als deren Identifikation vergeben. Jede Transaktion T liest dann zweimal den aktuellen Wert von tnc : zu ihrem Beginn (tnc = t0 als die Identifikation der letzten, nicht mehr zu berücksichtigenden Transaktion) und zu Beginn der Validierungsphase (tnc = t1 als Identifikation der zuletzt validierten Transaktion). Alle Transaktionen, deren Identifikationen zwischen t0 + 1 und t1 liegen, müssen sodann in die Validierung einbezogen und auf Konflikte mit T hin untersucht werden. Der seriellen Validierung lassen sich die beiden folgenden Bedingungen zugrunde- legen: a) Die Schreibphasen der Transaktionen werden seriell abgewickelt sowie b) T liest kein Element, welches gleichzeitig im Schreibzugriff einer parallelen Transaktion (mit der Identifikation t0 + 1, . . . t1 ) steht. Da alle Schreibphasen allein unter Kontrolle des DBMS stehen, kann Bedingung a) grundsätzlich eingehalten werden. Validierung, Schreibphase und Zählerfortschrei- bung/Identifizierung werden zur kritischen Phase“ gebündelt. Es wird angenom- ” men, daß das DBMS auch die kritischen Phasen in serieller Weise abarbeitet. Das DBMS muß außerdem für die einzelnen Transaktionen ein Verzeichnis über die gelesenen und geschriebenen Elemente führen. Damit ist für eine zu validierende Transaktion T nachzuprüfen, ob T Bedingung b) verletzt hat. Diese Strategie legt mit der Reihenfolge der Schreibphasen bzw. des Transakti- onszählers von vornherein eine Anordnung der validierten Transaktionen fest. Wir zeigen, daß dieses optimistische Verfahren stets einen konflikt-serialisierbaren Sche- dule erzeugt. Zuvor weisen wir nach, daß die Tripel der Abhängigkeitsrelation die Ordnung des Transaktionszählers widerspiegeln. Lemma 5.29 Für einen Schedule S, der durch ein optimistisches Verfahren gesteu- ert wurde, gilt: Mit (tnc (Ti ), X, tnc (Tj )) ∈ DEP (S) folgt tnc (Ti ) < tnc (Tj ). tnc (Ti ) bezeichnet den Transaktionszähler für Ti und <“ betrifft den numerischen Vergleich ” dieser Zähler. 5.6 Transaktionen in SQL 108 Beweis Zum Nachweis dieser Aussage unterscheiden wir die Konfliktarten, die dem Tripel (tnc (Ti ), X, tnc (Tj )) ∈ DEP (S) zugrundeliegen: (W,W)-Konflikt: Die Behauptung gilt wegen Bedingung a). (W,R)-Konflikt: Da die Schreibphase einer Transaktion erst nach ihrer Lesephase stattfindet, wird Ti vor der anderen validiert. Deshalb gilt auch hier tnc (Ti ) < tnc (Tj ). (R,W)-Konflikt: Bedingung b) garantiert, daß Ti vor Tj validiert wird: Ti wird abge- brochen, wenn es ein Element X gelesen hat, das auch im Schreibzugriff einer paral- lelen, aber vorher validierten Transaktion Tj steht. Daher gilt tnc (Ti ) < tnc (Tj ). Dieses Lemma gestattet es, eine Ordnung <∗ auf den Transaktionen T1 , . . . , Tn zu erklären. Mit Satz 5.25 erhält man dann: Satz 5.30 Das beschriebene optimistische Verfahren mit serieller Validierung er- zeugt stets einen konflikt-serialisierbaren Schedule. 5.6 Transaktionen in SQL In SQL gibt es keinen speziellen Befehl zum Starten einer Transaktion. Die meisten SQL-Statements können nur innerhalb einer Transaktion ablaufen (z.B. SELECT, INSERT, CREATE TABLE, nicht aber z.B. CONNECT). Soll ein solches Statement bear- beitet werden und es ist noch keine Transaktion aktiv, wird vom System implizit eine Transaktion gestartet. Eine Transaktion wird mit dem Befehl COMMIT beendet. Al- le durchgeführten Änderungen werden werden dadurch dauerhaft gespeichert. Eine Transaktion kann mit ROLLBACK abgebrochen werden. Alle durchgeführten Ände- rungen werden ungültig und dadurch zurückgenommen. Bislang haben wir immer die Serialisierbarkeit als Korrektheitskriterium für die Par- allelausführung von Transaktionen zugrundegelegt. Die Erzwingung der Serialisier- barkeit schränkt natürlich die Parallelität ein. In SQL92 existieren einige weitere weniger restriktive (aber teilweise obskure und potentiell die Datenbankkonsistenz gefährdende) Konsistenzstufen. Diese Konsistenzstufen werden als isolation level“ ” bezeichnet, da sie die Isolationsstufe von parallel ausgeführten Transaktionen zuein- ander beschreiben. Der Transaktionsmodus wird in folgender Syntax beschrieben: 5.6 Transaktionen in SQL 109 SET TRANSACTION [READ ONLY | READ WRITE] [ISOLATION LEVEL [READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE]] Zum Beispiel kann eine Transaktion auf Lesezugriffe durch SET TRANSACTION READ ONLY beschränkt werden oder allgemein lesend und schreibend auf die Datenbasis zugreifen (SET TRANSACTION READ WRITE). READ WRITE ist die Voreinstellung. Die vier Konsistenzstufen sind wie folgt (auch im Standard sehr vage) definiert: READ UNCOMMITTED: Dies ist die schwächste Konsistenzstufe. Sie darf auch nur für READ-ONLY-Transaktionen spezifiziert werden. Eine derartige Transakti- on hat Zugriff auf noch nicht festgeschriebene Daten. Zum Beispiel ist folgender Schedule möglich: T1 T2 read(A) ··· write(A) read(A) ··· ROLLBACK Hierbei liest die Transaktion T1 einen Wert des Datums A, der von T2 nie festgeschrieben wurde. Man kann sich leicht vorstellen, daß eine solche READ- UNCOMMITTED-Transaktion beliebig inkonsistente Datenbasiszustände zu sehen bekommt. Deshalb ist die Einschränkung solcher Transaktionen auf reine Lesezu- griffe (READ ONLY) äußerst notwendig. Transaktionen dieser Art sind i.a. nur sinnvoll, um sich einen globalen Überblick über die Datenbasis zu verschaffen (browsing). Die READ-UNCOMMITTED-Trans- aktionen behindern die parallele Ausführung anderer Transaktionen nicht, da sie selbst keine Sperren benötigen. READ COMMITTED: Diese Transaktionen lesen nur festgeschriebene Werte. Allerdings können sie unterschiedliche Zustände der Datenbasis-Objekte zu sehen bekommen: 5.6 Transaktionen in SQL 110 T1 T2 read(A) write(A) write(B) COMMIT read(B) read(A) ··· In diesem Fall liest die READ-COMMITTED-Transaktion T1 zunächst den Wert von A, bevor T2 A und B verändert. Danach liest T1 den Wert von B – das reicht schon aus, um die Serialisierbarkeit zu verletzen. Noch schwerwiegender ist, daß T1 jetzt nochmal A mit einem anderen Wert als zuvor liest. Man bezeichnet dieses Problem als non repeatable read. REPEATABLE READ: Das oben aufgführte Problem des non repeatable read wird durch diese Konsistenzstufe ausgeschlossen. Allerdings kann es hierbei noch zum Phantomproblem kommen. Dies kann z.B. dann passieren, wenn eine parallele Änderungstransaktion dazu führt, daß Tupel ein Selektionsprädikat erfüllen, das sie zuvor nicht erfüllten. SERIALIZABLE Diese Konsistenzstufe fordert die Serialisierbarkeit. Es dürfte klar sein, daß die schwächeren Isolationsstufen u.U. zu sehr schwerwiegenden Konsi- stenzverletzungen führen können. Ein DBMS muß – gemäß dem SQL92-Standard – nicht alle aufgeführten Isolationsstufen auch tatsächlich implementieren. Wenn eine benötigte Isolationsstufe nicht verfügbar ist, muß die jeweils schärfere“ vorhandene ” Form angewendet werden. Daraus folgt, daß mindestens die Serialisierbarkeit reali- siert sein muß. Datenbankanwender sollten darauf achten, daß einige kommerzielle DBMS-Produkte eine andere, also schwächere, Konsistenzstufe als serializable als Default eingestellt haben.
Enter the password to open this PDF file:
-
-
-
-
-
-
-
-
-
-
-
-