5 Transaktionsverwaltung 81 5 Transaktionsverwaltung Jeder zug ̈ angliche Datenbankzustand soll im Sinne eines ”Schnappschusses“ ein kor- rektes Gesamtbild der modellierten Welt wiedergeben. Wir bezeichnen eine Daten- bank als konsistent , wenn alle Aussagen ( ̈ uber Gegenst ̈ ande oder Sachverhalte), die sie vermittelt, als korrekt aufgefaßt werden. Grunds ̈ atzlich nehmen wir an, daß Anwendungen f ̈ ur sich allein eine konsistente Datenbank wieder in eine konsistente Datenbank ̈ uberf ̈ uhren. Sie st ̈ utzen sich dabei auf die elementaren Datenbankzugriffe, wobei wir zwischen lesenden Aktionen (Lesen eines Records) und schreibenden Aktionen (Neuzugang, L ̈ oschen und ̈ Andern 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 ̈ atzlich davon aus, daß Transaktionen (vom Anwender) so konzipiert sind, daß sie einen konsistenten Bestand wieder in einen konsistenten Zustand ̈ uberf ̈ uhren. Eine gr ̈ oßere Anwendung setzt sich in der Regel aus mehreren derartigen Einheiten zusammen, die dann im konkreten Einsatz nacheinander verarbeitet werden. F ̈ ur eine Transaktion fordern wir, daß ihre Abwicklung atomaren Charakter besitzt: entweder soll sie vom DBMS vollst ̈ andig oder ̈ uberhaupt nicht ausgef ̈ uhrt werden. Definition 5.1 Eine Transaktion ist eine vom Benutzer spezifizierte Folge von DB- ̈ Anderungen, welche die DB von einem zul ̈ assigen Zustand wieder in einen zul ̈ assigen Zustand ̈ uberf ̈ uhrt 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 ̈ ugung: 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 ̈ auft und die vorgesehenen Schrit- te ausf ̈ uhrt. Bei der Ausf ̈ uhrung von einer bzw. von mehreren Transaktionen kann es aber zu St ̈ orungen bzw. Fehlern kommen, die das verhindern. Um diese St ̈ orungen auszuschließen, werden gewisse Eigenschaften von Transaktionen gefordert. Diese sind Atomarit ̈ at, 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 ̈ at (atomicity): Eine Transaktion wird entweder ganz oder gar nicht aus- gef ̈ uhrt. Wenn nicht alle Operationen einer Transaktion ausgef ̈ uhrt werden k ̈ onnen, so muß diese abgebrochen werden, und bereits ausgef ̈ uhrte ̈ Anderungen m ̈ ussen r ̈ uckg ̈ angig gemacht werden. Beispiel 5.3 Bei unserer Umbuchungstransaktion m ̈ ussen wir sicherstellen, daß bei- de Aktionen durchgef ̈ uhrt 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 ̈ are das eine Verletzung der Atomarit ̈ at. Konsistenzerhaltung (consistency): Das Gesamtergebnis einer parallelen Aus- f ̈ uhrung von Transaktionen entspricht irgendeiner Hintereinanderausf ̈ uhrung dieser Transaktionen. (Da eine Transaktion alleine konsistenzerhaltend ist, ist auch eine Hintereinanderausf ̈ uhrung 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 ̈ ur 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 ̈ uhrt worden ist. 5.2 Zustands ̈ uberg ̈ ange einer Transaktion 83 Dauerhaftigkeit (durability): Die Ergebnisse einer erfolgreich durchgef ̈ uhrten Transaktion bleiben erhalten. Beispiel 5.6 Nach der Durchf ̈ uhrung der Umbuchung muß der neue Kontostand sowohl auf dem Konto als auch auf dem Sparbuch erscheinen und kann nicht mehr etwa aus Systemgr ̈ unden r ̈ uckg ̈ angig gemacht werden. Die Gew ̈ ahrleistung von Atomarit ̈ at und Dauerhaftigkeit wird von einer Recovery - Komponente ̈ ubernommen, Konsistenzerhaltung und Isolation werden durch eine Komponente f ̈ ur Mehrbenutzerkontrolle (concurrency control) sichergestellt. Die Mehr- benutzerkontrolle verwendet dabei ein Verfahren, das die Serialisierbarkeit von par- allel ablaufenden Transaktionen gew ̈ ahrleistet. 5.2 Zustands ̈ uberg ̈ ange einer Transaktion In der folgenden Abbildung sind die m ̈ oglichen Zust ̈ ande und die ̈ Uberg ̈ ange zwischen Zust ̈ anden f ̈ ur Transaktionen dargestellt. potentiell aktiv wartend abgeschlossen wiederholbar gescheitert persistent aufgegeben inkarnieren verdr ̈ angen einbringen beenden abbrechen abbrechen neu starten zur ̈ ucksetzen abbrechen festschreiben zur ̈ ucksetzen Eine Transaktion befindet sich in einem der folgenden Zust ̈ ande: potentiell: Die Transaktion ist codiert und ”wartet darauf“, in den Zustand aktiv zu wechseln. Diesen ̈ Ubergang 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 ̈ uhrung von Operationen, etc. wartend: Bei einer ̈ Uberlast des Systems kann die Transaktionsverwaltung einige aktive Transaktionen in den Zustand wartend verdr ̈ angen. Nach Behebung der ̈ Uberlast 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 ̈ ussen noch m ̈ oglicherweise verletzte Konsistenzbe- dingungen ̈ uberpr ̈ uft 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 ̈ oglichen Endzust ̈ anden einer Transaktionsverarbeitung. gescheitert: Transaktionen k ̈ onnen aufgrund vielf ̈ altiger Ereignisse scheitern. Z.B. kann der Benutzer selbst durch einen Abort-Befehl eine aktive Transaktion abbre- chen. Weiterhin k ̈ onnen Systemfehler zum Scheitern aktiver oder wartender Trans- aktionen f ̈ uhren. Bei abgeschlossenen Transaktionen k ̈ onnen 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 ̈ achst zur ̈ uckgesetzt werden. Danach k ̈ onnen sie durch Neustarten wiederum aktiviert werden. aufgegeben: Eine gescheiterte Transaktion kann sich aber auch als ”hoffnungslos“ herausstellen. In diesem Fall wird ihre Wirkung zur ̈ uckgesetzt und die Transakti- onsverarbeitung geht in den Endzustand aufgegeben ̈ uber. 5.3 Fehler bei unkontrolliertem Mehrbenutzerbetrieb Wir wollen uns zun ̈ achst mit den m ̈ oglichen Fehlern, die im unkontrollierten (und nicht synchronisierten) Mehrbenutzerbetrieb auftreten k ̈ onnen, besch ̈ aftigen. Wir werden diese Fehler in drei Fehlerklassen aufteilen. 5.3 Fehler bei unkontrolliertem Mehrbenutzerbetrieb 85 5.3.1 Verlorengegangene ̈ Anderungen Dieses Problem (lost update) soll wieder anhand der folgenden zwei Transaktionen aus dem Bankenbereich demonstriert werden: • Transaktion T 1 transferiert 30 EURO von Konto A nach Konto B , wobei zun ̈ achst Konto A belastet wird und danach die Gutschrift auf Konto B erfolgt. • Die gleichzeitig ablaufende Transaktion T 2 schreibt dem Konto A 3% Zin- seink ̈ unfte gut. Der Ablauf dieser beiden Transaktionen k ̈ onnte wie folgt verzahnt ablaufen – wenn es keine Mehrbenutzersynchronisation g ̈ abe: Schritt T 1 T 2 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 ̈ uhrung ist, daß die in Schritt 5 dem Konto A gutgeschriebenen Zinsen verlorengehen, da der in Schritt 5 von T 2 geschriebene Wert in Schritt 6 gleich wieder von T 1 ̈ uberschrieben wird. Deshalb geht der Effekt von Transaktion T 2 verloren. 5.3.2 Abh ̈ angigkeit von nicht freigegebenen ̈ Anderungen Diese Fehlerklasse wird manchmal auch als ”dirty read“ bezeichnet, da ein Datum gelesen wird, das so niemals in einem g ̈ ultigen (transaktionskonsistenten) Zustand der Datenbasis vorkommt. Wir wollen auch dies an unseren Beispieltransaktionen T 1 ( ̈ Uberweisung) und T 2 (Zinsgutschrift) demonstrieren: 5.3 Fehler bei unkontrolliertem Mehrbenutzerbetrieb 86 Schritt T 1 T 2 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 ̈ uhrung liest T 2 in Schritt 4 einen Wert f ̈ ur Konto A , von dem T 1 schon 30 EURO abgebucht hat. Aber T 1 wird in Schritt 9 abgebrochen, so daß die Wirkung von T 1 g ̈ anzlich zur ̈ uckgesetzt werden muß. Leider hat aber T 2 in Schritt 5 die Zinsen basierend auf dem falschen Wert von A berechnet und in Schritt 6 dem Konto gutgeschrieben. D.h., die Transaktion T 2 wurde auf der Basis inkonsistenter Daten durchgef ̈ uhrt. 5.3.3 Phantomproblem Das Phantomproblem taucht auf, wenn w ̈ ahrend der Abarbeitung einer Transak- tion T 2 eine andere Transaktion T 1 ein neues Datum generiert, das T 2 eigentlich h ̈ atte mitber ̈ ucksichtigen m ̈ ussen. Als Beispiel betrachten wir die folgenden beiden Transaktionen: T 1 T 2 SELECT SUM (KtStand) FROM Konto INSERT INTO Konto VALUES (1077, 42) SELECT SUM (KtStand) FROM Konto Hierbei f ̈ uhrt T 2 (innerhalb einer Transaktion) zweimal die SQL-Anfrage aus, um die Summe aller Kontost ̈ ande zu ermitteln. Das Problem besteht nun darin, daß T 1 zwischenzeitlich ein neues Konto – n ̈ amlich das Konto mit der Kennung 1077 und dem Kontostand 42 EURO einf ̈ ugt, das aber erst beim zweiten Durchgang der SQL- Anfrage ber ̈ ucksichtigt wird. Die Transaktion T 2 berechnet also zwei unterschiedliche Werte, da zwischenzeitlich das Phantom 1077 eingef ̈ ugt 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 ̈ at. Parallele Transaktionen sind so zu synchronisieren, daß die ̈ Aquivalenz 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 ̈ allt. Parallele Transaktionen, welche gemeinsame Datenobjekte ̈ andern, nehmen unter Umst ̈ anden inkonsistente Daten- bankzust ̈ ande entgegen. Das DBMS braucht bei parallelen Transaktionen dann nicht einzugreifen, wenn die Transaktionen (in einem noch zu pr ̈ azisierenden 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 ̈ otigt 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 = { T 1 , . . . , T n } eine Menge von Transaktionen. Jede Trans- aktion bestehe aus Einzelschritten. a) Ein Schedule f ̈ ur T ist eine Folge aus allen Einzelschritten der Transaktionen in T , worin die Einzelschritte jeder Transaktion T i in der gleichen Reihenfolge wie in T i vorkommen ( 1 ≤ i ≤ n ). b) Ein Schedule heißt seriell , wenn die Einzelschritte jeder Transaktion T i 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 ̈ ost, a ( i ) die Art dieser Aktion ( W f ̈ ur write bzw. R f ̈ ur read ) und e ( i ) die Identifikation des betreffenden Zugriffs-Objektes bedeuten. Eine Transaktion (mit der Identifikation) T n kann als eine Teilfolge des Schedules 5.4 Parallele Transaktionen 88 interpretiert werden; dazu sind alle Tripel auszuw ̈ ahlen, f ̈ ur die T ( i ) = T n gilt: { ( T ( i ) , a ( i ) , e ( i )) | T ( i ) = T n } Beispiel 5.9 Es seien die folgenden Transaktionen, welche auf die Datenbankele- mente A , B , C und D zugreifen, gegeben: T 1 : (( R , A ), ( W , A )) T 2 : (( R , C ), ( W , C )) T 3 : (( R , B ), ( W , B ), ( R , A ), ( W , A )) T 4 : (( R , D ), ( W , D )) T 5 : (( R , C ), ( R , B ), ( R , A ), ( W , A )) T 6 : (( R , A ), ( W , A )) Zeitliche Versetzungen sollen zu folgenden Abl ̈ aufen f ̈ uhren: a) S 1 als serieller Schedule mit der Reihenfolge T 1 , T 2 , T 3 , T 4 , T 5 , T 6 : S 1 : (( T 1 , R , A ), ( T 1 , W , A ), ( T 2 , R , C ), ( T 2 , W , C ), ( T 3 , R , B ), ( T 3 , W , B ), ( T 3 , R , A ), ( T 3 , W , A ), ( T 4 , R , D ), ( T 4 , W , D ), ( T 5 , R , C ), ( T 5 , R , B ), ( T 5 , R , A ), ( T 5 , W , A ), ( T 6 , R , A ), ( T 6 , W , A )) b) S 2 mit der Abfolge: T 1 T 2 T 3 T 4 T 5 T 6 ( 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 ) S 2 : (( T 1 , R , A ), ( T 2 , R , C ), ( T 2 , W , C ), ( T 3 , R , B ), ( T 4 , R , D ), ( T 1 , W , A ), ( T 3 , W , B ), ( T 5 , R , C ), ( T 3 , R , A ), ( T 5 , R , B ), ( T 4 , W , D ), ( T 3 , W , A ), ( T 5 , R , A ), ( T 5 , W , A ), ( T 6 , R , A ), ( T 6 , W , A )) 5.4 Parallele Transaktionen 89 F ̈ ur einen seriellen Schedule S k ̈ onnen die beteiligten Transaktionen auf nat ̈ urliche Weise linear angeordnet werden: Wir setzen T n < T m , falls T n vor T m verarbeitet wird. Ein DBMS k ̈ onnte die Datenbankkonsistenz dadurch erzwingen, daß es die parallelen Transaktionen in eine Warteschlange einreiht und nacheinander (seriell) abarbeitet. Eine derartige Strategie verbietet sich allerdings f ̈ ur 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 ̈ urfen Transaktionen sicherlich ohne Bedenken parallel abgewickelt werden, wenn einer der folgenden F ̈ alle vorliegt: • alle Transaktionen verwenden ausschließlich lesende Zugriffe oder • die Transaktionen greifen auf keine gemeinsamen Elemente zu. In beiden F ̈ allen f ̈ uhrt jede beliebige Verschiebung oder Verzahnung der Transaktio- nen zu demselben Resultat. 5.4.1 Konflikte Gefahren-Situationen k ̈ onnen sich bei der Abwicklung paralleler Transaktionen nur dann einstellen, wenn Schreibzugriffe auf gemeinsame Elemente stattfinden. Zur Be- schreibung derartiger Zusammenh ̈ ange zwischen Transaktionen dient die folgende Klassifizierung von Konflikten. Definition 5.10 Eine Transaktion T i steht mit einer anderen Transaktion T j in einem (W,R)-Konflikt , wenn T i zuerst schreibend und T j sp ̈ ater lesend auf ein gemein- sames Element zugreifen, (R,W)-Konflikt , wenn T i zuerst lesend und T j danach schreibend auf ein gemein- sames Element zugreifen, (W,W)-Konflikt , wenn zuerst T i und sp ̈ ater T j schreibend auf ein gemeinsames Element zugreifen. Konflikte k ̈ onnen 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 ̈ ur einen Schedule S = ( ( T (1) , a (1) , e (1)) , . . . , ( T ( k ) , a ( k ) , e ( k )) ) , an welchem die Transaktionen T = { T 1 , . . . , T m } und die Elemente E = { E 1 , . . . , E n } beteiligt sind, ist die Abh ̈ angigkeitsrelation (dependency relation) DEP ( S ) ⊆ T × E × T definiert als die Menge aller Tripel ( T ( h ) , E i , T ( j )) , f ̈ ur die gilt: a) 1 ≤ h < j ≤ k , 5.4 Parallele Transaktionen 90 b) die Transaktionen T ( h ) und T ( j ) stehen hinsichtlich E i 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 E i zu- greifen: F ̈ ur jedes l mit h < l < j , e ( l ) = E i , T ( l ) 6 = T ( h ) und T ( l ) 6 = T ( j ) gilt: a ( l ) = R Bedingung c) ber ̈ ucksichtigt in DEP ( S ) nur unmittelbare Konflikte. Wenn nur die (W,W)-Konflikte auf einem Element E i betrachtet werden, so gilt: Zu einem Index m , f ̈ ur den T ( m ) schreibend auf E i zugreift, existiert eindeutig ein Index n > m , so daß ( T ( m ) , E i , T ( n )) ∈ DEP ( S ) einen (W,W)-Konflikt wiedergibt. T ( n ) ist dabei die n ̈ achste Transaktion, die auf E i schreibend zugreift. Beispiel 5.12 Die Abh ̈ angigkeitsrelationen zu Beispiel 5.9 lauten DEP ( S 1 ) = DEP ( S 2 ) = { ( T 1 , A, T 3 ) , ( T 3 , A, T 5 ) , ( T 5 , A, T 6 ) , ( T 2 , C, T 5 ) , ( T 3 , B, T 5 ) } Aktionspaare, welche einem Tripel aus der Abh ̈ angigkeitsrelation zugrundeliegen, d ̈ urfen 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 ̈ angigkeitsrelation DEP ( S ) alle Transaktionspaare, die sich gegenseitig unmittelbar beeinflussen. Sie gestattet uns, ein genaues Kriterium zur Beurteilung von Konsistenzgef ̈ ahrdungen herzuleiten. Serielle Abwicklungen nehmen dabei eine Musterrolle ein. Definition 5.13 Zwei Schedules S 1 und S 2 heißen ̈ aquivalent , falls die beiden fol- genden Bedingungen erf ̈ ullt sind: a) In S 1 und S 2 sind dieselben Transaktionen vorhanden, b) S 1 und S 2 besitzen die gleiche Abh ̈ angigkeitsrelation: DEP ( S 1 ) = DEP ( S 2 ) Definition 5.14 Ein Schedule S heißt konflikt-serialisierbar , falls zu S ein ̈ aqui- valenter serieller Schedule S ∗ existiert. 5.4 Parallele Transaktionen 91 In einem konflikt-serialisierbaren Schedule treten zwei Transaktionen T m und T n bei allen Konflikten in derselben zeitlichen Abfolge auf: Auf alle Elemente, die in einen Konflikt zwischen T m und T n verstrickt sind, greift T m entweder immer vor T n oder immer nach T n zu. Aus der Sicht einer Transaktion T n finden deshalb alle ande- ren Transaktionen, mit denen sie in einem mittelbaren oder unmittelbaren Konflikt steht, entweder vollst ̈ andig vorher oder vollst ̈ andig nachher statt. Die Datenbank- zust ̈ ande, die jede Transaktion wahrnimmt oder an ihrem Ende erzeugt, verhalten sich deshalb so, als ob sie in einer seriellen Abwicklung entstanden w ̈ aren. Beispiel 5.15 Schedule S 2 aus Beispiel 5.9 ist konflikt-serialisierbar, da DEP ( S 1 ) = DEP ( S 2 ) gilt. Dagegen kann die Abfolge T 1 T 2 T 3 T 4 T 5 T 6 ( 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 S 3 : (( T 1 , R , A ), ( T 2 , R , C ), ( T 2 , W , C ), ( T 3 , R , B ), ( T 4 , R , D ), ( T 1 , W , A ), ( T 3 , W , B ), ( T 5 , R , C ), ( T 5 , R , B ), ( T 4 , W , D ), ( T 5 , R , A ), ( T 5 , W , A ), ( T 6 , R , A ), ( T 6 , W , A ), ( T 3 , R , A ), ( T 3 , W , A )) und der Abh ̈ angigkeitsrelation DEP ( S 3 ) = { ( T 1 , A, T 5 ) , ( T 5 , A, T 6 ) , ( T 6 , A, T 3 ) , ( T 2 , C, T 5 ) , ( T 3 , B, T 5 ) } 5.4 Parallele Transaktionen 92 nicht konflikt-serialisierbar sein: F ̈ ur das Element A gilt ” T 5 vor T 6 vor T 3 “, f ̈ ur B jedoch ” T 3 vor T 5 “, was offensichtlich im Widerspruch zueinander steht. Die lineare (irreflexive) Ordnung auf einem seriellen Schedule spiegelt sich zum Teil in der Abh ̈ angigkeitsrelation eines konflikt-serialisierbaren Schedules wider. Dazu er- kl ̈ aren wir auf einem Schedule S , bei dem die Elemente E = { E 1 , . . . , E n } einbezogen sind, die Relation ” < ∗ “ zwischen Transaktionen durch T m < ∗ T n , falls ( T m , E i , T n ) ∈ DEP ( S ) f ̈ ur ein E i ∈ E. Man beachte, daß ” < ∗ “ im allgemeinen keine (totale) Ordnung mehr festlegt. Aller- dings vertr ̈ agt sich ” < ∗ “ f ̈ ur konflikt-serialisierbare Schedules mit der totalen linearen Ordnung ” < “, die auf dem ̈ aquivalenten seriellen Schedule erkl ̈ art ist: Korollar 5.16 F ̈ ur einen konflikt-serialisierbaren Schedule S mit den Transaktio- nen T = { T 1 , . . . , T k } gilt: Mit T m < ∗ T n folgt auch T m < T n in jedem ̈ aquivalenten seriellen Schedule. Die Relation ” < ∗ “ enth ̈ alt in der Regel weniger Beziehungspaare als ” < “. Sie kann allerdings durch transitive Erweiterung zu einer totalen Ordnungsrelation erweitert werden. Satz 5.17 F ̈ ur den konflikt-serialisierbaren Schedule S mit den Transaktionen T = { T 1 , . . . , T n } erzeugt ” < ∗ “ mit ihrer transitiven Erweiterung eine strikte Ordnung auf T Beweis Die Transitivit ̈ at gilt laut Konstruktion, die Asymmetrie ist nach Korol- lar 5.16 erf ̈ ullt. Definition 5.18 F ̈ ur einen Schedule S mit den Transaktionen T = { T 1 , . . . , T n } , der Elementenmenge E und der Abh ̈ angigkeitsrelation DEP ( S ) ist der Pr ̈ azedenz- Graph P G ( S ) definiert durch ( T m , T n ) ∈ P G ( S ) , falls ( T m , E i , T n ) ∈ DEP ( S ) f ̈ ur ein E i ∈ E. Ein Pr ̈ azedenz-Graph P G ( S ) charakterisiert genau wie DEP ( S ) die Konflikte in ei- ner Abfolge von Transaktionen. Im Unterschied zur Abh ̈ angigkeitsrelation DEP ( S ) treten die Elemente ( E i ) dabei jedoch hier nicht mehr in Erscheinung. Es wird allein die Reihenfolge zweier in Konflikt stehender Transaktionen mit der Kante verdeutlicht. F ̈ ur 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 ̈ azedenz-Graphen zu den Beispielen 5.9 und 5.15 sind: zu S 1 und S 2 : T 1 T 3 T 5 T 2 T 6 zu S 3 : T 1 T 5 T 2 T 6 T 3 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 ( T i 1 , T i 2 ) , ( T i 2 , T i 3 ) , . . . , ( T i k , T i 1 ), was auch folgendermaßen dar- stellbar ist: T i 1 −→ T i 2 −→ · · · −→ T i k −→ T i 1 ” −→ “ gibt die zeitliche Reihenfolge f ̈ ur Zugriffe der Transaktionen auf beliebige Elemente wieder. Wegen der blockweisen Abarbeitung ist f ̈ ur einen seriellen Schedule eine Anordnung ” T i 1 vor T i 2 . . . vor T i k vor T i 1 “ jedoch nicht m ̈ oglich. Also kann S nicht konflikt-serialisierbar sein. Falls noch die Umkehrung des letzten Satzes (Zyklenfreiheit gew ̈ ahrleistet Konflikt- Serialisierbarkeit) nachgewiesen werden kann, verf ̈ ugen wir ̈ uber ein exaktes Krite- rium zur Beurteilung von Abfolgen. Dazu suchen wir ein Verfahren, das aus einem azyklischen Pr ̈ azedenz-Graphen einen seriellen Schedule konstruiert. Die Knoten eines beliebigen azyklisch gerichteten Graphen k ̈ onnen 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 ̈ ahlen aus diesen Kandidaten willk ̈ urlich 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 ̈ ur einen Schedule S mit azyklischem Pr ̈ azedenz-Graphen P G ( S ) gilt: Falls ( T m , E i , T n ) ∈ DEP ( S )( bzw. T m < ∗ T n ) besteht, so gilt auch f ̈ ur jeden, durch topologisches Sortieren erzeugten seriellen Schedule S ∗ : T m < T n Beweis ( T m , E i , T n ) ∈ DEP ( S ) f ̈ uhrt zu ( T m , T n ) ∈ P G ( S ). Da topologisches Sortieren die Auswahl eines Nachfolgerknotens im (Rest-)Graphen verbietet, gilt in S ∗ : T m < T n Zwischen einem Schedule S mit azyklischem Pr ̈ azedenz-Graphen und dem durch topologischen Sortieren erzeugten S ∗ besteht folgende Verwandtschaft: Lemma 5.22 Aus dem Schedule S mit einem azyklischen Pr ̈ azedenz-Graphen P G ( S ) sei S ∗ durch topologisches Sortieren erzeugt. Dann sind S und S ∗ ̈ aquivalent: 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 ̈ ahltes Element E i induzieren bei zyklenfreiem P G ( S ) dort eine lineare totale Ordnung der Transaktionen: T i 1 < ∗ T i 2 < ∗ · · · < ∗ T i k Nach Lemma 5.21 ̈ ubertr ̈ agt sich diese Anordnung auch auf S ∗ : T i 1 < T i 2 < · · · < T i k . 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 T m und T n , die in ei- nem unmittelbaren ( W, W )-Konflikt bzgl. E i zueinander stehen, nehmen wir nun eine Transaktion T k mit einem Lesezugriff auf E i an. Wir finden deshalb ( T m , E i , T k ) ∈ DEP ( S ) und ( T k , E i , T n ) ∈ DEP ( S ). Wieder f ̈ uhrt uns Lem- ma 5.21 hinsichtlich S ∗ zu T m < T k < T n . 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 ̈ azedenz-Graphen P G ( S ) ist kon- flikt-serialisierbar. 5.5 Synchronisationsverfahren 95 Beispiel 5.24 Aufgrund der Pr ̈ azedenz-Graphen gilt f ̈ ur die Schedules aus den Bei- spielen 5.9 und 5.15: S 1 : seriell, S 2 : konflikt-serialisierbar, S 3 : nicht konflikt-serialisierbar. Mit Hilfe des letzten Satzes l ̈ aßt sich auch die Umkehrung von Satz 5.17 nachweisen. Satz 5.25 L ̈ aßt sich die Relation ” < ∗ “ (abgeleitet aus einem Schedule S ) durch transitive Erg ̈ anzung 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 T i 1 → T i 2 → T i 3 → · · · → T i k → T i 1 , der mit Blick auf DEP ( S ) T i 1 < ∗ T i 2 < ∗ T i 3 < ∗ · · · < ∗ T i k < ∗ T i 1 ergibt. Dann kann aber ” < ∗ “ zu keiner totalen Ordnung f ̈ uhren. 5.5 Synchronisationsverfahren Datenbankmanagementsysteme k ̈ onnen unterschiedliche Strategien anwenden, um f ̈ ur Transaktionen (konflikt-)serialisierbare Schedules zu erzeugen. Mit Hilfe von Sperrmechanismen k ̈ onnen Transaktionen Elemente f ̈ ur sich reservieren und vor kon- kurrierenden Zugriffen sch ̈ utzen. Andere Konzepte verzichten auf Sperren und bre- chen Transaktionen bei drohender Inkonsistenz ab bzw. ̈ uberpr ̈ ufen erst am Schluß, vor der definitiven Eintragung der vorgenommenen Datenbank ̈ anderungen, 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 ̈ ur eine bestimmte Zeit f ̈ ur sich reservieren. Wir gehen grunds ̈ atzlich 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 ̈ ahrend wir gestatten, daß Transaktionen, die ausschließ- lich Lesezugriffe vollziehen, ungehindert parallel abgearbeitet werden d ̈ urfen, 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 ̈ ahrend der WRITE-Locks untersagt das DBMS anderen Transaktionen jeglichen Zugriff auf E . Andererseits wird ein WRITE- Lock zur ̈ uckgewiesen, wenn das Element bereits mit einerm READ-Lock ge- sperrt ist. Transaktionen, die vor einem Lesezugriff einen READ-Lock bzw. f ̈ ur 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 ̈ aß den obigen Regeln ausf ̈ uhrt, sprechen wir auch von legalen Abfolgen Die gesperrten Elemente k ̈ onnen 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 ̈ ochten, werden vom Lockmanager unterbrochen und in eine Warteschlange eingereiht. In der Sprache ESQL werden Sperren implizit mit den entsprechenden Anweisungen f ̈ ur die Daten- bankzugriffe vermittelt. Transaktionen, die ausschließlich lesend zugreifen, k ̈ onnen in beliebiger Verzahnung parallel abgearbeitet werden. Wie man aus dem folgenden Beispiel ablesen kann, gen ̈ ugt 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 T 1 eine Umbuchung von einem Girokonto (GK) auf ein Sparkonto (SK) vornehmen. T 1 ist offensichtlich wohl- geformt. Gleichzeitig ermittelt eine Transaktion T 2 das Guthaben des Kunden. (Es werden nur die Datenbankanweisungen gezeigt.) 5.5 Synchronisationsverfahren 97 T 1 T 2 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 ̈ angigkeitsrelation lautet DEP ( S ) = { ( T 1 , GK, T 2 ) , ( T 2 , SK, T 1 ) } . Demnach ist der zugrundeliegende Schedule nicht serialisierbar, weil T 2 einen inkonsistenten Zustand der Datenbank sieht. 5.5.2 Zwei-Phasen-Sperrprotokoll Eine serielle Abfolge von Transaktionen l ̈ aßt sich vor diesem Hintergrund derart interpretieren, daß jeder Transaktion der gesamte Bestand vom Start bis zu ihrem Ende exklusiv zur Verf ̈ ugung steht. Das DBMS kann die Konflikt-Serialisierbarkeit erzeugen, indem eine ̈ ahnliche Wirkung mit dem Zwei-Phasen-Sperrprotokoll erzielt wird. Eine Transaktion T gen ̈ ugt dem Zwei-Phasen-Sperrprotokoll , wenn sich Sperren und Freigaben der Elemente zeitlich voneinander trennen lassen: T l ̈ aß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 ̈ ur 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 ̈ azedenz-Graphen P G ( S ) ein Zyklus T i 1 −→ T i 2 −→ · · · −→ T i k −→ T i 1 . Aus 5.5 Synchronisationsverfahren 98 T m −→ T n folgt, daß mindestens eine dieser Transaktionen einen Schreibzugriff auf ein gemeinsames Element vornimmt. Unabh ̈ angig von der Konfliktart muß deshalb T m das betreffende Element freigeben, bevor T n seine Sperre realisieren kann. Im obigen Zyklus gibt daher T i 1 zuerst ein Element frei, bevor T i 2 darauf zugreift. Sp ̈ ater fordert allerdings T i 1 wieder eine Sperre an, die nach der Freigabe durch T i k 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 ̈ oge 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 S 3 anmelden, zu folgender Abwicklung (die Sperren sind nicht aufgef ̈ uhrt): T 1 T 2 T 3 T 4 T 5 T 6 ( 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 T 1 im ersten Schritt das Element A mit einem WRITE-Lock (wegen Schritt 6). Da T 1 noch nicht beendet ist, wird T 3 in Schritt 4 der Zugriff auf B untersagt. Erst nach Abschluß von T 1 wird T 3 fortgesetzt etc. Die Sperrmechanismen f ̈ uhren zum Schedule S 4 : (( T 1 , R , A ), ( T 2 , R , C ), ( T 2 , W , C ), ( T 4 , R , D ), ( T 1 , W , A ), ( T 3 , R , B ), ( T 3 , W , B ), ( T 4 , W , D ), ( T 3 , R , A ), ( T 3 , W , A ), ( T 5 , R , C ), ( T 5 , R , B ), ( T 5 , R , A ), ( T 5 , W , A ), ( T 6 , R , A ), ( T 6 , W , A )) mit der Abh ̈ angigkeitsrelation 5.5 Synchronisationsverfahren 99 DEP ( S 4) = { ( T 1 , A, T 3 ) , ( T 3 , A, T 5 ) , ( T 5 , A, T 6 ) , ( T 2 , C, T 5 ) , ( T 3 , B, T 5 ) } und dem Pr ̈ azedenz-Graphen T 1 T 2 T 3 T 4 T 5 T 6 S 4 ist konflikt-serialisierbar. 5.5.3 Verklemmungen Zwei Transaktonen T 1 und T 2 k ̈ onnen sich gegenseitig blockieren, wie die folgende Abfolge zeigt: T 1 T 2 Kommentar WLOCK ( A ) WLOCK ( B ) WLOCK ( B ) T 1 wartet auf die Freigabe von B WLOCK ( A ) T 2 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 ̈ osen. Eine der beteiligten Transaktionen muß dazu vom DBMS zur ̈ uckgesetzt werden. Je nach Strategie wird hier die ̈ alteste oder die j ̈ ungste Transaktion ausgew ̈ ahlt. Das DBMS nimmt dann ggf. einen Neustart der Transaktion vor, oder es teilt den Mißerfolg ̈ uber eine Fehlermeldung mit. Zur Aufdeckung einer Verklemmung kann der Wartegraph W G ⊆ T × T herangezo- gen werden. ( T m , T n ) ∈ W G dokumentiert, daß T n auf die Freigabe eines Objektes durch T m wartet. Nach der Freigabe wird die Kante wieder aus W G entfernt. Eine Verklemmung liegt genau dann vor, wenn W G einen Zyklus enth ̈ alt. Transaktionen mit sehr kurzer Aufbauphase verringern die Gefahr einer Verklem- mung. Deshalb sollten die Transaktionen alle aufzugreifenden Elemente m ̈ oglichst unmittelbar nach dem Start sperren. Allerdings verringert dieses Vorgehen wegen der l ̈ angeren Sperren die Parallelit ̈ at 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 ̈ at“ erworben werden. M ̈ ogliche Sperrgranulate sind: Datens ̈ atze: Ein Datensatz (Tupel) ist i.a. die kleinste Sperreinheit, die in einem Datensystem angeboten wird. Transaktionen, die auf sehr viele Datens ̈ atze zugreifen, m ̈ ussen bei dieser Sperrgranularit ̈ at einen hohen Sperraufwand in Kauf nehmen. Seiten: In diesem Fall werden durch Vergabe einer Sperre implizit alle auf der Seite gespeicherten Datens ̈ atze gesperrt. Segmente: Ein Segment ist eine logische Einheit von mehreren (i.a. vielen) Seiten. Werden Segmente als Sperreinheit gew ̈ ahlt, wird nat ̈ urlich die Parallelit ̈ at drastisch eingeschr ̈ ankt, 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 ̈ Ande- rungstransaktionen erzwungen wird. In der folgenden Abbildung sind diese hierarchisch miteinander in Beziehung ste- henden Sperrgranulate graphisch dargestellt. Datenbasis Segmente Seiten S ̈ atze Bezogen auf die Abbildung waren wir bislang davon ausgegangen, daß alle Trans- aktionen ihre Sperren auf derselben Hierarchiestufe – also auf der Ebene der S ̈ atze, Seiten, Segmente oder Datenbasis – anfordern. ̈ Uberlegen wir uns, welche Auswir- kungen die Vermischung der Sperrgranulate h ̈ atte: Nehmen wir an, Transaktion T 1 will das ”linke“ Segment exklusiv sperren. Dann m ̈ ußte man alle Sperren auf Seite- nebene durchsuchen, um zu ̈ uberpr ̈ ufen, ob nicht irgendeine andere Transaktion eine in dem Segment enthaltene Seite gesperrt hat. Gleichfalls muß man alle Sperren auf

举报滥用

PDF 详情

联系信息

DBS-Skript5 (1).pdf