7. Verteilte Transaktionen 7.1 Verteilte Datenbanksysteme

• Überblick 

7. Verteilte Transaktionen 

7.1 Verteilte Datenbanksysteme 

7.2 Verteilte Transaktionen 

7.3 Dezentrale Koordination 

7.4 Replikation 

O. Kao Systemaspekte Verteilter Systeme 7-1 

7.1 Verteilte 

Datenbanksysteme 

• Definition: Verteiltes Datenbanksystem (VDBS) 

Unter VDBS wird eine logisch integrierte Sammlung gemeinsam 

genutzter Daten verstanden, die physikalisch auf einer Anzahl von 

Knoten in einem Rechnernetzwerk verteilt ist 

• „Natürliche“ Datenverteilung: mehrere unabhängige Systeme mit 

ihren lokalen Datenmengen werden zu einer Einheit kombiniert 

Beispiel: multimediale Datenbank über Filme kann auf zwei Arten aus 

mehreren lokalen Datenbanken aufgebaut werden 

Lokale Datenbanken speichern Medien und Metainformationen, z.B. 

Bilddatenbank mit Fotos von Schauspielern, Bilddatenbank mit 

Keyframes aus verschiedenen Filmen, Videoserver sowie relationale 

Datenbanken mit bibliografischen und Filmangaben 

Jede lokale Datenbank enthält eine Teilmenge des Filmmaterials, 

z.B. nach Herstellerland geordnet 

In beiden Fällen ermöglicht eine zentrale Schnittstelle den Zugriff auf die 

Daten in allen lokalen Datenbanken 

O. Kao Systemaspekte Verteilter Systeme 7-2

Klassifikation Verteilter 

Datenbanksysteme 

DBMS = Datenbankmanagementsystem 


• Homogene VDBS leiten sich aus 

konventionellen DBS durch 

Partitionierung der Daten auf 

mehrere Knoten ab 

Zugriff auf alle Teile der 

lokalen Datenbanken zentral über 

ein einheitliches Schema 

Fragmentierungsschicht: 

Unterteilung der globalen 

Operationen in Segmente für 

einzelne Knoten ⇒ notwendige 

Einschränkungen zur sinnvollen 

Vereinigung der Teilergebnisse 

Homogene VDBS 

Allokationsschicht: Zuordnung von 

Fragmenten zu Knoten, besonders 

wichtig in Kombination mit 

Replikation, Scheduling, …. 


Heterogene VDBS 

• Verschiedene DBS auf den Knoten erlaubt ⇒ Vorteil der einheitlichen 

Verteilung/Ausführung der Operationen existiert nicht mehr 

• Die einzelnen Systeme verfügen über 

Umsetzungsschemata zur vollständigen Integration im globalen DBS 

Schnittstellen (Gateways) für den Zugriff auf die lokalen Daten 

Beispiel: Metasuchmaschinen geben Stichwörter nach syntaktischer 

Anpassung in mehrere Suchmaschinen ein ⇒ Parallele Bearbeitung 

Syntaktische Umwandlung betrifft die Formulierung der logischen 

Ausdrücke, z.B. Wort1 AND Wort2 wird zu +Wort1+Wort2 

• Vollintegrierte DBS: bereits vorhandene Datenbanken werden über 

Konvertierungssubsysteme in ein neues globales System gekoppelt 

• Partiell integrierte DBS 

Zentrale Schnittstelle zur Abfrage / Kombination der Ergebnisse 

Lokaler Zugriff ohne Nutzung globaler Schnittstellen und -mechanismen 

erlaubt ⇒ Mitgliedschaft im globalen System bleibt unsichtbar 


Föderierte Datenbanksysteme 

• Eng verbundene (Tightly 

coupled) DBS verfügen über 

ein globales konzeptionelles 

Schema als Vereinigung von 

Teilen der lokalen Schemata 

Lokale DBS erlauben – je nach 

Autonomiegrad – die 

Aufnahme von Teilen der 

Daten im globalen Schema 

Auf die anderen Daten kann 

nur lokal zugegriffen werden 

Hilfsschema legt die Regel für 

die Datenkonvertierung fest, 

z.B. 13. November 2000 in 

2000/11/13 


Datenmanagement in verteilten 

Datenbanksystemen 

• Wesentliche Bedingungen aus Verteilung der Daten über die Knoten 

• Kompromiss zwischen 

Datenlokalität (Benötigte Daten auf einem Knoten) und 

Nebenläufigkeit (Daten gleichmäßig über alle Knoten verteilt) 

• Dieses Allokationsproblem ist NP-vollständig ⇒ Einsatz von 

Heuristiken 

• Bei VDBS wird eine Transaktion in mehrere Subtransaktionen – 

Agenten – unterteilt und an die entsprechenden Knoten versendet 

Transaktionskontrolle muss auf alle beteiligten Knoten verteilt werden 

⇒ Anpassung der bestehenden Verfahren notwendig 

Berücksichtigung der Replikation 

Alle Knoten müssen stets die aktuelle Version der Daten haben 


7.2 Verteilte Transaktionen 

• Verteilte Transaktion greifen auf Objekte zu, die auf mehreren räumlich 

getrennten Servern verteilt sind 

Atomarität: Transaktion ist entweder bei allen Servern festgeschrieben 

oder wird von allen Servern abgebrochen 

⇒ Koordination durch einen/mehrere Server erforderlich 

• Transaktionsarten 

Flache Transaktion: Die aktuelle Anforderung der Transaktion wird 

abgeschlossen, bevor die nächste Anforderung abgesetzt wird 

Verschachtelte Transaktion: Top-Level-Transaktion öffnet untergeordnete 

Transaktionen, die wieder weitere Anforderungen absetzen können 

T 

T 

Client 

X 

Y 

Z 

Client 

T 

T 11 

X 

T 1 

T 12 

T 

T 21 

2 

Y 

T 22 

M 

N 

P 


Architektur verteilter 

Transaktionssysteme 

T 11 

T 12 

T 1m 

Transaktionsmanager 

T 21 

T 22 

T 2m 


T n1 

T n2 

T nm 


Kommunikationsnetz 

Scheduler 

Scheduler 

Scheduler 

Ressourcenmanager 



Daten 

Daten 

Daten 


Architektur verteilter 

Transaktionssysteme (2) 

• Annahmen 

Homogene Umgebung existiert ⇒ Jeder Knoten besteht aus einem lokalen 

Transaktionsverwaltungssystem 

Jeder Knoten verwaltet einen Teil der Daten 

Jedes Datum befindet sich auf genau einem Knoten (keine Redundanz) 

Eine Transaktion sendet Operationen an lokalen Transaktionsmanager TM 

Falls das Datum lokal nicht verfügbar ist, wird eine Anforderung an den 

TM geschickt, bei dem das Datum sich befindet 

Bei Commit oder Abort muss der TM alle Knoten verständigen, die von der 

Transaktion betroffen waren 

• Fehlerarten 

Knotenfehler: Der Knoten stoppt sofort und führt keinerlei Operationen 

mehr durch ⇒ Der Inhalt des flüchtigen Speichers geht verloren und der 

Knoten muss eine Restart-Operation durchführen 

Netzfehler: Ausfall der Verbindung, Fehler in Kommunikationssoftware, 

Ausfall eines Zwischenknoten, Nachrichtenverlust und -verfälschung 


Koordinator einer Verteilten 

Transaktion 

• Client startet eine verteilte Transaktion durch eine openTransaction 

Anforderung an einen Transaktionsverwalter auf beliebigem Server 

Verwalter öffnet die Transaktion, vergibt systemweit-eindeutige ID 

Verwalter wird zur Koordinator für die gesamte Transaktion ⇒ 

Verantwortung für Annahme/Abbruch der Transaktion 

Teilnehmer = Server, die benötigte Objekte bereitstellen 

openTransaction 

join Teilnehmer 

closeTransaction 

. 

A a.withdraw(4); 

join 

T = openTransaction 

a.withdraw(4); 

c.deposit(4); 

b.withdraw(3); 

d.deposit(3); 

closeTransaction 

T 

Client 

b.withdraw(T, 3); 

Koordinator ist einer der Server, z.B. Filiale X 

join 

Filiale X 

Teilnehmer 

Filiale Y 

Teilnehmer 

C 

D 

Filiale Z 


B 

b.withdraw(3); 

c.deposit(4); 

d.deposit(3); 

Koordinator einer Verteilten 

Transaktion (2) 

• Während der Ausführung der verteilten Transaktion 

Koordinator erstellt Liste mit Verweisen auf alle Teilnehmer 

Teilnehmer notieren den Koordinator 

Hinzufügen von weiteren Teilnehmern mit der Funktion join(Trans-ID, 

Verweis auf neuen Teilnehmer) 

⇒ Koordinator wird über die Neuzugänge informiert 

• Bei Aufruf von closeTransaction besitzt der Koordinator Verweise 

auf alle Teilnehmer 

• Sicherstellung der Atomaritätseigenschaft mit sog. Commit- 

Protokollen 


Koordination durch zentralen 

Planer 

• Zentraler Planer verwaltet alle 

Transaktionen 

2PL-Sperrprotokoll: Globale Sicht auf 

die Sperrsituation, wie im lokalen Fall 

Optimistische Verfahren: Nach 

Abschluss muss jede Transaktion 

ihren r/w-Set an die zentrale 

Validierungsstelle senden 

• Nachteile 

Zentrale darf nicht ausfallen 

Eingeschränkte Skalierbarkeit 

Eingeschränkte Knotenautonomie 

Auch ausschließlich lokale 

Transaktionen müssen sich an den 

zentralen Planer wenden ⇒ unnötiger 

Aufwand 

T 11 

T 12 T 1m T 21 

T 22 T 2m T n1 

T n2 T nm 

TM 

RM 

TM 

Sch. 

RM 

TM 

RM 

Daten Daten Daten 


7.3 Dezentrale Koordination 

• Gewährleistung der Korrektheit eines Transaktionskonzepts ist 

schwierig, da es im verteilten Fall einer Abstimmung der Knoten 

bedarf und Ausfälle nicht ausgeschlossen werden können 

• Anforderung an ein atomares Commit-Protokoll (ACP) für verteilte 

Transaktionen 

1. Alle Knoten, die eine Entscheidung treffen, treffen dieselbe Entscheidung 

2. Ein Knoten kann seine Entscheidung nicht nachträglich ändern 

3. Die Entscheidung, eine Transaktion zu bestätigen, kann nur von allen 

Knoten einstimmig getroffen werden 

4. Falls keine Ausfälle vorliegen und alle Knoten zugestimmt haben, wird 

die Transaktion bestätigt 

5. Nach Behebung von Ausfällen muss eine Entscheidung getroffen werden 

• Einfachste Realisierung: Koordinator fordert alle Teilnehmer solange 

auf, die aktuelle Transaktion zu bestätigen/abbrechen, bis alle 

geantwortet haben (Ein-Phasen-Commit-Protokoll, 1PC) 


Zwei-Phasen-Commit-Protokoll 

(2PC) 

• Probleme bei 1PC: Ein Server kann die Transaktion nicht einseitig 

abbrechen, z.B. wenn Konflikte oder Deadlocks aufgetreten sind 

• Bei 2PC kann jeder Teilnehmer seinen Transaktionsteil abbrechen und 

somit den Abbruch der gesamten Transaktion herbeiführen 

• Grundidee 

Jeder Knoten unterhält eine spezielle Log-Datei mit relevanten Ereignissen 

In der ersten Vorbereitungsphase (Abstimmphase) wird abgestimmt, ob 

die Transaktion festgeschrieben oder abgebrochen wird 

Ist einmal ein Votum abgegeben, so darf das Votum nicht geändert 

werden auch wenn das System ausfällt ⇒ alle relevanten Daten müssen 

im stabilen Speicher zusammen mit dem Status prepared sein 

In der zweiten Phase (Abschlussphase) wird die getroffene Entscheidung 

von jedem Teilnehmer durchgeführt 

• Probleme: Sicherstellung, dass alle Teilnehmer abstimmen und die 

getroffene Entscheidung tatsächlich umsetzen 


Zwei-Phasen-Commit-Protokoll (2) 

• Das 2PC-Protokoll besteht aus vier Schritten 

1. Aufforderung zur Stimmabgabe (vote request) 

2. Stimmabgabe (vote) 

3. Mitteilung über die Entscheidung (decision) 

4. Bestätigung der Entscheidung (acknowledge) 

• Einzelne Operationen 

canCommit?(trans)-> Yes / No: Aufruf vom Koordinator an den Teilnehmer, 

ob er eine Transaktion festschreiben kann. Teilnehmer stimmt ab 

doCommit(trans): Koordinator->Teilnehmer: Festschreiben der Transaktion 

doAbort(trans) : Analog zu doCommit(), jetzt aber mit Abort 

haveCommitted(trans, participant) : Teilnehmer->Koordinator: Transaktion 

festgeschrieben 

getDecision(trans) -> Yes / No: Teilnehmer->Koordinator mit Frage nach 

Entscheidung über Transaktion, für die er mit Yes gestimmt hat aber noch 

keine Antwort kam ⇒ Timeout zur Erkennung von Serverabstürzen 


Ablauf bei 2PC 

• Koordinator fragt alle Teilnehmer canCommit() und sammelt die 

Antworten 

• Koordinator wertet alle Stimmen (auch die eigene) aus 

Falls alle mit Yes gestimmt haben, so wird die Anweisung zum 

Festschreiben doCommit() verteilt 

Andernfalls wird die Transaktion abgebrochen doAbort() 

• Alle Teilnehmer warten auf den Befehl, bestätigen die Ausführung 

• Falls Bestätigung ⇒ haveCommited Nachricht an den Koordinator 

Schritt 

1 

3 

Koordinator 

Status 

Vorbereitet auf 

Festschreiben 

(Wartet auf Stimmen) 

festgeschrieben 

fertig 

canCommit? 

Yes 

doCommit 

haveCommitted 

Teilnehmer 

Schritt Status 

2 Vorbereitet auf 

Festschreiben 

(unsicher) 

4 Festgeschrieben 


Leistung des 2PC 

• Kosten für das 2PC im fehlerfreien Fall sind bei N Teilnehmern 

proportional zu 3N Nachrichten 

Je N Nachrichten für canCommit, Yes/No und doCommit 

haveCommited-Nachrichten werden nicht mitgezählt, da diese für die 

Organisation der Koordinatoraktivitäten notwendig sind 

• Ausfall- und Fehleranfälligkeit 

2PC kann mehrere Server-/Kommunikationsfehler tolerieren und wird 

garantiert irgendwann abgeschlossen. Die Vorgabe einer Zeitgrenze ist 

allerdings nicht möglich 

Die Verzögerung bei der Ausführung von 2PC kann dazu führen, dass 

einige Teilnehmer in einen unsicheren (ungewissen) Zustand geraten 

Besonders kompliziert, wenn der Koordinator ausgefallen ist und auf 

keine getDecision() Anforderung reagiert 

⇒ Drei-Phasen-Commit-Protokolle (3PC) zur Reduktion der 

Verzögerungen 


Drei-Phasen-Commit-Protokoll (3PC) 

• 3PC-Protokoll: nicht-blockierende Verbesserung des 2PC-Protokolls 

• Voraussetzung 

• Idee 

Höchstens K

Ablauf bei 3PC (2) 

Schritt 

1 

3 

Koordinator 

Status 


Festschreiben 

(Wartet auf Stimmen) 

Logging preCommit 

fertig 

5 Logging preCommit 

fertig 

canCommit? 

Yes 

preCommit 

preCommit ack 

Commit 

acknowledge 

Schritt 

2 

4 

Teilnehmer 

Status 


Festschreiben 

(ungewiss) 

Logging preCommit 

6 Logging Commit 

Sperrfreigabe 

• Ein Koordinatorausfall wird durch Time-Outs erkannt 

Alle aktiven Teilnehmer wählen einen neuen Koordinator 

Damit der neue Koordinator die commit-Behandlung fortführen kann, 

wird ein Terminierungsprotokoll gestartet 


3PC-Terminierungsprotokoll 

• Der neue Koordinator sammelt die Zustandsinformation aller 

Teilnehmer und verfährt nach den folgenden Regeln 

R1: Falls ein Knoten im Zustand finished oder aborted ist, so lautet die 

Entscheidung abort 

R2: Falls irgendein Knoten im Zustand commit ist, lautet die Entscheidung 

commit 

R3: Sind alle Knoten im Zustand uncertain, lautet die Entscheidung abort 

R4: Sind einige Knoten im Zustand preCommit, aber keiner im Zustand 

commit, sendet er preCommit an alle Knoten 

• Nach Eingang der Quittungen (Ack) kann commit entschieden 

werden 

• Teilnehmer, die ihren Zustand nicht melden, werden ignoriert 


Beispiel zu 3PC 

• Alle Teilnehmer haben mit Yes gestimmt 

• Der Koordinator beginnt, preCommit zu verschicken, fällt aber aus, 

so dass nur ein Teil der Knoten die Nachricht erhält 

• Einige Knoten sind im Zustand preCommit, die anderen im Zustand 

uncertain 

• Angenommen, die Knoten im Zustand preCommit fallen ebenfalls 

aus 

Die restlichen Knoten starten das Terminierungsprotokoll 

Der (gewählte) neue Koordinator sammelt die Zustände der 

operationalen Knoten (alle uncertain) und beschließt gemäß Regel 

R3 abort 

Ausgefallene Knoten starten nach dem Restart das 

Terminierungsprotokoll und erfahren die Entscheidung abort 

Obwohl sie bereits preCommit erhalten hatten, entscheiden sie Abort 


• Ziele der Replikation 

7.4 Replikation 

Steigerung der Verfügbarkeit 

Daten werden auf k Knoten kopiert ⇒ Daten bleiben auch beim 

Ausfall von k-1 Knoten erhalten 

Leistungssteigerung 

Parallele Ausführung der Lesezugriffe für die gleichen Daten 

Verringerung der Anzahl notwendiger Kommunikationsvorgänge 

durch Unterstützung der Datenlokalität 

• Beispiel: Replizierte Kontodaten 

A 

R1 

(Paderborn) 

R3 

(Frankfurt) 

A 

B 

B 

R2 

(Kassel) 


Probleme mit replizierten 

Daten 

• Verwaltung replizierter Daten erhöht den Speicherbedarf und die 

Kommunikationsleistung bei Schreibzugriffen 

• Hoher Implementierungsaufwand, da ein verteiltes DBS die 

Existenz der replizierten Daten für den Benutzer transparent sein 

soll 

Automatische, transparente Aktualisierung aller Repliken, sobald ein 

Datum verändert wird 

Aufrechterhaltung der Datenkonsistenz unter Berücksichtigung aller 

Repliken 

• Anforderungen für Synchronisationsprotokolle, die das 

Korrektheitskriterium der 1-Kopie-Serializierbarkeit unterstützen 

Es werden nur solche Schedules zugelassen, die zu serialisierbaren 

Schedules auf einer nicht-redundanten Datenbank äquivalent sind 

Insbesondere muss dies auch für mögliche Fehlerfälle gelten 


Ansätze 

• Drei wichtigste Verfahrensklassen für die Aktualisierung und 

Synchronisation auf replizierten Datenbanken 

Write-All-Ansatz: Synchrone Aktualisierung aller replizierten Kopien 

Primary-Copy-Verfahren: Sofortige Aktualisierung einer Masterkopie, 

die Veränderungen werden mit etwas Verspätung weitergegeben 

Voting-Verfahren: Jede der Repliken bekommt eine oder mehrere 

Stimmen zugeordnet. Bei jedem Schreib- oder Lesezugriff muss die 

Mehrheit dieser Stimmen durch Sperren der entsprechenden Objekte 

gewonnen werden 


Varianten des Write-All- 

Ansatzes 

• Bekanntestes Variante: Write-All-Read-Any oder auch Read-Once- 

Write-All (ROWA) Strategie genannt 

Synchrone Änderung aller Replikate vor Abschluss der 

Änderungstransaktion 

⇒ Jedes Replikat ist auf dem aktuellen Stand und kann für die 

Lesezugriffe verwendet werden 

⇒ Auswahl beim Lesen erfolgt basierend auf minimaler Kommunikation 

oder Auslastung der einzelnen Knoten 

⇒ Einzelne Knotenausfälle können problemlos kompensiert werden 

• Beispiel zu ROWA-Strategie (siehe Skizze auf Folie 7-33) 

Alle Lesezugriffe der Zentrale (R2) werden auf replizierten Daten und 

ohne Verzögerung ausgeführt 

Zugriff auf alle Daten trotz Ausfalls von einem der Rechner möglich 

Allerdings erfordert die Aktualisierung der Kontodaten das Sperren 

und die synchrone Aktualisierung beider Kopien 


Nachteile der ROWA-Strategie 

• Änderung der Sperrprotokolle erforderlich 

Vor dem Zugriff muss eine Schreibsperre auf allen replizierten 

Datensätzen – auf unterschiedlichen Knoten – erworben werden 

Alle Knoten müssen an dem Commit-Protokoll beteiligt werden 

• Entscheidender Nachteil: Ausfallsicherheit schlechter als bei nichtredundanten 

Datenbanken 

Fällt nur einer der replizierten Knoten aus, so ist die gesamte 

Datenbank nicht mehr funktionsfähig, da alle Knoten mit Replikaten 

berücksichtigt werden müssen 

• Abgeschwächte Forderung Write-All-Available-Read-Any 

Die replizierten Datensätze werden nur auf den verfügbaren Rechnern 

aktualisiert 

Bei ausgefallenen Rechnern werden alle Aktualisierungen protokolliert 

und beim nächsten Start nachgeholt 

Probleme entstehen, wenn sich die Knoten in unterschiedlichen 

Netzwerkpartitionen befinden 


Primary-Copy-Verfahren 

• Ziel 

Effiziente Bearbeitung von Änderungen, indem nur ein Replikat – so 

genannte Primärkopie – sofort aktualisiert wird 

Die anderen Kopien werden asynchron vom Primary-Copy-Rechner aus 

und sobald möglich (as soon as possible) aktualisiert 

• Effizienzvorteil 

Aktualisierungsnachrichten werden gebündelt und zusammen zum 

Zielknoten übertragen 

Primärkopien werden auf unterschiedlichen Knoten gespeichert, um 

Engpässe zu vermeiden 

• Nachteil: Verzögerte Anpassung der Replikate 

• Realisierung des Primary-Copy-Protokolls 

Anforderung von Schreibsperren für alle Replikate (wie bei ROWA), 

allerdings wird nur die primäre Kopie synchron aktualisiert 

Die Sperre geht in Besitz des Primary-Copy-Rechners über, der dann 

nach und nach die Replikate aktualisiert und erst nach Abschluss alle 

Sperren wieder frei gibt 


Alternativen zum Primary-Copy- 

Protokoll 

• Schreibsperren werden nur noch zentral auf der Primärkopie 

angefordert ⇒ Anzahl von Sperrkonflikte wird reduziert 

• Behandlung der Lesezugriffe wegen eventuell veralteter, 

inkonsistenter Daten erforderlich 

Lesezugriff auf Primärkopie: Alle Lesetransaktion referenzieren nur die 

primäre Kopie ⇒ keine Lokalität/Parallelität, lediglich Ausfallsicherheit 

Lesezugriff auf lokale Kopien, Sperranforderung beim Primary-Copy- 

Rechner: Nur die Sperren werden beim primären Rechner positioniert, 

die Zugriffe selbst können auf einem anderen Rechner erfolgen 

Beim Sperren wird überprüft, ob das Datum aktualisiert werden 

muss und ggf. die Aktualisierung bevorzugt behandelt 

Entlastung des Primary-Copy-Rechners 

Lokale Abwicklung von Lesezugriffen: Inkonsistenzen – in praktischen 

Anwendungen von wenigen Sekunden – werden in Kauf genommen 

und auf die Daten ohne vorherige Überprüfung der Primärkopie 

zugegriffen ⇒ Anwendung nur in speziellen Fällen tolerierbar 


• Annahmen 

Beispiel zu Primary-Copy- 

Verfahren 

Die Primärkopien der Kontodatensätze liegen auf den Filialrechnern (R1 

hält Primärkopie von A und R3 von B) 

Sämtliche Lese- und Schreibzugriffe können lokal durchgeführt werden, 

Kommunikation nur bei Kontenzugriffe der Zentrale (R2), d.h. Sperren 

und Aktualisieren der Primärkopien 

Strategie 1 verlangt Sperren und Lesen der Primärkopie ⇒ 

Nachrichten für Objektzugriff und Commit 

Strategie 2 erfordert Nachrichten für Sperranforderung und –freigabe 

Strategie 3 ist z.B. für globale Auswertungen ausreichend 

• Was passiert, wenn der Knoten mit der Primärkopie ausfällt? 

Primärkopie nicht erreichbar ⇒ keine Transaktion kann ausgeführt 

werden, wenn sie diese Daten benötigt 

Ausweg: Wahlalgorithmen zur Bestimmung einer neuen Primärkopie. 

Vorraussetzung ist allerdings, dass die Repliken auf dem aktuellen Stand 

sind bzw. gebracht werden können 


Voting-Verfahren 

• Vor jedem Zugriff auf ein repliziertes Datum müssen ausreichend 

viele Stimmen (votes) gesammelt werden 

• Mehrheits-Votum 

Die Transaktion muss die Mehrheit der Repliken des benötigten 

Objekts sperren (Sperre = Stimme) 

Beim Lesen wird analog eine Mehrheit der Repliken mit Lesesperren 

belegt und ein Element referenziert 

Somit ist es sichergestellt, dass das Objekt nicht von einer anderen 

Transaktion zwischenzeitlich verändert werden kann 

Mindestens ein der Replikate befindet sich auf dem aktuellen Stand 

⇒ Aktualität der Replikate wird durch einen Änderungszähler festgestellt 

• Vorteil: Objekte auch bei mehreren Knotenausfällen referenzierbar 

• Nachteil: Jede Zugriff verlangt mehrere Nachrichten zur 

Sicherstellung der Mehrheit 


Gewichtetes Voting 

(Quorum Consensus) 

• Jedem Replikat eines Objektes wird ein bestimmtes Gewicht 

(Stimmenanzahl) zugeordnet 

• Zum Lesen bzw. Schreiben eines Datums wird eine bestimmte Anzahl 

von Stimmen (Lese-Quorum bzw. Schreib-Quorum) gesammelt 

• Es seien insgesamt v Stimmen möglich und r/w Lese/Schreib-Quorum 

Bedingung w>v/2 garantiert, dass kein Objekt gleichzeitig von mehr als 1 

Transaktion geändert wird 

Bedingung r+w>v verhindert, dass ein Objekt gleichzeitig gelesen und 

geschrieben wird. Ferner wird sichergestellt, dass mindestens ein Objekt 

zum letzten Schreib-Quorum gehörte 

• Durch die Gewichte können sowohl die Kosten für Schreib/Lese- 

Zugriffe als auch die Verfügbarkeit bestimmt werden 

Je kleiner r bzw. w, desto schneller sind die Lese- bzw. Schreibzugriffe 

Erhöhte Verfügbarkeit, da einige Rechner ausfallen dürfen 

Lesebevorzugung geht auf Kosten der Schreiboperationen und umgekehrt 


Beispiel zu Quorum-Verfahren 

• Objekt A sei an vier Rechnern R1 bis R4 repliziert 

• Stimmenverteilung , d.h. R1 hat 2 Stimmen 

• Wählt man r = 3 und w = 3, so sind 2 oder 3 Rechner bei jeder 

Transaktion involviert 

Durch Bevorzugung von R1 ist ein schnellerer Zugriff auf die Daten 

von R1 gewährleistet 

Zugriff ist auch nach Ausfall von jedem der Rechner möglich. Wenn R1 

intakt bleibt, dürfen auch zwei Rechner ausfallen 

• Lesezugriffe werden gegenüber von Schreibzugriffen bevorzugt, 

wenn z.B. r=2 und w=4 gilt 

Lesezugriffe können auf R1 lokal ausgeführt werden 

Bei Schreibzugriffen sind allerdings mindestens 3 Rechner beteiligt. 

Nach Ausfall von R1 ist das Objekt nicht mehr modifizierbar 


Vor- und Nachteile des 

Quorum-Verfahrens 

• Durch spezielle Parameterwahl lassen sich das Mehrheits- und 

das ROWA-Verfahren sowie eines der Primary-Copy-Protokolle 

nachbilden 

Mehrheitsverfahren: Jedes Replikat hat das gleiche Gewicht (1 

Stimme) 

ROWA-Verfahren: Jedes Replikat hat eine Stimme. Ferner ist r=1 und 

w=v=Anzahl Replikate 

Primary-Copy: Primärkopie bekommt 1 Stimme, alle anderen Replikate 

bekommen keine Stimme und r=w=1 ⇒ Lesezugriffe müssen an 

Primärkopie gerichtet werden, Repliken ohne Stimme werden ohne 

Konsistenzzusicherung genutzt 

• Hauptnachteil der Voting-Verfahren ist die geeignete Wahl der 

Parameter, insbesondere wenn diese ohne oder mit geringer 

Beteiligung des Systemverwalters erfolgen sollen 


Schnappschuss-Replikation 

• Replikationsaufwand erhöht sich deutlich, wenn die Komponenten 

geographisch weit verteilt sind und die Aktualisierungskosten 

aufgrund der langsamen Netze noch höher sind 

• Verringerung der Aktualisierungskosten durch Einführung von 

Schnappschüssen (snapshots) 

• Definition Schnappschuss 

Entspricht materialisierten durch eine DB-Anfrage spezifizierten Sicht 

Ergebnis der Anfrage wird als eigenständiges DB-Objekt unter einem 

benutzerspezifizierten Namen abgelegt 

Zugriff auf einen Schnappschuss erfolgt mit der jeweiligen DB- 

Anfragesprache, nur Lesezugriffe zulässig 

• Beispieldefinition 

CREATE SNAPSHOT underflow AS 

SELECT KNR, KTONR, KTOSTAND 

FROM KONTO WHERE KTOSTAND

• Im Beispiel 

Eigenschaften des 

Schnappschusses 

Schnappschuss entspricht einer Kopie der Teilmenge aller überzogenen 

Konten 

Schnappschuss wird in explizit angegebenen Abschnitten aktualisiert 

(REFRESH – Angabe) 

• Vorteile 

Durch Bindung an DB-Sprachen können beliebige Informationen (auch 

aggregierte Informationen, Verknüpfungen, … ) zusammengefasst werden 

Entlastung des Primary-Copy-Rechners, da alle Zugriffe lokal und ohne 

Kommunikation erfolgen 

Kein Synchronisationsproblem, da lediglich Leseoperationen zulässig 

• Nachteile 

Qualität geringer als bei „echter“ Replikation ⇒ Daten im kontrollierten 

Maß veraltet 

Veraltete Daten reduzieren den Wert des Schnappschusses im Fehlerfall 


Anwendungen für 

Schnappschuss-Replikation 

• Die schwache Form der Replikation wird z.B. angewendet bei 

Ersatzteillisten bei KFZ-Betrieben 

Buchkataloge in Bibliotheken 

Telefonbücher 

Andere Verzeichnisse, auf die vorwiegend lesend zugegriffen wird 

⇒ Reduzierter Kommunikationsaufwand ist an dieser Stelle wichtiger als 

die 100% Aktualität (auf Sekunde/Minute/Stunde genau) 

• Varianten 

Quasi-Kopien: Verwendung von anwendungsbezogenem Wissen, um 

die Aktualisierungen bei bedeutender Veränderung weiterzugeben

7. Verteilte Transaktionen 7.1 Verteilte Datenbanksysteme

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?