Synchronisation in verteilten Datenbanken: Ein Überblick

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 04 – 09/1980

Synchronisation in verteilten Datenbanken

Ein Überblick

ZUSAMMENFASSUNG

Praktische Informatik Postfach 940

D 5800 Hagen

Dieser Beitrag gibt zunächst eine allgemeine Einführung in die Problematik der Synchronisation in zentralen und ver- teilten Datenbanken, wobei schwerpunktmäßig auf die Gewähr- leistung der Konsistenz der Datenbank eingegangen wird. Im Anschluß daran wird eine Reihe - sowohl in der Vorgehens-- weise als auch im Hinblick auf die erforderlichen Randbe- dingungen - unterschiedlicher Synchronisations-Verfahren vorgestellt. Diese spiegeln in etwa auch den Stand der

Forschung in diesem Bereich wider. Aus diesen Verfahren bzw.

den dort verwendeten Synchronisations-Techniken werden einige grundlegende Eigenschaften extrahiert.

ABSTRACT

First, this paper gives a general introduction to the

problems of synchronization in centralized and distributed databases. It concentrates on the requirement of ensuring the consistency of the database in the presence of parallel transactions. Subsequently a series of different synchroni- zation methods is presented. They differ in the synchroni- zation technique as well as in the preconditions. They

represent to some extent the state of the art in this area.

From these methods and the applied techniques some basic characteristics are extracted.

VORWORT

Seit einigen Jahren ist eine beachtliche Forschungsaktivität auf dem Gebiet der verteilten Datenbanken zu beobachten. Be- sonderes Interesse findet hierbei der Bereich der Synchroni- sation, d.h., der Steuerung gleichzeitig ablaufender, kon- kurrierender Transaktionen (Benutzerprogramme). Die Vielzahl der Veröffentlichungen, verteilt auf Fachzeitschriften,

Tagungsberichte und technische Berichte sowie die in diesem Bereich herrschende Begriffsvielfalt machen es einem nicht le:icht, hier den überblick zu bewahren bzw. einen überblick zu bekommen. Hinzu kommt, daß diese Problematik zum betriebs- system-nahen Teil der Datenbank-Systeme gehört, und wohl in den meisten Vorlesungen oder anderen Vorträgen über Daten- banken nur am Rande - sofern überhaupt - behandelt wird.

Nach einigen einleitenden Ausführungen über Sinn und Zweck von verteilten Datenbanken wird in Kapitel 2 zunächst eine kurze, allgemeine Einführung in die Synchronisations-

Problematik in zentralen und verteilten Datenbank-Systemer gegeben. In Kapitel 3 wird eine Characterisierung der für verteilte Datenbanken vorgeschlagenen Synchronisations-

Verfahren vorgenommen. Im Anschluß daran werden in Kapitel 4 eine Reihe von Synchronisations-Verfahren besprochen, die in etwa den Stand der Forschung in diesem Bereich repräsen- tieren.

Diese Besprechung soll dazu dienen, einige Merkmale dieser Verfahren aufzuzeigen, um dem Leser einen groben Eindruck und überblick zu verschaffen. Die Lektüre der jeweils ange- gebenen Original-Literatur kann und soll sie nicht ersetzen.

1.

Die bis vor wenigen Jahren im Vergleich zu heute noch äußerst hohen Hardware-Preise zwangen die DV-Anwender die ursprünglich dezentralisierte ("verteilte") Ver- und Bearbeitung von Geschäfts-Vorfällen zu zentrali- sieren, um die vorhandene Hardware auszulasten und damit

11 rentabel ^II zu m a c ~ e n . So g i n g man bei der E n t w i c k l u n g von Datenbank-Systemen bis vor wenigen Jahren denn auch ausschließlich von zentralen Systemen aus und bewirkte damit in den Bereichen, in denen Datenbanken zum Einsatz kamen, oft eine noch stärkere Zentralisierung der DV-An- wendungen, als sie ohnehin schon vorhanden war.

Heute stellt sich für viele DV-Anwender die Situation so dar, daß trotz enorm gestiegener Verarbeitungs-Geschwindig- keiten des eingesetzten Zentral-Systems dieses entweder bereits jetzt oder so doch in absehbarer Zeit einen kaum mehr tolerierbaren Engpaß darstellt bzw. darstellen wird.

Hinzu kommt, daß durch die Zentralisierung an die Verfüg- barkeit des Zentral-Rechners immer höhere Anforderungen gestellt werden, ein Problem, das oft nur mit hohen zusätz- lichen Kosten lösbar ist (z.B. durch zusätzlichen Stand-hy- Rechner).

Der erwähnte Engpaß resultiert vor allem aus der Situation, daß zwar die Verarbeitung der Daten zentralisiert wurde, der

Daten-AnfaZZ und der Daten-Bedarf jedoch nach wie vor vielfach

dezentral - z.B. in Zweig-Werken, Filialen, Tochter-Unternehmen usw. - auftritt, wobei das Datenvolumen im laufe der Zeit

meist stark gestiegen ist (mehr Geschäftsvorfälle, höherer Informations-Bedarf usw.). Mit diesem Wachstum konnten zwar die gestiegenen internen Verarbeitungs-Geschwindigkeiten der zentralen Re~hner in etwa mithalten, nicht aber die Obertragungs- Geschwindigkeit zwischen dem Ort des Datenanfalls bzw. Daten- bedarfs und dem zentralen Rechner.

Die logische Konsequenz ist eigentlich klar: Die Verarbeitung der Daten sollte (wieder) so weit wie möglich am Ort des

Datenanfalls bzw. des Datenbedarfs geschehen, die Kommunikation zwischen Rechnern oder zwischen Rechner und Remote-Job-Entry- Stationen wieder auf ein ¹¹ vernünftiges¹¹ Maß reduziert werden.

Wie kann ~an dies erreichen, ohne die Vorteile einer zentralen Datenbank im Hinblick auf umfassende und schnelle Informations- gewinnung sowie eine relativ komfortable Pflege der Daten-

bestände wieder aus der Hand zu geben? - Die Antwort hierauf heißt: verteilte Datenbank.

Unter einer verteilten Datenbank versteht man im allgemeinen eine Datenbank, bei der die Daten physisch so auf mehrere Rechner verteilt sind, daß jeweils in hohem Maße eine rein 1 o k a l e V e r a r b e i t u n g d e r D a t e n m ö g l i c h "' i r d ( Z i e l : a l l e o d e r fast alle oft benötigten Daten sind lokal verfügbar), die

logische Gesamtsicht als eine Datenbank jedoch erhalten bleibt.

Meist geht man zudem davon aus, daß der Benutzer weder von - der Verteilung der Daten (welche Daten liegen auf welchem Rechner?) noch von einer eventuellen Redundanz der Daten

(Kopien von Daten existieren an mehreren Rechnern) etwas zu wissen braucht. Er agiert mit der verteilten Datenbank so, als ob es eine zentrale Datenbank wäre.

Bei der Realisierung einer verteilten Datenbank treten jedoch eine Fülle von technischen Problemen auf, die in zentralen Datenbanken entweder nicht vorhanden oder dort zumindest nicht so gravierend wie bei einer verteilten Datenbank sind.

Hierzu gehören etwa

- Realisierung einer einheitlichen globalen Sicht, auch wenn an den lokalen Rechnern unterschiedliche Daten- bank-Systeme eingesetzt werden

- Effizienter Programm- und/oder Datenaustausch zwischen unterschiedlichen (inhomogenen) Rechnern

- Recovery - Datenschutz

- Synchronisation konkurrierender globaler Transaktionen

Obwohl für die meisten dieser Probleme bereits Lösungs-Vor- schläge existieren, haben doch deren Fülle sowie ihre wechsel- seitigen Abhängigkeiten dazu geführt, daß praktisch bis heute noch kein wirklich vollständiges verteiltes Datenbanksystem auf dem Markt erhältlich.ist.

Dieser Beitrag befaßt sich mit dem zuletzt genannten Problem, der Synchronisation konkurrierender, globaler Transaktionen, einem der zentralen Probleme sowohl in zentralen als auch

- und dies in ganz besonderem Maße - in verteilten Datenbanken.

Während man für zentrale Datenbanken Synchronisation durch

Sperren von Objekten auf der Basis des Zwei-Phasen-Sperrproto- kolls [10] wohl als allgemein akzeptiert - wenn auch nicht bei allen Datenbanken realisiert - betrachten kann, ist eine solche Obereinstimmung bei verteilten Datenbanken bis jetzt noch nicht vorhanden, wird es vielleicht auch nicht geben.

Die Synchronisation ist in Datenbanken gleich in zweifacher Hinsicht ein "zentrales" Problem. Zum einen berührt es direkt das wohl wichtigste Ziel - die Bewahrung der Datenbank-Kon- sistenz -, zum anderen hat die Wahl des Synchronisations- Verfahrens direkt oder indirekt Auswirkungen auf fast alle der oben angeführten Probleme (siehe Bild 1).

Im nächsten Kapitel wird zunächst noch einmal allgemein auf die wesentlichsten Synchronisations-Probleme in Datenbanken eingegangen. Im Vordergrund steht dabei zunächst das Problem des "korrekten Schedul ing". Anschließend wird dann noch kurz auf andere Probleme wie z.B. Deadlock, Rollback, fortge- pflanztes Rollback, Dauer-Blockierung usw. eingegangen.

In Kapitel 3 wird eine Charakterisierung der bekanntge-

wordenen Synchronisations-Verfahren für verteilte Datenbanken vorgenommen. Hierbei werden einige grundsätzliche Eigen-

schaften der Verfahren herausgestellt. In Kapitel 4 wird dann auf eine Reihe von Synchronisations-Verfahren, die in etwa den Stand der Forschung in diesem Bereich widerspiegeln, etwas detaillierter einge_gangen.

~---

/

'

I geringer \ . \ Bewahrung

der Datenbank- Konsistenz

I .

__ - - - ~ Kornmun.1.- l

\ kations- /

\Aufwand /

'

Bild 1: Ziel-Interdependenzen bei der Entwicklung von Synchronisations-Verfahren

I

,... ^___

2,

2.1

Im folgenden kommt dem Begriff der Konsistenz eine zentrale Bedeutung zu. Da in der Literatur die Begriffe Integrität und Konsistenz teils gleich, teils jedoch unterschiedlich verwendet werden, soll hier kurz angegeben werden, was im weiteren unter Integrität und Konsistenz verstanden wird.

Integrität bezieht sich auf die Beziehung der Datenbank

- repräsentiert durch die Art und Anzahl ihrer Objekte sowie deren Inhalte - zu der Realwelt bzw. eines Teiles davon.

Gewährleistung von Integrität bedeutet, diese Beziehung so widerspruchsfrei wie möglich zu gestalten. Hierzu b~di~nt man sich meist sogenannten Integritäts-Bedingungen. (vgl.

hierzu z.B. [8], S. 396 ff., [31] und [32], S. 75 ff._.) Diese werden dann entweder vor, während oder nach Ver-

änderungen an der Datenbank auf Einhaltung überprüft. Wurde eine Integritäts-Bedingung verletzt, so ist die gewünschte Operation zurückzuweisen bzw. sind deren Effekte rückgängig zu machen.

Konsistenz bezieht sich auf die korrekte Verarbeitung von Operationen durch das Datenbank-System selbst - vor allem im Hinblick auf parallel ablaufende, um dieselben Objekte

konkurrierende Operationen. Konsistenz betrifft also unter anderem das Problem, als korrekt (integer) betrachtete

Operationen so auszuführen, daß nicht durch die Pa~allelität solcher Operationen "system-interne" Integritäts-Verletzungen - im weiteren als Konsistenz-Verletzungen bezeichnet - auf- treten können, bzw., wenn sie schon auftreten, so doch vom Datenbank-System erkannt und korrigiert werden können. Dem Problem der Gewährleistung der Konsistenz widmen sich die beiden nächsten Abschnitte.

2,2

Eine Transaktion ist eine durch den Benutzer explizit oder implizit markierte Folge von Anweisungen (Aktionen), die eine Einheit der Integrität - und damit auch der Konsistenz - darstellen. (vgl. [13], S. 25.) Eine explizite Markierung ist zum Beispiel gegeben, wenn der Benutzer eine solche Aktions- Folge durch BEGIN-TRANSACTION und END-TRANSACTION ¹¹klammert''.

Eine implizite Markierung liegt zum Beispiel vor, wenn das

System beim ersten Online-Zugriff auf die Datenbank automatisch ein BEGIN-TRANSACTION und am Ende der Sitzung ein END-TRANSACTION absetzt.

Eine Transaction überführt die Datenbank von einem gültigen ( k o n s i s t e n t e n ) Z u s t a n d i n e i n e n n e u e n , e b e n f a l l s g ü l t -i g e n·

(konsistenten) Zustand (Prämisse!). Das Datenbank-System muß daher sicherstellen, daß keine unvollständigen Transaktionen in die Datenbank gelangen bzw. daß deren Effekte automatisch rückgängig gemacht werden. - Im allgemeinen wird man sogar fordern, daß das Rückgängigmachen solcher Effekte - hierfiir haben sich die Begriffe undo bzw. rollback eingebürgert - ohne Auswirkungen auf andere Transaktionen erfolgen soll.

Hierauf wird später etwas näher eingegangen. Wenn der Begriff

Transaktion im folgenden nicht näher spezifiziert wird, so ist damit immer eine vollständige Transaktion gemeint.

Stellt sich nachträglich heraus, daß die Prämisse "eine Transaktion überführt die Datenbank von einem konsistenten Zustand in einen neuen konsistenten Zustand" falsch war, weil die Transaktion z.B. Fehler enthielt, die bei der Integritäts- Prüfung nicht entdeckt wurden, so müssen in solchen Fällen spezielle Maßnahmen durchgeführt werden. Hierzu gehören z.B.

Ausführung von "Reparatur-Programmen (salvation programs)

- vgl. hierzu z.B. [33] -, Roll back von bereits abgeschlosse- nen Transaktionen (sofern möglich) oder sogar ein Zurücksetzen der gesamten Datenbank in einen früheren konsistenten Zustand

(backup) - vgl. hierzu z.B. [7] und [28].

Die Aktionen einer Transaktion sind aus der Sicht des Daten- bank-Systems die kleinsten ausführbaren Einheiten, deren korrekte Ausführung dem Betriebssystem obliegt. Deshalb sind Aktionen aus der Sicht des Datenbank-Systems atomar.

Stehen in einer Datenbank nun mehrere Transaktionen zur selben Zeit zur Verarbeitung an, für die keine Ausführungs- Reihenfolge von den Benutzern vorgegeben ist (wechselseitig unabhängige Transaktionen) so gibt es verschiedene Möglich- keiten diese auszuführen:

Es werden zuerst alle Aktionen einer Transaktion, dann alle Aktionen einer anderen Transaktion usw. ausgeführt

(serielle Ausführung der Transaktionen) oder

- es werden mehr oder weniger abwechselnd Aktionen von verschiedenen Transaktionen ausgeführt (überlappte oder parallele Ausführung der Transaktionen).

Eine solche Ausführungs-Reihenfolge (Liste von Aktionen) - ähnliches kennt man auch im Bereich der Betriebssysteme - bezeichnet man als Schedule .

•

Das Problem ist, daß im all9emeinen nicht alle aus Betriebs- system-Sicht möglichen Schedules die Konsistenz der Daten- b~nk gewährleisten. Aufgabe des Synchronisations-Verfahrens ist es dafür zu sorgen, daß nur Schedules, die diese Kon- sistenz gewährleisten - im weiteren konsistente Schedules

genannt - erzeugt werden. - Man wird allerdings die Güte eines Synchronisations-Verfahrens unter anderem daran messen, wie- viele konsistente Schedules es zu erzeugen vermag (vgl. hier- zu [ 1] und [ 11]).

Da die Anzahl und Reihenfolge von Aktionen innerhalb einer Transaktion sich meist erst zur Laufzeit ergibt, abhängig von irgendwelchen, erst dann bekannten Parametern, wird ein

Synchr0nisations-Verfahren im allgemeinen so vorgehen

müssen, daß es für jede Situation eine Regel gibt, wie die Ausführungs-Reihenfolge der Aktionen bzw. Transaktionen zu wählen ist, so daß inkonsistente Schedules verhindert werden.

Wann eine Schedule konsistent ist und wie man inkonsistente bzw. "potentiell" inkonsistente Schedules erkennen kann,

darauf wird im folgenden Abschnitt eingegangen.

2,3

Bevor auf die Konstruktion konsistenter $chedules - und damit auf die Arbeitsweise von Synchronisations-Verfahren - einge- gangen wird, soll zunächst noch einmal darauf eingeg~ngen werden, wie man eine gegebene Schedule daraufhin prüfen kann, ob sie konsistent ist oder nicht. (Da eine solche Schedule in vielen Fällen erst dann vorliegt, wenn die Transaktionen bereits ausgeführt wurden, wird , ,

,n

Als Entscheidungs-Kriterium, ob eine gegebene Schedule

konsistent ist oder nicht, hat sich weitgehend der Nachweis ihrer Serialisierbarkeit durchgesetzt. (vgl. z.B. [3], [10]

und [26].)

Eine Schedule für eine gegebene Menge von m Transaktionen heißt serialisierbar, wenn mindestens eine serielle Aus- führungs-Reihenfolge dieser m Transaktionen existiert, so daß der bei serieller Ausführung erzeugte Output sowie der dadurch erreichte Datenbank-Endzustand gleich dem wie bei Ausführung der Aktionen gemäß der Schedule ist. (Ähnliche bzw. äquivalente Definitionen finden sich z.B. in [5 L [10]

und [26 ]. )

Seien Ti, Tj zwei beliebige Transaktionen. Sei ferner Ai die Menge der Aktionen von Transaktion Ti, Aj die entsprechende Menge bezüglich Transaktion Tj. Wir sagen zwei Aktionen a E Ai,

b E Aj stehen in Konflikt, kurz a konflikt b, wenn beide auf dasselbe Objekt zugreifen und dies mindestens eine der beiden Aktionen nicht nur lesend tut. (Vgl. [26])

Wir definieren einen Abhängigkeits-Graph G5 = (T,U) für eine gegebene Schedule S wie folgt: T ist die Menge aller Knoten in G - sie repräsentieren Transaktionen Ti ES. U ist die Menge der gerichteten Kanten (Pfeile) in G, wobei gilt:

uij EU<==> a konflikt b und a < b (a E Ai, b E Aj).

uij bedeutet Pfeil von Knoten i nach Knoten j bzw. von Kno- ten Ti nach Knoten Tj und bedeutet, "Aktion a tritt in S vor b auf^{11 •}

Für eine Schedule S von wechselseitig unabhängigen Trans- aktionen gilt, daß S im allgemeinen nicht serialisierbar -ist, wenn der korrespondierende Abhängigkeits-Graph G Zyklen ent- hält. Eine Schedule, deren korrespondierender Abhängigkeits- Graph zyklenfrei ist, ist dagegen stets serialisierbar.

(Vergleiche [26])

Es gibt spezielle Fälle, in denen eine Schedule serialisier- bar ist, obwohl der korrespondierende Abhängigkeits-Graph Zyklen enthält. (Ein solches Beispiel wird in [6] angegeben.) Wir wollen hierauf an dieser Stelle nicht näher eingehen und im folgenden annehmen, daß für serialisierbare Schedules der korrespondierende Abhängigkeits-Graph zyklenfrei sein muß.

BEISPIEL 1:

a) Nicht-serielle Schedule:

r

[v]r3 [v]w2

[u]w3 [v]

Konflikt-Analyse:

==>

Äquivalente serielle Schedule:

2 2 1 1 3 3

r [v]w [u]r [v]w [v]r [v]w [v]

Konflikt-Analyse:

a) r1[v] <~w2_[v]

==>Tl --> T2

b) 2 1 - 2

r [V] < W [V] =,,,;> T --> Tl

c) 2 3 2

W [V] < r [V] ==> T --> T3

d) 3 1 3

r [V] < ^W [V] ==> T --> Tl

Bild 2: Abhängigkeits-Graph einer serialisierbaren Schedule

Bild 3 : Abhängigkeits-Graph

e) 1 3 1

W [V] < ^W [V] ==> T T3 einer nicht serialisier- -->

baren Schedule

Wird Synchronisation über Sperren von Objekten durchgeführt, muß das sog. Zwei-Phasen-Sperrprotokoll beachtet werden, um

die Konsistenz der Schedules gewährleisten zu können (vgl. [10]).

Es besagt im wesentlichen folgendes:

(1) Bevor man eine Transaktion auf ein Objekt lesend oder schreibend zugreift, muß sie dieses sperren.

(2) Hat eine Transaktion einmal eine Sperre wieder frei- gegeben, darf sie keine Sperren mehr anfordern bzw. er- halten.

2,4

Neben der Gewährleistung der Datenbank-Konsistenz durch Erzeugung konsistenter Schedules, müssen beim Entwurf eines Synchronisations-Verfahrens noch andere Aspekte, wie etwa

- Gewährleistung, daß jede korrekte Transaktion in endlicher Zeit erfolgreich beendet werden kann - Effizienz des Verfahrens

- Robustheit des Verfahrens berücksichtigt werden.

Die erfolgreiche Terminierung einer korrekten Transaktion kann gefährdet sein durch (vgl. [4])

- Deadlock

- unendliches Blockieren (indefinite blocking) - zyklischen Neu-Start

Deadlock tritt auf, wenn zwei oder mehr Transaktionen wechsel- seitig auf die Freigabe gesperrter Objekte warten, um selbst weitermachen zu können. Unendliches Blockieren kann auftreten, wenn das Synchronisations-Verfahren eine ungeeignete Auswahl- Strategie für wartende Transaktionen verfolgt. Wenn etwa

"Nur-Lese"-Transaktionen stets andere Transaktionen in der Warteschlange "überholen" dürfen, kann es in ungünstigen Fällen vorkommen, daß gewisse Update-Transaktionen nie zum Zuge kommen.

Zyklischer Neu-Start kann auftreten, wenn bei eingetreten.em drohendem oder potentiellem Deadlock immer diesselbe(n) Transaktion(en) zurückgesetzt werden. D.h., wenn beim Neu-

Start und eventuell erneutem Deadlock - nun im allgemeinen mit anderen Transaktionen - nicht berücksichtigt wird, welche dieser Transaktionen bereits "deadlock-geschädigt¹¹ sind und diese somit vielleicht wieder und wieder als "Opfer" für das Auflösen des Deadlocks ausgesucht werden. (Eine originelle Lösung dieses Problems finden sich z.B. in [27].)

Unter Effizienz eines Synchronisations-Verfahrens versteht man seine Fähigkeit, in einem gegebenen Zeitraum möglichst viele Transaktionen erfolgreich auszuführen. Ein Vergleich der

Effizienz eines Synchronisations-Verfahrens in Bezug auf andere Verfahren ist analytisch sehr schwer durchzuführen

(vgl. hierzu [34}). Zu viele umgebungsabhängige Faktoren wie z.B. Lokalität der Anwendungen, Konflikt-Häufigkeit

von Transaktionen, durchschnittliche Dauer von Transaktionen (Anzahl ihrer Aktionen), Verhältnis von "Nur-Lese^11- zu

Lese-Schreib-Transaktionen spielen im praktischen Einsatz hierbei eine wesentliche Rolle. Wir wollen diesen Aspek~- daher im folgenden nur sehr allgemein betrachten.

Eng verknüpft mit der Effizienz eines Synchronisations- Verfahrens ist das Problem der Recovery; und zwar einmal unter dem Aspekt , w e l c h e Aus w i r k u n gen der ¹¹ Absturz ^II e i n er Transakti~n haben kann und in welchem Umfange das Synchroni- sations-Verfahren selbst Recovery erforderlich macht (siehe unten). Eingangs wurde erklärt, daß und warum nur vollständige Transaktionen in die Datenbank gelangen dürfen. Erreicht

eine Transaktion also ihr normales Transaktions-Ende nicht, so muß sie zurückgesetzt, d.h., alle Effekte, die sie even- tuell in der Datenbank verursacht hat, müssen rückgängig gemacht werden. Diesen Vorgang bezeichnet man als Rollback.

(Um Roll back einfach durchführen zu können, wird in vielen F ä l l e n n i c h t sofort d i r e kt i n der Datenbank ( ¹¹ update i n place"), sondern zunächst auf einer Kopie ("shadow page") geändert und diese Änderung erst bei Erreichen des regulären Transaktions-Endes in die Datenbank eingebracht.)

Haben andere Transaktionen diese geänderten Werte bereits tatsächlich oder möglicherweise gelesen, so können diese Transaktionen dadurch inkonsistent sein - da sie

"schmutzige Daten" (dirty data) gelesen haben - und müssen daher ebenfalls zurückgesetzt werden. Den Effekt, daß

vom Rollback einer Transaktion auch andere Transaktionen erfaßt· werden, bezeichnet man als fortgepflanztes Rollback.

(Randell [23] hat dafür auch den Begriff "domino effect"

geprägt.)

Fortgepflanztes Rollback kann auch bereits abgeschlossene Transaktionen erfassen. Deshalb ist es fraglich, ob

Synchronisations-Verfahren, die diesen Effekt zulassen, für praktische Anwendungen überhaupt tauglich sind (vgl.

[12], S. 438). In diesem Fall kann das Problem nämlich meist nicht mehr system-intern behoben werden, sondern es sind im allgemeinen weitere orga~isatorische Maßnahmen er- forderlich, da abgeschlossene Transaktionen ihren Output bereits dem Benutzer sichtbar gemacht haben.

(Beispiel: die Transaktion hat eine Rechnung oder eine Platzbuchungs-Bestätigung ausgestellt und der Kunde ist inzwischen gegangen.)

BEISPIEL 2:

Gegeben sei die in Bild 4 dargestellte Situation.

Der Abbruch und das Rollback von T 1 erfaßt auch die Transaktionen T2, T3 und T4 , da sie entweder direkt oder indirekt inkonsistente Daten von T 1 gelesen haben können.

Transaktion Tl

Transaktion T2

Transaktion T³

T~ansaktion T~

Bild 4: Beispiel für fortgepflanztes Rollback

(Notation: x --> y: y hat Daten von x gelesen

Bei einer verteilten Datenbank, wo die Daten physisch auf mehrere Rechner (Knoten) in einem Rechner-Netz ver- teilt sind, kann es vorkommen, daß einzelne Knoten aus

irgendwelchen Gründen nicht arbeitsfähig sind. Als Robust- heit eines Synchronisations-Verfahrens bezeichnet man seine Fähigkeit, in solchen Fällen mit den noch verfügbaren Daten weiterarbeiten zu können. Die Robustheit des verteilten Datenbank-Systems (als Ganzes) ist noch von vielen anderen Faktoren, vor allem aber von der Zuverlässigkeit und

Ausfallsicherheit des Kommunikations-Systems abhängig.

Dieses Problem hier zu behandeln, würde den Rahmen dieser Ausarbeitung sprengen. - Zur Robustheit der Verfahren werden bei der Besprechung der einzelnen Verfahren (siehe Kapitel 4) einige Angaben gemacht werden.

-

3,

3,1

Der Hauptunterschied ist, daß das Synchronisations-Verfahren es in einem verteilten System im allgemeinen mit mehreren völlig autonom arbeitenden Rechnern zu tun hat, die auch

autonom Transaktionen initiieren können. Ein weiteres Merkmal ist - und hier liegt der Unterschied zu her-

kömmlichen Multi-Prozessor-Systemen-, daß die Rechner über

keinen gemeinsamen Speicher verfügen. Eine Koordination der Rechner, sowie die Synchronisation der auf ihnen aus- zuführenden Transaktionen, kann deshalb nur über Nach- richten-Austausch (Kommunikation) erfolgen. Hierbei':

können - je nach verwendetem Kommunikations-System - Probleme wie ¹¹sich überschneidende" Nachrichten, Verlust oder Ver-

zögerung von Nachrichten usw. auftreten, denen das Synchro- nisations-Verfahren gegebenenfalls Rechnung tragen muß.

Ferner wird man in einem verteilten System in vielen Fällen nicht nur Parallelität zwischen Transaktionen (wie dies von zentralen System her bekannt ist), sondern auch Parallelität

innerhalb von Transaktionen anstreben. Letzteres dann, wenn eine Transaktion in mehrere Teil-Transaktionen zerlegt werden muß, die dann auf verschiedenen Rechnern des Netzes auszu- führen sind. (Weil z.B. die Daten ganz oder teilweise auf anderen Rechnern liegen oder weil Kopien mitgeändert werden müssen.)

Größere Probleme als im zentralen Fall ergeben sich auch, wenn das Synchronisations-Verfahren nicht deadlock-frei ist.

Es genügt nämlich in einem verteilten System im allgemeinen nicht mehr, lediglich die lokalen Abhängigkeiten zu unter- suchen. Es sind globale Deadlocks, also Deadlocks, in die Transaktionen von mehreren Knoten verwickelt sind, möglich,

ohne daß an irgendeinem Knoten ein lokaler Deadlock vorliegen muß (vergleiche Bild 5).

Knoten c

Knoten A

Knoten B

Bi 1 d 5 : Beispiel für einen globalen Deadlock

Die Untersuchung der globalen Transaktions-Abhängigkeiten auf Deadlock ist jedoch relativ komplex (da sich die Ab- hängigkeits-Struktur im allgemeinen _laufend ändert) und

"teuer", sowohl in Bezug auf Rechenzeit als auch Kommuni- kations-Aufwand. (Vergleiche hierzu z.B. [16]. In [20]

werden unter anderem einige Algorithmen für die Erkennung globaler Deadlocks kritisch analysiert.) Es ist daher zu erwarten, daß sich für verteilte Datenbank-Systeme im wesentlichen solche Synchronisations-Verfahren durchsetzen werden, die Deadlocks vermeiden.

Als braucbbares Hilfsmittel für die Synchronisation in verteilten Datenbank-Systemen, und zwar sowohl in Bezug

•

auf konsistentes Scheduling als auch in Bezug auf Deadlock- Vermeidungs-Strategien, hat sich die Verwendung von Zeit- marken (time stamps) erwiesen.

3.2

Unter "time-stamping" in Verbindung mit Synchronisations- V erfahren versteht man das "An b r i n gen ¹¹ von Z e i t m a r k e n an (Datenbank-) Objekte oder Transaktionen. Versieht man Objekte oder Transaktionen mit Zeitmarken, so entsteht e i n e ¹¹ J ü n g er - Al t er - Re l a t i o n " z w i s c h e n i h n e n . W ä h r end b e i 0 b j e kt e n " G l e i c h -Al tri g k e i t ¹¹ auftreten kann und darf , i s t dies bei Transaktionen nicht zulässig.

Bei der VerknUpfung der Zeitmarken mit Objekten, gibt es im wesentlichen zwei Anwendungsarten:

- die Zeitmarke dient lediglich zum Ordnen ankommender Update-Aufträge: "Ältere" Update-Aufträge haben Vorrang,

"jüngere" müssen gegebenenfalls warten (vgl. [5])

- die Zeitmarke gibt an, auf welchem Aktualitäts-Stand sich ein Update-Auftrag befindet: "vera lterte" Update-Aufträge werden zurückgewiesen (vgl. [30])

Die VerknUpfung von Zeitmarken mit Transaktionen dient dazu, auftretende oder potentielle Zugriffs-Konflikte zwischen Transaktionen im ganzen Netz nach einheitlichen, eindeutigen und konsistenz-bewahrenden Regeln aufzulösen.

Sie kann sowohl als Basis für ein "eigenständiges" Synchro- nisations-Verfahren (bei Vorkenntnissen oder die _benötigten Objekte), als auch zur Deadlock-Vermeidung in Verbindung mit Sperren von Objekten verwendet werden.

-

Als Basis für diese ¹¹Zeitmarken" können hierbei - die physikalische (¹¹echte¹¹⁾ Zeit (vgl. [14])

- eine von der physikalischen Zeit abgeleitete logische Zeit (vgl. etwa [4] und [30])

irgendeine Art von Zähler, also eine rein logische Zeit (vgl. z.B. [9] und [15])

dienen.

Wesentlich ist, daß die Zeitmarken eindeutig sind. D.h.,

es dürfen nicht an verschiedenen Stellen im System identische Zeitmarken erzeugt werden. In den meisten Verfahren wird

hierfür die Methode von THOMAS [30] verwendet, der vorschlug, der lokalen ComRuter-Zeit rechtsseitig eine netz-eindeutige Knoten-Identifikation anzuhängen.

3,3

Die derzeit bekannten Synchronisations-Verfahren für ver- teilte Datenbanken lassen sich wie in Bild 6 angegeben

charakterisieren. Bevor wir in Kapitel 4 auf eine Reihe von Synchronisations-Verfahren etwas detaillierter eingehen, wollen wir im folgenden zunächst zu den verschiedenen Realisierungsformen einige allgemeine Angaben machen.

Sperren von Objekten

ohne Vorkenntnisse über die benötigten

Objekte

~

mit Vorkenntnissen über die benötigten

Objekte

/ ^~

Sperren von Ordnen der

Objekten Zugriffe auf

/ \

ohne Zeitmarken

an Transaktionen mit Zeitmarken an Transaktionen

(Zeitmarken an Objekte)

/~ ;•kt~

(Gray)

!

(Ston)

( RSL)

l

(Lela)*

( Ell i )

(MPM)

*

(Thom)

ohne Zeitmarken an Transaktionen

(Muse)

!

Bild 6: Charakterisierung der Synchronisations-Verfahren für verteilte Datenbanken (Die Verweise beziehen sich auf die in Vapitel 4 angegebenen Verfahren.

Bei den mit(*) gekennzeichneten Verfahren sind, je nach Ausprägung, verschiedene Zuordnungen möglich.)

mit Zeitmarken an Transaktionen

(Schl)

1

(Lela)*

(MPM)*

ohne Konflikt- Voranalyse

J,

(Ba Po)

mit Konflikt- Voranalyse

(BSR)

l

N ,_.

3.3.1

3.3.1.1 SPERREN VON OBJEKTEN OHNE ZEITMARKEN AN TRANSAKTIONEN Da zu Transaktions-Beginn keine Vorkenntnisse über die

benötigten Objekte vorhanden sind, muß sukzessive gesperrt werden. Es besteht daher prinzipiell Deadlock-Gefahr. Dead- locks kann auf zwei Arten Rechnung getragen werden: Entweder führt man eine Deadlock-Analyse (periodisch oder immer wenn eine Warte-Situation auftritt oder wenn eine Warte-Situation eine gewisse Zeitspanne überschreitet ("time out") durch oder man bricht die Transaktion nach überschreiten einer bestimmten Wartezeit ohne Deadlock-Analyse ab. (Bei hoher System-Last ist die letztgenannte Vorgehensweise im allgemeinen keine sehr geeignete Strategie. - Siehe [12], S. 451 ff.) In jedem Fall ist ein Rollback von Transaktionen erforderlich.

Bei erkanntem Deadlock erfolgt die Auswahl der zurückzu- setzenden Transaktionen oft nach gewissen Optimierungs-

Kriterien wie bisher verbrauchter CPU-Zeit, Anzahl der 1/O's oder ähnlichem. Hierdurch - aber auch bei der letztgenannten Strategie (time-out-Abbruch) - entsteht unter Umständen die Gefahr des zyklischen Neustarts.

Als positiv ist zu nennen, daß bei der Verwendung von Sperr- Hierarchien, wie z.B. Gesamt-Datenbank/Teil-Datenbank/Datei/

Satz, und/oder durch verschiedene Sperr-Modi für lesenden

und schreibenden Zugriff, sowie ggf. Konversions-Möglichkeiten zwischen verschiedenen Sperr-Modi, Sperren eine äußerst

flexible Methode darstellt. Bei geeigneter Wahl der Sperr- Einheiten läßt sich der erforderliche Kommunikations-Aufwand sehr gering halten. (Eine ausführliche Darstellung der oben erwähnten Sperr-Hierarchien sowie den Konversions-Möglichkeiten zwischen verschiedenen Sperr-Modi findet sich in [12], S.43O ff.)

-

3.3.1.2 SPERREN VON OBJEKTEN MIT ZEITMARKEN AN TRANSAKTIONEN Die Ausführungen über die positiven Eigenschaften von

Sperren gelten natürlich auch hier. Hinzu kommt nun, daß sich durch das time stamping der Transaktionen die Synchroni- sations-Verfahren so gestalten lassen, daß Deadlock-Analyse entweder überflüssig wird (präsentives Rollback von Trans- aktionen bei potentiellem Deadlock - z.B.: keine "ältere"

Transaktion wartet auf eine "jüngere" Transaktion) oder daß die "Opfer-Auswahl" so erfolgt, daß zyklischer Neustart ausgeschlossen werden kann.

3.3.1.3 ORDNEN DER ZUGRIFFE AUF OBJEKTE (ZEITMARKEN AN OBJEKTE) Wenn die Objekte mit Zeitmarken versehen werden, dann kann auf das globale Sperren der Objekte, also auf Implementierunq

einer globalen Sperr-Tabelle oder ähnlichem, im Prinzip

verzichtet werden. Greift man vor einer Veränderung auf alle Objekte einer Transaktion - also auch auf die Output-Objekte - lesend zu, wobei dieses Lesen auch die Zeitmarke des ent-

sprechenden Objektes liefert, so kann man bei dem sich eventuell anschließenden Update (-Versuch) durch Vergleich der Zeit-

marken stets feststellen, ob die Objekte zwischenzeitlich

verändert wurden. "Veraltete" Update-Anträge können so erkannt und zurückgewiesen werden.

Lokal muß man entweder durch Sperren oder durch andere Mechanismen sicherstellen, daß Änderungen anderen Trans- aktionen erst sichtbar gemacht werden, wenn sie vollständig durchgeführt wurden.

Aus der Sicht der Transaktionen spielen sich Updates also nach einer Art "try and error"-Verfahren ab. Obwohl diese

Synchronisations-Technik im Prinzip auch bei nicht-redundanten Datenbanken anwendbar ist, dürfte sie aus Effizienz-Gründen tatsächlich wohl nur für voll-redundante oder teil-redundante Datenbanken in Frage kommen.

Diese Vorgehensweise setzt voraus, daß

Konflikte zwischen Transaktionen im allgemeinen selten sind

- die Transaktionen meist r.elätiv kurz sind

- die globalen Verarbeitungskosten in Bezug auf die globalen Kommunikations-Kosten gering sind

Nachteilig bei diesem Verfahren ist zunächst einmal der

erhöhte Speicherbedarf durch das Abspeichern der Zeitmarken.

Hierzu wurde in [5] vorgeschlagen, die Zeitmarken lediglich für eine gewisse Zeit (z.B. einige Minuten) in einer Art von

,·

11differential file¹¹ abzulegen und nicht in die eigentliche Datenbank mit aufzunehmen. Ein weiterer Nachteil ist, daß, um die Konflikt-Gefahr möglichst gering zu halten, die Zeit- marken an relativ kleinen Objekt-Einheiten angebracht wefden müssen - und daher - im Vergleich zum Sperren unter Ver-

wendung von Sperr-Hierarchien - deshalb ein deutlich höherer Kommunikations-Aufwand erforderlich ist.

3.3.2

3.3.2.1 SPERREN VON OBJEKTEN OHNE ZEITMARKEN AN TRANSAKTIONEN Da nun alle benötigten Objekte bereits zu Anfang einer Trans- aktion bekannt sind, können diese entweder gleich am Anfang, in einer Sperr-Phase (seize phase), oder sukzessive - nun aber in einer festgelegten, für alle Transaktionen verbind- lichen Reihenfolge - angefordert werd~n. In beiden Fällen kann man DeadZock von vornherein vermeiden, Rollback wird aus diesem Grunde also nicht erforderlich. - Allerdings ist bei der ersten Vorgehensweise die Gefahr des zyklischen Neu-

?

starts vorhanden. (Die bereits erwähnten Vorteile gelten natürlich auch hier. - Siehe Abschnitt 3.3.1.1)

3.3.2.2 SPERREN VON OBJEKTEN MIT ZEITMARKEN AN TRANSAKTIONEN Hier gilt dasselbe wie vorstehend, jedoch kann nun der

Gefahr des zyklischen Neustarts auf einfache Weise be- gegnet werden. (Vgl. Abschnitt 3.3.1.2)

3.3.2.3 ORDNEN DER ZUGRIFFE AUF OBJEKTE

Da für jede Transaktion schon vor ihrer Ausführung bekannt ist, welche Objekte sie benötigt - evtl. noch unterteilt nach Input- und Output-Objekten-, läßt sich für eine ge- gebene Menge von Transaktionen auch bestimmen, welche in- Konflikt zueinander stehen und welche nicht. Alle nicht in Konflikt zueinander stehenden Transaktionen können ohne weitere Synchronisation parallel ausgeführt werden, alle Paare (T,T ^{1 )} von in Konflikt stehenden Transaktionen werden in der durch ihre Zeitmarken definierten Reihenfolge seriell

(in Beziehung zueinander) ausgeführt. Werden die Objekte (und nicht die Transaktionen) mit Zeitmarken versehen, so kann bei Zugriffs-Konflikten auf Aktions-Ebene seriali- siert werden, es ist also eine ¹¹feinere¹¹ Synchronisation möglich.

4,

Im folgenden wollen wir nun einen überblick über die nach- stehend aufgeführten Synchronisations-Verfahren geben.

(Vgl. hierzu auch Bild 6). Diese Verfahren repräsentieren

-

unseres Erachtens in etwa auch den Stand der Forschung in diesem Bereich.

(BaPo) (BSR) (Elli) (Gray) (Lela) (MPM) (MuSc) (RSL) (Schl) (Ston) (Thom)_

Badal, Popek [2]

Bernstein, Shipman, Rothnie ( lt SDD- l lt) [ 5]

Ellis [9]

Gray ( lt t wo - p h a s e c o mm i t" ) [ 1 2 ] Le Lann (ltticketinglt) [15]

Menasce, Popek, Muntz [17]

Munz, Schweppe (1tVDN1t) [22] ([21]) Rosenkrantz, Stearns, Lewis II

(ltwait-dielt/¹¹wound-waitlt) [24]

Schlageter [27]

Stonebraker (1tdistributed INGRES1t) [29]

Thomas ( ¹¹ maj ori ty consensus ^{11 ) [} 30]

Die nachstehende Besprechung der Verfahren kann und soll nicht das Studium der angegebenen Original-Literatur ersetzen. Sie ist vielmehr als überblick und Einstiegshilfe gedacht. Bei der Besprechung der Verfahren werden wir uns an die Struktur in Bild 6 (¹¹Haupt-Reihenfolge^{11 )} halten.)

4,1

4,1,1

(Gray) (¹¹two-phase commit^{11 )}

Eine direkte Erweiterung des von zentralen Datenbank-Systemen her bekannten Zwei-Phasen-Soerrprotokolls auf verteilte Daten- banken findet sich bei Gray [12]. Eine globale Transaktion wird dort ausgeführt, indem sie an einem Knoten gestartet wird

und, soweit erforderlich, an anderen Knoten Subtransaktionen

( 11cohorts^{11 )} initiiert. Alle Teil-Transaktionen (Initiator und Sub-Transaktionen) sperren ihre Objekte jeweils lokal.

Da sukzessive, ohne Vorkenntnisse Llber die benötigten Objekte gesperrt werden muß, ist das Verfahren nicht deadlock-frei.

Ein bestimmter Knoten wird daher als globaler Deadlock-Ent- decker (¹¹global deadlock detector^{11 )} eingesetzt, der periodisch die lokalen ¹¹wartet-auf¹¹ -Beziehungen zwischen den Transaktionen Llbermittelt bekommt, einen Abhängigkeits-Graphen konstruiert und darin nach Zyklen, d.h., nach Deadlocks, sucht.

Um fortgepflanztes Rollback zu vermeiden, genLlgt es in einem verteilten Datenbank-System nicht mehr, bei globalen-Trans- aktionen jeweils lediglich lokal das Zwei-Phasen-Sperrproto- koll zu beachten und die Sperren bei Erreichen des (lokalen) Teil-Transaktions-Endes freizugeben. Die Freigabe der Sp~rren muß vielmehr global koordiniert werden. In [12] wird daher ein Zwei-Phasen-Commit-Protokoll (¹¹ two phase commit protocol ^{11 )}

eingefLlhrt, das folgendes besagt:

- Alle Teil-Transaktionen beachten jeweils lokal das Zwei- Phasen-Sperrprotokoll

Alle Sperren werden jeweils erst am Ende einer Transaktion freigegeben.

- Die Teil-Transaktionen-einer globalen Transaktion teilen einem zentralen Koordinator (¹¹commit coordinator^{11 -} ver- mutlich die ¹¹Initiator¹¹-Teil-Transaktion) jeweils mit, wenn sie das Transaktions-Ende (commit point) erreicht haben.

- Hat der Koordinator diese Meldungen von allen Teil- Transaktionen erhalten, erhalten diese von ihm die Erlaubnis ihre Sperren freizugeben und zu enden.

Das Zwei-Phasen-Commit-Protokoll findet sich explizit oder implizit praktisch in allen nachfolgend vorgestellten Ver- fahren wieder. Das Synchronisations-Verfahren selbst ist für nicht-redundante Datenbanken konzipiert und nützt eventuell

vorhandene Redundanz der Daten nicht aus. Es ist daher gegen Knoten-Ausfälle relativ empfindlich. (Für nähere Erläuterungen zum Protokoll bzw. zum Verfahren insgesamt siehe [12], S. 466 ff.) (Ston) ^{( 11}distributed INGRES¹¹ )

Eine Weiterentwicklung des oben vorgestellten Ansatzes von Gray [12], die von redundanten Daten ausgeht, wird von Stone- braker in [29] vorgestellt. Die Redundanz der Daten wird dort verwendet, um die Zugriffs-Geschwindigkeit zu Objekten sowie die Robustheit des Systems gegen Knoten-Ausfälle zu verbessern.

Um die Konsistenz der Kopien zu gewährleisten, wird bei diesem Verfahren mit sog. Primär-Kopien (¹¹ primary copies¹¹ ) gearbeitet.

Von den vorhandenen Kopien einer bestimmten Datenmenge, z.B.

einer Relation, einem File oder ähnlichem, wird jeweils eine zur Primär-Kopie ernannt; und zwar diejenige mit der kleinsten Nummer. (Die Kopien sind aufsteigend durchnumeriert.)

Das Sperr- und Update-Problem wird hierbei im Prinzip zwei- . stufig gelöst. Eine globale Transaktion ¹¹ sieht¹¹ - außer am

eigenen Knoten - lediglich Primär-Kopien, muß also auch nur

diese sperren. Die Primär-Kopie wiederum ist - sofern ein Update durchzuführen ist - dafür verantwortlich, daß die Kopien

korrekt aktualisiert werden.

11Nur-Lese¹¹-Transaktionen werden - wenn möglich - lokal bedient.

Dies kann in manchen Fällen allerdings zu einem inkonsistenten Input führen (Daten können sich auf verschiedenen Aktuali-

täts-Stufen befinden). Will man auch für ¹¹ Nur-Lese¹¹-Trans-

. aktionen einen konsistenten Input sicherstellen ("no surprises") [29]), muß man sie wie Update-Transaktionen behandeln und über die Primär-Kopie routen.

Deadlock-Erkennung wird ähnlich wie bei Gray [12] von einer zentralisierten Komponente - dem ¹¹ SNOOP^{11 -} durchgeführt. Das Verfahren ist relativ robust, da es bei Knoten-Ausfällen, so- fern davon nicht der SNOOP und/oder eine Primär-Kopie be- troffen, so muß- vom System zuerst der SNOOP und/oder die Primär-Kopie(n) an einem anderen Knoten ins Leben gerufen werden, bevor weitergearbeitet werden kann.

Problematisch wird es allerdings, wenn durch teilweisen Aus- fall des Kommunikations-Systems eine Partitionierung des Netzes stattfindet. Die von Stonebraker in [12] angegebenen Rekonfigurierungs-Algorithmen schließen nicht aus, daß an- schließend zwei Primär-Kopien für ein Objekt existieren.

(Für weitere Ausführungen, wie z.B. Re-Integration ausge- fallener Knoten, die Erzeugung einer ¹¹Ersatz¹¹-Primär-Kopie oder die Schaffung eines ¹¹ Ersatz¹¹ -SNOOP, siehe [29]. Einige kritische Anmerkungen zur Realisierung des SNOOP finden sich in [20], S. 9 ff.)

4.1.2

(RSL) ^{( 11}wait-die^{11/ 11}wound-wait^{11 )}

Eine gewisse Ähnlichkeit bezüglich der Transaktions-Struktur (Initiierung von Teil-Transaktionen) mit dem von Gray [12]

beschriebenen Verfahren weist auch der Ansatz von Rosenkrantz, Stearns und Lewis [24] auf. Auch hier - in [4] wird er als

11 conflict-driven restart¹¹ bezeichnet - geht man im Prinzip von einer nicht-redundanten Datenbank aus, wobei man sich eben- falls vorstellt, daß eine Transaktion gegebenenfalls weitere Subtransaktionen an anderen Knoten zur Abarbeitung des

Benutzer-Auftrages initiiert. Allerdings nicht mehrere parallel, sondern es ist stets nur eine Teil-Transaktion einer globalen

Transaktion aktiv. Parallelität innerhalb von Transaktionen findet also nicht statt.

Gesperrt wird ebenfalls lokal. Der wesentliche Unterschied zu Gray liegt darin, daß die Transaktionen mit Zeitmarken

versehen sind, um das Verfahren deadlock-frei zu gestalten.

Die globale Koordination des Freigebens der Objekte wird von der zuletzt aktiven Teil-Transaktion durchgeführt.

~~r die Vermeidung von Deadlocks werden in [24Jzwei Vor- gehensweisen angeboten; und zwar

- die ¹¹wait-die¹¹-Methode und - die ¹¹wound-wait¹¹-Methode.

Nehmen wir an, eine Transaktion Q fordert eine Sperre an und gerät damit in Konflikt mit einer anderen Transaktion P, -die diese Sperre gerade ¹¹ besitzt^{11 •} Seien N(Q) und N(P) die Trans- aktions-Zeitmarken von Q bzw. P. Der Konflikt wird wie folgt aufgelöst:

Wait-Die-Methode:

i f N(Q) < N(P) then wait else die

Wound-Wait-Methode:

i f N(Q) < N(P) then wound elsewait

WAIT bedeutet warten auf das Ende oder den Abbruch der anderen Transaktion. DIE und WOUND bedeuten Abbruch einer Transaktion.

Sie unterscheiden sich dadurch, daß beim WAIT-DIE-Ansatz die Aktivität von der jüngeren Transaktion ausgeht. Versucht sie ein Objekt zu sperren, das eine ältere Transaktion aktuell gesperrt hat, so leitet sie selbst ihren Abbruch ein (DIE).

Bei WOUND ist die ältere Transaktion der aktive Teil und ver- sucht die jüngere Transaktion zu ¹¹canceln", sobald sie ein

Objekt benötigt, das diese jüngere Transaktion gesperrt

h ä 1 t.

Bei der WAIT-DIE-Methode erhält die jüngere Transaktion im Gegensatz zur 'WOUND-WAIT- Methode quasi noch eine Chance

11normal ¹¹ zu Ende zu kommen, sie wird erst dann abgebrochen (bzw. bricht sich selbst ab), wenn sie beim Anfordern einer weiteren Sperre mit einer älteren Transaktion in Konflikt gerät.

Eine abgebrochene Transaktion behält stets ihre alte Zeit- marke bei, d.h., sie wird erneut mit dieser gestartet. Da ältere Transaktionen im Konflikt-Fall nie abgebrochen werden, ist zykZischer Neustart ausgeschZossen. Bezüglich der-Robust- heit des Verfahrens gilt im Prinzip dasselbe wie bei Gray

(siehe oben).

(Lela) ^{( 11} ticketing^{11 )}

Einen anderen Weg versucht Le Lann [15] mit seinen ticketing- Algorithmen zu beschreiten. Jeder Knoten im Netz besitzt einen

sog. ¹¹Controller^{11 ,} der für den Zugriff auf die Datenbank zu- ständig ist. Diese Controller sind durch einen nvirtueiien Ringn miteinander verbunden. Auf diesem virtuellen Ring kreist ein token, d.h., ein Zähler, bei dem sich jeder Controller Nummern (¹¹ tickets^{11 )} holen kann. (Sofern er das token gerade besitzt - der Zähler wird dadurch erhöht).

Betrachten wir zunächst den Fall einer voii-redundanten

( 11 integrated¹¹ [15]) Datenbank. In diesem Fall besitzt das token nur einen einfachen Zähler (kein Vektor). Sei z der

aktuelle Zählerstand des tokens an einem Controller C gewesen.

C darf einen Update mit Nummer z+l erst dann ausführen, wenn er alle Aufträge mit Nummern kleiner/gleich z bereits empfangen hat. Nicht in Konflikt stehende Aufträge können dann gegebenen-

-

falls parallel, andere müssen seriell ausgeführt werden. Aber auch wenn C noch nicht mit dem lokalen Retrieve/Update starten darf, so darf er sich dennoch bereits ein oder mehrere Tickets

11abreißen^{11 •}

Für den Fall einer teil-redundanten oder nicht-redundanten

(

11 partitioned^{11 )} [15]) Datenbank weist das token einen Zähler für jede Partition der Datenbank auf; für n Partitionen hat das token also Zähler (Z 1 ,

z

für jede Partition - im nicht-redundanten Fall also für jeden Knoten - gibt es ein eigenes token mit einem einfachen Zähler.) Besitzt ein Controller nun gerade das token und möchte z.B.

3 Teil-Transaktionen starten, die die Partitionen i, j und k betreffen, muß er die Zählerz., _l

z.

die Teil-Transaktionen mit den entsprechenden Nummern (Zähler- wert) versehen und - sobald möglich (siehe oben) - an die

betroffenen Controller Ci' Cj und Ck senden.

Le Lann macht in [15] keine Angaben darüber, ob er davon aus- geht, daß Vorkenntnisse über die von den Transaktionen benötig- ten Objekte vorhanden sind oder nicht. Geht man davon aus,

daß Vorkenntnisse vorhanden sind, sieht man leicht ein, daß das Verfahren deadlock-frei ist. Im Falle, daß keine Vorkenntnisse •

vorhanden sind, muß man unterscheiden zwischen voll-redundanten und nicht-voll redundanten. Datenbanken.

Im voll-redundanten Fall kann die Verarbeitung - sobald die Sequenz-Nummer an der Reihe ist - zunächst vollständig lokal

erfolgen, da ja alle Daten "vor Ort" vorhanden sind. Anschließend kann man allen anderen Knoten entsprechende Update-Aufträge

11nachreichen^{11 •} Dies kann zwar bei den anderen Knoten unter Umständen zu längeren Wartezeiten führen, aber immerhin kann man auf diese Weise die Konsistenz der Datenbank gewährleisten.

Im nicht-vollredundaten Fall können Konsistenz-Probleme auf- treten, und zwar dann, wenn ein Controller Sperren "nachfordern"

muß. - Anscheinend hat Le Lann diesen Fall nicht berücksichtigt.

Robust ist das Verfahren insofern, als sowohl vorgesehen ist, das token bei Verlust zu regenerieren, als auch den virtuellen Ring ständig zu überwachen ("mutual suspicion" [15]) und bei Ausfall eines Knotens neu aufzubauen. (Für eine weitere Ver- tiefung siehe [15] und - als Ergänzung - [20] und [18].)

( El l i)

Ellis beschreibt in [9] ("decentralized solution"), wie man den Update von Kopien in teil- oder voll-redundanten ver- teilten Datenbanken korrekt durchführen kann. Bei seinem Ver- fahren besitzt jeder Knoten einen sog. Kontroll-Prozeß ("con- t r o l l e r p r o c e s s ^{11 ) ,} d e r f ü r d a s g l o b a l e S p e r r e n d e r K o p i e n z u - ständig ist. Jeder Kontroll-Prozeß kann sich jeweils tn genau e i n e m ✓v o n d r e i m ö g l i c h e n Z u s t ä n d e n b e f i n d e n ; u n d z w a r i m Passiv-3 Aktiv- oder Updating-Zustand.

Im Passiv-Zustand ist er bereit

- einen Benutzer-Auftrag("internal request") anzunehmen und eine entsprechende Anfrage an alle anderen Knoten zu senden (Wechsel nach aktiv)

- einen Update-Auftrag (einem entsprechenden Antrag hat er vorher bereits einmal zugestimmt) eines anderen Knoten auszuführen (Verbleiben in passiv)

- einer Update-Anfrage eines anderen Knoten ("external request") zuzustimmen (Verbleiben in passiv)

Im Aktiv-Zustand ist er bereit

- die auf seine Anfrage (Update) eingehenden Nachrichten auszuwerten (Verbleiben in aktiv); lehnt ein Knoten den Update-Antrag ab, wird der Benutzer-Auftrag zurückgewiesen

(Wechsel nach passiv)

- einen Update-Auftrag eines anderes Knoten auszuführen (Anmerkung wie oben; Verbleiben in aktiv)

- eine Update-Anfrage eines anderen Knoten zu beantworten:

Liegt kein Konflikt vor, wird ihr zugestimmt (Verbleib in aktiv), andernfalls, wenn die eigene Transaktion eine

höhere Priorität besitzt, wird sie abgelehnt (Verbleib in aktiv), ansonsten wird ihr zugestimmt und der eigene Be-

nutzer-Antrag zurückgewiesen (Wechsel nach passiv) Im Vpdating-Zustand ist er bereit

- Update-Vollzugsmeldungen (für seinen Auftrag) entgegen- zunehmen; falls noch nicht alle erhalten: Verbleib in updating, sonst Bestätigung an Benutzer und Wechsel nach passiv

~inen Update-Auftrag eines anderen Knoten auszuführen (Anmerkung wie oben; Verbleib in passiv)

Ein Update-Auftrag eines Benutzers wird wie folgt gehandhabt:

- Aufnahme-bereit ist der entsprechende Kontroll-Prozeß nur, wenn er sich im Passiv-Zustand befindet.

- Bevor irgend etwas geändert wird, fragt der Kontroll-Prozeß bei allen anderen Kontroll-Prozessen an, ob sie dem Update zustimmen können. (Diese stimmen - außer sie befinden sich im Aktiv-Zustand - stets zu. (Siehe unten.)

- Liegt die Zustimmung von allen Knoten vor, wird der Update- Auftrag versandt, am eigenen Knoten ebenfalls ausgeführt und auf die Vollzugsmeldungen der anderen Knoten gewartet.

- Erst wenn Vollzugsmeldungen von allen Knoten vorliegen, wird der Update dem Benutzer als durchgeführt bestätigt.

Konflikte - diese können nur im "Aktiv"-Zustand auftreten - werden bei diesem Verfahren durch Zeitmarken an Transaktionen

("eventcounts") gelöst. "Ältere" Transaktionen haben im Konflikt-Fall stets eine höhere Priorität. Um das Verfahren

robust zu machen, wird beim Abstimmungs-Verfahren mit einem time-out-Mechanismus gearbeitet.

Erhält der Update-Initiator innerhalb einer vorgegebenen

Zeitspanne von einem Knoten keine Antwort, so wird dieser als

"nicht verfügbar" markiert, in eine Liste eingetragen, und so getan, als ob er zugestimmt hätte. Sobald der Knoten wieder

"up" ist, setzt er sich mit den anderen Knoten in Verbindung, die für ihn alle zwischenzeitlich angefallenen Updates in einem "History Array" (9] gespeichert haben.

Diese Vorgehensweise kann zu Konsistenz-Problemen führen, wenn das Netz - aufgrund von teilweisen Ausfällen des

Kommunikations-Systems - in zwei oder mehr Teile "auseinander- bricht". In diesem Falle würden die Teile weitermachen und wechselseitig annehmen, daß die anderen Knoten "down" sind.

Dies kann zu einer Inkonsistenz der gesamten Datenbank führen, die in einem solchen Fall wahrscheinlich nur noch durch

Rollback bereits abgeschlossener Transaktionen und/oder durch ein globales Backup (siehe hierzu [7] und [28]) "repariert¹¹ werden kann.

(MPM)

Während Ellis in [9] (siehe oben) von einem dezentralisierten Sperr-Prozeß ausgeht, schlagen Menasce, Popek und Muntz in

[17] ein Verfahren vor, das auf einem zentralisierten Sperr- Prozeß (lock controller) basiert. Alle Sperr-Anforderungen müssen an diesen Sperr-Prozeß gerichtet werden, auch wenn die Date11 lokal verfügbar sind. (Dies kann natürlich zu Engpaß- problemen führen])

Der Schwerpunkt ihrer Arbeit liegt vor allem auf der Beschreibung der Kontroll-Prozesse für den Nachrichten- Austausch, die Gewährung sowie die Freigabe von Sperren vor dem Hintergrund möglicher Knotenausfälle und Netzwerk-

Partitionierungen. Auf Deadlock-Vermeidung/-Behandlung sowie Scheduling-Fragen wird in der Arbeit nicht eingegangen.

Menasce, Popek und Muntz weisen nach, daß ihr Verfahren auch bei diesen Fehlerfällen zu keinen Inkonsistenzen in dem Sinne führt, daß zwei Transaktionen gleichzeitig mit- einander unverträgliche Sperren für dieselben Objekte ge- währt werden oder daß unvollständige Transaktionen in die Datenbank gelangen, ohne daß vom System automatisch Rollback- Maßnahmen ergriffen werden.

Bei Netzwerk-Partitionierung ist vorgesehen, daß in dem Teil-Netz, das zunächst über keinen zentralisierten Sperr-:_

Prozeß verfügt, einen solchen ins Leben zu rufen. (Ein solches Teil-Netz kann u.U. auch nur aus einem einzigen Knoten be- stehen.) Jedes Teil-Netz ist solange uneingeschränkt arbeits- fähig, wie alle von einer Transaktion angesprochenen Daten

(einschließlich eventueller Kopien]) in diesem verfügbar sind. Sind gewisse Daten nicht verfügbar oder werden sie im laufe der Transaktions-Ausführung nicht verfügbar, so wird die Transaktion stets abgebrochen, zurückgesetzt und ihre Sperren werden freigegeben.

Diese Vorgehensweise bedeutet, daß das Vorhandensein möglicher Kopien überhaupt nicht ausgenutzt wird. Deshalb wird [17] er- wähnt, daß in solchen Fällen das Lesen von Kopien nqch

gestatten kann, das Ändern jedoch per Konvention verhindert werden muß.

Für voll-redundante und teil-redundante Datenbanken ist das Verfahren praktisch nur von beschränktem Nutzen, da bei Ausfall einer Kopie auf allen anderen Kopien keine Updates mehr durch-

11111