Transaktion

http://gotthard.work
Transaktion
Das wichtigste Merkmal einer Transaktion ist die Vollständigkeit. Die Dauer einer Transaktion sollte
so kurz wie möglich, jedoch so lang wie notwendig sein. Transaktionen werden entweder ganz
oder gar nicht durchgeführt. Sie gehen von einem konsistenten Zustand in einen anderen
konsistenten Zustand.
A …… Atomicity (unteilbar)
C …… Consistency (vor und nach der Transaktion konsistent)
I …… Isolation (Datenänderungen sind außerhalb der Transaktion nicht bekannt. Eine
Transaktion darf keine andere beeinflussen)
D …… Durability (Dauerhaftigkeit der Datenänderung nach Abschluss)
Beispiele für Transaktionen sind:
• Buchungen mit Gegenkonto (oder Überweisung)
• Auftragsstornierung (Artikelbestand)
• Master/Detail Datenänderung
• Primärschlüssel geändert —> in Beziehung stehende Fremdschlüssel ebenso
Eine Transaktion kann implizit oder explizit begonnen werden. Implizit wäre durch Absetzen eines
SQL - Statements in Oracle / SQLPlus. Explizit wäre durch „BEGIN TRANSACTION …“.
Synchronisationspunkte werden bei Grenzen zwischen aufeinanderfolgenden Transaktionen
durchgeführt. Transaktionsmonitor werden für die Überwachung verwendet und ist eine
Komponente des DBS’s oder gegebenenfalls ein eigenes Programm.
Recovery Typen
Recovery ist das Wiederherstellen eines konsistenten Systemzustandes nach Fehlersituationen.
Falls Fehler auftreten gibt es für die Transaktionen ein Undo Protokoll und Redo Protokoll.
1. TRANSAKTIONSFEHLER (LOKALER FEHLER)
Ein Transaktionsfehler tritt auf wenn eine Transaktion nicht ordnungsgemäß beendet wird. Dadurch
sind die Daten in einem inkonsistenten Zustand.
Beispiele:
• Laufzeitfehler im Programm (Div/0, Überlauf)
• Endlosschleife in Anwendung, Timeout
• Platte voll
• Abbruch Button oder Rollback SQL - Befehl
Gegenmaßnahme für Transaktionsfehler ist die „Transaction Recovery“. Hierbei werden alle
Änderungen der Transaktion rückgängig gemacht.
2. SYSTEMFEHLER (SOFT-CRASH)
tritt auf wenn der Transaktionsmonitor abgestürzt ist. Dies kann bei Stromausfällen sowie wenn der
Prozess abgeschlossen ist und wenn ein Betriebssystemfehler oder ein Hauptspeicherfehler
auftritt.
Die Gegenmaßnahme für einen Systemfehler ist die „Crash Recovery“. Hierbei werden
Änderungen der offenen Transaktion bei Systemneustart zurückgenommen.
© Gotthard.work
Seite 1 von 4
http://gotthard.work
„Crash-Recovery“: bei einem Absturz der Datenbank wird mittels Rollback automatisch der
Zustand wiederhergestellt.
3. MEDIUMFEHLER (HARD CRASH)
Hierbei werden die Daten physikalisch zerstört, dies kann durch einen Head Crash oder durch
einen Controller-Fehler oder wenn das Dateisystem kaputt ist, auftreten. Weitere Auslöser sind
Katastrophen (Brand, Erdbeben, Anschlag) oder ein irrtümliches Löschen oder Formatieren.
Die Gegenmaßnahme für einen Mediumfehler ist das „Archive Recovery“.
„Archive-Recovery“: es wird eine Sicherungskopie eingespielt, jedoch müssen Transaktionen
nachvollzogen werden.
Wiederherstellung
1. BACKWARD RECOVERY
LOGGING IN „UNDO - LOGS“:
Die Daten befinden sich im Before Image in Log, alte Werte werden gesichert. Um die
Transaktion rückgängig zu machen, wird das Undo - Log verkehrt abgearbeitet.
DEFERRED UPDATE (VERZÖGERTES UPDATE):
Die Daten werden erst bei „commit“ geschrieben, bis dahin wird mit Kopien gearbeitet, die
gelöscht werden.
In der Praxis meist mit Log Dateien gelöst.
2. FORWARD RECOVERY
LOGGING IN „REDO - LOGS“:
Veränderte Daten („After Image“) in Log, Zum Transaktionen nachzuvollziehen —> abarbeiten.
In der Praxis oft kombiniertes Backward/Forward Recovery notwendig!
GESPIEGELTE PLATTEN (MIRROR ODER SHADOW DISKS)
Doppelte Datenhaltung, parallel geändert, schneller recovery möglich,
Nachteil: Backup+LOG für Katastrophen trotzdem notwendig
Synchronisation
- Probleme
3. LOST UPDATE PROBLEM
© Gotthard.work
Seite 2 von 4
http://gotthard.work
4. INKONSISTENT ANALYSIS PROBLEM
5. UNCOMMITED DEPENDENCY PROBLEM (DIRTY READ)
Transaktion A liest einen Wert, der von B verändert wurde, und danach gab es Rollback.
- Lösungsansatz durch Serialisierbarkeit
Der Zustand einer Datenbank nach dem Ablauf von parallelen, konkurrierenden
Transaktionen soll gleich sein dem Zustand der Datenbank nach beliebigen sequentiellen
Ablauf dieser Transaktionen. Dies kann durch Sperrverfahren sichergestellt werden oder
ebenso durch das Zeitstempelverfahren.
Durch Sperrobjekte können je nach Genauigkeit die gesamte Datenbank, einzelne Tabellen,
physischer Datenblock, eine Zeile / Spalte einer Tabelle gesperrt werden.
Vorteil feiner Sperreinheiten ist, das eine hohe Parallelität zwischen Transaktionen
stattfinden kann.
Nachteil einer Sperreinheit, ist der hohe Verwaltungsaufwand für die notwendigen Sperren.
In der Praxis wird meist Blockweise oder Zeilenweise gesperrt.
SPERRMODI
6. X-Lock (exclusive Lock): kein anderer darf etwas tun. Vorteil wenn nur X-Locks
verwendet werden, dass diese sehr schnell sind.
7. S-Lock (shared Lock, Lesesperre): die anderen dürfen auch damit sperren, jedoch nur
ein ausschließlich von einem Prozess gesperrter Lock ermöglicht das Durchführen eines
X-Locks.
Vorteil wenn X+S Locks verwendet werden, dass eine höhere Parallelität möglich ist.
8. U-Lock (update Lock): wird bei Lese Operationen, bei dem ein Update erfolgen wird
angewendet. Vorteil: Hohe Parallelität, geringere Deadlock Gefahr
In der Praxis werden vor einem Read(Select) ein S-Lock und vor einem Write(Update) ein XLock gesetzt. Nach Abschluss des Zugriffes folgt ein Release (Freigabe) des Locks.
DEADLOCK
Ist ein wechselseitiges aufeinander „Warten“. Transaktionen können von sich aus nicht
erkennen, ob DL vorliegt.
© Gotthard.work
Seite 3 von 4
http://gotthard.work
REREAD METHODE( READ BEFORE WRITE)
1. Lese DS ohne Sperre nach Rec-OLD
2. Kopiere von Rec-OLD nach Rec-Update
3. User ändert Rec-Update
4. Einlesen Rec-CHECK
5. Vergleiche Rec-Check mit Rec-OLD
6. Wenn gleich —> unter Verwendung von Rec-Update ändern —> sonst Fehlermeldung
Erfüllt folgende Kriterien: Keine Inkonsistent, kein Deadlock, Objekte nur kurz echt gesperrt
Isolation Levels
ist die Beschreibung des Grades, zu dem die Datenkonsistenz zu Lasten der Parallelität
eingehalten wird. Definiert das Verhalten bei konkurrierenden Transaktionen. Es wird nicht für jede
Operation ein Sperrmodus angegeben, sondern es wird beschrieben, welche
Serialisierungsprobleme auftreten dürfen und welche nicht.
SERIALISIERUNGSPROBLEME
- Dirty Read
Transaktion A liest einen Wert, der von B verändert wurde, und danach gab es Rollback
- Nonrepeatable Read
Transaktion A liest eine Zeile, die dann von B geändert wird. A liest nochmals —> anderer Wert.
- Phantom Read
Zwischen 2 reads taucht eine neue Zeile auf, die von einem anderen Prozess eingefügt wurde
4 EBENEN
-
Serializable (keine Gefahr von Inkonsistenz, niedere Parallelität)
Repeatable Read
Read Committed
Read Uncommited (Gefahr von Inkonsistenz, hohe Parallelität)
Dirty
Nonrep.
Phantoms
Serializable
—
—
—
Repeatable Read
—
—
✅
Read Committed
—
✅
✅
Read Uncommited
✅
✅
✅
4 EBENEN MIT REALISIERUNG DURCH SPERREN
-
Serializable ……… S-Lock auf Tabelle oder Sperren der „Zugriffspfade“
Repeatable Read ……… S-Lock auf Zeile bis Transaktionsende
Read Committed ……… S-Lock auf Zeile beim Lesen
Read Uncommited ……… kein Lock beim Lesen
LOCKS:
© Gotthard.work
S
U
X
S
A X
S
x
-
-
S
x
x
-
U
x
-
-
A
x
-
-
X
-
-
-
X
-
-
-
Seite 4 von 4