philo

Verteilte Datenbanken
Szenario:
 Geographisch verteilte Organisationsform einer Bank
mit ihren Filialen
 Filialen sollen Daten lokaler Kunden lokal bearbeiten
können
 Zentrale soll Zugriff auf alle Daten haben (z.B. für
Kontostandsüberprüfung bei Kreditvergabe)
Terminologie
 Sammlung von Informationseinheiten (Knoten,
Stationen), verteilt auf mehreren Rechnern, verbunden
mittels Kommunikationsnetz  nach Ceri & Pelagatti
(1984)
 Kooperation zwischen autonom arbeitenden Stationen,
zur Durchführung einer globalen Aufgabe
2
Kommunikationsmedien
 LAN: local area network, z.B. Ethernet, Token-Ring
oder FDDI-Netz
 WAN: wide area network, z.B. das Internet
 Point-to-Point: z.B. Verbindungen über ISDN oder
analoge Modem-Verbindungen
 Hier: Kommunikationsmedium für verteiltes DBMS
transparent. Jede Station kann mit jeder
kommunizieren. Dabei werden u.U. signifikant
unterschiedliche Kosten (Zeiten) beobachtet.
3
Verteiltes Datenbanksystem
Station S1
Station S2
Kommunikationsnetz
Station S3
4
Client-Server-Architektur  VDBMS
Client C1
Client C2
Kommunikationsnetz
Server
5
Aufbau und Entwurf eines
verteilten Datenbanksystems
globales Schema
Ausganspunkt
Fragmentierungsschema
Zerlegung von Rel.s
in (disjunkte) Fragmente
Allokation von Rel.s
zu Stationen
Zuordnungsschema
lokales
Schema
...
lokales
Schema
lokales
DBMS
...
lokales
DBMS
lokale
DB
...
lokale
DB
Station S1
...
Station Sn
6
Fragmentierung und Allokation
einer Relation
 Fragmentierung von Relationen:
Fragmente enthalten Daten mit gleichem
Zugriffsverhalten, um Kommunikationskosten zu
minimieren ( Informationen über den zu erwartenden
Workload sind notwendig)
 Allokation:
Fragmente werden den VDBMS-Stationen zugeordnet:
Redundanzfreie Allokation: jedes Fragment ist
genau einer Station zugeordnet
Mit Replikation: Ein Fragment wird redundant auf
mehreren Stationen verwaltet (N:M-Zuordnung, s.
nächste Folie).
7
Fragmentierung
R
R1
Allokation
(Zuordnung)
R11
Station S1
R12
R2
R21
R3
Station S2
R32
R33
Station S3
8
Fragmentierung
 Horizontale Fragmentierung: Zerlegung der Relation
in disjunkte Tupelmengen
 Vertikale Fragmentierung: Zusammenfassung von
Attributen mit gleichem Zugriffsmuster
Extreme vertikale Fragmentierung: alle Relationen binär
(zweispaltig)  Vorlesung im WS 06/07
 Kombinierte Fragmentierung: Anwendung
horizontaler und vertikaler Fragmentierung auf dieselbe
Relation
9
Anforderungen an das
Fragmentierungsschema
 Rekonstruierbarkeit
Jede fragmentierte Relation läßt sich ohne Informationsverlust
aus den Fragmenten wiederherstellen.
 Vollständigkeit
Jedes Datum (Tupel, Attribut) ist einem Fragment zugeordnet.
(Voraussetzung für Rekonstruierbarkeit.)
 Disjunktheit
Ein Datum ist nicht mehreren Fragmenten zugeordnet.
10
Beispielrelation "Professoren"
Professoren
PersNr
Name
Rang
Raum
Fakultät
Gehalt
Steuerklasse
2125
Sokrates
C4
226
Philosophie
85000
1
2126
Russel
C4
232
Philosophie
80000
3
2127
Kopernikus
C3
310
Physik
65000
5
2133
Popper
C3
52
Philosophie
68000
1
2134
Augustinus
C3
309
Theologie
55000
5
2136
Curie
C4
36
Physik
95000
3
2137
Kant
C4
7
Philosophie
98000
1
11
Horizontale Fragmentierung
Abstrakte Darstellung:
R
R1
R2
R3
Für zwei Prädikate p1 und p2 ergeben sich 4 Fragmente:
R1 := p1  p2(R)
R2 := p1  p2(R)
R3 := p1  p2 (R)
R4 := p1  p2 (R)
n Zerlegungsprädikate p1,...,pn ergeben 2n Fragmente
12
Sinnvolle Gruppierung der Professoren nach Fakultät:
3 Zerlegungsprädikate:
p1  (Fakultät = 'Theologie')
p2  (Fakultät = 'Physik')
p3  (Fakultät = 'Philosophie')
TheolProfs´ := σp1p2  p3(Professoren) = σp1(Professoren)
PhysikProfs´ := σp1p2  p3(Professoren) = σp2(Professoren)
PhiloProfs´
:= σp1p2 p3(Professoren) = σp3(Professoren)
AndereProfs´ := σp1p2  p3(Professoren) = 
13
Abgeleitete horizontale
Fragmentierung
Die Fragmentierung verschiedener Relationen ist nicht beliebig
und hat Einfluß auf die Anfragebearbeitung.
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)
Für Anfragebearbeitung u.U. schlechte Zerlegung
14
SELECT Titel, Name
FROM Vorlesungen, Professoren
WHERE gelesenVon = PersNr;
resultiert in:
Titel, Name(
(TheolProfs´
(TheolProfs´
(PhiloProfs´
2SWSVorls) 
3SWSVorls)  … 
4SWSVorls) )
Join-Graph zu dieser Anfrage:
TheolProfs´
2SWSVorls
PhysikProfs´
3SWSVorls
PhiloProfs´
4SWSVorls
15
Einschub: Join-Arten
• natürlicher Join
A
a1
a2
L
B
b1
b2
C
c1
c2
C
c1
c3
R
D
d1
d2
E
e1
e2
=
A
a1
Resultat
B
C
D
b1 c1 d1
E
e1
16
Einschub: Join-Arten (Semi-Joins)
• Semi-Join von R mit L (Right Semi-Join)
A
a1
a2
L
B
b1
b2
C
c1
c2
C
c1
c3
R
D
d1
d2
E
e1
e2
=
Resultat
C D
E
c1 d1 e1
• Semi-Join von L mit R (Left Semi-Join)
A
a1
a2
L
B
b1
b2
C
c1
c2
C
c1
c3
R
D
d1
d2
E
e1
e2
=
Resultat
A
B
C
a1 b1 c1
17
Lösung: abgeleitete Fragmentierung
TheolProfs´
TheolVorls
PhysikProfs´
PhysikVorls
PhiloProfs´
PhiloVorls
TheolVorls := Vorlesungen
gelesenVon=PersNr
TheolProfs ´
PhysikVorls := Vorlesungen
gelesenVon=PersNr
PhysikProfs ´
PhiloVorls := Vorlesungen
gelesenVon=PersNr
PhiloProfs ´
Titel, Name(
(TheolProfs´
p
TheolVorls) 
(PhysikProfs´ p PhysikVorls) 
(PhiloProfs´ p PhiloVorls) )
mit p
 (PersNr = gelesenVon)
18
Vertikale Fragmentierung
Abstrakte: Vertikale Fragmentierung einer Relation R mit
Primärschlüssel :
R
R1
κ
R2
19
Vertikale Fragmentierung
Beliebige vertikale Fragmentierung gewährleistet keine
Rekonstruierbarkeit.
Mögliche Ansätze, um Rekonstruierbarkeit zu garantieren:
 Jedes Fragment enthält den Primärschlüssel der
Originalrelation. Aber: Verletzung der Disjunktheit.
 Jedem Tupel der Originalrelation wird ein eindeutiges
Surrogat (= künstlich erzeugter Tupelidentifikator)
zugeordnet, welches in jedes vertikale Fragment des
Tupels mit aufgenommen wird.
20
Vertikale Fragmentierung
(Beispiel)
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
21
Kombinierte Fragmentierung
a) Horizontale Fragmentierung nach vertikaler Fragmentierung:
R
R21
R22
R23
R1
R2

b) Vertikale Fragmentierung nach horizontaler Fragmentierung:
R
R1
R2
R3
R31

R32
22
Rekonstruktion nach kombinierter
Fragmentierung
Fall a)
R = R1
R1. = R2. 
(R21  R22  R23)
Fall b)
R = R1  R2  (R31
R31.  = R32. 
R32)
23
Baumdarstellung der
Fragmentierungen (Beispiel)
Professoren
v
Profs
abgeleitete Fragmentierung
ProfVerw
h
PhysikProfs TheolProfs
Vorlesungen
h
PhiloProfs
PhysikVorls TheolVorls
PhiloVorls
24
Allokation (Beispiel)
 Ein Fragment kann prinzipiell mehreren Stationen
zugeordnet werden (Replikation).
 Allokation für unser Beispiel jedoch ohne Replikation
 redundanzfreie Zuordnung.
Station
Bemerkung
zugeordnete Fragmente
SVerw Verwaltungsrechner
{ProfVerw}
SPhysik
Dekanat Physik {PhysikVorls, PhysikProfs}
SPhilo Dekanat Philosophie {PhiloVorls, PhiloProfs}
STheol Dekanat Theologie {TheolVorls, TheolProfs}
25
Transparenz in verteilten
Datenbanken
 Transparenz:
Grad der Unabhängigkeit den ein VDBMS dem
Benutzer/Client-Programmen beim Zugriff auf
verteilte Daten vermittelt.
 Transparenzgrade (abnehmende Transparenz):
 Fragmentierungstransparenz
Alle Aspekte der Verteilung verborgen, Nutzer arbeiten
mit globalem Schema
 Allokationstransparenz
Fragmentierung der Relationen sichtbar, Verteilung auf
Stationen verborgen
 Lokale Schema-Transparenz
Operationen adressieren Fragmente und Stationen explizit
26
Fragmentierungstransparenz
Beispiel (Fragmente/Stationen nicht explizit adressiert):
SELECT Titel, Name
FROM Vorlesungen, Professoren
WHERE gelesenVon = PersNr;
Beispiel für eine Änderungsoperation:
UPDATE Professoren
SET
Fakultät = "Theologie"
WHERE Name = "Sokrates";
Welche Operation(en) muß das VDBMS intern ausführen, um
die UPDATE-Anweisung zu realisieren?
27
Fragmentierungstransparenz
(cont.)
1. Im betroffenen Fragment: Ändern des Attributwertes von
Fakultät.
2. Transferieren des Sokrates-Tupels aus Fragment PhiloProfs
in das Fragment TheolProfs (= Löschen aus PhiloProfs,
Einfügen in TheolProfs).
3. Ändern der abgeleiteten Fragmentierung von Vorlesungen
(= Einfügen der von Sokrates gehaltenen Vorlesungen in
TheolVorls, Löschen der von ihm gehaltenen Vorlesungen
aus PhiloVorls).
28
Allokationstransparenz
Benutzer müssen Fragmentierung kennen, aber nicht die
Station(en) eines Fragmentes:
Beispiel:
SELECT Gehalt
FROM ProfVerw
WHERE Name = "Sokrates";
Fragmentname!
29
Allokationstransparenz (cont.)
Unter Umständen müssen Originalrelationen erst
rekonstruiert werden.
Beispiel:
Verwaltung möchte wissen, wieviel die C4-Professoren der
Theologie insgesamt verdienen?
Da Fragmentierungstransparenz fehlt, muß die Anfrage
folgendermaßen formuliert werden:
SELECT SUM (Gehalt)
FROM ProfVerw, TheolProfs
WHERE ProfVerw.PersNr = TheolProfs.PersNr AND Rang = "C4";
30
Lokale Schema-Transparenz
Der Benutzer muss jetzt auch noch die Station kennen, auf
der ein Fragment liegt.
Beispiel:
SELECT Name
FROM TheolProfs AT STheol
WHERE Rang = "C3";
31
Lokale Schema-Transparenz
(cont.)
Ist hier überhaupt noch Transparenz gegeben?
Lokale Schema-Transparenz setzt voraus, dass alle Rechner
dasselbe Datenmodell und dieselbe Anfragesprache
verwenden.
 Vorherige Anfrage kann somit analog auch an Station
SPhilo ausgeführt werden.
Dies ist nicht möglich bei Kopplung unterschiedlicher DBMS.
Verwendung grundsätzlich verschiedener Datenmodelle auf
lokalen DBMS nennt man Multi-Database-Systems. Oft
unumgänglich in realen (unternehmensweiten)
Applikationen.
32
Anfrageübersetzung und
Anfrageoptimierung
 Annahme: Es liegt Fragmentierungstransparenz vor
  Anfragen werden gegen das globale Schema/die
globalen Relationen formuliert
 Aufgabe des Anfrageübersetzers: Generierung eines
Anfrageauswertungsplans auf den Fragmenten
 Aufgabe des Anfrageoptimierers: Generierung eines
möglichst effizienten Auswertungsplanes
 abhängig von der Allokation der Fragmente auf
den verschiedenen Stationen des Rechnernetzes
33
Anfragebearbeitung bei
horizontaler Fragmentierung
Übersetzung einer SQL-Anfrage auf dem globalen
Schema in eine äquivalente Anfrage auf den Fragmenten
benötigt 2 Schritte:
1. Rekonstruktion aller in der Anfrage
vorkommenden globalen Relationen aus den
Fragmenten, in die sie während der
Fragmentierungsphase zerlegt wurden. Hierfür
erhält man einen algebraischen Ausdruck.
2. Kombination des Rekonstruktionsausdrucks mit
dem algebraischen Anfrageausdruck, der sich aus
der Übersetzung der SQL-Anfrage ergibt.
34
Beispiel
SELECT Titel
FROM Vorlesungen, Profs
WHERE gelesenVon = PersNr AND Rang = "C4";
Der entstandene algebraische Ausdruck heißt kanonische Form
der Anfrage:
ΠTitel
σRang="C4"
gelesenVon=PersNr


TheolVorls PhiloVorls PhysikVorls TheolProfs PhiloProfs PhysikProfs
35
Algebraische Äquivalenzen
Für eine effizientere Abarbeitung der Anfrage benutzt der
Anfrageoptimierer die folgende Eigenschaft:
(R1  R2)
(R1
p
p
(S1  S2) =
S1)  (R1
p
S2)  (R2
p
S1)  (R2
p
S2)
Die Verallgemeinerung auf n horizontale Fragmente R1,...,Rn
von R und m Fragmente S1,...,Sm von S ergibt:
(R1  ...  Rn)
p
(S1  ...  Sm) =

1in 1jm
(Ri
p
Sj)
Falls gilt:
Si = S p Ri mit S = Si  ...  Sn ,
dann tragen die Joins Ri p Sj für i  j nichts Neues zum
Join-Ergebnis bei.
(Achtung: Fehler im Buch!)
36
Algebraische Äquivalenzen (Forts.)
Für eine derartig abgeleitete horizontale Fragmentierung von S
gilt somit:
(R1  ...  Rn) p (S1  ...  Sm) =
(R1 p S1)  (R2 p S2)  ...  (Rn p Sn)
37
Algebraische Äquivalenzen (Forts.)
Für eine derartig abgeleitete horizontale Fragmentierung von S
gilt somit:
(R1  ...  Rn) p (S1  ...  Sm) =
(R1 p S1)  (R2 p S2)  ...  (Rn p Sn)
Noch einmal das konkrete Beispiel:
(TheolVorls  PhysikVorls 
(TheolProfs  PhysikProfs 
PhiloVorls)
PhiloProfs)
Um Selektionen und Projektionen über  hinweg "nach unten zu
drücken" (push down) benötigt man folgende Äquivalenzen:
σp(R1  R2) = σp(R1)  σp(R2)
L(R1  R2) =  L(R1)   L(R2)
38
Optimale Form der Anfrage
Die Anwendung dieser algebraischen Regeln generiert
den folgenden Auswertungsplan:

ΠTitel
ΠTitel
gelesenVon=PersNr
gelesenVon=PersNr
σRang=‚C4‘
TheolVorls
TheolProfs
ΠTitel
σRang=‚C4‘
PhysikVorls
PhysikProfs
gelesenVon=PersNr
σRang=‚C4‘
PhiloVorls PhiloProfs
Auswertungen können lokal auf den Stationen STheol, SPhysik und SPhilo
ausgeführt werden  Stationen können parallel abarbeiten und lokales
Ergebnis voneinander unabhängig an die Station, die die abschliessende
Vereinigung durchführt, übermitteln.
39
Anfragebearbeitung bei
vertikaler Fragmentierung
Kanonischer Auswertungsplan:
Beispiel:
SELECT Name, Gehalt
FROM Professoren
WHERE Gehalt > 80000;
ΠName, Gehalt
σGehalt>80000

TheolProfs
PhysikProfs PhiloProfs
ProfVerw
40
Optimierung bei vertikaler
Fragmentierung
Für unser Beispiel gilt:
Alle notwendigen Informationen sind in ProfVerw enthalten 
Der Teil mit Vereinigung und Join kann "abgeschnitten" werden.
Das ergibt den folgenden
ΠName, Gehalt
optimierten Auswertungsplan:
σGehalt>80000
ProfVerw
Beispiel für eine schlecht zu optimierende Anfrage:
(Attribut Rang fehlt in ProfVerw)
SELECT Name, Gehalt, Rang
FROM Professoren
WHERE Gehalt > 80000; 41
Der natürliche Verbund zweier
Relationen R und S
R
S
A
B
C
C
D
E
a1
a2
b1
b2
c1
c2
c1
c3
d1
d2
e1
e2
a3
b3
c1
c4
d3
e3
a4
b4
c2
c5
d4
e4
a5
b5
c3
c7
d5
e5
a6
b6
c2
c8
d6
e6
a7
b7
c6
c5
d7
e7
R
A
=
a1
a3
B
b1
b3
a5
b5
S
C
c1
c1
D
d1
d1
E
e1
e1
c3
d2
e2
42
Join-Auswertung in VDBMS
 Spielt eine kritischere Rolle als in zentralisierten Datenbanken
 Problem: Argumente eines Joins zweier Relationen können auf
unterschiedlichen Stationen des VDBMS liegen
 Zwei Möglichkeiten zur Realisierung:
Join-Auswertung mit und ohne Filterung
43
Join-Auswertung in VDBMS
Betrachtung des allgemeinsten Falles:
 Äußere Argumentrelation R ist auf Station StR gespeichert
 Innere Argumentrelation S ist der Station StS zugeordnet
 Ergebnis der Joinberechnung wird auf einer dritten
Station StResult benötigt
44
Join-Auswertung ohne Filterung
Ziel: Einsatz etablierter Join-Verfahren aus zentralisierten DBMS:
 Nested-Loops
 Transfer einer Argumentrelation
 Transfer beider Argumentrelationen
45
Nested Loops
Iteration durch die äußere Relation R mittels Laufvariable r und
Anforderung (über Kommunikationsnetz bei StS)
der zu jedem Tupel r passenden Tupel s  S mit r.C = s.C
Diese Vorgehensweise benötigt pro Tupel aus R eine
Anforderung und eine passende Tupelmenge aus S (welche bei
vielen Anforderungen leer sein könnte)
 es werden 2 R Nachrichten benötigt
Hohes Nachrichtenaufkommen, das sich nur in LANs
verantworten läßt.
46
Der natürliche Verbund zweier
Relationen R und S
R
S
A
B
C
C
D
E
a1
a2
b1
b2
c1
c2
c1
c3
d1
d2
e1
e2
a3
b3
c1
c4
d3
e3
a4
b4
c2
c5
d4
e4
a5
b5
c3
c7
d5
e5
a6
b6
c2
c8
d6
e6
a7
b7
c6
c5
d7
e7
47
Alternative 1:
Transfer einer Argumentrelation
1.
Vollständiger Transfer einer Argumentrelation (z.B. R)
zum Knoten der anderen Argumentrelation
2.
Ausnutzung eines möglicherweise auf S.C
existierenden Indexes auf Station StS
48
Alternative 2: Transfer beider
Argumentrelationen
1.
Transfer beider Argumentrelationen zum Rechner
2.
Berechnung des Ergebnisses auf dem Knoten StResult
mittels
a) Merge-Join (bei vorliegender Sortierung)
oder
b) Hash-Join (bei fehlender Sortierung)
StResult
 evtl. Verlust der vorliegenden Indexe (auf StR
und/oder StS) für die Join- Berechnung
 aber kein Verlust der Sortierung der
Argumentrelation(en)
49
Join-Auswertung mit Filterung
Bisher: Transfer potentiell großer Datenmengen, auch falls
Resultat der Join-Operation selbst sehr klein ist (hohe Selektivität).
Daher:
 Verwendung des Semi-Join-Operators zur Vorfilterung
 Schlüsselidee: transferiere nur die Tupel, die passenden
tatsächlich einen Join-Partner finden werden
 Benutzung der folgenden algebraischen Eigenschaften:
R
R
S=R
(R S)
S = ΠC(R)
S
(Join-Attribut in Relation R ist C)
50
Join-Auswertung mit Filterung
(Beispiel, Filterung der Relation S)
1. Transfer der unterschiedlichen C-Werte von R (= ΠC(R) )
nach StS
2. Auswertung des Right-Semi-Joins R S = ΠC(R)
S auf
StS und Transfer des Ergebnisses nach StR
3. Auswertung des Joins auf StR , der nur diese transferierten
Ergebnistupel des Semi-Joins braucht
Transferkosten werden nur reduziert, wenn gilt:
ΠC(R) + R
S <  S 
mit  = Größe (in Byte) einer Relation
51
...
R
A
(ΠC(R)
C
B
a1
a3
a5
b1
b3
b5
c1
c1
c3
StResult
S)
D
d1
d1
d2
E
e1
e1
e2
ΠC(R)
C
D
c1
d1
c3
d2
6 Attributwerte
C
c1
c2
c3
c6
A
a1
a2
a3
a4
a5
a6
a7
R
B
b1
b2
b3
b4
b5
b6
b7
C
c1
c2
c1
c2
c3
c2
c6
S
E
e1
e2
4 Attributwerte
ΠC
StR
StS
C
c1
c3
c4
c5
c7
c8
c5
S
D
d1
d2
d3
d4
d5
d6
d7
E
e1
e2
e1
e2
e3
e2
e6
Auswertung des Joins R A S
mit Semi-Join-Filterung von S
15 Attributwerte
52
Alternative
Auswertungungspläne
1. Alternative:
R
...
ΠC
StR
StResult
S
StS
2. Alternative:
(R
ΠC(S))
(ΠC(R)
S)
53
Parameter für die Kosten eines
VBMDS-Auswertungsplans
 Kardinalitäten von Argumentrelationen
 Selektivitäten von Joins und Selektionen
 Transferkosten für Datenkommunikation:
Verbindungsaufbau + Datenvolumen
 (CPU-)Auslastung der einzelnen VDBMS-Stationen
Effektive Anfrageoptimierung muss auf Basis eines Kostenmodells durchgeführt werden und soll mehrere Alternativen
für unterschiedliche Auslastungen des VDBMS erzeugen.
54
Transaktionskontrolle in VDBMS
 Globale 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.
55
EOT-Behandlung in VDBMS
Die EOT (End-of-Transaction)-Behandlung von globalen
Transaktionen stellt in VDBMS eine Herausforderung 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 an allen (relevanten)
Stationen nicht festgeschrieben
 Problem in verteilter Umgebung, da die Stationen eines
VDBMS unabhängig voneinander "abstürzen" können
56
Problemlösung:
Two-Phase-Commit-Protokoll (2PC)
 Gewährleistet die Atomarität der EOT-Behandlung in VDBMS
 Das 2PC-Verfahren wird von der sog. KoordinatorStationK überwacht.
 2PC gewährleistet, dass die n Agenten (= Stationen
im VDBMS) A1,…An , die an einer Transaktion beteiligt
waren, entweder alle von Transaktion T geänderten
Daten festschreiben oder alle Änderungen von T
rückgängig machen.
57
Nachrichtenaustausch beim
2PC-Protokoll (für 4 Agenten)
4 Messages?
A1
A1
A2
A2
K
K
PREPARE
K
A3
A3
A4
A4
FAILED/READY
Phase 1
COMMIT/ABORT
Phase 2
ACK
58
Ablauf der EOT-Behandlung beim
2PC-Protokoll
 K schickt allen Agenten eine PREPARE-Nachricht, um herauszufinden, ob
sie Transaktionen festschreiben können
 Jeder Agent Ai empfängt PREPARE-Nachricht und schickt eine von zwei
möglichen Nachrichten an K:
 READY, falls Ai in der Lage ist, die Transaktion T lokal
festzuschreiben
 FAILED, falls Ai kein commit durchführen kann (wegen Fehler,
Inkonsistenz etc.)
 Hat K von allen n Agenten A1,...,An 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
 Haben die Agenten ihre lokale EOT-Behandlung abgeschlossen, schicken sie
eine ACK-Nachricht (= acknowledgement, Bestätigung) an K.
59
Zustandsübergang beim
2PC-Protokoll: Koordinator
"Bullet" 
= wichtigste Aktion(en)
Timeout oder 1 x FAILED
empfangen:
 (T,abort) ins Log
 ABORT senden
Initial
Bereit
Abgebrochen
EOT:
 Alle an T beteiligen Agenten im
Log protokollieren
 sende PREPARE an Agenten
READY von allen Agenten
empfangen:
 (T,commit) ins Log
 sende COMMIT
Festschreibend
von allen ACK empfangen:
von allen ACK empfangen:
Fertig
 (T,terminated) ins Log
60
Zustandsübergang beim
2PC-Protokoll: Agent
Wartend
PREPARE empfangen und
Timeout od. PREPARE empfangen
lokal alles okay:
und lokaler Fehler entdeckt:
 Log-Einträge für T schreiben
 (T,ready) ins Log
 (T,abort) ins Log
 sende READY
 sende FAILED
Bereit
ABORT empfangen:
 (T,abort) ins Log
 sende ACK
Abgebrochen
(verspätetes) PREPARE empfangen:
 sende FAILED
Ab hier: Agent verpflichtet sich,
T erfolgreich zu beenden
COMMIT empfangen:
 (T,commit) ins Log
 sende ACK
Festgeschrieben
"Bullet" 
= wichtigste Aktion(en)
61
Blockierung eines Agenten
 2PC birgt die Gefahr der Blockierung der Agenten:
 Agent befindet sich im Zustand Bereit (hat sich also
verpflichtet, T erfolgreich zu beenden)
 Agent wartet vergeblich auf COMMIT/ABORTEntscheidung durch K  Timeout
1. Versuche globale COMMIT-Entscheidung bei K
nachzufragen (Kommunikationsfehler?)
2. Ist 1. erfolglos (K abgestürzt?), erfrage COMMITEntscheidung bei weiteren Agenten A oder erfrage, ob A
mit FAILED geantwortet hat
3. Ist auch 2. erfolglos, wird der Agent blockiert, bis K
wieder funktionsfähig ist und die COMMIT-Entscheidung
nachholt
62
Crash-Recovery in Agenten-Knoten
 Inspiziere den lokalen Log des Agenten, um nach Wiederanlauf
die Recovery zu steuern:
Ist auf dem Log ein Eintrag (T, commit) vorhanden, war T
bereits erfolgreich beendet. REDO(T) anstossen, um
Änderungen, die ausfallbedingt verloren gingen,
nachzuholen.
Ist Eintrag (T, abort) vorhanden, war T zur Rücksetzung
vorgesehen. Durch UNDO(T) alle Änderungen durch T an
der Datenbank zurücknehmen.
Ist Eintrag (T, ready) vorhanden, fehlte zum
Absturzzeitpunkt die COMMIT-Entscheidung von K.
Entscheidung bei K nachfragen (K hält diese Information
noch, da nicht alle ACK-Messages von allen Agenten
eingetroffen).
63
Crash-Recovery im Koordinator
 Koordinator K untersucht seinen lokalen Log:
Ist (T,terminated) im Log, stoße lediglich lokales
UNDO(T)/REDO(T) an, je nachdem ob (T,abort) oder
(T,commit) zuvor im Log gefunden wird
Ist (T,abort) im Log, führe lokal ein UNDO(T) aus. Sende
ABORT an alle Agenten, die bisher noch kein ACK
signalisiert haben.
Ist (T,commit) im Log, führe lokal REDO(T) aus. Sende
COMMIT an alle Agenten, die bisher noch kein ACK
signalisiert haben.
Setze im jeweils durch den Log signalisierten Zustand fort.
64
Lineare Organisationsform beim
2PC-Protokoll
COMMIT-Entscheidung wird sequentiell zwischen den Agenten
Kommuniziert:
FAILED/READY
K
COMMIT/ABORT
FAILED/READY
A1
FAILED/READY
A2
COMMIT/ABORT
A3
COMMIT/ABORT
ACK
• 2PC-Phase 1: Vorwärtskommunikation
• 2PC-Phase 2: Komm.sequenz in umgekehrter Reihenfolge
65
Mehrbenutzersynchronisation
in VDBMS
 Serialisierbarkeit
(kontrollierte und konsistente Verzahnung von DBMSOperationen: Zyklen im Serialisierbarkeitsgraphen?)
 Zwei-Phasen-Sperrprotokoll in VDBMS
●
●
lokale Sperrverwaltung an jeder Station
globale Sperrverwaltung
66
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):
S1
S2
Schritt T1
Schritt T1 T2
1.
2.
T2
r(A)
w(A)
3.
4.
T1
w(B)
r(B)
T2
67
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 (Shared,
eXclusive) mit bereits existierenden Sperren kann lokal
entschieden werden
 Favorisiert lokale Transaktionen, da diese nur mit
ihrem lokalen Sperrverwalter kommunizieren müssen
68
Globale Sperrverwaltung
Alle Transaktionen fordern alle Sperren an einer einzigen,
ausgezeichneten Station (Koordinator) an.
Nachteile:
 Zentraler Sperrverwalter kann zum Engpass des VDBMS
werden, besonders bei einem Absturz der SperrverwalterStation
 Verletzung der lokalen Autonomie der Stationen, da auch
lokale Transaktionen ihre Sperren bei der zentralisierten
Sperrverwaltung anfordern müssen
Zentrale Sperrverwaltung i.a. nicht akzeptabel
69
Deadlocks in VDBMS
 Erkennung von Deadlocks (Verklemmungen)
• Zentralisierte Deadlock-Erkennung: 
• Dezentrale (verteilte) Deadlock-Erkennung: schwierig
 Vermeidung von Deadlocks
70
Ein "Verteilter Deadlock"
Schritt
S1
T1
0.
1.
2.
BOT
lockS(A)
r(A)
T2
Schritt
S2
T1
3.
4.
5.
6.
lockX(A)

7.
T2
BOT
lockX(B)
w(B)
lockS(B)

• Lokal ist jeweils keine Deadlock-Situation zu erkennen
• Der globale Waits-for-Graph ist jedoch zyklisch
71
Erkennung von verteilten
Deadlocks : Timeout
 Betroffene Transaktion T wird nach Erreichen einer nicht
mehr akzeptablen Wartezeit zurückgesetzt und alle
Sperren freigegeben. Dann T erneut starten  einfach zu
realisieren
 Problem: Richtige Wahl des Timeout-Intervalls:
• zu lang  schlechte Ausnutzung der Systemressourcen,
Stationen sind für signifikante Zeit "idle"
• zu kurz  Deadlock-Behandlung initiiert, obwohl keine
Verklemmung vorliegt
72
Erkennung von verteilten
Deadlocks : Zentralisiert
 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 durch gegenseitiges
"Überholen" von Nachrichten im Kommunikationssystem
73
Erkennung von verteilten
Deadlocks : Dezentral
 Führe 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 repräsentiert
 Zuordnung jeder Transaktion zu einem Heimatknoten
(Station, auf der BOT ausgeführt wurde), von wo aus externe
Subtransaktionen auf anderen Stationen initiiert werden
74
Dezentrale Deadlock-Erkennung:
External
Schritt
S1
T1
0.
1.
2.
BOT
lockS(A)
r(A)
T2
Schritt
S2
T1
3.
4.
5.
6.
T2
BOT
lockX(B)
w(B)
lockX(A)
7.
lockS(B)
External  T2 *)
External  T1
T1  External
T2  External
*) Lies: Externe Transaktionen können potentiell aufgrund von T2 auf S1
gesetzten Locks blockieren.
75
Beispiel:
S1 Heimatknoten von T1, S2 Heimatknoten von T2
Wartegraphen (Zyklus mit External = potentieller Deadlock):
S1: External → T2 → T1 → External
S2: External → T1 → T2 → External
S2:
External
T1
S1 sendet Wartegraphen
an die Station, auf der T1
eine Teiltransaktion angestoßen
hat (hier: S2).
T2 External
T1 → T2 → T1
T2 → T1 → T2
 S2 kann globalen Deadlock (Zyklus ohne External) erkennen.
S2 wählt eine Opfer-Transaktion, setzt diese zurück und löst
damit den Deadlock auf.
76
Deadlock-Vermeidung
Deadlock-Erkennung in VDBMS ist aufwendig und
Kommunikationsintensiv  Versuche, Deadlocks von
vornherein zu vemeiden.
 Optimistische Mehrbenutzersynchronisation:
Nach Abschluss der Transaktionsbearbeitung auf lokalen
Kopien wird Validierung (alles serialisierbar?) 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)
77
Sperrbasierte Synchronisation
 Wound/wait:
Nur jüngere Transaktionen (jedes T bekommt zu BOT einen
time stamp) 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 ( strikte Bevorzugung
bereits lang laufender Transaktionen)
 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 ( ältere Transaktionen
bevorzugt, Blockierung mit zunehmender Alter aber immer
wahrscheinlicher)
78
Zeitstempel: Voraussetzungen für
Deadlockvermeidungsverfahren
 Vergabe global eindeutiger Zeitstempel als
Transaktionsidentifikatoren. Format:
lokale Zeit Stations-ID
 Vergleich von Zeitstempeln lexikographisch:
vergleiche erst bzgl. lokaler Zeit, dann bzgl.
Station.
 Lokale Uhren müssen hinreichend genau
aufeinander abgestimmt sein.
79
Synchronisation bei replizierten
Daten
Problem:
Im VDBMS gibt es zu einem Datum A mehrere Replikate A1,
A2, ..., An, die auf unterschiedlichen Stationen liegen.
Eine Lesetransaktion erfordert nur (irgend)eine Kopie,
bei Änderungstransaktionen müssen aber alle bestehenden
Kopien geändert werden, inkl. Sperrfanforderung,
Kommunikation, etc.
 Hohe Laufzeit und Verfügbarkeitsprobleme
(bspw. Heimatstation einer Kopie Ai nicht erreichbar)
 Lesetransaktionen eindeutig bevorteilt
80
Quorum-Consensus Verfahren
 Ausgleich der Leistungsfähigkeit zwischen Lese- und
Änderungstransaktionen  teilweise Verlagerung des
Overheads von den Änderungs- zu den Lesetransaktionen
indem den Kopien Ai eines replizierten Datums A
individuelle Gewichte (Stimmen) wi zugeordnet werden.
 Beispiel:
Station (Si)
Kopie (Ai)
Gewicht (wi)
S1
A1
3
S2
A2
1
S3
A3
2
S4
A4
2
 Gesamtgewicht W(A) =
i=1,…,4 wi(Ai) = 8
81
Quorum-Consensus Verfahren
 Weiterhin: Festlegung von Lesequorum Qr(A) und
Schreibquorum Qw(A).
 Eine Lesetransaktion, die r(A) ausführen will, muß zuvor
mindestens Qr(A) Stimmen an den Stationen "einsammeln"
und deren Kopien von A mit einem shared lock lockS(A)
belegen.
 Eine Schreibtransaktion muß vor Operation w(A) Qw(A)
Stimmen an den Stationen einsammeln und deren Kopien
jeweils mit exclusive locks lockX(A) belegen.
 Zusatzbedingungen (Beispiel: Qr(A) = 4, Qw(A) = 5):
Qw(A) + Qw(A) > W(A)
Qr(A) + Qw(A) > W(A)
82
Quorum-Consensus Verfahren
 Wie werden Updates propagiert?
Eine Schreibtransaktion wird ja nur die Kopien auf den
Stationen ändern, deren Stimmen sie eingesammelt hat (und
dort lockX-Locks besitzt).
 Protokolliere für jedes Datenobjekt eine Versionsnummer.
Eine Schreibtransaktion versieht das geschriebene Objekt mit
dem Maximum aller seiner Versionsnummern + 1.
83
Zustände vor (a) und nach (b)
Update A := A + 100
a) vor dem Schreiben eines Schreibquorums
Station
S1
S2
Kopie
A1
A2
Gewicht
3
1
Wert
1000
1000
Versions#
1
1
S3
S4
A3
A4
2
2
1000
1000
1
1
b) nach dem Schreiben eines Schreibquorums
Station
Kopie
Gewicht
Wert
Versions#
S1
S2
A1
A2
3
1
1100
1000
2
1
S3
S4
A3
A4
2
2
1100
1000
2
1
84
Quorum-Consensus Verfahren
 Eine Lesetransaktion liest mehrere Kopien, um mindestens
Qr(A) Stimmen "einzusammeln", nutzt aber nur den A-Wert mit
der höchsten Versionsnummer.
 Beispiel: Lese die Kopien A3 und A4 (Stimmen? w3(A) + w4(A) =
4  Qr(A) ), nutze jedoch nur den Wert der Kopie A3.
 Die Bedingunng
Qr(A) + Qw(A) > W(A)
stellt sicher, daß auf mindestens eine Kopie des letzten
Schreibquorums zugegriffen wird.
85