9 Mehrbenutzeraspekte, Transaktionen, Parallelität und

9 Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
I Bisheriger Kenntnisstand über (relationale) Datenbanken:
Datenbank(schema) besteht aus Relationen, Entwurf guter“ Schemata
”
Zugriff über SQL: Anfragen, Änderungen, DDL, Zugriffskontrolle, . . .
Trennung logischer und interner Aspekte ( Datenunabhängigkeit“)
”
bislang jedoch: lediglich die Ein-Benutzer-Sicht“
”
I Verwendung eines Datenbanksystems bietet einen weiteren entscheidenden Vorteil:
Transaktions-Management: kontrollierter Mehrbenutzerbetrieb ( Concurrency Control“)
”
Fehlertoleranz: Automatische“ Korrektur im Fehlerfall ( Recovery“): Technische Störungen
”
”
(Stromausfall, Festplatten-Crash, . . .) können abgefangen werden
Parallelisierung: automatische Durchsatz-Optimierung
Verteilung: Verschiedene (Teile von) Datenbanken können an unterschiedlichen Standorten
(Rechner, Ort) betrieben, aber gemeinsam genutzt werden.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-1
Problemstellung
I Bisher betrachtet:
Datenbanksysteme aus der Sicht eines einzelnen Benutzers/Programms (Einbenutzer-Sicht).
Axiom: Einbenutzerbetrieb ist korrekt
I Bisher nicht betrachtet:
Welche Anforderungen entstehen durch den zeitgleichen Zugriff mehrerer Benutzer auf die
gemeinsamen Daten?
Wie handhabt ein DBMS paralleles Ändern und Lesen im Mehrbenutzerbetrieb?
Wie kann sich ein DBMS gegen Programm- und System- Abstürze“ absichern?
”
Was kann ein DBMS zur Schadensbegrenzung im Fall von Plattendefekten (Lesefehlern) tun?
I Anwendungsszenarien
Flugbuchung / Platzreservierung
Bankbuchungen, Umbuchungen, Abbuchung, Überweisung . . .
allgemein Geschäftsvorfälle“ (häufig: mission critical applications“)
”
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-2
I Charakteristisch: Von vielen Benutzern kommen gleichzeitig“ Anfragen und Änderungsaufträge
”
an das Info-System
K1
K2
1
2
...
Kn
..
IS
Klienten:
Terminals
PCs / Workstations
Endgeräte (Geldautomaten,
Kontoauszugdrucker,
EC-Kartenleser, ...)
Informations-Server
Abbildung 9-1: Typisches Anwendungsszenario für Mehrbenutzer-IS
I Problem: Korrekte Abwicklung der parallelen Aufträge
Abstraktion von Geldtransaktionen, Banktransaktionen, Buchungstransaktionen, . . .
⇓
Transaktion
. . . Folge von DB-Operationen mit garantierten ACID“-Eigenschaften
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-3
9.1
Transaktionskonzept
Transaction Processing (TP)“ hat seine Ursprünge in Datenbank- und Informationssystemen (sowie
”
in sog. TP Monitors“, mit etwas anderer Interpretation)
”
Heute spielt TP jedoch auch eine wichtige Rolle in vielen anderen Bereichen, das Abstraktionskonzept
Transaktion“ und seine generische Realisierung zur Behandlung von parallelem Zugriff (concurrent
”
access) auf gemeinsam benutzte Daten und die Behandlung verschiedener Arten von Fehlern (failure
handling) sind in diversen Szenarien nützlich.
I ursprünglich: OLTP – Online Transaction Processing.
Bank-Buchungssysteme, Flugreservierungs- und -buchungssysteme, Mietwagen- und HotelReservierung, . . .
I heute in vielen neuartigen Geschäftszweigen: Electronic Commerce, Workflows (Geschäftsprozesse), . . .
I aber auch anderen generischen Software-Produkten: Betriebssysteme, Kommunikationssysteme,
E-Mail-Server, Dokumentenserver, . . .
Allgemeine Charakteristik: viele, verteilt zusammenarbeitende, heterogene Komponenten, die auf
große, gemeinsame Datenbestände zugreifen.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-4
Transaktionen
I sind ein Meilenstein moderner Informationssystem-Technologie
I abstrahieren von den unterschiedlichsten, komplexen und oftmals schwierig zu durchschauenden
Aufgaben, gemeinsam benutzte Daten konsistent zu halten.
. . . bei vielen gleichzeitigen Zugriffen,
. . . bei diversen möglichen Fehlerkonstellationen,
. . . bei enormen Performance-Anforderungen,
. . . bei (vom Benutzer verborgenem) Parallelisierungspotential,
. . . unter Verwendung generischer (anwendungsunabhängiger) Methoden,
. . . und zwar völlig transparent für die Anwendung.
Wir sprechen im folgenden von Transactional Data Servers“ oder kurz von Transaktionssystemen“
”
”
und untersuchen Methoden zur Realisierung solcher Systeme. Datenbanksysteme (DBMSs) sind bei
weitem die bedeutendste Klasse von Transaktionssystemen, jedoch gelten alle Betrachtungen auch
für andere transaktionsorientierte Dienste.
Wir konzentrieren uns auf die folgenden Merkmale der vorgestellten Methoden und Algorithmen:
I Zuverlässigkeit (reliability) und
I Korrektheit
I Performance
I Verfügbarkeit (availability)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-5
9.1.1
Anwendungsszenarien
Wir betrachten drei Anwendungsfälle
1. Banküberweisungen (die klassische OLTP-Anwendung),
2. Web-basiertes Electronic Commerce (E-Commerce),
3. Reiseplanung (als Workflow-Anwendung)
9.1.1.1
OLTP: Debit/Credit
Vereinfachte Bankanwendung auf einer relationalen Datenbank mit vier Relationen:
Account (Account ID, Br anch ID, Account Balance)
Br anch (Br anch ID, Br anch Balance)
T eller (T eller ID, Br anch ID, T eller Balance)
Histor y (Account ID, T eller ID, Br anch ID, Amount, Date and T ime)
Transaktionen sind hier entweder Einzahlungen (Deposits) oder Abhebungen (Withdrawals). Die Rolle
des Tellers“ kann auch von einem PC mit Banking-Software oder einem Bankautomaten gespielt
”
werden.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-6
Pseudo-Code für ein Debit/Credit-Programm
read Aid, Tid, Bid, Delta from user input;
/* Delta positive: deposit; Delta negative: withdrawal */
begin transaction;
/* read and modify account balance */
Select Account Balance Into A From Account Where Account Id = Aid;
A := A + Delta;
/* possibly perform various sanity checks */
...
Update Account Set Account Balance = A Where Account Id = Aid;
/* read and modify teller balance */
Select Teller Balance Into T From Teller Where Teller Id = Tid;
T := T + Delta;
Update Teller Set Teller Balance = T Where Teller Id = Tid;
/* read and modify branch balance */
Select Branch Balance Into B From Branch Where Branch Id = Bid;
B := B + Delta;
Update Branch Set Branch Balance = B Where Branch Id = Bid;
/* write audit trail record */
Insert into History Values (Aid, Tid, Bid, Delta, timestamp);
commit transaction;
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-7
Beobachtungen
I Je nach Betrag von Delta“ (+/−) wird ein Deposit oder ein Withdraw realisiert.
”
I Dieses Client-Programm greift nach dem Einlesen der Daten auf alle vier Relationen zu.
I Alle Zugriffe müssen zusammen ausgeführt werden. Nachdem die Transaktion gestartet wurde
muss es von außen so aussehen, als ob entweder alle oder gar keine der Operationen ausgeführt
werden (Atomarität, Atomicity), denn nur so kann die Konsistenz (Consistency) der Datenbank
gewahrt werden.
I . . . insbesondere auch in Gegenwart diverser möglicher Fehlerquellen, d.h. ggf. muss die unvollständig ausgeführte Transaktion zurückgesetzt werden (Fehlerbehandlung, Recovery).
I . . . umgekehrt dürfen Änderungen erfolgreich abgeschlossener Transaktionen nicht verloren gehen
(Dauerhaftigkeit, Durability).
I Zur optimalen Nutzung von Server-Ressourcen und wegen der Performance-Anforderungen vieler gleichzeitiger“ Transaktionen müssen die Zugriffe simultan (concurrent oder echt parallel)
”
ausgeführt werden.
Das einzelne Transaktionsprogramm soll von möglichen Komplikationen und Fehlerfällen abgeschirmt werden (logische Einbenutzersicht): Isolation paralleler Transaktionen untereinander.
I Trade-Off: Concurrency (Performance) ⇔ sequentielle Ausführung (Einfachheit, Korrektheit)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-8
Beispiel 9-1: Zwei Debit/Credit-Transaktionen werden in Prozessen P1, P2 ausgeführt; P1 will $50
vom Konto x abheben, P2 will $100 auf x einzahlen. Ursprünglicher Kontostand: $100. Die Tabelle
zeigt nur die Zugriffe auf die Account-Tabelle, A1, A2 bezeichnen die lokalen Account BalanceVariablen der beiden Prozesse.
P1
Time
P2
/* A1 = 0, x.Account Balance = 100, A2 = 0 */
Select Account Balance Into A1
1
From Account Where Account Id = x
/* A1 = 100, x.Account Balance = 100, A2 = 0 */
2
Select Account Balance Into A2
From Account Where Account Id = x
/* A1 = 100, x.Account Balance = 100, A2 = 100 */
A1 := A1 - 50
3
/* A1 = 50, x.Account Balance = 100, A2 = 100 */
4
A2 := A2 + 100
/* A1 = 50, x.Account Balance = 100, A2 = 200 */
Update Account Set Account Balance = A1
5
Where Account Id = x
/* A1 = 50, x.Account Balance = 50, A2 = 200 */
6
Update Account Set Account Balance = A2
Where Account Id = x
/* A1 = 50, x.Account Balance = 200, A2 = 200 */
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-9
Transaktionsgarantien
Die o.a. Eigenschaften von Transaktionen: Atomarität, Dauerhaftigkeit und Isolation garantieren zusammengenommen, dass sich das Client-Programm nicht um Concurrency und Fehlerbehandlung
kümmern muss, der Transaktionsserver übernimmt diese Aufgaben transparent.
Auf dieser Basis dieser generischen Dienste können hochzuverlässige und performante Informationssysteme realisiert werden, und zwar nicht nur im OLTP-Bereich.
Man fasst diese Transaktionseigenschaften üblicherweise unter dem Acronym ACID-Transactions“
”
zusammen:
A . . . Atomicity
C . . . Consistency
I
. . . Isolation
D . . . Durability
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-10
9.1.1.2
Electronic Commerce
Abwicklung von Bestellungen/Bezahlungen über Internet, z.B. Buchbestellungen. Charakteristisch hier:
in eine solche Transaktion sind mehrere verteilte Server mit unterschiedlicher Hard- und Software
involviert.
Die Anwendung kann etwa in folgenden Schritte ablaufen:
1. Client besucht Internet-Seiten eines Online Book Store mittels eines Browsers und durchsucht den
Katalog.
2. Client füllt schrittweise einen elektronischen Einkaufswagen ( Shopping Cart“) mit einzukaufenden
”
Büchern.
3. Vor dem eigentlichen Kauf wird der Inhalt nochmals inspiziert und ggf. verändert.
4. Client gibt alle relevanten Informationen ein: insbesondere Lieferadresse und Zahlungsinformationen (z.B. Kreditkartennummer oder eine andere Art von Cybercash; diese Informationen werden
typischerweise verschlüsselt)
5. Der Book Store verifiziert die Zahlung mit der Bank, dem Kreditkartenunternehmen oder einem
Clearing House für Cybercash, im Erfolgsfall wird die Lieferung veranlasst und der Client über den
Erfolg benachrichtigt.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-11
Anforderungen an solche Transaktionen
I Offensichtlich müssen auch hier gewisse Daten konsistent gehalten werden, sogar solche, die auf
verschiedenen Rechnern gespeichert sind.
I Das kann bereits für den Inhalt des Shopping Cart beim Client und im Server des Book Store
gelten. (Natürlich auch bei Fehlern auf Client- oder Server-Seite bzw. im Netzwerk!) Weiterhin
kann dies weitere Konsistenzprobleme nach sich ziehen (z.B. im Abgleich mit dem Lager beim
Server des Book Store).
I Während die Konsistenz des Shopping Carts noch als Luxus“ bezeichnet werden könnte, ist sie im
”
letzten Schritt des Ablaufs essentiell: alle Beteiligten (Client, Server, Bank) sollten ein konsistentes
Bild vom Ausgang der Transaktion haben!
Man könnte den Anforderungen auf sehr viele verschiedene Arten gerecht werden, die Verwendung
von Transaktionen mindestens im letzten Schritt vereinfacht jedoch die Realisierung der E-CommerceAnwendung entscheidend, da die Betrachtung der Atomaritätseigenschaften und Fehlerfälle obsolet
wird.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-12
Vergleich mit dem OLTP-Szenario
Es gibt viele Gemeinsamkeiten, aber auch wichtige Unterschiede, die diese Verallgemeinerungen des
klassischen Transaktionskonzeptes nahelegen:
I Die Anwendung ist verteilt auf mehrere Rechner mit heterogener Software (z.B. Nutzung verschiedener DBMSs auf den verschiedenen Servern) und Hardware (weniger relevant).
I Die Server sind nicht notwendigerweise Datenbanksysteme, es können allgemeinere Dienste, wie
z.B. Document Management Servers, Information Repositories, . . . beteiligt sein.
I Die von Transaktionen verursachten Effekte können auch Nachrichten zwischen beteiligten Rechnern sein, nicht nur gespeicherte Daten.
Transaktionstechniken können entsprechend erweitert werden.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-13
9.1.1.3
Workflow Management: Reiseplanung
Workflow Management Systeme dienen der (Teil-) Automatisierung von Geschäftsprozessen“.
”
Workflow = Folge von Aktivitäten (Steps), die zusammen ein bestimmtes Geschäftsziel (Geschäftsvorgang) realisieren, z.B.:
I Kreditantrag bei einer Bank, Versicherungsfall in einer Versicherung,
I Arbeit eines Programmkommittees für eine wissenschaftliche Tagung (Einreichung von Beiträgen,
Begutachtung, Benachrichtigungen, . . .),
I Administrationsabläufe beim Immobilienkauf,
I Behandlungsablauf bzw. -planung für Patienten in einer Klinik, . . .
Kontroll- und Datenfluss einer solchen Anwendung werden im Workflow vorstrukturiert, obwohl zur
Bearbeitungszeit oft Abweichungen möglich sein müssen. So wird der stereotypische, sich immer gleich
wiederholende Teil der Anwendung automatisierbar, während der Entscheidungsspielraum für adhocAbweichungen erhalten bleibt. Dazu ist die Spezifikation der Kontroll- und Datenflüsse das essentielle
Hilfsmittel.
Da in den Entscheidungsverlauf menschliche Interventionen eingebaut sind, ist ein wesentliches Merkmal von Workflows die lange Bearbeitungsdauer; typischerweise wird ein Workflow verteilt über mehrere
verantwortliche Personen, unter Verwendung verschiedener Informationssysteme, oftmals aus unterschiedlichen Unternehmen, abgearbeitet.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-14
Workflow Management Systeme bieten
I Möglichkeiten zur High-Level-Spezifikation solcher Abläufe (sowie zur Simulation, Verifikation
wünschenswerter Eigenschaften, . . .), inklusive der notwendigen Schritte
I eine Laufzeitumgebung, die nach der gegebenen Spezifikation automatisch die Schritte auslöst.
Beispiel 9-2: Als konkretes Beispiel betrachten wir die Reiseplanung zur einer (wissenschaftlichen
oder Fortbildungs-) Tagung. Annahme: Mitarbeiter dürfen sich jährlich eine Tagung im Rahmen eines
Weiterbildungsprogrammes aussuchen.
Folgende Aktivitäten sind involviert:
I Auswahl einer Konferenz aufgrund von Thema, Inhalt, Zeit, Ort, . . .
Wenn keine geeignete Konferenz gefunden wird, dann wird der Prozess beendet.
I Bestimmung der Reisekosten, typischerweise ausgelagert auf ein Reisebüro.
I Bestimmung der Teilnahmegebühr zur Konferenz, diese hängt oft von Zusatzinformationen (Mitgliedschaft in Verbänden) und Zusatzleistungen (Bankett, Tutorien) ab.
I Vergleich der Gesamtkosten mit dem Budget und Buchung nur wenn Budget nicht überschritten.
Da Tagungen ständig teurer werden, die Budgets immer enger, werden mehrere Versuche zugelassen,
aber nur begrenzt viele, damit Terminierung garantiert werden kann.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-15
Das folgende Diagramm zeigt eine Workflow-Spezifikation in Form eines sog. State Charts“ (vgl. end”
licher Automat). Jedes Oval bezeichnet einen Abarbeitungszustand, in dem sich der Prozess befinden
kann, sowie eine Aktion, die bei Erreichen dieses Zustandes ausgeführt wird. Die Ausführung beginnt
in einem ausgezeichneten Startzustand (hier: SelectConference) und terminiert, wenn ein Endzustand
(hier: Go und No) erreicht wird.
Zustandsübergänge werden durch Event-Condition-Action-Rules“ gesteuert, die an den Kanten an”
gegeben sind. Es können so Verzweigungen und Iterationen ausgedrückt werden. Hierarchische Verfeinerung ist durch Schachtelung“ eines tieferliegenden Charts in den Zustand eines höherliegenden
”
Charts möglich. Werden mehrere Charts in einem Knoten geschachtelt, so wird damit Parallelität
ausgedrückt.
/ Budget:=1000;
Trials:=1;
Select
Conference
[ConfFound]
/ Cost:=0
[!ConfFound]
CheckConfFee
Go
Check
Flight
Select
Tutorials
[Cost £ Budget]
Compute
Fee
/ Cost =
ConfFee +
TravelCost
Check
Áirfare
Check
Hotel
Check
Cost
[Cost > Budget
& Trials ³ 3]
Check
Hotel
CheckTravelCost
No
[Cost > Budget & Trials < 3] / Trials++
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-16
Transaktionen und Workflows
Wie können Workflow Management Systeme von Transaktionsservices profitieren?
1. Aktivitäten können Transaktionen auf betroffenen Informationssystemen ausführen. Am Beispiel
sicher innerhalb der Aktivität CheckTravelCost: ausführen verschiedener Transaktionen in Hotel-,
Flug- und ähnlichen Reservierungssystemen. Nicht nur Preisbestimmung sondern ggf. auch Buchung, diese aber nur gemeinsam (z.B. Flug ohne Hotel sinnlos). Hier sind mehrere autonome
Informationssysteme beteiligt!
2. Mehrere Schritte des Workflow kommunizieren über Status-Variablen, so dass z.B. bei Nichtverfügbarkeit eines Fluges eine andere Konferenz gewählt werden kann. Dazu ist der gemeinsame
Zugriff verschiedener Schritte (Transaktionen) auf Status-Variablen des Workflow-Systems nötig
(d.h. der Workflow sollte unter Transaktionskontrolle ablaufen!)
3. Es wäre zu überlegen, ob der ganze Workflow nicht eine Transaktion sein sollte (schließlich ist auch
hier Atomarität gewünscht). Problem jedoch: Langlebigkeit (Stunden, Tage, Wochen)! Klassische
Transaktoinsmechanismen sind dafür völlig ungeeignet (wegen der Kopplung von Atomarität und
Isolation: andere Workflows könnten nicht auf Teilergbnisse zugreifen).
In der Literatur wurden daher flexiblere Transaktionsmodelle vorgestellt, die die verschiedenen
ACID-Eigenschaften entkoppeln, z.B. die Realisierung von Atomarität durch kompensierende Aktionen.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-17
9.1.2
Transaktionen: Konzept & Realisierung
Eine Transaktion (TX) ist ein Vertrag über die Schnittstelle zwischen dem Client und dem Server.
Gegenstand des Vertrages sind die ACID-Eigenschaften.
Dieser Vertrag befreit den Client von allen Auswirkungen von
I Concurrency – d.h. allen Effekten der überlappten oder parallelen Ausführung von Transaktionsprogrammen, insbesondere solcher Datenzugriffe,
I Fehlern – d.h. allen Folgen von ungewollten Programmunterbrechungen aufgrund von Prozessoder Rechnerfehlern.
Anwendungen können so entwickelt werden, als liefen sie in einer strikt sequentiellen, fehlerfreien
Umgebung ab. Dazu ist lediglich die Verwendung von drei Primitiven an der Client-/Server-Schnittstelle
(Transaction Programming Interface) erforderlich:
I BOT – begin of transaction: Start einer TX,
I EOT – end of transaction ( commit“): erfolgreiches Ende,
”
I RBT – rollback transaction ( abort“): erfolgloses Ende mit der Aufforderung, alle Effekte unge”
”
schehen“ zu machen.
Die BOT- und EOT-Aufrufe (die TXs) werden vom Client dynamisch erzeugt, ein Client-Programm
kann mehrere TXs (nacheinander oder gar parallel) starten, siehe Workflow-Beispiel.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-18
Transaktionsserver
Zur Gewährleistung der ACID-Eigenschaften mindestens die folgenden zwei Komponenten:
I Concurrency Control – Synchronisation der (überlappt) parallelen TXs: Isolation der (committed
und aborted) TXs
I Recovery – zur Sicherung der Atomarität und Dauerhaftigkeit der TXs
Anforderungen darüberhinaus:
I Performance: gute Performance bei gegebener HW/SW-Konfiguration bzw. allgemeiner gute
Cost/Performance Ratio bei flexibler Konfiguration. Typischerweise zwei Metriken:
Durchsatz (high throughput): # erfolgreich abgeschlossener TXs pro Zeiteinheit,
Antwortzeit (short response time): Zeitspanne zwischen BOT und EOT einer erfolgreichen
TX aus der Sicht des Client.
I Zuverlässigkeit (reliablility): Korrektes Verhalten in Gegenwart von Fehlern, d.h. TX-Server darf
unter keinen Umständen Daten verlieren, muss immer in einen konsistenten Zustand zurückkehren
können.
I Verfügbarkeit (high availability): wenige Betriebsunterbrechungen, schnelle Fehlerbehandlung bei
Unterbrechungen
I Sicherheit, Administrierbarkeit, Standards, . . .
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-19
Client-/Server-Architekturen
3-Tier-Architecture“:
”
Users
...
Clients
Request
Application
Server
Reply
Application
Program 1
Request
Data
Server
Spezialfälle
( 2-Tier-Architectures“):
”
Client-/Server-Systeme
Application
Program 2
...
Reply
encapsulated
data
Objects
...
exposed
data
I Fat Client – Kombination von Client und
Application Server:
Client kommuniziert direkt mit Data Server (z.B. über SQL, ODBC).
Problem: Data Servers oft nicht für sehr
viele Clients konzipiert.
I Thin Client – Kombination von Application
& Data Server:
Anwendungsprogramm läuft auf dem Server (z.B. objektorientiertes DBMS).
Problem: Skalierbarkeit des Servers.
Stored
Data
(Pages)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-20
Föderierte/Interoperable Server
Typischerweise greifen Anwendungen auf Applikationen und Daten verschiedener Server zu (vgl. Beispiele E-Commerce und Workflow). Es handelt sich um hochgradig verteilte und heterogene Architekturen mit Servern unterschiedlichen Autonomiegrades, die durch geeignete Middleware“ (eine
”
komfortable Kommunikationsinfrastruktur“) verknüpft wird (z.B. CORBA, DCOM).
”
Users
Clients
Application
Servers
Data
Servers
...
...
...
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-21
Datenbanksysteme als TX-Server
Datenbankserver folgen i.d.R. einer Schichtenarchitektur nach folgendem Vorbild. Es ist Aufgabe der
Transaktionsverwaltungskomponenten eines DBMS, die Requests der Clients so auszuführen, dass
neben einem möglichst großen Parallelisierungspotential die ACID-Garantien eingehalten werden (⇒
u.a. Scheduling).
...
Clients
Requests
Language & Interface Layer
Database
Server
Request
Execution
Threads
Query Decomposition &
Optimization Layer
Query Execution Layer
Access Layer
Storage Layer
Data
Accesses
Database
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-22
9.1.3
Aspekte der Datenbank-Integrität
I Inhalt der Datenbank in der Regel Abbild (Modell) der Realwelt (Ausschnitt).
I Daten sollten möglichst korrekt (Einzelbetrachtung) und widerspruchsfrei (im Zusammenhang mit
anderen Daten) sein.
I Datenbank-Änderungsoperationen sollten die Integrität der Datenbank nicht verletzen.
9.1.3.1
Semantische Integrität
I Inhaltsbezogene“ Betrachtung von Datenbank-Operationen.
”
I Einbeziehung Wissen über die Semantik“ von Attributen.
”
I Beispiel 9-3:
PersNr ist zwar als INTEGER definiert, sollte aber nur Werte zwischen 10.000 und 99.999
”
annehmen, da keine höheren Personalnummern vergeben werden. Außerdem muss sich die
letzte Ziffer (Prüfziffer) nach Algorithmus x“ aus den ersten 4 Ziffern ergeben.“
”
Falls Familienstand ledig‘, muss Steuerklasse ∈ {1, 2} sein.“
”
’
Übergang von Familienstand verheiratet‘ auf Familienstand ledig‘ ist nicht erlaubt.“
”
’
’
Eine Kursbuchung mit einem neuen Teilnehmer in der Nimmt teil-Relation darf nur durch”
geführt werden, wenn er/sie bereits in der Teilnehmer-Relation eingetragen wurde.“
Eine Kontobuchung muss stets auf einem Soll- und einem Habenkonto ausgeführt werden
”
(doppelte Buchführung).“
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-23
9.1.3.2
Operationale Integrität (Konsistenz)
I Formale“ Betrachtung von DB-Operationen.
”
I Keine Verfälschungen der Daten/Informationen durch das DBMS selbst (z.B. durch ungenügende
Isolation“ der Benutzer im Mehrbenutzerbetrieb).
”
=⇒ Synchronisation ( Concurrency Control“)
”
9.1.3.3
Integritäts-Wiederherstellung (Recovery)
I Rückgängigmachung von Änderungen wegen Verstoß gegen Integritätsregeln, Benutzer-Abbruch
(ABORT) oder Absturz“ des Anwendungsprogramms
”
=⇒ transaction rollback, undo, in-transaction backout“
”
I Wiederherstellung der Datenbankintegrität nach System-Zusammenbrüchen (SW-Fehler, Stromausfall, . . .)
=⇒ crash recovery
I Wiederherstellung der Datenbankintegrität nach Speicherfehlern (z.B. Disk-Block nach Head
”
Crash“ nicht mehr lesbar)
=⇒ media recovery
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-24
9.1.3.4
Maßnahmen zur Gewährleistung der Integrität
I Semantische Integrität
Durch DBMS-unterstützte Integritätsprüfungen
. z.B. CHECK-, UNIQUE-Klauseln, in SQL-Systemen
Durch (Plausibilitäts-) Prüfungen im Anwendungsprogramm.
I Operationale Integrität (Konsistenz)
Durch geeignete Isolierung“ der Benutzer im Mehrbenutzerbetrieb
”
. z.B. Einhaltung von Sperrprotokollen
. z.B. durch kein vorzeitiges“ Sichtbarmachen von Änderungen.
”
I Recovery (Fehlerbehandlung)
Durch Speicherungsredundanz
. für das Rückgängigmachen von Änderungen
. für das Wiedereinspielen ( Wiederholen“) bereits durchgeführter Änderungen
”
Durch Erzwingen geeigneter Update-Propagation“-Strategien durch die Systempuffer-Verwal”
tung.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-25
9.2
Definition DB-Transaktionen
I Transaktion = Eine durch den Benutzer explizit markierte Folge logisch zusammengehörender
DB-Operationen.
I Kann eine Transaktion (TX) nicht ganz ausgeführt werden (z.B. wegen Integritätsverletzung), so
ihre evtl. vorgenommenen Änderungen in der DB komplett rückgängig zu machen.
⇒ Alles-oder-nichts-Prinzip“ (Atomarität).
”
I Mit COMMIT WORK“ wird eine TX abgeschlossen ( End of Transaction“).12
”
”
I Mit ABORT WORK“ wird die TX abgebrochen und eventuelle Änderungen rückgängig gemacht
”
(in-transaction backout, undo, rollback).3
I Nach jedem COMMIT WORK“ oder ABORT WORK“ (bzw. beim Start der Datenbank”
”
Sitzung) wird implizit ein Begin of Transaction“ (BOT) ausgeführt.
”
I Eine vollständig ausgeführte TX überführt die Datenbank (per Definition!) von einem konsistenten
Zustand S in einen neuen konsistenten Zustand S 0.4
I Eine TX muss deshalb (aus DBMS-Sicht) stets vollständig ausgeführt werden (operationaler
Aspekt).
1 Wir betrachten hier die entsprechenden SQL-Anweisungen für RDBMSe, allgemeine Notationen: BOT, EOT, RBT.
2 I.d.R. gibt es auch einen Arbeitsmodus, bei der jedes SQL-Statement als eigene TX betrachtet wird ( auto-commit“).
”
3 Wie bereits früher erwähnt, lassen sich bei manchen DBMSen DDL-Operationen nicht zurücksetzen; im
Gegenteil, sie implizieren
sogar ein COMMIT WORK“. Bei der Verwendung dieser Operationen in Anwendungsprogrammen ist also Vorsicht geboten!
4 Stellt sich”für eine gegebene TX nachträglich heraus, dass diese Prämisse falsch war, so muss die Datenbank manuell“ (z.B.
”
durch Ausführung einer inversen“ TX) repariert werden“. Normale Recovery-Funktionen sind nicht mehr anwendbar.
”
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-26
I Beispiel 9-4:
Transaktion“ aus Anwendersicht:
”
(Programm mit Embedded SQL)
➢ {BOT}
➢ < Übernehme AngNr, KursNr, TnNr von Eingabemaske >;
➢ < SELECT ∗ FROM Angebot WHERE AngNr = . . . AND KursNr = . . . >;
➢ < if ”NOT FOUND” then Fehlermeldung; ABORT WORK >;
➢ < andere Anweisungen des Anwendungsprogramms >
➢ ...
➢ < SELECT ∗ FROM Teilnehmer WHERE TnNr = . . .>;
➢ < if ”NOT FOUND” then Fehlermeldung; ABORT WORK >;
➢ < andere Anweisungen des Anwendungsprogramms >
➢ ...
➢ < INSERT INTO Nimmt teil VALUES (. . .) >;
➢ COMMIT WORK; {EOT}
Dieselbe Transaktion aus DBMS-Sicht: ( reines SQL“)
”
(Annahme: NOT FOUND-Bedingung war nirgends erfüllt)
{BOT}
< SELECT ∗ FROM Angebot WHERE AngNr = . . . AND KursNr = . . .>;
< SELECT ∗ FROM Teilnehmer WHERE TnNr = . . .>;
< INSERT INTO Nimmt teil VALUES (. . .) >;
COMMIT WORK; {EOT}
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-27
I Beispiel 9-5:
Transaktion“ aus Anwendersicht:
”
➢{BOT}
➢< for i := 1 to 4 do >
➢{
➢< Lese Eingabe von Maske >;
➢< SELECT ∗ FROM . . . >
➢< if FOUND then Fehlermeldung; ABORT WORK >;
➢< INSERT INTO . . . VALUES . . . >;
➢}
➢ COMMIT WORK; {EOT}
Dieselbe Transaktion aus DBMS-Sicht:
(Annahme: FOUND-Bedingung nicht eingetreten)
{BOT}
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
< SELECT ∗ FROM . . . >
< INSERT INTO . . . VALUES . . . >;
COMMIT WORK; {EOT}
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-28
I Anmerkungen:
Das DBMS weiß nichts von der Ablauf-Logik des Anwendungsprogramms.
Eine Transaktion ist aus DBMS-Sicht lediglich eine Folge von SQL-Anweisungen, die stück-
weise“ zur Laufzeit des Programms an das DBMS übergeben werden.
”
I Etwas formaler . . .
τ = {T1, T2, . . . , Tn }
Menge von wechelseitig unabhängigen Transaktionen
(
Reihenfolge der Ausführung beliebig)
T =< A1, A2, . . . , Ak >
Jede Transaktion ist eine Folge von Aktionen
A = [op, a]
Jede Aktion ist Paar aus Operation op und Objektmenge a
op: Datenbankoperation (z.B.: read, write)
a ∈ 2DB, DB = Menge von Datenbank-Objekten
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-29
9.3
9.3.1
Synchronisation parallel ausgeführter Transaktionen (Concurrency
Control)
Einführung
I Zur Erhöhung des System-Durchsatzes werden Transaktionen in Mehrbenutzersystemen in der
Regel nicht sequentiell (hintereinander), sondern (überlappt) parallel ausgeführt.
I Pro Benutzer / Anwendungsprogramm wird (mind.) eine DBMS-Task gestartet (zur Ausführung
des DBMS-Codes)5.
I Übliche Task- Umschalt“-Zeitpunkte: I/O-Operation erfordert Externspeicherzugriff (Systempuffer”
Zugriff reicht nicht aus oder Seite nicht im Systempuffer)6
I DBMS wartet“ nicht auf I/O-Beendigung (asynchrones I/O), sondern schaltet auf andere Task
”
um.
I Aktivierung einer Task durch den Scheduler des DBMS.
I Der Scheduler bestimmt damit die Folge der Lese-/Schreib-Operationen auf der Datenbank.
5 Da in diesen Tasks“ jeweils derselbe (reentrant) Code ausgeführt wird, wird bei der DBMS-Implementierungen oft ein
”
vereinfachtes Task-Konzept verwendet (−→ Threads, Multi-Threaded“ Tasks).
6 Mit Systempuffer“ ist der durch das DBMS verwaltete” Seiten-Puffer gemeint.
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-30
User 1
¾
AP 1
T1 :
User 2
¾
AP 2
..
.
T2 :
..
.
Tn :
SQL-Stmt 14
SQL-Stmt 23
SQL-Stmt 13
SQL-Stmt 22
SQL-Stmt 12
...
...
User n
¾
AP n
..
.
SQL-Stmt n4
SQL-Stmt n3
Transaktionen
SQL-Stmt n2
SQL-Stmt 21
SQL-Stmt
SQL-Stmt 11
n1
Query Compiler / Interpreter
.
..
..
.
r122 [d]
w 222 [d]
r121 [c]
.
..
w 113 [a]
r221 [d]
r112 [b]
r111 [a]
..
.
rn22 [e]
..
.
r213 [a]
r212 [g]
[f]
r
...
211
rn21 [c]
.
..
w n13 [f]
DB-Aktionen
r n12 [f]
rn11 [a]
r213 [a]
Input Queue
w 113 [a]
DBMS-Scheduler
rn11 [a]
executing
..
.
r211 [f]
Schedule
r111 [a]
Datenbank
Abbildung 9-2: Ausführung paralleler Transaktionen durch das DBMS
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-31
I Unkoordinierter Schreib-/Lesezugriff auf Daten kann zu Konsistenzproblemen führen!
nicht integre Zwischenzustände werden sichtbar
verlorene Änderung ( lost update“)
”
einfügen in Lesemenge (Phantome; siehe später)
Beispiel 9-6: Kreditcheck: Für eine gewünschte Abbuchung soll geprüft werden, ob dadurch
das Kreditlimit überschritten würde. Falls ja, Buchung zurückweisen, falls nein, Abbuchung
durchführen.
Programmskizze:
{BOT}
Eingabe Kontonummer k, Abbuchung a;
read
Kontostand s und Kreditlimit kl von k in DB;
if (s − a) < kl then {‘Zurückweisung’, ABORT};
s := s − a;
update Kontostand s von k;
COMMIT WORK {EOT}
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-32
Annahme: Für das Konto 5371 mit Kreditlimit −10.000 DM und aktuellem Kontostand −2.000
DM laufen gleichzeitig zwei Abbuchungsaufträge über je 7.900 DM ein.
T1:
Zeit
Eingabe k, a
read(k) →s1, kl1
hs1 − a1 ≥ kl1i
k.s := s1 − a1
write(k)
COMMIT
T2:
Eingabe k, a
read(k) →s2, kl2
hs2 − a2 ≥ kl2i
k.s := s2 − a2
write(k)
COMMIT
Resultat:
. beide Abbuchungen würden genehmigt.
. die erste Abbuchung würde verloren gehen ( lost update“).
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-33
Inconsistent Read-Problem
Drei Integer-Objekte (für Konten) x, y , z mit Ausgangswerten x = 40, y = 50, z = 30; Bedingung
x + y + z = 120 erfüllt. Prozess 1 berechnet aktuelle Summe, Prozess 2 transferiert $10 von z nach
x:
P1
sum := 0
read(x)
read(y )
sum := sum + x
sum := sum + y
read(z)
sum := sum + z
Time
1
2
3
4
5
6
7
8
9
10
11
12
13
P2
read(z)
z := z − 10
write(z)
read(x)
x := x + 10
write(x)
Prozess 1 gibt Summe 110 aus, was offensichtlich falsch ist, aber schwer zu erkennen.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-34
Beobachtungen
Beide Beispiele zeigen Probleme wie sie auch allgemein bei der Prozess-Synchronisation, etwa in
Betriebssystemen, auftreten können:
I Die aufgetretenen Effekte sind unerwünscht, prinzipiell aber nach außen (d.h. für die ablaufenden
TX-Programme) nicht erkenntlich.
I Keine der möglichen seriellen Ausführungsreihenfolgen (also solche, in denen jeweils eine TX
vollständig zu Ende barbeitet wird, bevor eine neue begonnen wird) hätte ein Problem verursacht.
→ Diese Beobachtung führt später zu einem Korrektheitskriterium.
Das nächste Beispiel zeigt ein spezielles Problem im Zusammenhang mit der Atomaritätsforderung bei
einer unvollständig ausgeführten TX.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-35
Dirty Read-Problem
Ein Prozess verändert Daten, ein zweiter liest die Änderung, anschließend tritt beim ersten ein Fehler
auf:
P1
Time P2
read(x)
1
x := x + 100
2
write(x)
3
4
read(x)
5
x := x - 100
failure & rollback
6
7
write(x)
Da Prozess 2 einen inkonsistenten Zustand von x gelesen hat (sog. uncommitted data“), muss
”
dafür gesorgt werden, dass Prozess 2 nicht daraus falsche Folgeänderungen ableiten kann (z.B. könnte
Prozess 2 auch abgebrochen werden).
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-36
Concurrency Control
Offenbar gibt es mögliche Konflikte zwischen den Operationen verschiedener, gleichzeitig ablaufender
Transaktionen. Es ist Aufgabe der Concurrency Control, die (überlappt) parallelen Abläufe unter
Berücksichtigung solche Konflikte zu steuern.
Am Beispiel ist ersichtlich, dass die genaue Semantik der TX-Programme (was sie genau mit den
Datenelementen tun) weitgehend irrelevant ist. Es genügt, die Lese- und Schreiboperationen auf Seiten
zu beachten. (Hierbei ist es wichtig, dass die Operationen auf den Seiten als atomar angenommen
werden!)
Aus diesem Grund sprechen wir hier vom (Page) Read-/Write-Model der Concurrency Control.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-37
9.3.2
Schedules – Serialisierbarkeit
Definition 9-1: Schedule
Die Sequenz S der vom Datenbank-Scheduler auf der Datenbank ausgeführten Lese- und Schreiboperationen nennt man Schedule.
I Die Lese- und Schreiboperationen eines gegebenen Schedules stammen von mehreren Transaktionen und können verschränkt“ werden (überlappende Ausführung der Transkationen).
”
D
E
i1
i2
Schedule . . . Folge der Aktionen aller Ti ∈ τ .
S = A1 , A1 , . . .
Jede Transaktion T ist Teilfolge in S.
2
2
n
1
T1 A 1 A 2
1
1
...
2
2
...
n
...
A 1 A 2 A 1 A 1 ...
T2 A 1 A 2
Schedule für t
Tn A 1 A 2
n
t
[V9-Sche]
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-38
Definition 9-2: Serieller Schedule
Ein Schedule Sser heißt seriell, wenn er jeweils alle Aktionen einer einzelnen Transaktion direkt
hintereinander ausführt (keine überlappte Ausführung von Transaktionen):
2
2
n
n
1
1
A 1 A 2 ... A 1 A 2 ... A 1 A 2 ...
T2
Tn
T1
I Korrektheit bei paralleler Ausführung?
AXIOM:
Die serielle Ausführung ist korrekt
I Bei paralleler Ausführung:
Nachweisen, dass es (mindestens) eine serielle Ausführung gegeben hätte, die äquivalent zur parallelen Ausführung ist. → Was genau heißt Äquivalenz?
I Erforderlich: Kriterien, wann eine nicht-serielle (überlappende) Ausführung von Transaktionen zu
korrekten (konsistenten) Resultaten führt.
I Sei τ := {T1, T2, . . . , Tn } eine Menge in Spar parallel (gleichzeitig) ausgeführter Transaktionen.
I Sei Z ein konsistenter Ausgangszustand der Datenbank und Z 0 := Spar(Z) der Zustand der
Datenbank nach Ausführung des Schedules Spar ausgehend von Z.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-39
Definition 9-3: Serialisierbarkeit paralleler Transaktions-Ausführungen
Gibt es zu Spar mindestens eine serielle Ausführungsreihenfolge Sser, so dass für jeden gültigen
Zustand Z gilt Sser(Z) = Spar(Z), dann nennt man Spar serialisierbar.
Definition 9-4: Konsistenz von Datenbank-Zuständen
Ein Datenbankzustand Z 0 := Spar(Z) ist konsistent, wenn der Ausgangszustand Z konsistent
ist und Spar serialisierbar ist.
I Forderung: Durch die parallele Ausführung von Datenbank-Transaktionen sollen:
keine anderen Datenbank-Ausgaben und
keine anderen Datenbank-(End-)Zustände auftreten können, als es auch im sequentiellen Be-
trieb möglich wäre (=⇒ logischer Einbenutzer-Betrieb).
I Die Sicherstellung dieser Forderung wird durch geeignete Verfahren zur Synchronisation (concurrency control) paralleler Transaktionen erreicht.
I Fragen:
Wann ist eine gegebene Schedule serialisierbar?
Wie gewährleistet man, dass ein Scheduler nur serialisierbare Schedules erzeugt?
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-40
Definition 9-5: Konflikt
Sei Ai die Menge der Datenbank-Operationen (Aktionen) von Transaktion Ti , Aj die Menge
der Aktionen von Tj (Ti 6= Tj ):
Zwei Aktionen a ∈ Ai und b ∈ Aj stehen in Konflikt, kurz a konflikt b, wenn beide auf dasselbe
Datenbank-Objekt (z.B. Tupel) zugreifen und mindestens eine von beiden eine Schreib-Aktion
ist.
Definition 9-6: Abhängigkeits-Graph G(τ, E)
Zu einem Schedule Spar für τ erzeuge einen Graphen G = (V, E) mit:
Knotenmenge V = τ = {T1, T2, . . . Tn } (wobei gilt: T ∈ τ ⇐⇒ T ∈ Spar)
E Menge der gerichteten Kanten, wobei gilt:
eij ∈ E ⇐⇒ ∃a ∈ Ai , ∃b ∈ Aj : a konflikt b ∧ a < b in Spar.8
Lemma:
Ein Schedule Spar für eine Menge von Transaktionen τ und deren Aktionen ist serialisierbar,
wenn der zugehörige Abhängigkeitsgraph von Spar zyklenfrei ist.
8
a < b in S“ steht für a tritt vor b im Schedule S auf“
”
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-41
Beispiel 9-7: Gegeben sei folgender Schedule der Transaktionen T1, T2 und T3:
Spar := hr1[v ] r2[v ] w1[v ] r3[v ] w2[u] w3[v ]i
Konflikt-Analyse:
r1[v ] < w3[v ]
r2[v ] < w1[v ]
r2[v ] < w3[v ]
w1[v ] < r3[v ]
w1[v ] < w3[v ]
=⇒ e13
=⇒ e21
=⇒ e23
=⇒ e13
=⇒ e13
∈E
∈E
∈E
∈E
∈E
T
1
T
2
T
3
Abhängigkeits-Graph
Resultat: Abhängigkeitsgraph ist zyklusfrei ⇒ Schedule ist serialisierbar!
Äquivalenter serieller Schedule:
Sseq := hr2[v ]w2[u]r1[v ]w1[v ]r3[v ]w3[v ]i
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-42
Beispiel 9-8: Gegeben sei der folgende Schedule der Transaktionen T1, T2, T3 :
Spar := hr1[v ]r2[v ]w2[v ]r3[v ]w1[v ]w3[v ]i
Konflikt-Analyse:
a) r1[v ] <
b) r2[v ] <
c) w2[v ] <
d) r3[v ] <
e) w1[v ] <
w2[v ]
w1[v ]
r3[v ]
w1[v ]
w3[v ]
=⇒
=⇒
=⇒
=⇒
=⇒
e12
e21
e23
e31
e13
∈E
∈E
∈E
∈E
∈E
a)
T
1
b)
T
2
d)
e)
c)
T
3
Abhängigkeits-Graph
Resultat: Der Abhängigkeits-Graph ist nicht zyklenfrei. (Der Schedule ist nicht serialisierbar.)
Anmerkungen:
I Die Aussage in Beisp. 9-8: (Resultat) Abhängigkeits-Graph nicht zyklenfrei ⇒ Schedule nicht
”
serialisierbar“ ist streng genommen nicht korrekt.
I Es gibt Schedules mit zyklischem Abhängigkeits-Graphen, die dennoch serialisierbar sind.9
I Solche Schedules sind im Rahmen des normalen Scheduling allerdings nicht erzeugbar und daher
praktisch nicht relevant.10
I Konstruktion des Abhängigkeits-Graphen i.w. nur für den Korrektheitsnachweis von Synchronisationsverfahren interessant, weniger zur Realisierung von Scheduling-Algorithmen.
9 Die Zyklen werden von Aktionen verursacht, deren Ergebnisse von später folgenden Aktionen blind“ überschrieben werden.
”
10 Vgl. etwa (Weikum und Vossen 2001)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-43
Definition 9-7: (Konflikt-Serialisierbarkeit)
Ein Schedule S heißt konflikt-serialisierbar, wenn es einen seriellen Schedule mit gleicher Abhängigkeitsrelation gibt.
Abhängigkeitsrelation: gibt die Reihefolge der im Konflikt stehenden Operationen verschiedener
Transaktionen in einem Schedule wieder.
In der Literatur: S ∈ CPSR . . . Klasse der Conflict Preserving-Serializable Schedules“
”
Satz 9-1:
Ein Schedule ist genau dann CP-serialisierbar, wenn sein Abhängigkeitsgraph zyklenfrei ist.
Beweisskizze:
I Kein Zyklus =⇒ topologische Sortierung
↓
äquivalenter serieller Schedule S 0
I CP-Serialisierbar =⇒ ∃ äquivalenten seriellen Schedule
↓
kein Zyklus, sonst Widerspruch!
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-44
Vorberechnung serialisierbarer Schedules nicht möglich, weil
I die Aktionsfolgen einer Transaktion in der Regel nicht im voraus bekannt sind
I die Berechnungskomplexität zu hoch wäre: Bei n Transaktionen T1, T2, . . . Tn , mit jeweils mi
Aktionen (1 ≤ i ≤ n) sind insgesamt
«
„ n
P
mi !
i=1
Schedules möglich.11
#sched =
n
Q
mi !
i=1
Zahlenbeispiel:
3 Transaktionen mit je 5 Aktionen: #sched =
11
15!
(5!)3
= 756.756
Das Problem der Bestimmung aller möglichen Schedules lässt sich zurückführen auf die Bestimmung der Permutationen von k
Elementen x1 , x2 , . . . , xk , wobei nicht alle xi (1 ≤ i ≤ k) voneinander verschieden sind.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-45
9.3.3
Sperrverfahren
I Gängiges Synchronisationsverfahren im Betriebssystembereich für Zugriffssynchronisation auf zentrale Betriebsmittel.
I Dort im allgemeinen nur max. eine Sperre pro Betriebsmittel (z.B. Datei) und Anwendung (Prozess/Task).
I Transaktionen greifen in der Regel auf mehrere Datensätze einer Relation oder eines Table Space“
”
(=⇒ BS-Datei) zu.
I Folge:
Funktionalität der BS-Synchronisation für DB-Synchronisation nicht ausreichend.
DBMS führen Synchronisation für Zugriffe auf die Datenbank selbst durch.12
Definition 9-8: Zwei-Phasen-Sperrprotokoll (2PL) (two phase locking)
Ein DBMS beachtet genau dann das Zwei-Phasen-Sperrprotokoll, wenn folgendes gilt:
1. Bevor eine Transaktion (lesend oder schreibend) auf ein Objekt zugreift, muss sie für dieses
eine entsprechende Sperre anfordern.
2. Hat eine Transaktion einmal eine Sperre wieder freigegeben, so darf sie keine Sperren mehr
anfordern.
12 Das DBMS greift hierbei z.T. auf vom Betriebssystem zur Verfügung gestellte Hilfsmittel wie Interprozess-Kommunikation,
Task-Aktivierung und -Deaktivierung, Nicht-Unterbrechbarkeit und Ähnliches zurück.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-46
# S p e rre n
T r a n s a k tio n T
S p e rr-P h a s e
( lo c k p h a s e )
F r e ig a b e - P h a s e
( u n lo c k p h a s e )
t
la ( T )
Abbildung 9-3: Die zwei Phasen des Zwei-Phasen-Sperrprotokolls
I Behauptung:
Unter Einhaltung des Zwei-Phasen-Sperrprotokolls erzeugte Schedules sind stets serialisierbar.
I Beweisskizze:
Sei T S ein gegebener Schedule.
Für jede Transaktion T ∈ T S existiert ein Zeitpunkt la(T ) (siehe Abb. 9-3), an dem sie alle
ihre Objekte aktuell gesperrt hat.
Für jedes Paar (T1 , T2 ) von Transaktionen, T1 , T2 ∈ TS, für die T1 konflikt T2 gilt, gilt auch,
la(T1) 6= la(T2). (D.h. entweder gilt la(T1) < la(T2) oder umgekehrt.)
Die Transaktionen T1 , T2 , . . . des Schedule T S
können daher stets in der durch
la(T1, ), la(T2), . . . definierten Reihenfolge serialisiert werden. Gilt la(Ti ) = la(Tj ) für irgendein Paar von Transaktionen (Ti , Tj ) aus T S, so ist die Serialisierungs-Reihenfolge dieser
Transaktionen untereinander beliebig.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-47
Sperr- und Freigabe-Strategien
I Sperr-Strategien:
a. Eine Transaktion sperrt alle (evtl.) benötigten Objekte gleich am Anfang (preclaiming).
b. Eine Transaktion sperrt ein Objekt erst, wenn sie es aktuell benötigt (sukzessives Sperren).
I Freigabe-Strategien:
c. Eine Transaktion gibt alle gesperrten Objekte erst am Ende frei ( Striktes 2PL“).
”
d. Eine Transaktion gibt (nach Erreichen von la(T ); siehe Abb. 9-3) ein Objekt frei, sobald es
für die weitere Verarbeitung nicht mehr benötigt wird.
Abbildung 9-4: Mögl. Ausprägungen des Zwei-Phasen-Sperrprotokolls
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-48
Sperr- &
FreigabeStrategie
a)
b)
c)
d)
Vorteile
- optimales“ Scheduling möglich, da alle benötigten Betriebsmittel bereits von
”
Anfang an bekannt
- keine Verklemmungsgefahr (keine entspr. Vermeidungs-, Entdeckungs-, Auflösungs-Strategien/-Verfahren notwendig; insb. kein Zurücksetzen wegen Verklemmung)
- es werden nicht mehr Objekte gesperrt als notwendig
- es können dadurch evtl. mehr Transaktionen parallel ausgeführt werden
- isoliertes Zurücksetzen einer Transaktion möglich (d.h. kein fortgepflanztes“
”
Zurücksetzen)
- es können evtl. mehr Transaktionen parallel ausgeführt werden, da die Objekte
für andere Transaktionen früher wieder zur Verfügung stehen.
Abbildung 9-5: Sperr- und Freigabe-Strategien
I Anmerkungen:
Sperr-Strategie a) nur dann sinnvoll anwendbar, wenn entweder Objekte vorher bekannt oder
hinreichend genau abschätzbar.
Freigabe-Strategie d) aus Konsistenzgründen eigentlich nur auf Lese-Sperren anwendbar.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-49
9.3.4
Verklemmungen (Deadlocks)
I Treten bei sukzessivem Sperren (Sperr-Strategie a) in Abb. 9-5) auf.
I Beteiligte Transaktionen verklemmen“ sich ( beissen“ sich gegenseitig fest).
”
”
9-7:
Korrespondierender
Abb. 9-6: Beispiel für Auftreten einer Verklem- Abb.
tet-auf-Graph“ (wait-for graph)
mung
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
War”
9-50
I Maßnahmen:
Zeitschrankenüberwachung (time out): Falls Transaktion zu lange benötigt, wird eine Ver-
klemmung angenommen und die Transaktion abgebrochen und zurückgesetzt (Rollback).
Problem: Wahl der Zeitschranke
. zu klein: Gefahr von unnötigen Transaktionsabbrüchen (besonders kritisch: bei Überbelastung des Rechners kann Zeitüberschreitung wegen Überlast auftreten).
. zu groß: Verklemmungen bleiben lange bestehen, Resourcen werden blockiert, Durchsatz
des Systems nimmt ab).
Deadlock-Erkennung (deadlock detection): Suche nach Zyklen im Wait-for-Graph, peri-
odisch oder bei Nicht-Gewährung von Sperren:
. Ermittlung der Transaktionen, die in eine Verklemmung involviert sind.
. Auswahl eines oder mehrerer Opfer“ (in der Regel werden die Transaktionen, die noch am
”
wenigsten Ressourcen verbraucht haben, ausgewählt).
. Abbruch und Zurücksetzen dieser Transaktionen (oft verbunden mit spezieller Markierung“,
”
um wiederholtes Zurücksetzen derselben Transaktion(en) zu vermeiden).
Deadlock-Vermeidung (deadlock prevention): Einführung von Beschränkungen hinsicht-
lich Wartet-auf-Beziehungen“, etwa: Eine ‘ältere’ Transaktion wartet nie auf Freigabe einer
”
”
Sperre durch eine ‘jüngere’ Transaktion, die jüngere Transaktion wird im Konfliktfall abgebrochen.“
Anmerkung: Time out“ und Deadlock Detection“ am weitesten verbreitet.
”
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-51
9.3.5
Fortgepflanztes Zurücksetzen (Cascading Rollback)
I Kann bei vorzeitiger Freigabe von Schreibsperren auftreten (Freigabe-Strategie d) in Abb. 9-5)
" A b s tu rz "
v o n T 1
S p e rr-P h a s e
F r e ig a b e - P h a s e
T r a n s a k tio n T 1
T r a n s a k tio n T
2
T r a n s a k tio n T
L e g e n d e :
T i
T j
: T j h a t D a te n v o n T i g e le s e n
3
T r a n s a k tio n T 4
t
Abbildung 9-8: Ausgangssituation für fortgepflanztes Zurücksetzen
I Annahme: Durch vorzeitiges Freigeben von Schreib-Sperren durch Transaktion T1 können andere
Transaktionen bereits Daten von T1 vor dem COMMIT von T1 lesen ( dirty read“)
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-52
I Wird T1 zurückgesetzt, basiert die Ausgabe von T2 (und davon abhängiger“ Transaktionen) auf
”
ungültigen Eingabewerten.
I Fortgepflanztes Zurücksetzen ist im allgemeinen nicht tolerabel.
9.3.6
Implementierungsaspekte und Sperrgranulate
I Implementierung von Sperrverfahren mittels gemeinsamer ( zentraler“) Sperrtabelle (lock table)
”
oder Sperrgraph, in der (dem) alle Sperren zusammen mit dem Sperrmodus eingetragen werden.
I Meist wird zwischen Lesesperren (read locks, shared locks) und Schreibsperren (write locks,
exclusive locks) unterschieden.
Lesesperren sind untereinander verträglich, Schreibsperren sind mit keiner anderen Sperre verträglich.
I Der Zugriff auf die Sperrtabelle muss mit Betriebssystem-Mitteln synchronisiert werden
(=⇒ kritischer Abschnitt, wechselseitiger Ausschluss).
I Übliche Sperr-Granulate“ sind
”
Tupel (tuple level locking, row“ level locking) oder
”
13
Seiten (page level locking)
I Gesperrt werden typischerweise Tupel-Identifier (TID) bzw. Seitenadressen (also keine Prädikate,
sondern Adressen!).14
13 Seitensperren sind einfacher zu implementieren, verursachen jedoch potentiell mehr Zugriffskonflikte, da unschärfer“.
”
Tupelsperren bedingen zusätzlich temporäre Seitensperren (nur für die Dauer einzelner Lese- /Schreiboperationen).
14 Für Indexe werden gelegentlich verfeinerte“ Sperrverfahren eingesetzt und z.B. Schlüsselwert-Intervalle gesperrt.
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-53
I Vielfach werden hierarchische Sperrkonzepte (Mehrebenen-Sperrkonzepte) unterstützt:
Tupel −→ Relation −→ Table Space −→ Datenbank
I Zum Teil in Verbindung mit automatischer Sperr-Eskalation (lock escalation), z.B. TupelLevel-Lock −→ Relation-Level-Lock, um die Anzahl von Einzelsperren zu reduzieren. Umschalten“
”
bzw. Umwandlung bei Überschreiten eines vorgegebenen Schwellwertes.
I Für Gewährleistung von repeatable read“ in Verbindung mit Tupel-Einfügungen (und manchen
”
Änderungen), ist Sperren auf Tupel-Ebene nicht ausreichend (=⇒ Phantom-Problem).
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-54
I Beispiel 9-9: Ausgangsbasis: TEILNEHMER-Relation. Die Teilnehmer mit TnNr 171 und 194
sind aus Ulm, der Teilnehmer mit TnNr 173 ist aus Stuttgart.
{BOT T1}
TnNr {Read-1}
SELECT
FROM
Teilnehmer
{BOT T2}
WHERE Ort = ‘Ulm’
...
UPDATE Teilnehmer
<andere Verarbeitung>
SET Ort = ‘Ulm’
...
WHERE
TnNr = 173
...
COMMIT WORK {EOT T2}
SELECT
TnNr {Read-2}
FROM
Teilnehmer
WHERE Ort = ‘Ulm’
COMMIT WORK {EOT T1}
Resultat: Read-1 und Read-2 führen zu unterschiedlichen Ergebnissen, obwohl innerhalb der-
selben Transaktion ausgeführt. Ähnliche Effekte würden sich auch bei Einfügungen von Tupeln
mit Ort = ‘Ulm’ ergeben.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-55
I Konsequenz: Für Einfügungen (und manche Änderungen) ist für repeatable read“ jeweils ein
”
Sperren auf (mindestens) der nächsthöheren Ebene erforderlich (hierarchische, DAG-Sperren):
Einfügen Tupel =⇒ Relation-Lock.
Einfügen Relation =⇒ Table Space-Lock (incl. Katalog).
Einfügen Table Space =⇒ Database-Lock
I Wird in der Praxis jedoch aus Performance-Gründen oft unterlassen (oder nur auf explizite Anforderung hin durchgeführt).
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-56
9.3.7
Optimistische Synchronisationsverfahren15
I Beobachtung 1: Sperr-Aufwand relativ hoch.
Sperr-Anforderung =⇒ Einreihung in Warteschlange (lock request queue)
Suspendierung der Task (Task-Wechsel, task switch)
pro Objekt-Zugriff mindestens ein Lock-Request
Ein- und Austräge aus der Sperrtabelle aufwendig (mehrfach verzeigerte Ketten: Objektbezo-
gen, Transaktion, . . .)
im Verklemmungsfall bleiben Objekte oft relativ lange gesperrt
I Beobachtung 2: In manchen Anwendungen überwiegend
kurze Transaktionen
Lesezugriff
wenig Updates =⇒ wenig Zugriffskonflikte
Aufwand für Sperren im Vergleich zum Gesamtaufwand relativ hoch
15 Vertiefungsliteratur: (Kung und Robinson 1981) – Hat viele Nachfolgearbeiten zum selben Thema inspiriert!
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-57
I Überlegung/Idee: Lieber gelegentlich16 eine Transaktionen umsonst ausgeführt (wegen Konflikt), als ständig einen hohen Aufwand für Sperr-Synchronisation zu treiben.
I Lösungs-Ansatz: Jede Transaktion wird in drei Phasen eingeteilt:
1) Lesephase
2) Validationsphase
3) Schreibphase
1. Lesephase (read phase):
Jede Transaktion protokolliert lokal17 alle Lesezugriffe (=⇒ read set) sowie alle Schreibzugriffe (=⇒ write set)
Alle Schreiboperationen werden zunächst nur auf lokalen Kopien durchgeführt.
Jede Transaktion Ti hält ihren BOT-Zeitpunkt TBOT (Ti ) fest.
Bei Erreichen des (gewünschten) COMMIT-Zeitpunkts tritt Transaktion Ti in die Validationsphase Tval(Ti ) ein.
16 Optimistische“ Annahme: Zugriffskonflikte sind selten.
17 ”Lokal“ bezieht sich hier auf den lokalen Adressraum“ der Task, etwa im Gegensatz zur Sperrtabelle, die (zumindest logisch) in
”
”
einem globalen Adressraum“ realisiert wird.
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-58
2. Validationsphase (validation phase)
Bezeichne TEOT (Tj ) den Zeitpunkt, an dem eine erfolgreich abgeschlossene Transaktion Tj
ihre Änderungen in die Datenbank eingebracht hat.
Validation von Ti :
. Eintritt in den kritischen Abschitt“ 18 zum Zeitpunkt tval(Ti ).
”
. Für alle Transaktionen Tk für die gilt: TEOT(Tk ) ∈ [TBOT(Ti ), tval(Ti )] überprüfe, ob gilt:
write set(Tk) ∩ read set(Ti) = ∅
. Falls Durchschnitt (für alle Tk ) leer, dann führe Änderungsoperationen in der Datenbank
aus (Schreibphase, write phase), sonst Abort/Restart
. Freigeben des kritischen Abschnitts
Anmerkungen:
. Bei dieser einfachen Variante des Verfahrens tritt die Transaktion bereits sehr früh in den
kritischen Abschnitt ein und verbleibt auch bis zum Abschluss der Schreibphase darin.
. Man kann das Verfahren durch einen späteren Eintritt in den kritischen Abschnitt sowie
die Durchführung der Schreibphase außerhalb des kritischen Abschnitts verbessern.
(=⇒ Spezialvorlesung: Transaktionssysteme)
18 Es kann sich jeweils nur eine Transaktion im kritischen Abschnitt befinden. Während sich eine Transaktion (bei diesem
Validationsverfahren) im kritischen Abschnitt befindet, kann somit keine andere Transaktion ihr EOT durchführen (außer bei
ABORT).
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-59
9.3.8
Abschließende Bemerkungen
I Wahl des geeigneten Synchronisationsverfahren kritisch für Performance von Hochleistungs-DBMS
(> 300 TX/s).
I Untersuchungen sprechen dafür, dass für solche Umgebungen optimistische“ Verfahren vorteilhaft
”
sind (keine Blockierungen).
I Synchronisationsverfahren immer noch sehr aktuelles Forschungs- und Entwicklungsgebiet in der
Informatik:
Kombination von optimistischen mit Sperr-Verfahren
Mehr Semantik“ (Prädikatsperren, kommutative Operationen)
”
Spezielle Verfahren für interne“ Datenstrukturen:
. Indices
. Katalog
. ...
”
Verteilte Datenbanken
lange“ Transaktionen ( CAD-Datenbanken“)
”
”
geschachtelte“ Transaktion
”
...
I Korrektheit von Synchronisationsverfahren essentiell für Konsistenz
I Korrektheit kaum zu testen.
⇓
Formaler Korrektheitsnachweis erforderlich !
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-60
9.4
Recovery
I Wiederherstellung eines konsistenten DB-Zustandes nach
=⇒ Transaktions-Recovery
Transaktionsabbruch
=⇒ Crash-Recovery
System-Zusammenbruch
Stromausfall
...
9
permanenten Block-Lesefehlern =
=⇒ Media-Recovery
;
physischer Zerstörung
...
I Recovery-Fähigkeit ist essentiell für Sicherheit und Konsistenz der Daten.
I Verursacht zusätzlichen Aufwand (Speicherplatz), z.B. Protokolldatei ( Log-File“, DBLOG“);
”
”
Archivkopien
I Kann sich negativ auf Performance auswirken (erzwungenes Warten auf Abschluss der LogfileSchreiboperation).
I Versuchung ist groß, am Aufwand für Recovery zu sparen“.
”
I Systeme mit hohen Sicherheitsanforderungen treiben hohen Recovery-Aufwand (Spiegelplatten,
dual logging, . . .)
I Einheit der Recovery ist die Transaktion: Garantie für9
=
Erhaltung der Änderungen abgeschlossener TX
in der DB
;
keine Spuren nicht beendeter TX (!)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-61
9.4.1
Transaktions-Recovery / Crash Recovery
I Wiederherstellung eines konsistenten Datenbankzustandes, so dass die Datenbank enthält:
keine Änderungen nicht abgeschlossener Transaktionen (ABORT, Abbruch)
alle Änderungen abgeschlossener Transaktionen (COMMIT erreicht)
9.4.1.1
Gewährleistung der Zurücksetzbarkeit unvollständiger Transaktionen
Fall 1: update-in-place“,
”
I DBMS führt Änderungen
I Geänderte Seiten können
I Folge:
dirty writes“
”
unmittelbar auf den Original-Seiten/-Tupeln im Systempuffer durch.
vor COMMIT in die gespeicherte Datenbank verdrängt“ werden:
”
DBMS muss ein Undo-Logfile für den Rollback-Fall führen.
Undo-Log-Seiten müssen stets vor den korrespondierenden Daten-Pages auf Platte geschrieben
werden.
Fall 2: workspace copy“, shadow copy“
”
”
I DBMS führt Änderungen nur auf Kopien durch
I Es gelangen keine dirty updates“ vor dem COMMIT einer Transaktion in die physische Daten”
bank.19
I Folge: DBMS kann auf Undo-Logfile verzichten.
19 Arbeiten auf Kopien oder sicherstellen, dass keine geänderten Seiten vor COMMIT aus dem Puffer verdrängt werden.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-62
9.4.1.2
Sicherung der Änderungen abgeschlossener Transaktionen
I Fall 1: forced write“
”
Schreiben der geänderten Seiten aus dem Systempuffer in die Datenbank als Teil der CommitBearbeitung.
Kann Schreibphase nicht beendet werden, gilt Transaktion als nicht abgeschlossen (=⇒ Roll-
back).
Folge
. DBMS muss kein zusätzliches Redo-Logfile“ (s.u.) führen.
”
. Aber: Erzwungenes Schreiben nicht performance-optimal ( write peek“).
”
I Fall 2: deferred write“, write as necessary“
”
”
DBMS erzwingt bei COMMIT nicht das Durchschreiben der geänderten Seiten in die
Datenbank.
Änderungen können bei Systemausfall verloren gehen.
Folge:
. DBMS muss zusätzliche Vorkehrungen treffen: =⇒ Redo-Logfile.
. Redo-Logfile erlaubt, die gemachten Änderungen nochmals in die Datenbank einzubringen.
. Redo-Logfile muss als Teil der COMMIT-Bearbeitung geschrieben werden.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-63
9.4.2
Logfile-Implementierung, Protokollierung
D B M S
D B P u ffe r
... A r c h iv K o p ie
L o g P u ffe r
D B
D B L o g
D B '
D B L o g '
T e m
L o g E n th
fü r T
A B O
U N D
C ra s
p o rä re
D a te i.
ä lt U N D O
r a n s a k tio n R T s o w ie
O / R E D O fü r
h R e c o rv e ry
A r c h iv - L o g
e n th ä lt R E D O
In fo rm . fü r
M e d ia R e c o r v e r y
Abbildung 9-9: DBMS – DB-Log – Übersicht
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-64
9.4.2.1
Vorgehensweise, Logpuffer-Verwaltung
I
UNDO-LOG vor DO“ Für das (jederzeit mögliche) Rücksetzen einer unvollendeten Transakti”
on muss gelten:
Bevor eine Änderung in die DB eingebracht wird, muss die zugehörige UNDO Info auf die (temporäre) LOG-Datei gezwungen werden.
=⇒ WAL Prinzip – Write-Ahead-Log“
”
I REDO-LOG vor EOT“ Für die Wiederholbarkeit einer abgeschlossenen Transaktion muss gel”
ten:
Vor dem Commit einer Transaktion (also vor Schreiben des EOT Logsatzes) müssen alle REDOLogsätze auf die (temporäre u. Archiv-) LOG-Datei gezwungen werden.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-65
Abbildung 9-10: Zusammenhang: DO – UNDO – REDO
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-66
9.4.2.2
Art der Protokollierung
I Im allgemeinen physische Protokollierung (Bitmuster) von Wert-Änderungen
Wert vor der Änderung (before image – BFIM)
Wert nach der Änderung (after image – AFIM)
I Kompaktifizierungs-Möglichkeiten:
Log-Granulat = Seite: XOR-Bitvektor, komprimiert gespeichert
Log-Granulat = Tupel: attributbezogene Aufzeichnung.
I Anmerkungen:
Implementierung Redo-Logfile wie Undo-Logfile.
Oft gibt es nur ein gemeinsames Log (Logeintrag = (alter Wert, neuer Wert)).
Zur Verkürzung von Wiederanlaufzeiten / Begrenzung des Redo-Logfiles wird i.a. ein periodi-
sches Ausschreiben des Systempuffers erzwungen
=⇒ Sicherungspunkt, Checkpoint (siehe später)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-67
9.4.2.3
Zusammenhang Sperr- und Log-Granulat
I Es muss stets gelten: Log-Granulat ≤ Sperr-Granulat!“
”
I Beispiel:
Sperr-Einheit
Seite
Tupel
mögliche Log-(Eintrags-)Einheit
Attribut
Tupel
Seite
Tupel
Attribut
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-68
9.4.3
Durchführung von Crash-Recovery
Bestimme den letzten geschriebenen Log-Datensatz20
Bestimme unvollendete Transaktionen ( Verlierer“: BOT auf LOG, kein EOT)
”
Bestimme vollendete Transaktionen ( Gewinner“: EOT auf LOG)
”
Lese Logdatei rückwärts, ermittle alle UNDO-Logeinträge der Verlierer bis zum Anfang der Logdatei und führe jeweils UNDO durch.
5. Lese vom Anfang der Logdatei her vorwärts alle REDO Logeinträge der Gewinner und führe jeweils
REDO durch.
1.
2.
3.
4.
I Bemerkungen:
Schritte 2, 3 und 4 können beim Rückwärtslesen“ auf einmal erledigt werden (Erläuterung:
siehe Vorlesung)
”
Das Zurückgehen ganz bis zum Anfang der Logdatei verursacht natürlich u.U. einen enormen
Aufwand im Recoveryfall, da dann für sehr viele Transaktionen UNDO bzw. REDO durchgeführt
werden muss.
Abhilfe: Erzeugung von Sicherungspunkten/Checkpoints (siehe später)
20 D.h. bestimme letzten Log-Record, der noch vor dem Crash geschrieben wurde
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-69
I Beispiel für Crash Recovery
T
S y s te m A b s tu rz
1
T
2
T
3
T
T
4
5
t
Erforderliche Recovery-Maßnahmen nach dem Systemabsturz:
UNDO für die Verlierer: T4, T5
REDO für Gewinner: T1, T2, T3
Ob REDO oder UNDO wirklich notwendig ist, hängt davon ab, ob Änderungen in DB eingebracht sind oder nicht. (siehe Abschnitte 9.4.1.1 und 9.4.1.2)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-70
9.4.4
Sicherungspunkte (Check Points)
I Sicherungspunkt (SP): Zeitpunkt, zu dem bestimmte Annahmen über den Zustand der DB
gemacht werden können.
Zweck: REDO-Aufwand im Recoveryfall begrenzen.
I Sicherungspunkterzeugung:
Herauszwingen von geänderten Seiten aus dem DB-Puffer
Unterschiedliche Arten von Sicherungspunkten:
1. Wenn keine Transaktion aktiv ist
=⇒ transaktionskonsistenter Sicherungspunkt
2. Wenn keine Aktion aktiv ist
=⇒ aktionskonsistenter SP
3. Jede Transaktion zwingt bei EOT ihre geänderten Seiten heraus
=⇒ transaktionsorientierter SP
SP-Eintrag in die Logdatei
Evtl. zusätzlich: ID’s der nicht abgeschlossenen Transaktionen zum SP-Zeitpunkt
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-71
9.4.5
Media-Recovery
I Dient (zunächst einmal) zur physischen Wiederherstellung der Datenbank-Dateien
−→ Sicherungskopien von Dateien
−→ seitenbezogene Recovery
I Wiederherstellung der logischen Konsistenz (DB-Sicht):
Wiederherstellung der physischen Konsistenz der DB-Dateien
−→ Zurücksetzen auf letzte Sicherungskopie
Wiederherstellung der logischen Konsistenz der Datenbank
−→ Einspielen der Änderungen vom Redo-Logfile21
22
I Komplette Sicherungskopie (disk dump):
Komplette Sicherungskopie aller Datenbank-Dateien
Voraussetzung: kein Transaktions-Betrieb
I Sicherung nur der Änderungen (incremental dumping):
Nur die seit dem letzten Dump geänderten Seiten werden kopiert.
Bitvektor hilft geänderte Seiten schnell zu lokalisieren.
Bis zum nächsten kompletten Dump müssen alle Incremental Dumps aufbewahrt werden.
Durchführung ggf. auch im laufenden Betrieb (z.B. als konkurrierende Transaktion) möglich.
21 Dies ist ein weiterer Grund, warum man stets ein Redo-Log haben sollte.
22 Man sagt in diesem Zusammenhang auch, dass die Transaktionen wiederholt“ werden.
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-72
9.4.6
Abschließende Bemerkungen
I Synchronisations- und Logkomponente sehr performance-kritische DBMS-Teile
I Bei Höchstleistungs-DBMSen u.U. mehrere tausend Synchronsiations- und Logaufrufe pro Sekunde!
I Wahl des richtigen Synchronisations- und Recovery-Verfahrens daher sehr wichtig für
Verlässlichkeit des DB-Systems
Anwortzeitverhalten
I Eignung der Verfahren nicht ganz unabhängig vom Anforderungsprofil der (typischen) Anwendungen
I Neue DB-Anwendungsklassen/neue DB-Systemtechnologien stellen neue Herausforderungen
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-73
9.5
9.5.1
Verteilte Informationssysteme
Grundlegende Konzepte
Verteiltes Informationssystem besteht aus einer Menge von Informationseinheiten, die auf mehreren
über ein Kommunikationsnetzwerk (LAN, WAN, Internet) verbundenen Rechnern verteilt sind:
I Autonomie: Auf jedem Server können lokale Anwendungen ohne die Daten der anderen Server
arbeiten.
I Integration: in globalen Anwendungen über das Kommunikationsnetzwerk.
Die an dem Kommunikationsnetzwerk beteiligten Rechner können unterschiedliche Aufgaben haben
und auf verschiedene Weise miteinander kommunizieren.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-74
9.5.1.1
Mögliche Architekturen
I Kopplung/Integration mehrerer Subsysteme
IS
SubIS 1
SubIS 2
...
SubIS k
Zum Beispiel:
. Textsystem + Graphiksystem + Datenbanksystem ( + Editoren. . .)
. Datenwörterbuch/Directory
Typisch: Funktionalität mehrerer Subsysteme über eine Schnittstelle ansprechen
Anwendungen: Büro, CIM
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-75
I Örtliche Verteilung/lokale Verarbeitung
IS 2
IS 1
IS
3
Gleiches“ IS an verschiedenen Orten
”
Grundlage: Verteilte DBMSe
Anwendung: Filialen (Bank, Versicherung . . .)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-76
I Client-/Server- oder Server-Workstation-Kopplung
WS
WS
S
1
WS
2
k
Workstations für spezielle Aufgaben ausgestattet
Anwendung: Reisebüros, Versicherungen,. . .
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-77
9.5.1.2
Grundlegender Aufbau eines VDBMS
globales Schema
Fragmentierungsschema
Zuordnungsschema
lokales Schema
...
lokales Schema
lokales DBMS
...
lokales DBMS
...
Station S1
Station Sn
Abbildung 9-11: Aufbau eines verteilten DBMS
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-78
Ein wesentlicher Entwurfsaspekt besteht in der Entscheidung, wie die Daten auf den verschiedenen
Rechnern fragmentiert und ggf. repliziert werden:
I redunzfreie Allokation
I Allokation mit Replikation
Fragmentierung
R
Allokation
R11
R1
Station S1
R12
R2
R21
R3
Station S2
R23
R33
Station S3
Abbildung 9-12: Fragmentierung und Allokation
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-79
I Fragmentierung kann auf verschiedene Weise geschehen:
horizontal: Selektionen
vertikal: Projektionen
kombiniert
I Transparenz: Verteilung nicht sichtbar. Dadurch können Benutzer/Anwendungsprogramme flexibler
arbeiten.
Transparenz ist auf verschiedenen Stufen möglich:
Fragmentierungstransparenz
Allokationstransparenz
Lokale Schematransparenz
I Anfrageoptimierung in verteilten Datenbanken:
Allokationstransparenz
wesentlicher Kostenfaktor: Austausch von Teilergebnissen zwischen verschiedenen Rechnern.
spezielle Join-Algorithmen, die lokal ausgeführt werden, und nur notwendige Daten übertragen
=⇒ Semi-Joins
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-80
9.5.2
Das Zwei-Phasen-Commit-Protokoll ( Two-Phase-Commit, 2PC“)
”
I Idee: Zur Beendigung einer globalen Transaktion wird ein (Zwischen-)Zustand eingerichtet, der ein
sicheres gemeinsames COMMIT oder ABORT der beteiligten Subsysteme ermöglicht.
GST1
BOT1
Opk,1 … OpK,n
LDBMS1
Opl,1 … Opl,o
LDBMS2
GST2
BOT2
Verzögerung bis zum EOTi
der längsten GSTi
GST3
BOT3
Opk,1 … OpK,p
LDBMS3
Notation: GSTi ist eine globale Subtransaktion, d.h. eine lokale Transaktion, die einen Teil einer
globalen TX auf jeweils einem lokalen System realisiert.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-81
I Die zwei Phasen des 2PC:
Kern:
Alle an der Ausführung von T beteiligten Knoten stimmen ab, ob T global
committed“ oder aborted“ wird.
”
”
(Knoten, auf dem T gestartet ist, ist Koordinator“, übrige sind Agenten“)
”
”
Phase 1:
Prepare to Commit and Vote“
”
Koordinator fordert Agenten auf, Commit von T vorzubereiten und fordert Abstimmungsergebnis an (⇒ Sichern der After-Images)
Phase 2:
Commit/Abort“
”
Nach Erhalt aller positiver Stimmen (Fall Commit) oder mindestens einer negativen
Stimme (Fall Abort) teilt der Koordinator
Ergebnis mit:
COMMIT im Fall Commit, ABORT, falls mind. eine Abort-Meldung
(⇒ Freigabe von Sperren)
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-82
I Übersicht: 2-Phase-Commit
Koordinator
Commit-Wunsch
von T
K1
Sende Prepare to Commit
an alle Agenten
K2
von mind.
einem Agenten
"No" erhalten
von allen Agenten
"Yes" erhalten
K3
Speichere
"EOT-COMMIT"
für T sicher
K AB
Sende
"ABORT T"
an alle
Agenten
K CO
Sende
"COMMIT T"
an alle
Agenten
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-83
Agenten
"Prepare to Commit"
erhalten
A1
Sende "Yes"
an Koordinator
Sende "No"
an Koordinator
A2
"ABORT T"
erhalten
AAB
setze T
zurück
"Commit T"
erhalten
A CO
führe
COMMIT für T
aus
bei Knoten-Crash oder Unterbrechung: Time-Out“ Parameter!
”
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-84
9.5.3
Synchronisation replizierter Daten
I Einfache Möglichkeit: Wenn ein Datum geändert wird, so muss es in allen Fragmenten, wo es
auftritt sofort geändert werden.
Vorteil: Lesetransaktionen können sich das optimale Fragment aussuchen.
Nachteil: Schreibtransaktionen müssen alle zugehörigen Fragmente sperren.
I Alternative: Quorum-Consensus:
Schreibtransaktionen verändern nur einen bestimmten Anteil Qw der beteiligten Fragmente.
Lesetransaktionen lesen mindestens Qr Fragmente, um sicher zu sein, dass das gelesene Datum
korrekt ist.
Dabei können die Quoren flexibel gesetzt werden, damit sichere“ von unsicheren“ Servern
”
”
unterschieden werden können.
Dafür muss gelten:
1. Qw (A) + Qw (A) > W (A) und
2. Qr (A) + Qw (A) > W (A).
I Beispiel 9-10:
Station (Si )
S1
S2
S3
S4
Kopie (Ai )
A1
A2
A3
A4
Gewicht (wi )
3
1
2
2
Mögliche Quoren:
Qr (A) = 4
Qw (A) = 5
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-85
9.6
Zusätzliche Literaturhinweise (Auswahl)
I zu Architektur und Realisierung von DBSen: (Härder 1999; Heuer und Saake 1999; Ramakrishnan
und Gehrke 2003; Mitschang 1995; Elmasri und Navathe 2000)
I zu Transaktionsverwaltung: (Bernstein und Newcomer 1997; Jajodia 1997; Gray und Reuter 1994;
Weikum 1988; Bernstein et al. 1987; Lockemann und Schmidt 1987; Reuter 1981; Weikum und
Vossen 2001)
I zu Verteilten Datenbanken: (Ceri und Pelagatti 1984; Özsu und Valduriez 1991; Kudlich 1992;
Bell und Grimson 1992; Gray und Reuter 1994; Dadam 1996)
Bell, D. und J. Grimson (1992). Distributed Database Systems. Addison-Wesley.
Bernstein, P. und E. Newcomer (1997). Principles of transaction processing. Morgan Kaufmann.
Bernstein, P.A., V. Hadzilacos und N. Goodman (1987). Concurrency Control and Recovery in Database Systems.
Addision-Wesley.
Ceri, S. und G. Pelagatti (1984). Distributed Databases, Principles and Systems. McGraw-Hill.
Dadam, P. (1996). Verteilte Datenbanken und Client/Server-Systeme: Grundlagen, Konzepte und Realisierungsformen. Springer.
Elmasri, R. und S. Navathe (2000). Fundamentals of Database Systems. Addison-Wesley, Reading, MA., 3 Aufl.
Titel der deutschen Ausgabe von 2002: Grundlagen von Datenbanken.
Gray, J. und A. Reuter (1994). Transaction processing — concepts and techniques. Morgan Kaufmann.
Härder, T (1999). Datenbanksysteme: Konzepte und Techniken der Implementierung. Springer.
Heuer, A. und G. Saake (1999). Datenbanken: Implementierungstechniken. Int’l Thompson Publishing, Bonn.
Jajodia, S. (1997). Advanced transaction models and architectures. Kluwer.
Kudlich, H. (1992). Verteilte Datenbanken, Systemkonzepte und Produkte. Siemens Nixdorf Informationssysteme
AG.
Kung, H.T. und J. Robinson (1981). On Optimistic Methods for Concurrency Control. ACM Transactions on
Database Systems, 6(2):213–226.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-86
Lockemann, P.C. und J. Schmidt, Hrsg. (1987). Datenbank-Handbuch. Springer-Verlag.
Mitschang, B. (1995). Anfrageverarbeitung in Datenbanksystemen - Entwurfs- und Implementierungsaspekte.
Vieweg.
Özsu, M.T. und P. Valduriez (1991). Principles of Distributed Database Systems. Prentice Hall.
Ramakrishnan, R. und J. Gehrke (2003). Database Management Systems. McGraw-Hill, New York, 3 Aufl.
Reuter, A. (1981). Fehlerbehandlung in Datenbanksystemen. Carl Hanser-Verlag.
Weikum, G. (1988). Transaktionen in Datenbanksystemen. Addison-Wesley.
Weikum, Gerhard und G. Vossen (2001). Transactional Information Systems: Theory, Algorithms, and Practice
of Concurrency Control and Recovery . Morgan Kaufmann, San Francisco, CA.
c M. Scholl, 2003/04 – Informationssysteme: 9. Mehrbenutzeraspekte, Transaktionen, Parallelität und Fehlertoleranz
9-87