pdf-half

Integritätsüberwachung des DBVS
TA-orientierte Verarbeitung
undefinierter DB-Zustand nach einem
Systemausfall
Transaktionsorientierte Fehlerbe-
handlung (Recovery)
Synchronisation
Fehler auf den Externspeichern,
Inkonsistenzen in den Zugriffspfaden
Fehlertolerante Implementierung,
Archivkopien (Backup)
- erlaubt „Vertragsrecht“ in rechnergestützten IS zu implementieren
• Gefährdung der DB-Konsistenz
- ACID-Eigenschaften
- Architektur
- Integration heterogener Komponenten
• Transaktionsablauf
- SQL-Operationen: COMMIT WORK, ROLLBACK WORK
(Beginn einer Transaktion implizit)
- Zustände und Zustandsübergänge
• Wie erreicht man Atomarität?
- Einsatz von Commit-Protokollen
(zentralisierter TA-Ablauf)
- 2PC (Zweiphasen-Commit-Protokoll)
• verteilter TA-Ablauf
durch das
Anwendungspro-
• Fehleraspekte
Gefährdung der DB-Konsistenz
• Transaktionsverwaltung
• Kostenbetrachtungen
- Hierarchisches 2PC
5-1
gramm
- ist Voraussetzung für die Abwicklung betrieblicher Anwendungen
(mission-critical applications)
Korrektheit der Abbildungshierarchie
- führt ein neues Verarbeitungsparadigma ein
Übereinstimmung zwischen
DB und Miniwelt
• Transaktionskonzept
5-2
durch das DBVS
und
die Betriebsumgebung
unzulässige Änderungen
Mehrbenutzer-Anomalien
5. Transaktionsverwaltung
Transaktionsverwaltung
Transaktionsverwaltung (2)
• Ablaufkontrollstruktur: Transaktion
T1
BOT
T2
O11
BOT
• DB-bezogene Definition der Transaktion:
O12
O21
O13
O22
Eine TA ist eine ununterbrechbare Folge von DML-Befehlen,
welche die Datenbank von einem logisch konsistenten Zustand in einen
neuen logisch konsistenten Zustand überführt.
EOT
O23
EOT
➥ Diese Definition eignet sich insbesondere für relativ kurze TA,
die auch als ACID-Transaktionen bezeichnet werden.
• Welche Eigenschaften von Transaktionen sind zu garantieren?
(zur Erinnerung)
- Atomicity (Atomarität)
• TA ist kleinste, nicht mehr weiter zerlegbare Einheit
• Entweder werden alle Änderungen der TA festgeschrieben
oder gar keine („alles-oder-nichts“-Prinzip)
- Consistency
• TA hinterläßt einen konsistenten DB-Zustand, sonst wird sie komplett
(siehe Atomarität) zurückgesetzt
• Wesentliche Abstraktionen aus Sicht der DB-Anwendung
- Alle Auswirkungen auftretender Fehler bleiben der Anwendung verborgen
(failure transparency)
- Es sind keine anwendungsseitigen Vorkehrungen zu treffen, um Effekte
der Nebenläufigkeit beim DB-Zugriff auszuschließen
(concurrency transparency)
➥ Gewährleistung einer fehlerfreien Sicht auf die Datenbank
im logischen Einbenutzerbetrieb
• Zwischenzustände während der TA-Bearbeitung dürfen inkonsistent sein
• Endzustand muß die Integritätsbedingungen des DB-Schemas erfüllen
• Transaktionsverwaltung
- Isolation
- koordiniert alle DBS-seitigen Maßnahmen, um ACID zu garantieren
• Nebenläufig (parallel, gleichzeitig) ausgeführte TA dürfen sich nicht
gegenseitig beeinflussen
• Parallele TA bzw. deren Effekte sind nicht sichtbar
- Durability (Dauerhaftigkeit)
- besitzt zwei wesentliche Komponenten
• Synchronisation
• Logging und Recovery
- kann zentralisiert oder verteilt (z.B. bei VDBS) realisiert sein
• Wirkung erfolgreich abgeschlossener TA bleibt dauerhaft in der DB
- soll Transaktionsschutz für heterogene Komponenten bieten
• TA-Verwaltung muß sicherstellen, daß 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-3
5-4
Transaktionsverwaltung (3)
• Abstraktes Architekturmodell für die Transaktionsverwaltung
(für das Read/Write-Modell auf Seitenbasis)
T1
T2
...
Tn
Transaktionsverwaltung (4)
• Einsatz kooperierender Ressourcen-Manager (RM)
- RM sind Systemkomponenten, die Transaktionsschutz für ihre gemeinsam
nutzbaren Betriebsmittel (BM) bieten
- RM gestatten die externe Koordination von BM-Aktualisierungen durch spezielle Commit-Protokolle
Transaktionsverwalter
➥ Gewährleistung von ACID für DB-Daten und auch für andere BM
Scheduler
(persistente Warteschlangen, Nachrichten, Objekte von persistenten
Programmiersprachen)
Speichersystem
• Ziel:
TA-orientierte Verarbeitung in heterogenen Systemen
RecoveryKomponente
DB-Pufferverwalter
Server
DB
• Transaktionsverwalter
- Verteilung der DB-Operationen in VDBS und Weiterreichen an den Scheduler
- zeitweise Deaktivierung von TA (bei Überlast)
- Koordination der Abort- und Commit-Behandlung
• Scheduler (Synchronisation)
kontrolliert die Abwicklung der um DB-Daten konkurrierenden TA
• Recovery-Komponente
sorgt für die Rücksetzbarkeit/Wiederholbarkeit der Effekte von TA
• DB-Pufferverwalter
stellt DB-Seiten bereit und gewährleistet persistente Seitenänderungen
5-5
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
➥ Die gesamte verteilte Verarbeitung in einer SoC ist eine ACID-TA
- alle Komponenten werden durch die TA-Dienste integriert
- für die Kooperation ist eine Grundmenge von Protokollen erforderlich
5-6
erzwungenes
abnormales Ende
erzwungenes ROLLBACK
DML3
DML2
DML1
BOT
• Transaktionsprogramm – Beispiel:
BOT
UPDATE Konto
...
UPDATE Schalter
...
UPDATE Zweigstelle
...
INSERT INTO Ablage (...)
COMMIT;
• Zustandsübergangs-Diagramm
verdrängen
inkarnieren
potentiell
aktiv
wartend
abnormales Ende
ROLLBACK
DMLn
•
•
•
DML3
DML2
DML1
BOT
reaktivieren
normales Ende
COMMIT
DMLn
•
•
•
DML2
DML1
DML3
5-7
neustarten
beenden
wiederholbar
abgeschlossen
BOT
Mögliche Ausgänge einer Transaktion
Systemausfall,
Programm,
fehler
usw.
Zustände einer Transaktion
abbrechen
rücksetzen
gescheitert
rücksetzen
abbrechen
festschreiben
aufgegeben
persistent
5-8
Zustände einer Transaktion (2)
Schnittstelle zwischen AP und DBS transaktionsbezogene Aspekte
• Transaktionsverwaltung
- muß die möglichen Zustände einer TA kennen und
- ihre Zustandsübergänge kontrollieren/auslösen
Aktionen auf Seite
des AP
Aktionen auf Seite
des DBS
Sicherstellen der Rücksetzbarkeit von Änderungsoperationen
BOT
• TA-Zustände
- potentiell
• TAP wartet auf Ausführung
• Beim Start werden, falls erforderlich, aktuelle Parameter übergeben
- aktiv
TA konkurriert um Betriebsmittel und führt Operationen aus
- wartend
• Deaktivierung bei Überlast
• Blockierung z.B. durch Sperren
•
•
•
Befehle
Op
i
Ausführen von DML-Befehlen
(Überprüfen der unverzögerten
Integritätsbedingungen)
•
•
•
EOT
- abgeschlossen
(Überprüfen der verzögerten
Integritätsbedingungen)
C
• TA kann sich (einseitig) nicht mehr zurücksetzen
O
• TA kann jedoch noch scheitern (z.B. bei Konsistenzverletzung)
- persistent (Endzustand)
Wirkung aller DB-Änderungen werden dauerhaft garantiert
- gescheitert
Vielfältige Ereignisse können zum Scheitern ein TA führen
(siehe Fehlermodell, Verklemmung usw.)
2PC
Phase 1
Sicherstellen der Wiederholbarkeit
aller Änderungen
M
Freigabe der Betriebsmittel
M
Phase 2
(Sperren)
I
- wiederholbar
Gescheiterte TA kann ggf. (mit demselben Eingabewerten)
erneut ausgeführt werden
T
Bestätigung über erfolgreiches
Ende an das AP
Weiterarbeit
im AP
- aufgegeben (Endzustand)
5-9
5 - 10
Verarbeitung in Verteilten Systemen
• Ein verteiltes System besteht aus autonomen Subsystemen, die koordiniert
zusammenarbeiten, um eine gemeinsame Aufgabe zu erfüllen
Verarbeitung in Verteilten Systemen (2)
• Erweitertes Transaktionsmodell
verteilte Transaktionsbearbeitung (Primär-, Teiltransaktionen)
- Client/Server-Systeme
- Mehrrechner-DBS, . . .
C
1 Koordinator
• Beispiel: The „Coordinated Attack“ Problem
N Teiltransaktionen
(Agenten)
A1
A2
. . .
AN
attack at dawn
blue general
red general
➥ rechnerübergreifendes Mehrphasen-Commit-Protokoll notwendig,
um Atomarität einer globalen Transaktion sicherzustellen
• Anforderungen an geeignetes Commit-Protokoll:
- Geringer Aufwand (#Nachrichten, #Log-Ausgaben)
Generals-Paradoxon
- Minimale Antwortzeitverlängerung (Nutzung von Parallelität)
- Robustheit gegenüber Rechnerausfällen und Kommunikationsfehlern
➥Zentralisiertes Zweiphasen-Commit-Protokoll stellt geeignete Lösung dar
• Grundproblem verteilter Systeme
• Erwartete Fehlersituationen
Das für verteilte Systeme charakteristische Kernproblem ist der
Mangel an globalem (zentralisiertem) Wissen
➥ symmetrische Kontrollalgorithmen sind oft zu teuer
oder zu ineffektiv
➥ fallweise Zuordnung der Kontrolle
5 - 11
- Transaktionsfehler
- Systemfehler (Crash)
➥ i. allg. partielle Fehler (Rechner, Verbindungen, ...)
- Gerätefehler
➥ Fehlererkennung z. B. über Timeout
5 - 12
Zentralisiertes Zweiphasen-Commit
Zustandsübergang
Nachricht
2PC: Zustandsübergänge
Zustandsübergang
Koordinator C
Ai
C
INITIAL
EOT
Log-Write: Begin
Sende PREPARE
PREPARE
Phase 1
READY / FAILED
COMMIT / ABORT
FAILED empfangen
oder TIMEOUT
Log-Write: Abort
Sende ABORT
BEGIN
READY von allen empfangen
Log-Write: Commit
Sende COMMIT
COMMITTING
ABORTING
alle ACK-Nachrichten
empfangen
alle ACK-Nachrichten
empfangen
Log-Write: End
Phase 2
Log-Write: End
TERMINATED
ACK
• Protokoll erfordert Folge von Zustandsübergängen
Agent Ai
- für Koordinator
- für jeden Agenten
➥ Zustandsübergänge müssen auf „sicherem Platz“ (Log) vermerkt sein!
(Übergang nach TERMINATED braucht nicht synchron zu erfolgen)
ABORT empfangen
oder TIMEOUT
Log-Write: Abort
ABORTED
• Aufwand im Erfolgsfall:
WAIT
PREPARE empfangen
Log-Write: Prepared
sende READY
PREPARED
ABORT empfangen
Log-Write: Abort
Sende ACK
COMMIT empfangen
Log-Write: Commit
Sende ACK
COMMITTED
- Nachrichten:
PREPARE empfangen
sende FAILED
- Log-Ausgaben (forced log writes):
5 - 13
5 - 14
2PC: Fehlerbehandlung
• Timeout-Bedingungen für Koordinator:
- WAIT ➥ setze Transaktion zurück; verschicke ABORT-Nachricht
- ABORTING, COMMITTING
Commit: Kostenbetrachtungen
• vollständiges 2PC-Protokoll
(N = #Teil-TA, davon M = #Leser)
- Nachrichten: 4 N
➥ vermerke Agenten,
für die ACK noch aussteht
- Log-Ausgaben: 2 + 2 N
- Antwortzeit:
• Timeout-Bedingungen für Agenten:
längste Runde in Phase 1 (kritisch, weil Betriebsmittel blockiert)
+ längste Runde in Phase 2
- WAIT ➥ setze Teiltransaktion zurück (unilateral ABORT)
- PREPARED ➥ erfrage Transaktionsausgang bei Koordinator
(bzw. anderen Rechnern)
• Aufwand bei spezieller Optimierung für Leser:
• Ausfall des Koordinatorknotens:
Vermerkter Zustand auf Log
Lesende Teil-TA nehmen nur an Phase 1 teil, dann Freigabe der Sperren
- Nachrichten:
- TERMINATED:
• UNDO bzw. REDO-Recovery, je nach Transaktionsausgang
• keine "offene" Teiltransaktionen möglich
- Log-Ausgaben:
für N > M
- ABORTING:
• UNDO-Recovery
• ABORT-Nachricht an Rechner, von denen ACK noch aussteht
- COMMITTING:
• REDO-Recovery
• COMMIT-Nachricht an Rechner, von denen ACK noch aussteht
• Läßt sich das zentralisierte 2PC-Protokoll weiter optimieren?1
- Sonst: UNDO-Recovery
• Rechnerausfall für Agenten:
Vermerkter Zustand auf Log
- COMMITTED: REDO-Recovery
- ABORTED bzw. kein 2PC-Log-Satz vorhanden: UNDO-Recovery
- PREPARED: Anfrage an Koordinator-Knoten, wie TA beendet wurde
(Koordinator hält Information, da noch kein ACK erfolgte)
5 - 15
1.
Leseroptimierung läßt sich mit allen nachfolgenden Varianten kombinieren, wird jedoch nachfolgend
nicht berücksichtigt
5 - 16
Commit: Kostenbetrachtungen (2)
• Weglassen der expliziten Acknowledge-Nachricht
Commit: Kostenbetrachtungen (3)
• Ai geht beim letzten Auftrag in den PREPARED-Zustand
- Ai fragt ggf. nach;
"unendlich langes Gedächtnis" von C
- Normaler Aufruf von Ai: Work
- Letzter Aufruf von Ai: Work&Prepare;
Läßt sich diese Art der Optimierung immer erreichen?
- Nachrichten:
- Nachrichten:
- Log-Ausgaben:
- Log-Ausgaben:
• Ai geht nach jedem Auftrag in den PREPARED-Zustand
- Jeder Aufruf von Ai: Work&Prepare
Agent Ai
• Spartanisches Protokoll
PREPARE-Nachr. implizit
Log-Write: Prepared
vor der COMMIT/ABORT-Nachr.
PREPARED
ABORTED
ABORT empf.
Log-Write: Abort
Sende ACK
- Ai geht nach jedem Auftrag in den PREPARED-Zustand;
Weglassen der expliziten Ack-Nachricht
- Nachrichten:
COMMIT empf.
Log-Write: Commit
Sende ACK
- Log-Ausgaben:
COMMITTED
- Nachrichten:
- Nur letzter Aufruf: Work&Prepare;
Log-Ausgaben:
- durchschnittlich K Aufträge pro Agent;
Log-Ausgaben:
➥ Log-Aufwand bleibt gleich (oder erhöht sich drastisch) !
5 - 17
5 - 18
Zusammenfassung
Hierarchisches 2PC
• Allgemeineres Ausführungsmodell
• Transaktionsparadigma
- beliebige Schachtelungstiefe, angepaßt an Client/Server-Modell
- Verarbeitungsklammer für die Einhaltung von semantischen
Integritätsbedingungen
- Modifikation des Protokolls für “Zwischenknoten”
C
A1
A2
Initial
Wait
Wait
- Verdeckung der Nebenläufigkeit (concurrency isolation)
➥ Synchronisation
PREPARE
Wait
- Verdeckung von (erwarteten) Fehlerfällen (failure isolation)
PREPARE
Preparing
(Aborting)
➥ Logging und Recovery
Prepared/
Aborted
- im SQL-Standard: COMMIT WORK, ROLLBACK WORK
Phase 1
READY / FAILED
➥ Beginn einer Transaktion implizit
Prepared
(Aborted)
• Zweiphasen-Commit-Protokolle
READY / FAILED
- Hoher Aufwand an Kommunikation und E/A
Committing/
Aborting
- Optimierungsmöglichkeiten sind zu nutzen
COMMIT / ABORT
Committed/
Aborted
Phase 2
- Maßnahmen erforderlich, um Blockierungen zu vermeiden!
COMMIT / ABORT
➥ Kritische Stelle: Ausfall von C
Committed/
Aborted
ACK
• Einsatz in allen Systemen!
ACK
Terminated
• Varianten des Commit-Protokolls:
• Aufwand
- Hierarchisches 2PC:
- Optimierung für lesende Teil-TA
Verallgemeinerung auf beliebige Schachtelungstiefe
• kein Logging, Sperrfreigabe in Phase 1 (in ganzen Teilbäumen)
• Kommunikation für zweite Phase wird vermieden
- 3PC
- Antwortzeit steigt mit Schachtelungstiefe
• Problem bei 2PC: Koordinatorausfall
5 - 19
➥ Blockierung möglich!
5 - 20