Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Transaktionen in verteilten Datenbanken Motivation:  geographisch verteilte Organisationsform einer Bank mit ihren Filialen   Filialen sollen Daten.

Ähnliche Präsentationen


Präsentation zum Thema: "Transaktionen in verteilten Datenbanken Motivation:  geographisch verteilte Organisationsform einer Bank mit ihren Filialen   Filialen sollen Daten."—  Präsentation transkript:

1 Transaktionen in verteilten 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 Kontogutschriften)  Ferienplanung: Buchung des Fluges, des Hotels und des Mietwagens soll entweder ganz oder gar nicht stattfinden

2 2 Ziel verteilter Datenbanken  Sammlung von Informationseinheiten, verteilt auf mehreren Rechnern, verbunden mittels Kommunikationsnetz  Kooperation zwischen autonom arbeitenden Stationen, zur Durchführung einer globalen Aufgabe

3 3 Client-Server-Architektur Kommunikations- netz Client C 1 Client C 2 DBMS DB z.B. WAN / Internet

4 4 Nachteile Client-Server Client-Server:  Zentrale Datenbank für viele Clients  Nachteil: Datenbankmanagementsystem ist single point of failure  Bei großen Datenmengen ist der Transport der angeforderten Daten an entfernte Clients u. U. zu langwierig. Forderung:  schnelle Ad-hoc-Anfragen  dezentrale Datenbanksysteme  hohe Benutzerzahlen sollen möglich sein  Verteilung der Gesamtdatenmenge auf verschiedene Standorte: Daten sind näher am Anwender. Reduzierte Datenzugriffszeiten  Reduzierung des Netzwerkverkehrs  ein verteiltes Datenbanksystem soll dem Benutzer wie eine einzelne Datenbank erscheinen -> er muss nicht wissen, welche Daten wo lagern

5 5 Verteiltes Datenbanksystem Kommunikations- netz Station S 1 Station S 2 Station S 3 z.B. WAN / Internet DB 2 DB 1 DB 3

6 6 Nachteile verteilter Datenbanksysteme  deutlich komplizierter zu planen, implementieren, sichern und zu warten  Daten müssen mit Ortsinformation belegt sein, so dass das DBMS weiß, wo welche Daten zu finden sind  Zugriffskonflikte müssen an zentraler Stelle gelöst werden  Transaktionskontrolle muss auf das gesamte Netzwerk ausgedehnt werden  Deadlocks können sich z.B. über mehrere Server verteilen  gewollte Redundanzen müssen konsistent gehalten werden

7 7 Distributed Database Management System Client Datenbank- Fragment 1 Datenbank- Fragment 2 Logische Datenbank DB-Server 1 DB-Server 2 DDBMS: Distributed Database Management System

8 8 Aufgaben des DDBMS  entscheidet darüber, ob Datenbankoperationen lokal oder im verteilten System stattfinden  Optimierung der Zugriffspfade zu den Daten für schnelle Abfragen  Ermittlung der physikalischen Standorte der Daten  Implementierung von Sicherheitsfunktionen  Backup und Recovery über das gesamte Datennetz  serverübergreifende Transaktionsverwaltung  lässt mehrere Datenbank-Fragmente für den Client wie eine einzige logische Datenbank aussehen  → DDBMS muss sämtliche Funktionen eines DBMS implementieren plus Funktionen für die verteilte Datenverwaltung und -verarbeitung

9 9 Aufbau und Entwurf eines verteilten Datenbanksystems globales Schema Fragmentierungs- schema Zuordnungsschema lokales Schema lokales Schema lokales DBMS lokales DBMS lokale DB lokale DB Station S 1 Station S n... DDBMS Distributed Database Management System

10 10 Fragmentierung und Allokation einer Relation  Fragmentierung: Fragmente enthalten Daten mit gleichem Zugriffsverhalten  Allokation: Fragmente werden den Stationen zugeordnet - mit Replikation (redundanzfrei) - ohne Replikation

11 11 R2R2 R3R3 R1R1 R3R3 R3R3 R2R2 R1R1 R3R3 R2R2 R1R1 R1R1 R1R1 R2R2 R Fragmentierung Allokation (Zuordnung) Station S 1 Station S 3 Station S 2

12 12 Fragmentierung  horizontale Fragmentierung: Zerlegung der Relation in disjunkte Tupelmengen  vertikale Fragmentierung: Zusammenfassung von Attributen mit gleichem Zugriffsmuster  kombinierte Fragmentierung: Anwendung horizontaler und vertikaler Fragmentierung auf dieselbe Relation

13 13 Korrektheits-Anforderungen  Rekonstruierbarkeit Die fragmentierte Relation lässt sich aus den Fragmenten wiederherstellen.  Vollständigkeit Jedes Datum ist einem Fragment zugeordnet.  Disjunktheit Die Fragmente überlappen sich nicht, d.h. ein Datum ist nicht mehreren Fragmenten zugeordnet.

14 14 Range-Partitionierung in Oracle  Jede Partition hat eine Klausel VALUES LESS THAN.  Alle Werte des Partitionierungs-Schlüsselwerts, die höher oder gleich dem Wert in VALUES LESS THAN sind, werden der nächsthöheren Partition zugeordnet.  Alle Partitionen außer der ersten haben eine untere Grenze, die durch die vorhergehende Partition festgelegt wird  Für die letzte Partition kann als obere Grenze MAXVALUE angegeben werden, was bedeutet, dass sie nach oben offen ist. Diese Partition nimmt auch die NULL-Werte mit auf.  Partitionierungsschlüssel können auch mehrere Felder sein CREATE TABLE sales_range (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_amount NUMBER(10), sales_date DATE) PARTITION BY RANGE(sales_date)( PARTITION sales_jan2000 VALUES LESS THAN(TO_DATE('02/01/2000','MM/DD/YYYY')), PARTITION sales_feb2000 VALUES LESS THAN(TO_DATE('03/01/2000','MM/DD/YYYY')), PARTITION sales_mar2000 VALUES LESS THAN(TO_DATE('04/01/2000','MM/DD/YYYY')), PARTITION sales_apr2000 VALUES LESS THAN(TO_DATE('05/01/2000','MM/DD/YYYY')) );

15 15 Transaktionskontrolle in DDBMS  Transaktionen können sich bei DDBMS ü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.

16 16 EOT-Behandlung  commit: globale Transaktion wird an allen (relevanten) lokalen Stationen festgeschrieben Die EOT (End-of-Transaction)-Behandlung von globalen Transaktionen stellt in DDBMS ein Problem dar. Eine globale Transaktion muss atomar beendet werden, d.h. entweder  abort:globale Transaktion wird gar nicht festgeschrieben oder   Problem in verteilter Umgebung, da die Stationen eines VDBMS unabhängig voneinander „abstürzen“ können

17 17 Problemlösung: Zweiphasen-Commit-Protokoll  das 2PC-Verfahren wird von sog. Koordinator K überwacht  gewährleistet, dass die n Agenten (=Stationen im DDBMS) A 1,...A 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   gewährleistet die Atomarität der EOT-Behandlung

18 18 Nachrichtenaustausch beim 2PC-Protokoll (für 4 Agenten) KK A1A1 A2A2 A3A3 A4A4 K A1A1 A2A2 A3A3 A4A4 PREPAREFAILED/READYCOMMIT/ABORTACK

19 19 Ablauf der EOT-Behandlung beim 2PC-Protokoll PREPARE  K schickt allen Agenten eine PREPARE-Nachricht, um herauszufinden, ob sie Transaktionen festschreiben können PREPARE  jeder Agent A i empfängt PREPARE-Nachricht und schickt eine von zwei möglichen Nachrichten an K: READY COMMIT FAILED ABORT  hat K von allen n Agenten A 1,...,A n ein READY erhalten, kann K ein COMMIT an alle Agenten schicken mit der Aufforderung, die Änderungen von T lokal festzuschreiben; antwortet einer der Agenten mit FAILED od. gar nicht innerhalb einer bestimmten Zeit (timeout), schickt K ein ABORT an alle Agenten und diese machen die Änderungen der Transaktion rückgängig ACK  haben die Agenten ihre lokale EOT-Behandlung abgeschlossen, schicken sie eine ACK-Nachricht (=acknowledgement, dt. Bestätigung) an den Koordinator  READY  READY, falls A i in der Lage ist, die Transaktion T lokal festzuschreiben  FAILED  FAILED, falls A i kein commit durchführen kann (wegen Fehler, Inkonsistenz etc.)

20 20 Lineare Organisationsform beim 2PC-Protokoll A1A1 A2A2 A3A3 A4A4 FAILED/READY COMMIT/ABORT

21 21 Zustandsübergang beim 2PC-Protokoll: Koordinator Initial Abgebrochen Bereit Fertig Festschreibend EOT: sende PREPARE an alle Agenten READY von allen Agenten empfangen: commit ins Log sende COMMIT Timeout oder FAILED empfangen: abort ins Log ABORT senden von allen ACK empfangen: „ Bullet“ = wichtigste Aktion(en)

22 22 Zustandsübergang beim 2PC-Protokoll: Agent Wartend Bereit AbgebrochenFestgeschrieben COMMIT empfangen: commit ins Log sende ACK ABORT empfangen: abort ins Log sende ACK PREPARE empfangen und lokal alles okay: Log-Einträge ausschreiben ready ins Log sende READY Timeout oder lokaler Fehler entdeckt: abort ins Log sende FAILED PREPARE empfangen: sende FAILED „ Bullet“ = wichtigste Aktion(en)

23 23 Fehlersituationen des 2PC-Protokolls  Absturz eines Koordinators  Absturz eines Agenten  verlorengegangene Nachrichten

24 24 Absturz eines Koordinators  ●Absturz vor dem Senden einer COMMIT-Nachricht  Rückgängigmachen der Transaktion durch Versenden einer ABORT-Nachricht  Blockierung der Agenten ●Absturz nachdem Agenten ein READY mitgeteilt haben  Blockierung der Agenten   Hauptproblem des 2PC-Protokolls beim Absturz des Koordinators, da dadurch die Verfügbarkeit des Agenten bezüglich andere globaler und lokaler Transaktionen drastisch eingeschränkt ist Um Blockierung von Agenten zu verhindern, wurde ein Dreiphasen-Commit-Protokoll konzipiert, das aber in der Praxis zu aufwendig ist (DDBMS benutzen das 2PC-Protokoll).

25 25 Absturz eines Agenten ●antwortet ein Agent innerhalb eines Timeout-Intervalls nicht auf die PREPARE-Nachricht, gilt der Agent als abgestürzt; der Koordinator bricht die Transaktion ab und schickt eine ABORT-Nachricht an alle Agenten ●„abgestürzter“ Agent schaut beim Wiederanlauf in seine Log-Datei:  ▪kein ready-Eintrag bzgl. Transaktion T  Agent führt ein abort durch und teilt dies dem Koordinator mit (FAILED- Nachricht)  ▪ready-Eintrag aber kein commit-Eintrag  Agent fragt Koordinator, was aus Transaktion T geworden ist; Koordinator teilt COMMIT oder ABORT mit, was beim Agenten zu einem Redo oder Undo der Transaktion führt  Agent weiß ohne Nach- fragen, dass ein (lokales) Redo der Transaktion nötig ist ▪commit-Eintrag vorhanden  Agent weiß ohne Nach- fragen, dass ein (lokales) Redo der Transaktion nötig ist

26 26 Verlorengegangene Nachrichten oder ●PREPARE-Nachricht des Koordinators an einen Agenten geht verloren oder  ●READY-(oder FAILED-)Nachricht eines Agenten geht verloren  nach Timeout-Intervall geht Koordinator davon aus, dass betreffender Agent nicht funktionsfähig ist und sendet ABORT-Nachricht an alle Agenten (Transaktion gescheitert)  ●Agent erhält im Zustand Bereit keine Nachricht vom Koordinator  Agent ist blockiert, bis COMMIT- oder ABORT-Nachricht vom Koordinator kommt, da Agent nicht selbst entscheiden kann (deshalb schickt Agent eine „Erinnerung“ an den Koordinator)

27 27 Mehrbenutzersynchronisation in DDBMS  Serialisierbarkeit  Zwei-Phasen-Sperrprotokoll in VDBMS ● lokale Sperrverwaltung an jeder Station ● globale Sperrverwaltung

28 28 Serialisierbarkeit globaler 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): SchrittT1T1 T2T SchrittT1T1 T2T r(A) w(A) w(B) r(B) S1S1 S2S2 T 1 ↔ T 2

29 29 Lokale Sperrverwaltung  globale Transaktion muß vor Zugriff/Modifikation eines Datums A, 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

30 30 Globale Sperrverwaltung  zentraler Sperrverwalter kann zum Engpass des DDBMS werden, besonders bei einem Absturz der Sperrverwalter- Station („rien ne va plus“)  Verletzung der lokalen Autonomie der Stationen, da auch lokale Transaktionen ihre Sperren bei der zentralisierten Sperrverwaltung anfordern müssen = alle Transaktionen fordern alle Sperren an einer einzigen, ausgezeichneten Station an. Nachteile: nicht zentrale Sperrverwaltung i.a. nicht akzeptabel

31 31 Deadlocks in VDBMS  Erkennung von Deadlocks (Verklemmungen) zentralisierte Deadlock-Erkennung dezentrale (verteilte) Deadlock-Erkennung  Vermeidung von Deadlocks

32 32 „Verteilter“ Deadlock SchrittT1T1 T2T BOT lockS(A) r(A) lockX(A)  S1S1 SchrittT1T1 T2T lockS(B)  BOT lockX(B) w(B) S2S2

33 33 Timeout   betreffende Transaktion wird zurückgesetzt und erneut gestartet  einfach zu realisieren  Problem: richtige Wahl des Timeout-Intervalls: zu lang  schlechte Ausnutzung der Systemressourcen zu kurz  Deadlock-Erkennung, wo gar keine Verklemmung vorliegt

34 34 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 Aufwand (viele Nachrichten)  Entstehung von Phantom-Deadlocks (=nicht- existierende Deadlocks) durch „Überholen“ von Nachrichten im Kommunikationssystem

35 35 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übergreifende Wartebeziehungen zu externen Subtransaktionen modelliert  Zuordnung jeder Transaktion zu einem Heimatknoten, von wo aus externe Subtransaktionen auf anderen Stationen initiiert werden 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. Die Kante External → T i wird für jede „von außen“ kommende Transaktion T i eingeführt.

36 36 Beispiel: S 1 Heimatknoten von T 1, S 2 Heimatknoten von T 2 Wartegraphen: S1:S1: External → T 2 → T 1 → External S2:S2: External → T 1 → T 2 → External S2:S2: 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 ‘ hat (= path pushing).

37 37 Deadlock-Vermeidung  optimistische Mehrbenutzersynchronisation: nach Abschluss 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)

38 38 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

39 39 Voraussetzungen für Deadlockvermeidungsverfahren  Vergabe global eindeutiger Zeitstempel als Transaktionsidentifikatoren  lokale Uhren müssen hinreichend genau aufeinander abgestimmt sein lokale Zeit Stations-ID

40 40 Synchronisation bei replizierten Daten Problem: Zu einem Datum A gibt es mehrere Kopien A1, A2,..., An, 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

41 41 Quorum-Consensus Verfahren   Ausgleich der Leistungsfähigkeit zwischen Lese- und Änderungstransaktionen  teilweise Verlagerung des Overheads von den Änderungs- zu den Lesetransaktionen indem den Kopien A i eines replizierten Datums A individuelle Gewichte zugeordnet werden  Lesequorum Q r (A)  Schreibquorum Q w (A)  Folgende Bedingungen müssen gelten: 1.Q w (A) + Q w (A) > W(A) 2.Q r (A) + Q w (A) > W(A)

42 42 Beispiel Station (S i )Kopie (A i )Gewicht (w i ) S1S1 A1A1 3 S2S2 A2A2 1 S3S3 A3A3 2 S4S4 A4A4 2

43 43 Zustände StationKopieGewichtWertVersions# S1S1 A1A S2S2 A2A2 1 1 S3S3 A3A3 2 1 S4S4 A4A4 2 1 a) vor dem Schreiben eines Schreibquorums b) nach dem Schreiben eines Schreibquorums StationKopieGewichtWertVersions# S1S1 A1A S2S2 A2A S3S3 A3A S4S4 A4A


Herunterladen ppt "Transaktionen in verteilten Datenbanken Motivation:  geographisch verteilte Organisationsform einer Bank mit ihren Filialen   Filialen sollen Daten."

Ähnliche Präsentationen


Google-Anzeigen