pdf (2/1)

Datenbankanwendung
DATENBANKANWENDUNG
Wintersemester 2013/2014
Holger Schwarz
Universität Stuttgart, IPVS
[email protected]
Beginn:
M ittwochs:
Donner stags:
2 3 .1 0.2013
1 1 .4 5 – 1 5.15 Uhr, Raum 4 6-268 ( Pause 13.00 – 1 3.30)
1 0 .0 0 – 1 1.30 Uhr, Raum 4 6-268
1 1 .4 5 – 1 3.15 Uhr, Raum 4 6-260
http://w w w lgis.informatik.uni-kl.de/cms/courses/datenbankanw endung/
Datenbankanw endung
5. Transaktionsverwaltung

•
•
•
TA-Paradigma
DB-Konsistenz


TA-Verw.
CommitProtokolle
Transaktionsparadigma

BASE
A C ID-E igenschaften
P rogrammierschnittstelle
M ögliche A usgänge einer TA
Gefährdung der DB-Konsistenz
Transaktionsverwaltung und Transaktionsablauf
•
•
•
•
A rchitektur
S Q L-O perationen: C O MMIT WO RK, ROLLBACK WO RK
Zustände und Zustandsübergänge
V erarbeitung in v erteilten S y stemen
•
•
E insatz v on C ommit-P rotokollen (zentralisierter TA -A blauf)
2 P C ( Zweiphasen-Commit-P rotokoll)
Commit-Protokolle



•
•

verteilter TA-Ablauf
Fehleraspekte
Kostenbetrachtungen
2P C -P rotokoll in Bäumen


Bestimmen eines Koordinators
Hierarchisches 2PC
TA -V erarbeitung in offenen S y stemen
BASE (basically available, soft state, eventually consistent)
•
•
eine A C ID-Alternativ e
C A P-Theorem
5-2
Datenbankanw endung
Transaktionsparadigma

Ablaufkontrollstruktur: Transaktion
TA-Paradigma
BO T
O 11
x
T1
O 12
x
O 13
x
x
EO T
x
DB-Konsistenz
BO T
TA-Verw.
CommitProtokolle
x
T2

BASE
O 11
x
O 12
x
O 13
x
EO T
x
Transaktionsparadigma

führt ein neues Verarbeitungsparadigma ein

ist Voraussetzung für die Abwicklung betrieblicher Anwendungen
(mission-critical applications)

erlaubt „Vertragsrecht“ in rechnergestützten IS zu implementieren
5-3
Datenbankanw endung
Transaktionsparadigma (2)

TA-Paradigma
Welche Eigenschaften von Transaktionen sind zu garantieren?
•
A tomicity (Atomar ität)
-
DB-Konsistenz
•
C onsistency
TA-Verw.
-
CommitProtokolle
-
•
BASE
TA hinterlässt einen konsistenten DB-Zustand, sonst wird sie komplett zurückgesetzt
(siehe Atomarität)
Zwischenzustände während der TA-Bearbeitung dürfen inkonsistent sein
Endzustand muß die Integritätsbedingungen des DB-Schemas erfüllen
Isolation
-
•
TA ist kleinste, nicht mehr weiter zerlegbare Einheit
Entweder werden alle Änderungen der TA festgeschrieben oder gar keine
(„alles-oder-nichts“-Prinzip)
Nebenläufig (parallel, gleichzeitig) ausgeführte TA dürfen sich nicht gegenseitig beeinflussen
Parallele TA bzw. deren Effekte sind nicht sichtbar
Dur ability (Dauerhaftigkeit)
-
Wirkung erfolgreich abgeschlossener TA bleibt dauerhaft in der DB
TA-Verwaltung muß sicherstellen, dass dies auch nach einem Systemfehler
(HW- oder System-SW) gewährleistet ist
-
Wirkung einer erfolgreich abgeschlossenen TA kann nur durch eine sog. kompensierende
TA aufgehoben werden
5-4
Datenbankanw endung
Transaktionsparadigma (3)

DB-bezogene Definition der Transaktion
E ine TA ist eine ununterbrechbare F olge v on DM L-Befehlen, w elche die Datenbank v on
einem logisch konsistenten Zustand in einen neuen logisch konsistenten Zustand überführt.
TA-Paradigma
DB-Konsistenz

TA-Verw.

Diese Definition eignet sich insbesondere für relativ kurze TA , die auch als A C IDT r ansaktionen bezeichnet w erden.
Transaktionsprogramm – Beispiel:
CommitProtokolle
BO T
U P DATE
.. .
U P DATE
.. .
U P DATE
.. .
IN S E RT
C O MM IT;
BASE
Konto
S chalter
Zw eigstelle
IN TO Ablage (...)
5-5
Datenbankanw endung
Transaktionsparadigma (4)

TA-Paradigma
DB-Konsistenz

TA-Verw.
Programmierschnittstelle für Transaktionen:
•
begin of transaction (BO T)
•
•
commit transaction (“commit w ork” in S Q L)
rollback transaction (“rollback w ork” in S Q L)
Mögliche A usgänge einer Transaktion
BOT
BOT
BOT
CommitProtokolle
DML1
DML 1
DML 1
BASE
DML2
DML 2
DML 2
DML3
DML 3
DML 3
•
•
•
•
•
•
DMLn
DML n
COMMIT
ROLLBA CK
nor males Ende
abnor males Ende
Systemausfall,
Programmfehler,
usw.
erzwungenes ROLLBA CK
er zwungenes
abnor males Ende
5-6
Datenbankanw endung
Gefährdung der DB-Konsistenz
TA-Paradigma
Korrektheit der
A bbildungshierarchie
DB-Konsistenz
TA-Verw.
durch das
A nw endungsprogramm
CommitProtokolle
BASE
durch das DBV S
und
die Betriebsumgebung
Ü bereinstimmung zw ischen DB
und M iniw elt
M ehrbenutzer-A nomalien
unzulässige Ä nderungen
S y nchronisation
Integritätsüberw achung des DBVS
TA -orientierte V erarbeitung
F ehler auf den E xternspeichern,
Inkonsistenzen in den Zugriffspfaden
undefinierter D B-Zustand nach
einem S y stemausfall
F ehlertolerante Implementierung,
A rchiv kopien (Backup)
Transaktionsorientierte F ehlerbehandlung (Recov ery )
5-7
Datenbankanw endung
Transaktionsverwaltung

Wesentliche Abstraktionen aus Sicht der DB-Anwendung
TA-Paradigma
•
A lle A usw irkungen auftretender F ehler bleiben der A nw endung v erborgen
(failure transparency )
DB-Konsistenz
•
E s sind keine anw endungsseitigen V orkehrungen zu treffen, um E ffekte der
N ebenläufigkeit beim DB -Zugriff auszuschließen
(concurrency transparency )
TA-Verw.
 G ew ährleistung einer fehlerfreien S icht auf die Datenbank im logischen
E inbenutzerbetrieb
CommitProtokolle

BASE
Transaktionsverwaltung
•
koordiniert alle DBS -seitigen M aßnahmen, um A C ID zu garantieren
•
besitzt drei w esentliche Komponenten zur/zum
-
Synchronisation
Logging und Recovery
-
Konsistenzsicherung/Regelverarbeitung
•
kann zentralisiert oder v erteilt (z.B. bei V DBS ) realisiert sein
•
soll Transaktionsschutz für heterogene Komponenten bieten
5-8
Datenbankanw endung
Transaktionsverwaltung (2)

RM sind S y stemkomponenten, die T r ansaktionsschutz für ihr e gemeinsam
nutzbar en Betr iebsmittel (BM ) bieten
• RM gestatten die externe Koordination v on BM -A ktualisierungen durch spezielle
C ommit-P rotokolle
 G ew ährleistung v on A C ID für DB -Daten und auch für andere BM (persistente
Warteschlangen, N achrichten, O bjekte v on persistenten P rogrammiersprachen)
DB-Konsistenz
TA-Verw.
CommitProtokolle
Einsatz kooperierender Ressourcen-Manager (RM)
•
TA-Paradigma

Ziel: TA-orientierte Verarbeitung in heterogenen Systemen
BASE
 Die gesamte v erteilte
V erarbeitung in einer S oC
ist eine A C ID-TA
Server
Kontext
TA-Program
receive
SQL
call
SQL
store
send
DB X
•
•
DB Y
alle Komponenten w erden
durch die TA -D ienste
integriert
für die Kooperation ist
eine G rundmenge v on
P rotokollen erforderlich
Sphere of Control (SoC), die z. B. durch
einen TP-Monitor etabliert wurde
5-9
Datenbankanw endung
Transaktionsverwaltung (3)

TA-Paradigma
DB-Konsistenz

Abstraktes Architekturmodell für die Transaktionsverwaltung
(für das Read/Write-Modell auf Seitenbasis)
•
TA-Verw.
•
CommitProtokolle
•
BASE

kontrolliert die A bw icklung der um DB Daten konkurrierenden TA
sorgt für die
Rücksetzbarkeit/Wiederholbarkeit der
E ffekte v on TA
DB-Pufferverwalter
•
stellt DB-S eiten bereit und gew ährleistet
persistente S eitenänderungen
T2
...
Tn
Transaktionsv erw alter
Koordination der A bort- und C ommitBehandlung
Recovery-Komponente
•

V erteilung der DB-O perationen in V DBS und
Weiterreichen an den S cheduler
zeitw eise Deaktiv ierung v on TA
(bei Ü berlast)
Scheduler (Synchronisation)
•

T1
Transaktionsverwalter
S cheduler
S peichersy stem
Recov ery Komponente
DB-P ufferv erw alter
DB
5-10
Datenbankanw endung
Zustände einer Transaktion

Zustandsübergangs-Diagramm
TA-Paradigma
inkarnieren
potentiell
aktiv
DB-Konsistenz
CommitProtokolle
w iederholbar
abgeschlossen
BASE
reaktiv ieren
neu starten
beenden
TA-Verw.
v erdrängen
w artend
abbrechen
rücksetzen
abbrechen
festschreiben
gescheitert
rücksetzen
aufgegeben
persistent

Transaktionsverwaltung
•
•
muß die möglichen Zustände einer TA kennen und
ihre Zustandsübergänge kontrollieren/auslösen
5-11
Datenbankanw endung
Zustände einer Transaktion (2)

TA-Paradigma
DB-Konsistenz
TA-Verw.
TA-Zustände
•
•
•
CommitProtokolle
•
BASE
•
•
•
•
potentiell
- TA P w artet auf A usführung
- Beim S tart w erden, falls erforderlich, aktuelle P arameter übergeben
aktiv
- TA konkurriert um Betriebsmittel und führt O perationen aus
war tend
- D eaktiv ierung bei Ü berlast
- Blockierung z.B. durch S perren
abgeschlossen
- TA kann sich (einseitig) nicht mehr zurücksetzen
- TA kann jedoch noch scheitern (z.B. bei Konsistenzv erletzung)
per sistent (E ndzustand)
- Wirkung aller D B-Ä nderungen w erden dauerhaft garantiert
gescheiter t
- V ielfältige E reignisse können zum S cheitern ein TA führen
(siehe F ehlermodell, V erklemmung usw .)
wieder holbar
- G escheiterte TA kann ggf. (mit demselben E ingabew erten) erneut ausgeführt
w erden
aufgegeben (E ndzustand)
5-12
Datenbankanw endung
Schnittstelle zwischen AP und DBS –
transaktionsbezogene Aspekte
A ktionen auf Seite
des A P
A ktionen auf Seite
des DBS
TA-Paradigma
S icherstellen der Rücksetzbarkeit
v on Ä nderungsoperationen
BO T
.
.
.
DB-Konsistenz
TA-Verw.
O pi
CommitProtokolle
.
.
.
Befehle
A usführen v on DM L-Befehlen
(Ü berprüfen der v erzögerten
Integritätsbedingungen)
BASE
EO T
(Ü berprüfen der v erzögerten
Integritätsbedingungen)
C
O
P hase 1
M
2PC
S icherstellen der Wiederholbarkeit
aller Ä nderungen
M
I
P hase 2
Bestätigung über erfolgreiches
E nde an das A P
T
Weiterarbeit
im A P
Datenbankanw endung
5-13
Verarbeitung in Verteilten Systemen

TA-Paradigma
Ein verteiltes System besteht aus autonomen Subsystemen, die koordiniert
zusammenarbeiten, um eine gemeinsame Aufgabe zu erfüllen
•
DB-Konsistenz
TA-Verw.
•

C lient/S erv er-S ysteme (C /S ), Doppelrolle v on S erv ern:
S ie können w iederum als C lients anderer S erv er auftreten!
M ehrrechner-DBS , . . .
Beispiel: The „Coordinated Attack“ Problem
CommitProtokolle
BASE
F reigabe der Betriebsmittel
(S perren)
attack at daw n
red general
blue general
RM 1
RM 2
G enerals’ P aradoxon
Wie wir d die Eindeutigkeit einer Entscheidung bei
Unsicher heit in einer verteilten Situation erreicht?
5-14
Datenbankanw endung
Verarbeitung in Verteilten Systemen (2)

Grundproblem verteilter Systeme
TA-Paradigma
Das für v erteilte S y steme charakteristische Kernproblem
ist der M angel an globalem (zentralisiertem) Wissen
DB-Konsistenz
 symmetr ische Kontrollalgorithmen sind oft zu teuer oder zu ineffektiv
 fallweise Zuor dnung der Kontrolle
TA-Verw.
CommitProtokolle

Annahmen im allgemeinen Fall
•
BASE
nicht nur V erlust (omission) v on N achrichten (Bote/Kurier w ird gefangen)
• sondern auch ihre bösartige V erfälschung (commission failures)
 dann komplexer e P rotokolle erfor derlich:
Distr ibuted consensus (bekannt als Byzantine agr eement)
5-15
Datenbankanw endung
Verarbeitung in Verteilten Systemen (3)

TA-Paradigma
Fehlermodell
•
- Transaktionsfehler
- C rash (i. A llg. einiger Rechner)
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE
allgemein:
•
- G erätefehler
speziell (nur omission failures):
- N achrichtenv erluste
- N achrichten-D uplikate: dieselbe N achricht erreicht ihr Ziel mehrmals,
möglicherw eise v erschachtelt mit anderen N achrichten
- transiente P rozessfehler (soft crashs):
Restart erforderlich, aber kein D atenv erlust auf E xternspeicher
- A chtung: Wir schließen hier bösartige V erfälschungen v on N achrichten aus!
 keine speziellen Annahmen:
Kommunikationssy stem arbeitet mit D atagrammen als einfachstem Ty p v on
unbestätigten, sitzungsfreien N achrichten
 schw ierige F ehlererkennung, z. B. oft über Timeout
5-16
Datenbankanw endung
Verarbeitung in Verteilten Systemen (4)

TA-Paradigma
Erweitertes Transaktionsmodell
ver teilte Transaktionsbearbeitung (P rimär-, Teiltransaktionen) –
zentr alisierte Steuerung des C ommit-P rotokolls (v ergleiche „H eirat“)
DB-Konsistenz
1 Koor dinator
C
TA-Verw.
CommitProtokolle
N T eiltr ansaktionen
( A genten)
BASE

A1
A2
. . .
AN
rechnerübergreifendes M ehrphasen-C ommit-P rotokoll notw endig, um A tomarität einer
globalen Transaktion sicherzustellen
5-17
Datenbankanw endung
Commit-Protokolle

TA-Paradigma
DB-Konsistenz
Allgemeine Anforderungen an geeignetes Commit-Protokoll:
•
G eringer A ufw and (#N achrichten, #Log-A usgaben)
•
M inimale A ntw ortzeitv erlängerung (N utzung v on P arallelität)
•
Robustheit gegenüber Rechnerausfällen und Kommunikationsfehlern
TA-Verw.

Zentralisiertes Zw eiphasen-C ommit-P rotokoll stellt geeignete Lösung dar
CommitProtokolle
BASE
5-18
Datenbankanw endung
Zentralisiertes Zweiphasen-Commit
Zustandüber gang
TA-Paradigma
C
DB-Konsistenz
Nachr icht
Initial
Ai
P hase 1
(Voting)
CommitProtokolle
Wait
P RE P ARE
* Begin
TA-Verw.
Zustandüber gang
RE A DY / F A ILE D
* P repared/
A borted
* C ommitting/
A borting
BASE
C O MM IT / A BO RT
P hase 2
(Decision)
ACK
* C ommitted/
A borted
E nd
* sy nchrone Log-A usgabe (log record is force-w ritten)
“E nd” ist w ichtig für G arbage C ollection im Log v on C
5-19
Datenbankanw endung
Zentralisiertes Zweiphasen-Commit (2)

Protokoll (Basic 2PC)
•
TA-Paradigma
F olge v on Zustandsänderungen für Koordinator und für A genten
- P rotokollzustand auch nach C rash eindeutig: sy nchrones Logging
- S obald C ein N O V OTE (F AILE D ) erhält, entscheidet er A BORT
DB-Konsistenz
- S obald C die A C K-N achricht v on allen A genten bekommen hat, w eiß er, dass alle
A genten den A usgang der TA kennen
TA-Verw.
 C kann diese TA vergessen, d. h. ihre Log-Einträge im Log löschen!
CommitProtokolle
•
Warum ist das 2P C -P rotokoll blockierend?
BASE

Aufwand im Erfolgsfall:
•
N achrichten:
•
Log-A usgaben (forced log w rites):
5-20
Datenbankanw endung
2PC: Zustandsübergänge
INITIAL
EOT
Log-Write: Begin
Sende PREPARE
TA-Paradigma
DB-Konsistenz
TA-Verw.
FAILED empfangen
oder TIMEOUT
READY von allen empfangen
Log-Write: Abort
Sende ABORT
Log-Write: Commit
Sende COMMIT
CommitProtokolle
BASE
Koordinator
BEGIN
ABORTING
C
Agent
COMMITTING
alle ACK-Nachrichten
empfangen
alle ACK-Nachrichten
empfangen
Log-Write: End
Log-Write: End
Ai
WAIT
PREPARE empfangen
END
Log-Write: Prepared
sende READY
ABORT empfangen
oder TIMEOUT
Log-Write: Abort
PREPARED
COMMIT empfangen
Log-Write: Commit
sende ACK
ABORT empfangen
PREPARE empfangen
ABORTED
sende FAILED
Log-Write: Abort
sende ACK
COMMITTED
5-21
Datenbankanw endung
2PC: Fehlerbehandlung

•
•
TA-Paradigma
DB-Konsistenz
Timeout-Bedingungen für Koordinator:

CommitProtokolle

BASE

setze Transaktion zurück; v erschicke A BO RT -Nachricht
v ermerke A genten, für die A C K noch aussteht
Timeout-Bedingungen für Agenten:
•
•
TA-Verw.
BEGIN

A BO RTING

C O M M ITTING
WA IT
P REP ARED


setze Teiltransaktion zurück (unilateral A BORT)
erfrage Transaktionsausgang bei Koordinator
(bzw . bei anderen Rechnern)
Ausfall des Koordinatorknotens: Vermerkter Zustand auf Log
•
END

•
A BO RTING

•
C O M M ITTING 
RE DO -Recovery
C O MM IT-N achricht an Rechner, v on denen A C K aussteht
•
S onst
U N DO-Recov ery

U N DO bzw . RE DO-Recovery, je nach Transaktionsausgang
keine "offene" Teiltransaktionen möglich
U N DO-Recov ery
A BO RT-N achricht an Rechner, v on denen A C K noch aussteht
Rechnerausfall für Agenten: Vermerkter Zustand auf Log
•
•
•
C O M M ITTED 
RE DO -Recovery
A BO RTED bzw . kein 2P C -Log-S atz v orhanden  U N DO-Recovery
P REP ARED

A nfrage an Koordinator-Knoten, w ie TA beendet w urde
(Koordinator hält Information, da noch kein A C K erfolgte)
5-22
Datenbankanw endung
2PC-Protokoll in TA-Bäumen

TA-Paradigma
Typischer AW-Kontext: C/S-Umgebung
•
Beteiligte: C lients (C ), A pplikations-S erv er (A S ), DB-S erver (DB)
•
unterschiedliche Q uality of S erv ice bei Zuv erlässigkeit, E rreichbarkeit, Leistung, ..
DB-Konsistenz
C
. ..
C
C
. ..
C
TA-Verw.
AS
AS
DB
DB
CommitProtokolle
BASE
5-23
Datenbankanw endung
2PC-Protokoll in TA-Bäumen (2)

TA-Paradigma
Wer übernimmt die Koordinatorrolle? – wichtige Aspekte
•
TA -Initiator
•
Zuv erlässigkeit und G eschw indigkeit der Teilnehmer
- A nzahl der Teilnehmer
DB-Konsistenz
- momentane Last
- G eschw indigkeit der N etzw erkverbindung
TA-Verw.
•
CommitProtokolle
Kommunikationstopologie und -protokoll
- sichere/schnelle E rreichbarkeit
- im LA N : N etzw erkadressen aller S erv er sind bekannt; jeder kann jeden mit
D atagrammen oder neu eingerichteten S itzungen erreichen
- im WA N : „transitiv e“ E rreichbarkeit; mehrere H ops erforderlich; Initiator kennt
nicht unbedingt alle (dy namisch hinzukommenden) Teilnehmer (z. B. im Internet)
BASE

Im einfachsten Fall: TA-Initiator übernimmt Koordinatorrolle
 sinnv oll, w enn Initiator ein zuv erlässiger, schneller und gut angebundener
A pplikations-S erv er ist!
5-24
Datenbankanw endung
2PC-Protokoll in TA-Bäumen (3)

TA-Paradigma
DB-Konsistenz
Drei wichtige Beobachtungen
•
•
TA-Verw.
Während der TA -V erarbeitung formen die inv olv ierten P rozesse einen (unbalancierten)
Baum mit dem Initiator als Wurzel. Jede Kante entspricht einer dy namisch
eingerichteten Kommunikationsv erbindung
F ür die C ommit-V erarbeitung kann der Baum
Initiator
„flachgemacht“ w erden
(Prozess 0)
- D er Initiator kennt die N etzw erkadressen
aller Teilnehmerprozesse bei C ommit
(durch „piggy backing“ bei v orherigen
A ufrufen)
CommitProtokolle
Prozess 1
- N icht möglich, w enn die S erv er
die Information, w elche S erv er sie
aufgerufen haben, kapseln
BASE
•
Prozess 2
„F lachmachen“ kann als spezieller F all der
Restrukturierung der C /S -A ufrufhierarchie
gesehen w erden
Prozess 3
Prozess 4
Prozess 5
Kommunikation während Transaktionsausf.
- E s könnte auch ein zuv erlässiger innerer Knoten als Koordinator ausgew ählt
w erden
- „Rotation“ der A ufrufhierarchie um den neu gew ählten Koordinatorknoten
5-25
Datenbankanw endung
2PC-Protokoll in TA-Bäumen (4)
TA-Paradigma
DB-Konsistenz
TA-Verw.
H ierarchisches 2P C
Initiator
(Prozess 0)
CommitProtokolle
BASE
Initiator = Koordinator
F laches 2P C
Prozess 1
Prozess 2
Initiator
(Prozess 0)
Prozess 3
Prozess 4
Prozess 5
Kommunikation während Transaktionsausf.
Prozess 1
Prozess 2
Prozess 3
Prozess 4
Prozess 5
Kommunikation während Commitprotokoll
5-26
Datenbankanw endung
Hierarchisches 2PC

Allgemeineres Ausführungsmodell
•
•
TA-Paradigma
beliebige S chachtelungstiefe, angepasst an C /S -M odell
M odifikation des P rotokolls für “Zw ischenknoten”
C
DB-Konsistenz
A1
Initial
* Begin
Preparing/
Aborting
TA-Verw.
CommitProtokolle
A2
Wait
Wait
PREPARE
Phase 1
PREPARE
READY / FAILED
* Prepared/
Aborted
* Prepared/
Aborted
BASE
READY / FAILED
* Committing/
Aborting
COMMIT / ABORT
* Committing/
Aborting
Phase 2
COMMIT / ABORT
ACK
End
ACK
End
* sy nchrone Log-A usgabe (log record is force-w ritten)
“E nd” ist w ichtig für G arbage C ollection im Log
Datenbankanw endung
* Committed/
Aborted
5-27
Hierarchisches 2PC (2)

TA-Paradigma
DB-Konsistenz
Aufwand im Erfolgsfall:
•
N achrichten:
•
Log-A usgaben (forced log w rites):
•
A ntw ortzeit steigt mit S chachtelungstiefe
TA-Verw.
CommitProtokolle

Problem Koordinator-/Zwischenknotenausfall
 Blockierung möglich!
BASE
5-28
Datenbankanw endung
Commit: Optimierungen

Beobachtung:
TA-Paradigma
Commit-Protokoll
•
DB-Konsistenz
hat erheblichen E influss auf den TA -Durchsatz
- substanzieller A nteil an der gesamten TA -Zeit bei kurzen TA s
(Reserv ierungen, Buchungen, Kreditkartenv alidierung usw .)
- C ommit-A nteil bei TA s, die einen S atz ändern, etw a 1/3 der TA -Zeit
TA-Verw.
•
CommitProtokolle
BASE
S chnelleres C ommit-P rotokoll kann Durchsatz v erbessern
- Reduktion der C ommit-Dauer jeder TA
- frühere F reigabe v on S perren, w as die Wartezeit anderer TA v erkürzt
- V erkleinerung des Zeitfensters für die Blockierungsgefahr
(C rash oder N icht-E rreichbarkeit v on C )
5-29
Datenbankanw endung
Commit: Optimierungen (2)

TA-Paradigma
Wünschenswerte Charakteristika eines Commit-Protokolls
1.
A von A C ID: stets garantierte TA -A tomarität1
2.
F ähigkeit, den A usgang der C ommit-V erarbeitung einer TA „nach einer Weile“
v ergessen zu können
DB-Konsistenz
-
TA-Verw.
CommitProtokolle
3.
4.
BASE
begrenzte Log-Kapazität v on C
C muss sicher sein, dass alle A genten den C ommit-A usgang für T i kennen oder
C nimmt einen bestimmten A usgang an, w enn er keine Information über Ti mehr
besitzt
M inimaler A ufw and für N achrichten und sy nchrones Logging
O ptimierte Leistungsfähigkeit im fehlerfreien F all (no-failure case)
ist w esentlich häufiger zu erw arten: optimistisches V erhalten
v or allem M inimierung v on sy nchronen Log-A usgaben (forced log w rite)
-
5.
dafür zusätzlicher Recov ery -A ufwand, um v erlorengegangene Information im
F ehlerfall w ieder zu beschaffen
S pezielle O ptimierung für Leser
(ihre C ommit-Behandlung ist unabhängig v om A usgang der TA )
1. May all your transactions commit and never leave you in doubt! (Jim Gray)
5-30
Datenbankanw endung
Commit: Kostenbetrachtungen

Vollständiges 2PC-Protokoll (N = #Teil-TA, davon M = #Leser)
TA-Paradigma
•
N achrichten:
DB-Konsistenz
•
Log-A usgaben:
•
A ntw ortzeit:
längste Runde in P hase 1 (kritisch, w eil Betriebsmittel blockiert)
+ längste Runde in P hase 2
TA-Verw.
CommitProtokolle

Spezielle Optimierung für Leser
•
BASE
•
Teil-TA , die nur Leseoperationen ausgeführt haben, benötigen keine Recov ery !
- C und D v on A C ID sind nicht betroffen
- für A und I genügt das H alten der S perren bis P hase 1
Lesende Teil-TA brauchen deshalb nur an P hase 1 teilzunehmen
- M itteilung an (Zw ischen-)Koordinator: „read-only v ote“
- dann F reigabe der S perren
•
•
- (Zw ischen-)Koordinator darf (Teil-)Baum nur freigeben,
w enn er ausschließlich read-only v otes erhält
N achrichten:
Log-A usgaben:
für N > M
1. Leseroptimierung läßt sich mit allen 2PC-Varianten kombinieren, wird jedoch nachfolgend nicht berücksichtigt
Datenbankanw endung
Commit: Kostenbetrachtungen (2)

1PC-Protokolle
•
TA-Paradigma
DB-Konsistenz

TA-Verw.
5-31
Bei A ufruf der C ommit-O peration durch die TA sind bereits alle A genten
im P RE P ARED-Zustand
- „implicit y es-v ote“ (IYV )
- M odifikation der A P I erforderlich
Variante 1: A i geht nach jedem Auftrag in den PREPARED-Zustand
•
Jeder A ufruf v on A i: Work & P repare
•
E inschränkungen bei v erzögerten Integritätsprüfungen erforderlich (deferred)
CommitProtokolle
Agent A i
BASE
PREPARE-Nachr. implizit
Log-Write: Prepared
von der COMMIT/ABORT-Nachr.
P REP ARED
COMMIT empfangen
ABORT empfangen
A BO RTED
Log-Write: Abort
sende ACK
•
N achrichten:
•
durchschnittlich K A ufträge pro A gent;
Log-A usgaben:
Log-Write: Commit
sende ACK
C O M M ITTED
5-32
Datenbankanw endung
Commit: Kostenbetrachtungen (3)

TA-Paradigma
DB-Konsistenz
TA-Verw.
CommitProtokolle

BASE
Variante 2: A i geht beim letzten Auftrag in den PREPARED-Zustand
•
N ormaler A ufruf v on A i: Work
•
Letzter A ufruf v on A i: Work&P repare;
Lässt sich diese A rt der O ptimierung immer erreichen?
•
N achrichten:
•
Log-A usgaben:
Weglassen der expliziten ACK-Nachricht
•
A i fragt ggf. nach, falls ihn die Koordinatorentscheidung nicht erreicht
•
C w eiß nicht, ob alle A i die C ommit/A bort-N achricht erhalten haben
 impliziert "unendlich langes Gedächtnis" von C
•
N achrichten:
•
Log-A usgaben:
5-33
Datenbankanw endung
Commit: Kostenbetrachtungen (4)

Spartanisches Protokoll
TA-Paradigma
•
A i geht nach jedem A uftrag in den P RE P ARED-Zustand;
Weglassen der expliziten A C K-N achricht
DB-Konsistenz
•
N achrichten:
TA-Verw.
•
Log-A usgaben:
CommitProtokolle
•
N ur letzter A ufruf: Work&P repare;
Log-A usgaben:
BASE
 Log-Aufwand bleibt gleich (oder erhöht sich drastisch) !
5-34
Datenbankanw endung
TA-Verarbeitung in offenen Systemen

TA-Paradigma
Standards zur TA-Verwaltung
TA -M grs benötigen S tandards, w eil sie letztendlich den „Klebstoff“ v erkörpern, der die
unterschiedlichen und heterogenen S W-Komponenten zusammenfügt.
DB-Konsistenz
Server
TA-Verw.
CommitProtokolle
BASE
Kontext
TA-Program
receive
SQL
call
SQL
store
send
DB X
DB Y
Sphere of Control (SoC), die z. B. durch
einen TP-Monitor etabliert wurde
•
Ihre A W laufen auf v erschiedenartigen P lattformen und
•
haben Zugriff zu v erschiedenen DBs und RM s
•
Die A W haben absolut kein Wissen v oneinander
 E inziger Weg zur V erknüpfung: „O ffene Standards“
Bereitstellung v on S chnittstellen zw ischen TA -M gr und RM , TA -M grs untereinander und
TA -M gr und A W
5-35
Datenbankanw endung
TA-Verarbeitung in offenen Systemen (2)

Standards kommen aus zwei Quellen
TA-Paradigma
•
IS O :
O S I-TP spezifiziert die N achrichtenprotokolle zur Kooperation v on TA -M grs
DB-Konsistenz
•
X/O P E N definiert den allgemeinen Rahmen für TA -V erarbeitung:
X/O pen DTP (distributed transaction processing) stellt eine S W-A rchitektur dar, die
mehreren A WP erlaubt, gemeinsam Betriebsmittel mehrerer RM s zu nutzen und die
A rbeit der beteiligten RM s durch globale Transaktionen zusammenzufassen.
TA-Verw.
CommitProtokolle
BASE
5-36
Datenbankanw endung
TA-Verarbeitung in offenen Systemen (3)

TA-Paradigma
X/Open DTP (1991) für die lokale Zusammenarbeit von Anwendung (AW),
TA-Mgr (TM) und Resource-Mgrs (RMs)
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE

Standardisierung
•
•
S chnittstelle zur Transaktionsv erw altung (TX: A W — TM )
S chnittstelle zw ischen TM und RM s (XA : zur TA-V erwaltung und A C ID-Kontrolle)
•
zusätzlich: A nforderungsschnittstellen (A P I, z. B. S Q L)
5-37
Datenbankanw endung
TA-Verarbeitung in offenen Systemen (4)

TA-Paradigma
DB-Konsistenz
TA-Verw.
CommitProtokolle

TA-Ablauf
•
Die A W startet eine TA , die v om lokalen TA -M gr v erw altet w ird
•
RM s melden sich bei erster Dienst-A nforderung beim lokalen TA -M gr an (Join)
•
Wenn A W C ommit oder Rollback ausführt (oder zw angsw eise zurückgesetzt w ird),
schickt TA -M gr E rgebnis zu den RM s (über Broadcast)
hier sor gen die RM s für Synchronisation und Logging
in ihrem Bereich (priv ate Lock-M gr und Log-M gr) — Warum?
BASE
5-38
Datenbankanw endung
TA-Verarbeitung in offenen Systemen (5)

TA-Paradigma
DB-Konsistenz

TA-Verw.
X/Open DTP (1993) standardisiert die verteilte TA-Verarbeitung.
•
E s kommt der „C ommunication Resource M anager“ (C RM ) hinzu
•
XA + erw eitert S chnittstelle XA für den v erteilten F all
Definition von Schnittstellen
auf der AW-Ebene
•
CommitProtokolle
•
BASE
•
TxRP C definiert transaktionalen
RP C . S eine TA -Eigenschaften
können ausgeschaltet w erden
(optional)
C P I-C V 2 ist Konv ersationsschnittstelle (peer-to-peer),
w elche die O S I-TP-Semantik
unterstützen soll
XA TM I ist Konv ersationsschnittstelle für C lient/S erv erBeziehungen
 S ind drei S chnittstellen-S tandards erforderlich?
Kompromisslösung für drei existierende P rotokolle (DC E , C iCS, Tuxedo)
5-39
Datenbankanw endung
TA-Verarbeitung in offenen Systemen (6)
TA-Paradigma
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE

TA-Ablauf
•
A W startet TA , die v om lokalen TA -M gr v erw altet w ird
•
Wenn die A W oder der RM , der für die A W eine A nforderung bearbeitet, eine entfernte
A nforderung durchführen, informieren die C RM s an jedem Knoten ihre lokalen TA -M gr
über die ankommende oder ausgehende TA
•
•
TA -M gr v erw alten an jedem Knoten jew eils die TA -A rbeit am betreffenden Knoten
Wenn die A W C O MMIT oder RO LLBA CK durchführt oder scheitert, kooperieren alle
beteiligten TA -M gr, um ein atomares und dauerhaftes C ommit zu erzielen.
5-40
Datenbankanw endung
BASE – Eine ACID-Alternative?

TA-Paradigma
2PC ist teuer: Wie erreicht man Skalierbarkeit?
•
V ertikales S kalieren:
V erschiebe die A nw endung auf das nächst größere Rechensy stem
 aufw ändig, teuer, v erstärkte H erstellerbindung, ...
•
H orizontales S kalieren:
P artitioniere (gruppiere) die Daten nach A W-F unktionen und v erteile die funktionalen
G ruppen auf v erschiedene DBs
•
Shar ding*:
Weitere Dimension beim horizontalen S kalieren, d.h. horizontale Zerlegung der Daten
(Tabellen) innerhalb v on funktionalen G ruppen und Zuordnung auf v erschiedene DBs
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE
 H orizontales S kalieren bietet mehr F lexibilität, ist aber auch w esentlich komplexer!
* Nach Wikipedia: Horizontal partitioning is a database design principle whereby rows of a database table are held separately,
rather than splitting by columns (as for normalization). Each partition forms part of a shard, which may in turn be located on a
separate database server or physical location.
5-41
Datenbankanw endung
BASE – Eine ACID-Alternative? (2)

TA-Paradigma
Funktionale Partitionierung – wesentlich für hohe Skalierbarkeit
•
DB-Konsistenz
Beispiel-S chema
tr ansaction(xid, seller_id, buy er_id, amount)
TA-Verw.
user (id, name, amt_sold, amt_bought)
CommitProtokolle
•
U m C onstraints (automatisch) einhalten zu können, müssen alle betroffenen Daten
(Tabellen) v on einem einzigen DBM S v erwaltet w erden
 horizontales S kalieren w äre hier ausgeschlossen !
•
V erw altung durch v erschiedene DBM S s v erlangt die V erschiebung v on
partitionsübergreifenden C onstraints in die A W
BASE
5-42
Datenbankanw endung
CAP-Theorem oder Brewer‘s Theorem

CAP-Theorem
•
TA-Paradigma
F ür ein S y stem zum ver teilten Rechnen ist es unmöglich, gleichzeitig die folgenden
drei E igenschaften zu garantieren:
- C onsistency (Konsistenz):
A us Benutzersicht findet eine M enge v on O perationen auf einmal statt
DB-Konsistenz
- A vailability (V erfügbarkeit):
Jede O peration muss mit einer bestimmungsgemäßen A ntw ort beendet w erden
TA-Verw.
CommitProtokolle
- P ar tition tolerance (P artitionstoleranz):
O perationen kommen zum E nde, selbst w enn indiv iduelle Komponenten nicht
v erfügbar sind
BASE
 E ine Web-A W kann höchstens zw ei
v on diesen E igenschaften für jeden
beliebigen DB-E ntw urf unterstützen!
partition
tolerance
av ailablility
no
go
consistency
5-43
Datenbankanw endung
CAP-Theorem oder Brewer‘s Theorem (2)

Wie lassen sich ACID-Lösungen annähern?
TA-Paradigma
•
DB-Konsistenz
 Wir müssen uns zw ischen Konsistenz und V erfügbarkeit entscheiden!
TA-Verw.

CommitProtokolle
E ine horizontale S kalierungsstrategie basiert auf Datenpatitionierung
Aber Konsistenz ist zu garantieren!

Wenn Brew er recht hat, muss an der V erfügbarkeit „gedreht“ w erden!
BASE

Auswirkungen reduzierter Verfügbarkeit bei ACID-Lösungen
•
•
angenommene Komponentenv erfügbarkeit v on 99,9%
G esamtv erfügbarkeit als P rodukt der E inzelv erfügbarkeiten:
2P C -P rotokoll bei zw ei D Bs  99,8%
(zusätzliche A usfallzeit v on 43 M in./M onat)
 Reicht das für erhöhte S kalierbarkeit aus?
5-44
Datenbankanw endung
BASE (basically

TA-Paradigma
DB-Konsistenz
available, soft state, eventually consistent)
*
Eine ACID-Alternative
•
A C ID ist pessimistisch und erzw ingt Konsistenz bei C ommit
•
BA S E ist dazu diametral entgegengesetzt
- E s ist optimistisch und akzeptiert, dass sich die D B-Konsistenz in einem
fließenden Zustand befindet
TA-Verw.
- V erfügbarkeit w ird dadurch erreicht, dass
bestimmte F ehlerzustände akzeptiert w erden, ohne dass
es zu einem A usfall des G esamtsy stems kommt
Bsp.: Wenn nur einer v on fünf S erv ern ausfällt, w ird im V ergleich zu einem
S y stem-C rash eine deutlich höhere V erfügbarkeit w ahrgenommen
CommitProtokolle
BASE
- Beim D B-E ntw urf sind die Daten in funktionale Gr uppen zu zerlegen; nach
V erkehrsaufkommen w erden sie dann auf v erschiedene D BM S v erteilt

BASE verlangt eine weitaus detailliertere Analyse der TA -Ops als
ACID!
* In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability
(Dan Britchett, eBay)
5-45
Datenbankanw endung
BASE (2)

TA-Paradigma
Schema
tr ansaction(xid, seller_id, buy er_id, amount)
user (id, name, amt_sold, amt_bought)
DB-Konsistenz
TA-Verw.

Konsistenzmuster
CommitProtokolle
•
N ach Brew er müssen Wege zur Lockerung der Konsistenzforderung gefunden w erden,
w enn die V erfügbarkeit in einer partitionierten DB erhalten bleiben soll
BASE
•
E in Benutzer kann in mehreren TA s kaufen oder v erkaufen
•
M üssen die laufenden G esamtsummen in Tabelle user immer aktuell sein?
•
Die Tabellen user und transaction w erden hier als v erschiedene funktionale G ruppen
klassifiziert
•
Im A llgemeinen ist die Konsistenz zwischen funktionalen G ruppen leichter zu lockern
als innerhalb einer funktionalen G ruppe
5-46
Datenbankanw endung
BASE (3)

TA-Paradigma
tr ansaction(xid, seller_id, buy er_id, amount)
user (id, name, amt_sold, amt_bought)
DB-Konsistenz
TA-Verw.
Schema

DB-Ausprägung verteilt
transaction
CommitProtokolle
BASE
xid
seller_id
buyer_id
amount
123
4711
0815
20,000
124
0007
4711
10,000
user
id
name
amt_sold
amt_bought
4711
Coy
200,000
50,000
0815
May
520,000
100,000
0007
Bond
30,000
600,000
node 2
node 1
5-47
Datenbankanw endung
BASE (4)

Eine ACID-Lösung mit SQL
TA-Paradigma
DB-Konsistenz
TA-Verw.
CommitProtokolle
Begin transaction
Insert into transaction(xid, seller_id, buyer_id, amount);
Update user set amt_sold = amt_sold+$amount where id=$seller_id;
Update user set amt_bought = amount_bought+$amount
where id=$buyer_id;
End transaction
BASE
•
2 P C erforderlich
•
Die Zähler amount, amt_bought und amt_sold, die zu v erschiedenen funktionalen
G ruppen gehören, w erden gemeinsam aktualisiert
 T he Unavailability P roblem! (W. V ogels, A mazon)
 Konsistenz gar antier t!
5-48
Datenbankanw endung
BASE (5)

Zerlegung in zwei ACID-Transaktionen
TA-Paradigma
Begin transaction
Insert into transaction(id, seller_id, buyer_id, amount);
End transaction
Begin transaction
Update user set amt_sold=amt_sold+$amount
where id=$seller_id;
Update user set amt_bought=amount_bought+$amount
where id=$buyer_id;
End transaction
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE
•
Lockerung der Konsistenzanforderung: Die Zähler brauchen nicht sofort das E rgebnis
einer Transaktion reflektieren; sie enthalten „S chätzungen“!
•
Konsistenz zw ischen beiden Tabellen w ird nicht garantiert!
5-49
Datenbankanw endung
BASE (6)

Ein möglicher Ablauf von xid = 125
TA-Paradigma
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE
5-50
Datenbankanw endung
BASE (7)

Eine einfache BASE-Lösung
•
TA-Paradigma
•
DB-Konsistenz
TA-Verw.
F alls Zähler-Werte als S chätzungen nicht akzeptabel sind und die Konsistenz
zumindest zeitv erzögert garantiert w erden muss?
P ersistente N achrichtenw arteschlange (P M Q : persistent message queue)
löst das P roblem
Begin transaction
Insert into transaction(id, seller_id, buyer_id, amount);
Queue message “update user(seller_id, “seller“, amount)“;
Queue message “update user(buyer_id, “buyer“, amount)“;
End transaction
CommitProtokolle
BASE
For each message in queue
Begin transaction
Dequeue message
If message.balance == “seller“
Update user set amt_sold = amt_sold + message.amount
where id=message.id;
Else
Update user set amt_bought = amt_bought + message.amount
where id=message.id;
End if
End transaction
End for
Datenbankanw endung
TA-Paradigma
5-51
BASE (8)

Transaktionsablauf
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE
•
E rste Transaktion aktualisiert tr ansaction und fügt atomar in P M Q ein:
•
- update user(“seller“, 0815, 100,000)
- update user(“buy er“, 0007, 100,000)
P M Q garantiert, dass die N achrichten in endlicher Zeit atomar v erarbeitet
w erden und die Zähler aktualisieren
 eventually consistent!
•
2P C bei der P M Q -Verarbeitung erforderlich!
5-52
Datenbankanw endung
BASE (9)

2PC soll vermieden werden!
•
TA-Paradigma
DB-Konsistenz
TA-Verw.
•
•
Begin transaction
Insert into transaction(id, seller_id, buy er_id, amount);
Q ueue message “update user(seller_id, “seller“, amount)“;
CommitProtokolle
BASE
G ew ährleistung v on Idempotenz (bei partiellem A usfall) !
Welche Zähleraktualisierungen w aren erfolgreich und w elche nicht?
H ilfstabelle: updates_applied(trans_id, balance, user_id)
A lgorithmus unterstützt partielle F ehler und bietet TA -G arantien (ev entually
consistent), ohne 2P C auf user und P M Q zu erfordern!
Q ueue message “update user(buy er_id, “buy er“, amount)“;
E nd transaction
…
5-53
Datenbankanw endung
TA-Paradigma
BASE (10)
For each message in queue
Peek message
Begin transaction
Select count(*) as processed from updates_applied
where trans_id = message.trans_id
and balance = message.balance and user_id = message.user_id
If processed == 0
DB-Konsistenz
TA-Verw.
If message.balance == “seller“
Update user set amt_sold=amt_sold + message.amount
CommitProtokolle
BASE
where id=message.user_id;
Else
Update user set amt_bought=amt_bought + message.amount
where id=message.user_id;
End if
Insert into updates_applied (message.trans_id, message.balance, message.user_id);
End if
End transaction
If transaction successful
Remove message from queue
End if
End for
•
•
Lösung hängt hier dav on ab, dass N achricht in P M Q aufgesucht (peek) und nach
erfolgreicher V erarbeitung aus P M Q entfernt w erden kann!
Q ueue-O perationen sind v or dem C ommit der DB -Transaktion nicht erfolgreich
5-54
Datenbankanw endung
BASE (11)

Ein möglicher Ablauf von xid = 125

PMQ mit (user_id, balance, amount)
TA-Paradigma
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE
•
message.trans_id: update user(0815, “seller“, 1 0 0,000)
•
•
message.trans_id: update user(0007, “buy er“, 1 0 0,000)
…
5-55
Datenbankanw endung
BASE (12)

Stand von Tabelle user

Kontrolle erfolgreicher Aktualisierungen von user durch
TA-Paradigma
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE
5-56
Datenbankanw endung
Zusammenfassung

TA-Paradigma
Transaktionsparadigma
•
V erarbeitungsklammer für die E inhaltung v on semantischen Integritätsbedingungen
•
V erdeckung der N ebenläufigkeit (concurrency isolation)
 S y nchronisation
•
V erdeckung v on (erw arteten) F ehlerfällen (failure isolation)
 Logging und Recov ery
•
im S Q L-S tandard: C O MMIT WO RK, RO LLBACK WO RK
 Beginn einer Transaktion implizit
DB-Konsistenz
TA-Verw.
CommitProtokolle
BASE

Zweiphasen-Commit-Protokolle
•
Hoher A ufw and an Kommunikation und E /A
•
•
O ptimierungsmöglichkeiten sind zu nutzen
M aßnahmen erforderlich, um Blockierungen zu v ermeiden!
 Kr itische Stelle: A usfall v on C
5-57
Datenbankanw endung
TA-Paradigma
Zusammenfassung (2)

Einsatz in allen Systemen!

Varianten des Commit-Protokolls:
DB-Konsistenz
TA-Verw.
•
H ierarchisches 2P C :
V erallgemeinerung auf beliebige S chachtelungstiefe
•
Reduzierte Blockierungsgefahr durch 3P C :
N ach V oting-P hase w ird in einer zusätzlichen Runde (Dissemination-P hase) allen
A genten der TA -A usgang mitgeteilt. E rst nachdem C sicher ist, dass alle A genten das
E rgebnis kennen, w ird die Decision-P hase initiiert: unabhängige Recov ery , aber
komplexes F ehlermodell
CommitProtokolle
BASE

BASE (basically available, soft state, eventually consistent)
•
C A P-Theorem: E ine Web-A W kann höchstens zw ei der drei E igenschaften (Konsistenz,
V erfügbarkeit, P artitionierungstoleranz) für jeden beliebigen DB -E ntw urf unterstützen!
•
Lockerung der Konsistenz (zw ischen funktionalen G ruppen), w enn die V erfügbarkeit in
einer partitionierten DB erhalten bleiben soll
5-58