Terminologie. Kapitel 17 Verteilte Datenbanken. Use Cases. Kommunikationsmedien. Multi-Datenbanksysteme. Verteilte Datenbank

Transkript

1 Kapitel 17 Verteilte Datenbanken Motivation: geographisch verteilte Organisationsform einer Bank mit ihren Filialen + Filialen sollen Daten lokaler Kunden bearbeiten können + Zentrale soll Zugriff auf alle Daten haben (z.b. für Kontogutheissungen) Terminologie Verteilte Datenbank Sammlung von Informationseinheiten, verteilt auf mehreren Rechnern, verbunden mittels Kommunikationsnetz nach Ceri & Pelagatti (1984) Kooperation zwischen autonom arbeitenden Stationen, zur Durchführung einer globalen ufgabe Lose integrierte Datenbanken / Multi-Datenbanksysteme utonomes rbeiten utonome Strukturierung Keine gemeinsame Verwaltung 2 Use Cases Kommunikationsmedien Verteilte Datenbank Multi-Datenbanksysteme Bank mit Filialen Data Warehousing Legacy Datenbanken Integration von Datenbanken verschiedener Unternehmen LN: local area network, z.b. Ethernet, Token-Ring oder FDDI-Netz WN: wide area network, z.b. das Internet Telefonverbindungen, z.b. ISDN oder einfache Modem- Verbindungen 3 4

2 Verteiltes Datenbanksystem Client-Server-rchitektur Client C 1 Station S 1 Kommunikat Station S 2 ionsnetz Station S 3 Client C 2 Kommunikat ionsnetz Server 5 6 ufbau und Entwurf eines verteilten Datenbanksystems lokales Schema globales Schema Fragmentierungsschema Zuordnungsschema... lokales Schema Fragmentierung und llokation einer Relation Fragmentierung: Fragmente enthalten Daten mit gleichem Zugriffsverhalten llokation: Fragmente werden den Stationen zugeordnet - mit Replikation - ohne Replikation lokales DBMS... lokales DBMS lokale DB Station S lokale DB Station S n 7 8

3 Fragmentierung llokation (Zuordnung) Fragmentierung R R 1 1 R 1 R 1 2 Station S 1 horizontale Fragmentierung: Zerlegung der Relation in disjunkte Tupelmengen R 2 vertikale Fragmentierung: Zusammenfassung von ttributen mit gleichem Zugriffsmuster R 3 R 2 1 R 2 3 Station S 2 kombinierte Fragmentierung: nwendung horizontaler und vertikaler Fragmentierung auf dieselbe Relation R 3 Station S Korrektheits-nforderungen Beispielrelation Professoren Rekonstruierbarkeit PersNr Name Rang Professoren Raum Fakultät Gehalt Steuerklasse 2125 Sokrates C4 226 Philosophie Vollständigkeit 2126 Russel C4 232 Philosophie Kopernikus C3 310 Physik Disjunktheit Popper ugustinus C3 C Philosophie Theologie Curie C4 36 Physik Kant C4 7 Philosophie

4 Horizontale Fragmentierung sinnvolle Gruppierung der Professoren nach Fakultätszugehörigkeit: abstrakte Darstellung: R 3 Zerlegungsprädikate: R 1 R 2 R 3 p 1 Fakultät = Theologie p 2 Fakultät = Physik p 3 Fakultät = Philosophie Für 2 Prädikate p 1 und p 2 ergeben sich 4 Zerlegungen: R1 := σ p1 p 2 (R) R2 := σ p1 p 2 (R) R3 := σ p1 p 2 (R) R4 := σ p1 p 2 (R) n Zerlegungsprädikate p 1,...,p n ergeben 2 n Fragmente 13 TheolProfs := σ p1 p2 p3 (Professoren) = σ p1 (Professoren) PhysikProfs := σ p1 p2 p3 (Professoren) = σ p2 (Professoren) PhiloProfs := σ p1 p2 p3 (Professoren) = σ p3 (Professoren) ndereprofs := σ p1 p2 p3 (Professoren) 14 bgeleitete horizontale Fragmentierung Beispiel Vorlesungen aus dem Universitätsschema: Zerlegung in Gruppen mit gleicher SWS-Zahl 2SWSVorls := σ SWS=2 (Vorlesungen) 3SWSVorls := σ SWS=3 (Vorlesungen) 4SWSVorls := σ SWS=4 (Vorlesungen) select Titel, Name from Vorlesungen, Professoren where gelesenvon = PersNr; resultiert in: Π Titel, Name ((TheolProfs n2swsvorls) (TheolProfs 3SWSVorls)... (PhiloProfs 4SWSVorls) ) Join-Graph zu diesem Problem: für nfragebearbeitung schlechte Zerlegung TheolProfs PhysikProfs 2SWSVorls 3SWSVorls 15 PhiloProfs 4SWSVorls 16

5 Lösung: abgeleitete Fragmentierung TheolProfs TheolVorls PhysikProfs PhysikVorls PhiloProfs PhiloVorls TheolVorls := Vorlesungen E gelesenvon=persnr TheolProfs PhysikVorls := Vorlesungen E gelesenvon=persnr PhysikProfs PhiloVorls := Vorlesungen E gelesenvon=persnr PhiloProfs Vertikale Fragmentierung abstrakte Darstellung: R Π Titel, Name ((TheolProfs p TheolVorls) (PhysikProfs p PhysikVorls) (PhiloProfs p PhiloVorls) ) mit p (PersNr = gelesenvon) 17 R 1 κ R 2 18 Vertikale Fragmentierung Vertikale Fragmentierung (Beispiel) Beliebige vertikale Fragmentierung gewährleistet keine Rekonstruierbarkeit 2 mögliche nsätze, um Rekonstruierbarkeit zu garantieren: jedes Fragment enthält den Primärschlüssel der Originalrelation. ber: Verletzung der Disjunktheit jedem Tupel der Originalrelation wird ein eindeutiges Surrogat (= künstlich erzeugter Objektindikator) zugeordnet, welches in jedes vertikale Fragment des Tupels mit aufgenommen wird 19 für die Universitätsverwaltung sind PersNr, Name, Gehalt und Steuerklasse interessant: ProfVerw := Π PersNr, Name, Gehalt, Steuerklasse (Professoren) für Lehre und Forschung sind dagegen PersNr, Name, Rang, Raum und Fakultät von Bedeutung: Profs := Π PersNr, Name, Rang, Raum, Fakultät (Professoren) Rekonstruktion der Originalrelation Professoren: Professoren = ProfVerw ProfVerw.PersNr = Profs.PersNr Profs 20

6 Kombinierte Fragmentierung a) horizontale Fragmentierung nach vertikaler Fragmentierung R Rekonstruktion nach kombinierter Fragmentierung R 21 R 1 R 2 R 22 R 23 b) vertikale Fragmentierung nach horizontaler Fragmentierung R R 1 R 2 Fall a) R = R 1 p (R 21 R 22 R 23 ) Fall b) R = R 1 R 2 (R 31 R31. κ =R 32. κ R 32 ) R 3 R 31 R Baumdarstellung der Fragmentierungen (Beispiel) Professoren v llokation Dasselbe Fragment kann mehreren Stationen zugeordnet werden llokation für unser Beispiel ohne Replikationen redundanzfreie Zuordnung Profs h ProfVerw Vorlesungen h Station S Verw S Physik S Philo S Theol Bemerkung Verwaltungsrechner Dekanat Physik Dekanat Philosophie Dekanat Theologie zugeordnete Fragemente {ProfVerw} {PhysikVorls, PhysikProfs} {PhiloVorls, PhiloProfs} {TheolVorls, TheolProfs} PhysikProfs TheolProfs PhiloProfs PhysikVorls TheolVorls PhiloVorls 23 24

7 Transparenz in verteilten Datenbanken Fragmentierungstransparenz Beispielanfrage, die Fragmentierungstransparenz voraussetzt: Grad der Unabhängigkeit den ein VDBMS dem Benutzer beim Zugriff auf verteilte Daten vermittelt verschiedene Stufen der Transparenz: Fragmentierungstransparenz llokationstransparenz Lokale Schema-Transparenz select Titel, Name from Vorlesungen, Professoren where gelesenvon = PersNr; Beispiel für eine Änderungsoperation, die Fragmentierungstransparenz voraussetzt: update Professoren set Fakultät = Theologie where Name = Sokrates ; Fortsetzung Beispiel llokationstransparenz Ändern des ttributwertes von Fakultät Transferieren des Sokrates-Tupels aus Fragment PhiloProfs in das Fragment TheolProfs (= Löschen aus PhiloProfs, Einfügen in TheolProfs) Ändern der abgeleiteten Fragmentierung von Vorlesungen (= Einfügen der von Sokrates gehaltenen Vorlesungen in TheolVorls, Löschen der von ihm gehaltenen Vorlesungen aus PhiloVorls) Benutzer müssen Fragmentierung kennen, aber nicht den ufenthaltsort eines Fragments Beispielanfrage: select Gehalt from ProfVerw where Name = Sokrates ; 27 28

8 llokationstransparenz (Forts.) Lokale Schema-Transparenz unter Umständen muss Originalrelation rekonstruiert werden Beispiel: Verwaltung möchte wissen, wieviel die C4-Professoren der Theologie insgesamt verdienen da Fragmentierungstransparenz fehlt muss die nfrage folgendermaßen formuliert werden: select sum (Gehalt) from ProfVerw, TheolProfs where ProfVerw.PersNr = TheolProfs.PersNr and Rang = C4 ; 29 Der Benutzer muss auch noch den Rechner kennen, auf dem ein Fragment liegt. Beispielanfrage: select Name from TheolProfs at S Theol where Rang = C3 ; 30 Lokale Schema-Transparenz (Forts.) nfrageübersetzung und nfrageoptimierung Ist überhaupt Transparenz gegeben? Lokale Schema-Transparenz setzt voraus, dass alle Rechner dasselbe Datenmodell und dieselbe nfragesprache verwenden. vorherige nfrage kann somit analog auch an Station S Philo ausgeführt werden Dies ist nicht möglich bei Kopplung unterschiedlicher DBMS. Voraussetzung: Fragmentierungstransparenz ufgabe des nfrageübersetzers: Generierung eines nfrageauswertungsplans auf den Fragmenten ufgabe des nfrageoptimierers: Generierung eines möglichst effizienten uswertungsplanes abhängig von der llokation der Fragmente auf den verschiedenen Stationen des Rechnernetzes Verwendung grundsätzlich verschiedener Datenmodelle auf lokalen DBMS nennt man Multi-Database-Systems (oft unumgänglich in realer Welt)

9 nfragebearbeitung bei horizontaler Fragmentierung Übersetzung einer SQL-nfrage auf dem globalen Schema in eine äquivalente nfrage auf den Fragmenten benötigt 2 Schritte: Beispiel select Titel from Vorlesungen, Profs where gelesenvon = PersNr and Rang = C4 ; Der entstandene algebraische usdruck heißt kanonische Form der nfrage: Π Titel Rekonstruktion aller in der nfrage vorkommenden globalen Relationen aus den Fragmenten, in die sie während der Fragmentierungsphase zerlegt wurden. Hierfür erhält man einen algebraischen usdruck. Kombination des Rekonstruktionsausdrucks mit dem algebraischen nfrageausdruck, der sich aus der Übersetzung der SQL-nfrage ergibt. σ Rang= C4 gelesenvon=persnr 33 TheolVorls PhiloVorls PhysikVorls TheolProfs PhiloProfs PhysikProfs 34 lgebraische Äquivalenzen Für eine effizientere barbeitung der nfrage benutzt der nfrageoptimierer die folgende Eigenschaft: (R 1 R 2 ) p (S 1 S 2 ) = (R 1 >< p S 1 ) (R 1 p S 2 ) (R 2 p S 1 ) (R 2 p S 2 ) Die Verallgemeinerung auf n horizontale Fragmente R 1,...,R n von R und m Fragmente S 1,...,S m von S ergibt: (R 1... R n ) p (S 1... S m ) = (R i p S j ) 1 i n 1 j m Falls gilt: S i = S E p R i mit S = S i... S n Dann gilt immer: R i p S j = für r i j 35 lgebraische Äquivalenzen (Forts.) Für eine derartig abgeleitete horizontale Fragmentierung von S gilt somit: (R 1... R n ) p (S 1... S m ) = (R 1 p S 1 ) (R 2 p S 2 )... (R n p S n ) Für unser Beispiel gilt nun folgendes: (TheolVorls PhysikVorls PhiloVorls)... (TheolProfs PhysikProfs PhiloProfs) Um Selektionen und Projektionen über den Vereinigungsoperator hinweg nach unten zu drücken benötigt man folgende Regeln: σ p (R 1 R 2 ) = σ p (R 1 ) σ p (R 2 ) Π L (R 1 R 2 ) = Π L (R 1 ) Π L (R 2 ) 36

10 Optimale Form der nfrage Die nwendung dieser algebraischen Regeln generiert den folgenden uswertungsplan: Π Titel gelesenvon=persnr Π Titel gelesenvon=persnr Π Titel gelesenvon=persnr nfragebearbeitung bei vertikaler Fragmentierung Beispiel: select Name, Gehalt from Professoren where Gehalt > 80000; kanonischer uswertungsplan: Π Name, Gehalt σ Gehalt>80000 σ Rang= C4 σ Rang= C4 σ Rang= C4 TheolVorls TheolProfs PhysikVorls PhysikProfs PhiloVorls PhiloProfs ProfVerw uswertungen können lokal auf den Stationen S Theol, S Physik und S Philo ausgeführt werden Stationen können parallel abarbeiten und lokales Ergebnis voneinander unabhängig an die Station, die die abschliessende Vereinigung durchführt, übermitteln. 37 TheolProfs PhysikProfs PhiloProfs 38 Optimierung bei vertikaler Fragmentierung Für unser Beispiel gilt: lle notwendigen Informationen sind in ProfVerw enthalten der Teil mit Vereinigung und Join kann abgeschnitten werden. Das ergibt den folgenden Π optimierten uswertungsplan: Name, Gehalt σ Gehalt>80000 ProfVerw Der natürliche Verbund zweier Relationen R und S R B C a 1 a 2 a 3 a 4 b 1 b 2 b 3 b 4 c 1 c 2 c 1 c 2 S C D E c 1 c 3 c 4 c 5 d 1 d 2 d 3 d 4 e 1 e 2 e 3 e 4 = a 1 a 3 B b 1 b 3 R S C D E c 1 c 1 d 1 d 1 e 1 e 1 Beispiel für eine schlecht zu optimierende nfrage: (ttribut Rang fehlt in ProfVerw) select Name, Gehalt, Rang from Professoren a 5 a 6 b 5 b 6 a 7 b 7 c 6 c 5 d 7 e 7 where Gehalt > 80000; c 3 c 2 c 7 c 8 d 5 d 6 e 5 e 6 a 5 b 5 c 3 d 2 e 2

11 Join-uswertung in VDBMS Join-uswertung spielt kritischere Rolle als in zentralisierten Datenbanken Problem: rgumente eines Joins zweier Relationen können auf unterschiedlichen Stationen des VDBMS liegen 2 Möglichkeiten: Join-uswertung mit und ohne Filterung Betrachtung des allgemeinsten Falles: äußere rgumentrelation R ist auf Station St R gespeichert innere rgumentrelation S ist dem Knoten St S zugeordnet Ergebnis der Joinberechnung wird auf einem dritten Knoten St Result benötigt Join-uswertung ohne Filterung Nested-Loops Nested-Loops Transfer einer rgumentrelation Transfer beider rgumentrelationen Iteration durch die äußere Relation R mittels Laufvariable r und nforderung des zu jedem Tupel r passenden Tupel s S mit r.c = s.c (über Kommunikationsnetz bei St S ) Diese Vorgehensweise benötigt pro Tupel aus R eine nforderung und eine passende Tupelmenge aus S (welche bei vielen nforderungen leer sein könnte) es werden 2 R Nachrichten benötigt 43 44

12 Transfer einer rgumentrelation Transfer beider rgumentrelationen vollständiger Transfer einer rgumentrelation (z.b. R) zum Knoten der anderen rgumentrelation usnutzung eines möglicherweise auf S.C existierenden Indexes 1. Transfer beider rgumentrelationen zum Rechner St Result 2. Berechnung des Ergebnisses auf den Knoten St Result mittels a) Merge-Join (bei vorliegender Sortierung) oder b) Hash-Join (bei fehlender Sortierung) evtl. Verlust der vorliegenden Index für die Join- Berechnung kein Verlust der Sortierung der rgumentrelation(en) Join-uswertung mit Filterung Verwendung des Semi-Join-Operators zur Filterung Schlüsselidee: nur Transfer von Tupel, die passenden Join-Partner haben Benutzung der folgenden algebraischen Eigenschaften: R S = R (R FS) R F S = Π C (R) F S Join-uswertung mit Filterung (Beispiel, Filterung der Relation S) Transfer der unterschiedlichen C-Werte von R (= Π C (R) ) nach St S uswertung des Semi-Joins R F S = Π C (R) F S auf St S und Transfer nach St R uswertung des Joins auf St R, der nur diese transferierten Ergebnistupel des Semi-Joins braucht Transferkosten werden nur reduziert, wenn gilt: Π C (R) + R F S < S mit P = Größe (in Byte) einer Relation 47 48

13 15 ttributwerte... R (Π C (R) F S) B C D E a 1 b 1 c 1 d 1 e 1 a 3 b 3 c 1 d 1 e 1 a 5 b 5 c 3 d 2 C c 1 c 2 c 3 c 6 R B C a 1 b 1 c 1 a 2 b 2 c 2 a 3 b 3 c 1 a 4 b 4 c 2 a 5 b 5 c 3 a 6 b 6 c 2 a 7 b 7 c 6 Π C e 2 St Result 6 ttributwerte 4 ttributwerte St R St S Π C (R) F S C D E c 1 c 3 d 1 d 2 e 1 e 2 F S C D E c 1 d 1 e 1 c 3 d 2 e 2 c 4 d 3 e 1 c 5 d 4 e 2 c 7 d 5 e 3 c 8 d 6 e 2 c 5 d 7 e 6 uswertung des Joins R S mit Semi-Join-Filterung von S 49 lternative uswertungungspläne 1. lternative: R 2. lternative: F St R St S Π C (R E Π C (S)) (Π C (R) F S)... S St Result 50 Parameter für die Kosten eines uswertungsplan Kardinalitäten von rgumentrelationen Selektivitäten von Joins und Selektionen Transferkosten für Datenkommunikation (Verbindungsaufbau + von Datenvolumen abhängiger nteil für Transfer) uslastung der einzelnen VDBMS-Stationen Effektive nfrageoptimierung muss auf Basis eines Kostenmodells durchgeführt werden und soll mehrere lternativen für unterschiedliche uslastungen des VDBMS erzeugen. Transaktionskontrolle in VDBMS Transaktionen können sich bei VDBMS über mehrere Rechnerknoten erstrecken Recovery: Redo: Wenn eine Station nach einem Fehler wieder anläuft, müssen alle Änderungen einmal abgeschlossener Transaktionen - seien sie lokal auf dieser Station oder global über mehrere Stationen ausgeführt worden - auf den an dieser Station abgelegten Daten wiederhergestellt werden. Undo: Die Änderungen noch nicht abgeschlossener lokaler und globaler Transaktionen müssen auf den an der abgestürzten Station vorliegenden Daten rückgängig gemacht werden

14 EOT-Behandlung Die EOT (End-of-Transaction)-Behandlung von globalen Transaktionen stellt in VDBMS ein Problem dar. Eine globale Transaktion muss atomar beendet werden, d.h. entweder commit: globale Transaktion wird an allen (relevanten) lokalen Stationen festgeschrieben oder abort: globale Transaktion wird gar nicht festgeschrieben Problemlösung: Zweiphasen-Commit-Protokoll gewährleistet die tomarität der EOT-Behandlung das 2PC-Verfahren wird von sog. Koordinator K überwacht gewährleistet, dass die n genten (=Stationen im VDBMS) 1,... n, die an einer Transaktion beteiligt waren, entweder alle von Transaktion T geänderten Daten festschreiben oder alle Änderungen von T rückgängig machen Problem in verteilter Umgebung, da die Stationen eines VDBMS unabhängig voneinander abstürzen können K Nachrichtenaustausch beim 2PC- Protokoll (für 4 genten) PREPRE FILED/REDY COMMIT/BORT CK K K 55 blauf der EOT-Behandlung beim 2PC-Protokoll K schickt allen genten eine PREPRE-Nachricht, um herauszufinden, ob sie Transaktionen festschreiben können jeder gent i empfängt PREPRE-Nachricht und schickt eine von zwei möglichen Nachrichten an K: REDY, falls i in der Lage ist, die Transaktion T lokal festzuschreiben FILED, falls i kein commit durchführen kann (wegen Fehler, Inkonsistenz etc.) hat K von allen n genten 1,..., n ein REDY erhalten, kann K ein COMMIT an alle genten schicken mit der ufforderung, die Änderungen von T lokal festzuschreiben; antwortet einer der genten mit FILED od. gar nicht innerhalb einer bestimmten Zeit (timeout), schickt K ein BORT an alle genten und diese machen die Änderungen der Transaktion rückgängig haben die genten ihre lokale EOT-Behandlung abgeschlossen, schicken sie eine CK-Nachricht (=acknowledgement, dt. Bestätigung) an den Koordinator 56

15 Lineare Organisationsform beim 2PC- Protokoll Zustandsübergang beim 2PC-Protokoll: Koordinator FILED/REDY FILED/REDY FILED/REDY COMMIT/BORT COMMIT/BORT COMMIT/BORT Bullet = wichtigste ktion(en) Timeout oder FILED empfangen: abort ins Log BORT senden bgebroc hen Initial Bereit EOT: sende PREPRE an alle genten REDY von allen genten empfangen: commit ins Log sende COMMIT Festschrei bend 57 von allen CK empfangen: Fertig von allen CK empfangen: 58 Timeout oder lokaler Fehler entdeckt: abort ins Log sende FILED Zustandsübergang beim 2PC-Protokoll: gent BORT empfangen: abort ins Log sende CK Warte nd PREPRE empfangen und lokal alles okay: Log-Einträge ausschreiben ready ins Log sende REDY Bereit COMMIT empfangen: commit ins Log sende CK Fehlersituationen des 2PC-Protokolls bsturz eines Koordinators bsturz eines genten verlorengegangene Nachrichten bgebroc hen PREPRE empfangen: sende FILED Festgesch rieben Bullet = wichtigste ktion(en) 59 60

16 bsturz eines Koordinators bsturz vor dem Senden einer COMMIT-Nachricht + Rückgängigmachen der Transaktion durch Versenden einer BORT-Nachricht bsturz nachdem genten ein REDY mitgeteilt haben + Blockierung der genten Hauptproblem des 2PC-Protokolls beim bsturz des Koordinators, da dadurch die Verfügbarkeit des genten bezüglich andere globaler und lokaler Transaktionen drastisch eingeschränkt ist Um Blockierung von genten zu verhindern, wurde ein Dreiphasen-Commit-Protokoll konzipiert, das aber in der Praxis zu aufwendig ist (VDBMS benutzen das 2PC-Protokoll). 61 bsturz eines genten antwortet ein gent innerhalb eines Timeout-Intervalls nicht auf die PREPRE-Nachricht, gilt der gent als abgestürzt; der Koordinator bricht die Transaktion ab und schickt eine BORT-Nachricht an alle genten abgestürzter gent schaut beim Wiederanlauf in seine Log-Datei: kein ready-eintrag bzgl. Transaktion T + gent führt ein abort durch und teilt dies dem Koordinator mit (FILED-Nachricht) ready-eintrag aber kein commit-eintrag + gent fragt Koordinator, was aus Transaktion T geworden ist; Koordinator teilt COMMIT oder BORT mit, was beim genten zu einem Redo oder Undo der Transaktion führt commit-eintrag vorhanden + gent weiß ohne Nach-fragen, dass ein (lokales) Redo der Transaktion nötig n ist 62 Verlorengegangene Nachrichten PREPRE-Nachricht des Koordinators an einen genten geht verloren oder REDY-(oder FILED-)Nachricht eines genten geht verloren + nach Timeout-Intervall geht Koordinator davon aus, dass betreffender gent nicht funktionsfähig ist und sendet BORT-Nachricht an alle genten (Transaktion gescheitert) gent erhält im Zustand Bereit keine Nachricht vom Koordinator + gent ist blockiert, bis COMMIT- oder BORT-Nachricht vom Koordinator kommt, da gent nicht selbst entscheiden kann (deshalb schickt gent eine Erinnerung an den Koordinator) 63 Mehrbenutzersynchronisation in VDBMS Serialisierbarkeit Zwei-Phasen-Sperrprotokoll in VDBMS lokale Sperrverwaltung an jeder Station globale Sperrverwaltung 64

17 Serialisierbarkeit Lokale Serialisierbarkeit an jeder der an den Transaktionen beteiligten Stationen reicht nicht aus. Deshalb muß man bei der Mehrbenutzersynchronisation auf globaler Serialisierbarkeit bestehen. Beispiel (lokal serialisierbare Historien): S 1 S 2 Lokale Sperrverwaltung globale Transaktion muß vor Zugriff/Modifikation eines Datums, das auf Station S liegt, eine Sperre vom Sperrverwalter der Station S erwerben Verträglichkeit der angeforderten Sperre mit bereits existierenden Sperren kann lokal entschieden werden + favorisiert lokale Transaktionen, da diese nur mit ihrem lokalen Sperrverwalter kommunizieren müssen Schritt T 1 T r() w() Schritt T 1 T r(b) w(b) T 1 T Globale Sperrverwaltung = alle Transaktionen fordern alle Sperren an einer einzigen, ausgezeichneten Station an. Nachteile: zentraler Sperrverwalter kann zum Engpass des VDBMS werden, besonders bei einem bsturz der Sperrverwalter- Station ( rien ne vas plus ) Verletzung der lokalen utonomie der Stationen, da auch lokale Transaktionen ihre Sperren bei der zentralisierten Sperrverwaltung anfordern müssen Deadlocks in VDBMS Erkennung von Deadlocks (Verklemmungen) zentralisierte Deadlock-Erkennung dezentrale (verteilte) Deadlock-Erkennung Vermeidung von Deadlocks zentrale Sperrverwaltung i.a. nicht akzeptabel 67 68

18 Verteilter Deadlock Timeout S 1 Schritt T 1 T 2 S 2 Schritt T 1 T 2 betreffende Transaktion wird zurückgesetzt und erneut gestartet einfach zu realisieren BOT locks() r() lockx() locks(b) BOT lockx(b) w(b) Problem: richtige Wahl des Timeout-Intervalls: zu lang schlechte usnutzung der Systemressourcen zu kurz Deadlock-Erkennung, wo gar keine Verklemmung vorliegt Zentralisierte Deadlock-Erkennung Stationen melden lokal vorliegende Wartebeziehungen an neutralen Knoten, der daraus globalen Wartegraphen aufbaut (Zyklus im Graphen Deadlock) sichere Lösung Nachteile: hoher ufwand (viele Nachrichten) Entstehung von Phantom-Deadlocks (=nichtexistierende Deadlocks) durch Überholen von Nachrichten im Kommunikationssystem 71 Dezentrale Deadlock-Erkennung lokale Wartegraphen an den einzelnen Stationen + Erkennen von lokalen Deadlocks Erkennung globaler Deadlocks: jeder lokale Wartegraph hat einen Knoten External, der stationenübergreifenden Wartebeziehungen zu externen Subtransaktionen modelliert Zuordnung jeder Transition zu einem Heimatknoten, von wo aus externe Subtransaktionen auf anderen Stationen initiiert werden Die Kante External T i wird für jede von außen kommende Transaktion T i eingeführt. Die Kante T j External wird für jede von außen kommende Transaktion T j dieser Station eingeführt, falls T j nach außen geht. 72

19 Beispiel: S 1 Heimatknoten von T 1, S 2 Heimatknoten von T 2 Wartegraphen: S 1 : S 2 : S 2 : External T 2 T 1 External External T 1 T 2 External External T 1 T 2 External T 1 T 2 T 1 T 2 T 1 T 2 Zur Reduzierung des Nachrichtenaufkommens wird der Pfad External T 1 T 2... T n External nur weitergereicht, wenn T 1 einen kleineren Identifikator als T n Deadlock-Vermeidung optimistische Mehrbenutzersynchronisation: nach bschluss der Transaktionsbearbeitung wird Validierung durchgeführt Zeitstempel-basierende Synchronisation: Zuordnung eines Lese-/Schreib-Stempels zu jedem Datum entscheidet, ob beabsichtigte Operation durchgeführt werden kann ohne Serialisierbarkeit zu verletzen oder ob Transaktion abgebrochen wird (abort) hat (= path pushing) Sperrbasierte Synchronisation wound/wait: nur jüngere Transaktionen warten auf ältere; fordert ältere Transaktion Sperre an, die mit der von der jüngeren Transaktion gehaltenen nicht verträglich ist, wird jüngere Transaktion abgebrochen wait/die: nur ältere Transaktionen warten auf jüngere; fordert jüngere Transaktion Sperre an, die mit der von der älteren Transaktion gehaltenen nicht kompatibel ist, wird jüngere Transaktion abgebrochen Voraussetzungen für Deadlockvermeidungsverfahren Vergabe global eindeutiger Zeitstempel als Transaktionsidentifikatoren lokale Zeit Stations-ID lokale Uhren müssen hinreichend genau aufeinander abgestimmt sein 75 76

20 Problem: Synchronisation bei replizierten Daten Zu einem Datum gibt es mehrere Kopien 1, 2,..., n, die auf unterschiedlichen Stationen liegen. Eine Lesetransaktion erfordert nur eine Kopie, bei Änderungstransaktionen müssen aber alle bestehenden Kopien geändert werden. hohe Laufzeit und Verfügbarkeitsprobleme Quorum-Consensus Verfahren usgleich der Leistungsfähigkeit zwischen Lese- und Änderungstransaktionen + teilweise Verlagerung des Overheads von den Änderungs- zu den Lesetransaktionen indem den Kopien i eines replizierten Datums individuelle Gewichte zugeordnet werden Lesequorum Q r () Schreibquorum Q w () Folgende Bedingungen müssen gelten: 1. Q w () + Q w () > W() 2. Q r () + Q w () > W() Beispiel Station (S i ) Kopie ( i ) Gewicht (w i ) S S S S Zustände a) vor dem Schreiben eines Schreibquorums Station Kopie Gewicht Wert Versions# S S S S W ( ) = w i() Q () Q r w () 4 i= 1 = 4 = 5 = 8 b) nach dem Schreiben eines Schreibquorums Station Kopie Gewicht Wert Versions# S S S S