Introduction To Transaction Management

Einführung ins Transaction Management
Distributed Concurrency Control
Distributed DBMS Reliability
Autor:
Thomas Schnöller
0008691
[email protected]
Seite 1
Inhaltsverzeichnis
1. Einführung ins Transaction Management
1.1 Definitionen
1.2 Eigenschaften von Transaktionen
1.2.1 ... Untrennbarkeit
1.2.2 ... Konsistenz
1.2.3 ... Isolation
1.2.4 ... Widerstandsfähigkeit
1.3 Typen von Transkation
1.3.1 ... Kriterium der Dauer von transaktionen
1.3.2 ... Kriterium der Organisation der Lese- und Schreibaktionen
1.3.3 ... Kriterium der Struktur
2. Distributed Concurrency Control
2.1 Klassifizierung von wichtigen Gleichzeitigkeitskontrollmechanismen
(Algorithmen)
2.2 Locking-Based Concurrency Control Algorithms
2.3 Timestamp-Based Concurrency Control Algorithms
3. Distributed DBMS Reliability
3.1 Definition
3.2 System, Status und Fehler
3.3 Zuverlässigkeit und Verfügbarkeit
3.4 Gründe für Fehler in verteilten Systemen
3.5 Ansätze und Techniken zur Fehlervermeidung
3.6 Fehler in verteilten DBMS
3.6.1 ... Transaction Failures
3.6.2 ... Site (System) Failures
3.6.3 ... Media Failures
3.6.4 ... Communication Failures
Seite 2
1 Einführung ins Transaction Management
Das Konzept einer Transaktion wird in der Datenbank-Domain als eine Grundeinheit des
konsistenten und zuverlässigen computings angesehen.
Transaction management behandelt das Problem die Datenbank immer in einen konsistenten
Zustand zu halten, auch wenn gleichzeitige Zugriffe und Fehler auftreten.
1.1 Definition
Eine Transaktion besteht aus einer Sequenz von Schreib- und Leseoperationen auf eine
Datenbank zusammen mit Berechnungsschritten.
Im Prinzip macht eine Transaktion genau das Gleiche wie eine Query, mit dem Unterschied
dass man nun die Garantie hat, dass sich die Datenbank in einem konstanten und
zuverlässigen Zustand befindet.
1.2 Eigenschaften von Transaktionen
Es gibt vier Eigenschaften, die der Grund sind, dass eine Transaktion einen konsistenten und
zuverlässigen Datenbankstatus garantiert.
 Untrennbarkeit(=Atomicity)
 Konsistent(=consistency)
 Isolation (=isolation)
 Widerstandsfähigkeit(=durability)
1.2.1 Untrennbarkeit
Die Untrennbarkeit ist darauf zurückzuführen, dass eine Transaktion als eine Einheit von
Operationen angesehen wird. Darum werden entweder alle Transaktionen Aktionen beendet,
oder keine von Ihnen. Dies ist auch bekannt alst das sogennante „Alles oder Nichts Prinzip“.
1.2.2 Konsistenz
Die Konsistenz einer Transaktion, ist einfach ihre Richtigkeit. Eine Transaktion ist ein
korrektes Programm , dass einen konsistenten Datenbankstatus zu einem anderen mapped.
1.2.3 Isolation
Isolation ist die Eigenschaft, die jede Transaktion braucht um die ganze Zeit eine konsistente
Datenbank zu sehen. Eine ausführende Transaktion kann ihre Ergebnisse nicht anderen
gleichzeitig ausführenden Transaktionen offenbaren, bis zu deren Einsatz.
1.2.4 Widerstandsfähigkeit
Diese Eigenschaft macht sicher, dass wenn eine Transaktion einsetzt ihre Resultate permanent
sind und diese auch nicht aus der Datenbank gelöscht werden können.
Seite 3
1.3 Typen von Transaktionen
Transaktionen können auf Grund verschiedener Kriterien klassifiziert werden.
1.3.1 Kriterium der Dauer von Transaktionen

Short-life Transaction
Haben eine kurze Ausführungs- und Antwortzeit und auch eine relativ kleine
Datenbank z.B.: Banking Transaktionen, Fluglinien Reservierungs Transaktionen....

Long-life Transaction
Sind das Gegenteil der short-life Transaction z.B.: CAD/CAM database, statistische
Applikationen, komplexe Abfragen, image processing.
1.3.2 Kriterium der Organisation der Lese- und Schreibaktionen

General Model
Lese- und Schreibaktionen haben keine bestimmte Reihenfolge

Two-step Model
Leseaktionen werden vor den Schreibaktionen durchgeführt

Restricted Model(=read-before-write)
Daten müssen gelesen werden bevor etwas geschrieben werden kann.

Restricted two-step Model
Vereint das Two-Step Model und das Restricted Model

Action Model
Besteht aus dem Restricted Model mit der Beschränkung, dass jedes <Lese und
Schreib> Paar automatisch ausgeführt wird.
Seite 4
General model
Two-step model
Restricted model
Restricted two-step
model
Action Model
1.3.3 Kriterium der Struktur

Flat Transactions
Haben einen einzigen Startpunkt und einen einzigen Endpunkt. Die meiste Arbeit im
Transactionmanagement beruht auf Flat Transactions

Nested Transactions
Man erlaubt einer Transaktion, eine andere mit ihren eigenen Start- und Endpunkt zu
inkludieren.
o Open nested Transactions
o Closed nested Transactions

Workflows
Neuer Typ. Wurde erstellt da die alten Typen den Anforderungen von komplexen
Geschäftsmodellen nicht gerecht wurden.
Seite 5
2 Distributed Concurrency Control
Das Level der Gleichzeitigkeit (=Die Anzahl der gleichzeitig ausgeführten Transaktionen) ist
wahrscheinlich der wichtigste Parameter in verteilten Systemen.
Der Concurrency Control Mechanism versucht einen Kompromiss zu finden, um einerseits
die Konsistenz der Datenbank zu gewährleisten und auch ein Hohes Level der
Gleichzeitigkeit (High Level Concurrency)
2.1 Klassifizierung von wichtigen
Gleichzeitigkeitskontrollmechanismen (Algorithmen)
Das weitverbreitetste Klassifizierungsmerkmal ist das Kriterium der Synchronisation. Der
Durchbruch in der Klassifizierung der Gleichzeitigkeitskontrollalgorithmen liegt in den 2
folgenden Klassen:
Locking: Basieren auf den exklusiven zugriff von gemeinsamen Daten.
Protocols: Ordnen die Ausführungen von Transaktionen auf Grund eines Rule Set.
Diese beiden Klassen können wiederum aus zwei verschiedenen Sichtweisen betrachtet
werden:
Pessimistische Sichtweise(Pessimistic View): Viele Transaktionen werden einen
Konflikt mit anderen Transaktionen haben
Validate
-
Read
Compute
Wri te
Optimistische Sichtweise (Optimistic View): Nicht viele Transaktionen werden
Konflikte mit anderen Transaktionen haben.
Read
Compute
Validate
Wri te
Auf Grund dieser Sichtweisen, kann man die Concurrency Control Methods wieder in zwei
Klassen einteilen:
Pessmistic Algorithms: Synchronisieren die gleichzeitige Ausführung von
Transaktionen schon früh im Lebenskreis der Ausführungen.
Optimistic Algorithms: Verzögern die Synchronisation der Transaktionen bis zur
Terminierung.
Seite 6
Concurrency Control
Algorithms
Pessimistic
Locking
Optim istic
Timestamp
Orderi ng
Cent ralized
Basic
Prim ary
Copy
Multi version
Distribut ed
Conservati ve
Hypri d
Timestamp
Orderi ng
Locking
2.2 Locking-Based Concurrency Control Algorithms
Die Grundidee die hinter diesem Konzept steht ist sicher zu gehen, dass gemeinsame Daten,
auf die von Operationen zugegriffen wird, die einen Konflikt verursachen können, immer nur
einer Operation zugreifen kann. Dies passiert durch den sogenannten „lock“ in jeder Einheit.
Der lock wird von jeder Transaktion gesetzt bevor auf sie zugegriffen wird und wird am Ende
der Benutzung gelöst. Ein locked unit kann nicht von einer Operation benutzt werden, wenn
diese schon von einer anderen gelocked wurde.
Es gibt zwei Typen von locks:
Read lock
Write Lock
Die Kompatibilität von locks ist hier noch zu erwähnen. Man spricht von Kompatibilität
zweier lock-Modes, wenn 2 Transaktionen, die auf die selben Daten zugreifen, die
Berechtigung für einen lock zur selben Zeit haben.
Read Lock
Write Lock
Read Lock
compatible
Not compatible
Write Lock
Not compatible
Not compatible
2.3 Timestamp-Based Concurrency Control Algorithms
Ein Zeitstempel ist ein einfaches Identifizierungsmittel für Transaktionen. Zeitstempel sind
einzigartig und monoton (Zwei Zeitstempel, die vom selben Transaction Manager generiert
wurden, sollten monoton steigen sein).
Seite 7
Es gibt eine Vielzahl von Möglichkeiten, wie Zeitstempel zugewiesen werden können. Eine
Methode ist, einen global (systemweit) steigenden Zähler zu verwenden. Dies stellt in
verteilten Systemen aber ein Problem dar. Darum verwendet, jede Seite in einem verteilten
System meist ihren eigenen lokalen Zähler.
Seite 8
3 Distributed DBMS Reliability
3.1 Definition
Distrbuted DBMS Reliability:
Ein zuverlässiges DBMS ist eines, dass auch dann noch User-Requests bearbeiten kann, auch
wenn das darunter liegende System unzuverlässig ist. In anderen Worten, wenn Komponenten
der verteilten Umgebung Fehler haben, sollte ein zuverlässiges DBMS in der Lage sein weiter
User-Requests zu bearbeiten ohne die Datenbankkonsistenz zu zerstören.
3.2 System, Status und Fehler
System: Ein System besteht aus einer Sammlung von Komponenten und interagiert mit seiner
Umwelt durch Antworten mit einem bestimmten Verhalten, die auf bestimmte
Reize(=Stimuli) erfolgen. Jede Komponente stellt ebenfalls ein System dar und kann daher als
Subsystem bezeichnet werden. Die Art wie die Komponenten eines Systems
zusammengesetzt werden, nennt man Design.
Component 1
Stimuli
Component 2
Response
Component 3
Externer Status: Kann die Antwort sein, die ein System auf einen externen Reiz gibt.
Interner Status: Ist der externe Status der Komponenten des Systems. Auch hier verändert das
System den Status auf Grund externer Reize.
Spezifikation: Beinhaltet das gültige Verhalten, die ein System in einem bestimmten Status
hat.
Fehler: Es gibt 3 Arten von Fehlern die unterschieden werden müssen:
 Failure: Jedes abweichende Verhalten von der Spezifikation ist ein Fehler.
 Error: Der Teil eines Status der falsch ist.
 Fault: Jeder Fehler in den internen states der Komponenten oder des Designs eines
Systems.
Kettenreaktion: Fault  Error  Failure
Seite 9
3.3 Zuverlässigkeit und Verfügbarkeit
Zuverlässigkeit bedeutet, dass in einem System, während eines bestimmten Zeitintervalls
keine Fehler auftreten. Wird typischerweise für Systeme beschrieben, die nicht repariert
werden können (z.B.: Weltraum-basierte Systeme), oder wo die Operation des Systems so
kritisch ist, dass keine Zeit zum Reparieren toleriert werden kann.
Verfügbarkeit hingegen bedeutet, dass ein System zu einem bestimmten Zeitpunkt genau das
macht, was in der Spezifikation spezifiziert wurde. Eine bestimmte Anzahl an Fehlern kann
auftreten, wenn diese aber beseitigt wurden, ist das System zu einem bestimmten Zeitpunkt
wieder Verfügbar. Damit sieht man, dass sich Verfügbarkeit auf reparable Systeme bezieht.
Zuverlässigkeit und Verfügbarkeit sind deshalb von einander zu unterscheiden.
3.4 Gründe für Fehler in Verteilten Systemen
90% der Hardware System Fehler tritt auf Grund von sogenannten Soft Faults auf. Diese
Statistik hat sich auch nicht seit den Anfängen des Computings geändert.
Es gibt auch verschiedene Studien über Fehler Statistik von bestimmten Computersystemen:

1985: IBM/XA Operating System mit Stanford linear accelerator (SLAC) :
SLAC data
Software
12%
Hardware
Operations
14%
Environment
17%

Environment
Hardware
57%
Operations
Software
1985: Tandem Computers (beruht auf Frühwarnmeldungen):
Tandem data
Software
33%
Hardware
24%
Hardware
Environment
Operations
Environment
20%
Operations
23%
Seite 10
Software

Performance Studie des AT&T 5ESS digital Switch:
5ESS sw itch data
Softw are
44%
Hardw are
32%
Hardw are
Unknow n
Operations
Unknow n
6%
Softw are
Operations
18%
3.5 Ansätze und Techniken zur Fehlervermeidung
2 fundamentale Ansätze zur Fehler Vermeidung sind die Toleranz und Prävention von
Fehlern.
Die Toleranz von Fehlern beruht auf den Designansätzen von Systemen, welche es in
Betracht ziehen, dass Fehler auftreten können. Das Design versucht Mechanismen in das
System einzubauen, damit Fehler entdeckt und entfernt bzw. kompensiert werden können
bevor sie einen Systemfehler verursachen.
Fehlerprävention hingegen hat das Ziel, dass das implementierte System keine Fehler
beinhaltet.
Beispiele für Techniken wären z.B.:
Redundanz in Systeme einbauen: Falls eine Komponente ausfällt
übernimmt(=kompensieren) die redundante Komponente die Aufgaben.
Modularer Aufbau des Systems: Modularität des Systems ermöglicht die Isolation von
Fehlern in einer Komponente. Ist darum für Software- Hardwaresysteme wichtig.
3.6 Fehler in verteilten DBMS
Um ein zuverlässiges DBMS zu designen ist es notwendig die Fehler, die in so einem System
auftreten können zu identifizieren um ein mögliches Recovery zu gewährleisten.
Der Datenbank Recovery Manager muss dabei 4 Typen von möglichen Fehlern kennen.
Transaction Failures(aborts)
Site (system) failures
Media (disk) failures
Communication line failures
3.6.1 Transaction Failures
Es gibt eine Vielzahl von Möglichkeiten, wieso eine Transaktion einen Fehler verursachen
kann z.B.: incorrect input data, deadlock. Der gebräuchliche Ansatz für einen
Transaktionsfehler ist die Möglichkeit eines Abbruchs (=abort) der Transaktion.
Seite 11
3.6.2 Site (System) Failures
Ein solcher Fehler ist meist auf einen Hardwarefehler (Prozessor, Hauptspeicher,
Stromversorgung ...) oder Softwarefehler (bug im Betriebssystem oder im DBSM)
zurückzuführen.
Ein System Fehler führt einen Verlust von Hauptspeicherinhalten mit sich.
Darum ist bei einem solchen Fehler jeder Inhalt der Datenbank, der in einem Buffer des
Hauptspeichers gelegen hat verloren. In verteilten Systemen werden die System Failures auch
als Site Failures bezeichnet, weil ja z.B.: ein Computer im System (=andere Seite) ausfallen
kann. Man unterscheidet hierbei auch noch zwischen totalen Fehlern (=Alle sites im verteilten
System sind ausgefallen), oder auch partiellen Fehlern (=einer oder einige sites im VS sind
ausgefallen).
3.6.3 Media Failures
Treten bei sogenannten secondary storage devices auf, die die Datenbank speichern. Können
bei Betriebssystemfehlern als auch Hardwarefehlern auftreten. Das DBMS ist insofern
betroffen, als das alle Daten, die sekundär gespeichert wurden zerstört werden. Abhilfe schafft
dabei das Duplizieren und Archivieren des Sekundärmediums.
3.6.4 Communication Failures
Die obigen Fehler treten sowohl in zentralisierten als auch in verteilten Systemen auf.
Communication Failures hingegen treten nur in verteilten Systemen auf. Es gibt verschiedene
Arten von Communication Failures z.B.: Fehler in Nachrichten, unsachgemäß angeforderte
Nachrichten, verlorene Nachrichten, line failures.
Verlorene oder nicht lieferbare Nachrichten sind meist die Konsequenz eines line failures.
Falls eine Kommunikationslinie fällt, kann es sein, dass das Netzwerk in zwei oder mehrere
getrennte Gruppen fällt. Dies wird auch als Netzwerk partitioning bezeichnet.
Seite 12