Transaktion
Werbung
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
