10 Transaktionen Änderungen verwalten

Transkript

1 Eindruck eines Einnutzer- Systems Datenbanken werden meist von vielen Nutzern fast gleichzeitig genutzt. Dieses Kapitel zeigt Ihnen die möglichen Gefahren und Lösungsansätze. In den bisherigen Kapiteln wurde implizit angenommen, dass man alleine am System arbeitet. Dies ist bei großen Datenbanken typischerweise nicht der Fall. Um die Arbeit nicht unnötig zu verkomplizieren, sollte das Datenbank-Managementsystem dafür sorgen, dass der Nutzer auf andere Nutzer keine Rücksicht nehmen muss. In diesem Kapitel wird gezeigt, dass diese Aufgabe zwar grundsätzlich vom Datenbank-Managementsystem übernommen wird, es aber sinnvoll ist, sich über kritische Situationen Gedanken zu machen. Wenn zwei Nutzer die gleiche Zeile gleichzeitig verändern wollen, ist es nicht möglich, beiden Nutzern das Gefühl zu geben, alleine an der Datenbank zu arbeiten. Im folgenden Unterkapitel wird zunächst die Möglichkeit zur Transaktionssteuerung für einen einzelnen Nutzer vorgestellt. Danach werden typische Probleme gezeigt, die bei der gleichzeitigen Nutzung der gleichen Tabellen auftreten können und welche Lösungsmöglichkeiten es für diese Probleme gibt Änderungen verwalten Änderungen rückgängig machen Wurden bisher Änderungen an den Tabellen vorgenommen, konnte man davon ausgehen, dass diese Änderungen direkt in der Datenbank durchgeführt wurden. Dieser einfache Ansatz hat dann Probleme, wenn eine größere Anzahl von Änderungen durchgeführt werden soll, es aber möglich ist, dass man nach einigen Teilschritten feststellt, dass die Änderungen doch nicht durchgeführt werden sollen. Bisher müsste man sich alle Folgen von INSERT-, UPDATE- und DELETE-Befehlen merken, um dann diese Änderungen mit einer neuen Folge von SQL-Befehlen wieder rückgängig zu machen. Dies ist gerade durch die Nutzung komplexer WHERE- Bedingungen und die verschiedenen Verknüpfungsmöglichkei- 223 S. Kleuker, Grundkurs Datenbankentwicklung, DOI / _10, Springer Fachmedien Wiesbaden 2013

2 Transaktion In verschiedenen Datenbank-Managementsystemen gibt es die Möglichkeit, statt eines SAVEPOINTs mehrere durch den Befehl SAVEPOINT <name> anzulegen und dann mit ROLLBACK TO SAVEPOINT <name> zu diesem Sicherungspunkt zu springen. Interessant ist die Aussage, dass mit COMMIT versucht wird, die Änderungen endgültig in die Datenbank zu übernehmen. Die- Transaktionssteuerung nur für Tabellenänderungen COMMIT garantiert keine Ausführung ten durch die Fremdschlüsselbeziehungen sehr aufwändig und potenziell fehlerträchtig. Aus diesem Grund wird im SQL-Standard die Möglichkeit zur Transaktionssteuerung spezifiziert. Dabei ist eine Transaktion eine Menge von SQL-Befehlen zur Veränderung von Tabelleninhalten, die ein Nutzer zusammen durchführen und die er vor einer endgültigen Ausführung abbrechen können möchte. Zu beachten ist, dass sich die Transaktionssteuerung auf Veränderungen existierender Tabellen bezieht, Befehle zum Erzeugen und Löschen von Tabellen sind explizit ausgeschlossen. Zur Transaktionssteuerung stehen dem Nutzer grundsätzlich folgende Befehle zur Verfügung: BEGIN TRANSACTION: Mit diesem Befehl wird eine Transaktion gestartet. Häufiger wird auf die Angabe des Befehls explizit verzichtet, da man beim Start des Systems und durch ein COMMIT oder ROLLBACK automatisch eine neue Transaktion beginnt. COMMIT: Die vorher eingegebenen Befehle zur Veränderung von Tabellen sollen endgültig in die Datenbank übernommen werden. Die Transaktion wird damit abgeschlossen. ROLLBACK: Die Änderungen an den Tabellen, die seit dem Ende der letzten Transaktion durchgeführt wurden, sollen verworfen werden. Es sollen keine Änderungen in der eigentlichen Datenbank stattfinden. SAVEPOINT: Mit diesem Befehl kann in der laufenden Transaktion ein Sicherungspunkt gesetzt werden. Mit dem nächsten ROLLBACK-Befehl wird dann zu der Situation zurück gesprungen, die zum Zeitpunkt des SAVEPOINT-Befehls vorlag. Mit einem weiteren ROLLBACK würde dann die gesamte Transaktion verworfen. 224

3 10.1 Änderungen verwalten ser Versuch kann scheitern, wenn ein zweiter Nutzer Änderungen an den gleichen Tabellen vornehmen möchte. In diesem Fall führt das Datenbank-Managementsystem automatisch ein ROLLBACK durch und verwirft die gesamte Transaktion. Werden neue Tabellen angelegt, Tabellen gelöscht oder bricht ein Nutzer die Datenbank-Verbindung ab, wird typischerweise automatisch ein COMMIT durchgeführt. Dies kann aber in der Konfiguration von Datenbank-Managementsystemen eingestellt werden. Der beispielhafte Ablauf von Tabellenänderungen mit Transaktionssteuerung wird mit dem folgenden SQL-Skript und der zugehörigen Ausgabe gezeigt. CREATE TABLE ( MNr INTEGER, Name VARCHAR(6), Gehalt INTEGER, PRIMARY KEY(MNr) ); INSERT INTO VALUES(1,'Egon',70); INSERT INTO VALUES(2,'Uwe',60); SAVEPOINT; INSERT INTO VALUES(3,'Ute',80); SELECT * FROM ; ROLLBACK; SELECT * FROM ; ROLLBACK; INSERT INTO VALUES(4,'Udo',70); COMMIT; SELECT * FROM Die erste Ausgabe liefert: MNR NAME GEHALT Egon 70 2 Uwe 60 3 Ute 80 Danach wird zum vorher festgelegten Sicherungspunkt zurück gesprungen, die Ausgabe liefert: MNR NAME GEHALT Egon 70 2 Uwe 60 Dann wird zum Ausgangspunkt der Transaktion zurück gesprungen und danach ein neuer namens Udo angelegt. Die Ausgabe liefert: 225

4 Originaltabelle im Datenbank-Managementsystem Transaktionssteuerung ist systemabhängig MNR NAME GEHALT Udo 70 Die Realisierung der Transaktionssteuerung wird im SQL- Standard offen gelassen und ist Aufgabe der Hersteller der Datenbank-Managementsysteme. Ein häufig gewähltes Verfahren ist der Schattenspeicher. Dabei werden alle Änderungen einer Transaktion lokal in einem Zwischenspeicher gehalten und erst bei einem COMMIT in die eigentliche Datenbank übertragen. MiNr Name 2 Uwe Nutzer der Datenbank UPDATE SET Gehalt=100 WHERE.Name='Uwe' Gehalt 100 Schattenspeicher mit aktuellen Änderungen Aktualisierung bei COMMIT MiNr Name 1 Egon 2 Uwe Gehalt Abb. 10-1: Schattenspeicher-Verfahren Schattenspeicher-Verfahren In Abb wird das Schattenspeicher-Verfahren verdeutlicht. Der Nutzer ändert das Gehalt von Uwe auf 100. Diese Information wird lokal im Speicher zur Transaktion vermerkt. In der eigentlichen Datenbank findet die Änderung noch nicht statt. Fragt der Nutzer die tabelle in der laufenden Transaktion ab, wird er trotzdem das Gehalt 100 bei Uwe sehen, da alle Anfragen durch den Schattenspeicher laufen. Interessant und schwierig an diesem Ansatz ist, wenn ein zweiter Nutzer gleichzeitig die Tabelle bearbeitet, da er die Änderungen des ersten Nutzers typischerweise nicht sehen kann. Die dahinter stehenden Probleme und ihre Lösungsansätze werden in den folgenden Unterkapiteln diskutiert. 226

5 10.2 Typische Probleme beim parallelen Zugriff 10.2 Typische Probleme beim parallelen Zugriff lokale Variablen in Datenbanken Hat das Datenbankmanagementsystem keine ordentliche Verwaltung von Transaktionen, kann es zu den folgenden Problemen kommen. Zur Erklärung wird ein Befehl SELECT.Gehalt INTO :X FROM WHERE.MiNr=1 genutzt. Für die Zeile INTO :X wird davon ausgegangen, dass eine Variable :X im System definiert wurde, die vom Typ her zum Ergebnis der Anfrage, hier zur Spalte.Gehalt, passt. Eine solche Variablendeklaration ist in verschiedenen Datenbank-Managementsystemen möglich, ist aber sparsam eingesetzt worden, da Ergebnisse von Anfragen nicht in zusätzlichen Variablen verwaltet werden sollten. Der Ansatz wird hier vorgestellt, der als Platzhalter dafür dienen kann, dass eine Applikation einen Wert aus der Datenbank liest und nach einer Bearbeitung wieder, eventuell an anderer Stelle, in die Datenbank schreiben will. Nutzer 1 Nutzer 2 Datenbankinhalt SELECT.Gehalt INTO :X 1 Uwe 70 WHERE.MiNr=1 SELECT.Gehalt INTO :Y WHERE.MiNr=1 UPDATE SET Gehalt=:X+10 WHERE.MiNr=1 UPDATE SET Gehalt=:Y+20 WHERE.MiNr=1 1 Uwe 80 1 Uwe 90 Abb. 10-2: Lost Update Lost Update In Abb ist ein Beispiel für eine verloren gegangene Änderung, ein Lost Update, beschrieben. Beide Nutzer wollen das Gehalt des s mit der MiNr 1 ändern. Dazu lesen sie den aktuellen Wert jeweils in eine Variable. Diese Variable wird dann zur Aktualisierung des Datenbankeintrags genutzt. Da 227

6 Dirty Read Phantom Read das Lesen der zweiten Variable vor der schreibenden Änderung des ersten Nutzers stattfindet, geht die Änderung des ersten Nutzers verloren. Solch eine Situation kann z. B. auftreten, wenn ein zwei Prämien aus unterschiedlichen Gründen erhalten soll und dann eine Prämie verloren geht. In Abb ist ein Beispiel für das Lesen eines nicht bestätigten Wertes, ein Dirty Read, beschrieben, das nur durch die im vorherigen Unterkapitel vorgestellte Transaktionssteuerung auftreten kann. Dabei ist allerdings zu beachten, dass man eine ähnliche Situation erreicht, wenn der Nutzer 1 statt eines ROLLBACKs den Wert mit einem UPDATE-Befehl wieder zurücksetzt. Dieses eng mit dem Dirty Read verwandte Problem wird auch Phantom Read genannt. Der Name ist passend, da während der Aktionen des Nutzers 2 ein Datum erscheint, vom Nutzer 2 genutzt wird und wieder verschwindet ohne dass der Nutzer 2 nachvollziehen kann, was eigentlich passiert ist. Nutzer 1 Nutzer 2 Datenbankinhalt 1 Uwe 70 UPDATE SET Gehalt=Gehalt+20 WHERE.MiNr=1 UPDATE SET Gehalt=Gehalt+20 WHERE.MiNr=1 ROLLBACK COMMIT Abb. 10-3: Dirty Read 1 Uwe 90 1 Uwe Uwe 70 1 Uwe 110 Im beschriebenen Fall will der Nutzer 1 das Gehalt von Uwe um 20 erhöhen, danach nutzt der Nutzer 2 den neuen Wert, um das Gehalt um 20 zu erhöhen. Nutzer 1 entscheidet sich zur Rücknahme der Änderung, so dass der Nutzer 2 mit einem nicht bestätigten Wert gearbeitet hat. Eine solche Situation kann z. B. auftreten, wenn zwei Sachbearbeiter das gleiche Personal 228

7 10.3 Transaktionssteuerung Unrepetable Read bearbeiten und ein Fehler bei der Trennung der Kompetenzen vorliegt. Ein drittes typisches Problem, ist die Nichtwiederholbarkeit lesender Operationen, Unrepeatable Read genannt. In Abb ist ein Beispiel dargestellt. Der Nutzer 2 lässt sich zweimal die Summe der Gehälter berechnen. Dies kann z. B. dann sinnvoll sein, wenn eine Softwarekomponente die Berechnungen einer anderen Komponente überprüfen möchte. Diese Prüfung, ob :X und :Y den gleichen Wert haben, scheitert in diesem Fall, da der Nutzer 1 einen Wert in der Tabelle geändert hat. Sinnvoll wäre es, wenn der Nutzer 2 innerhalb einer Transaktion immer die gleichen Werte sehen würde, das Ergebnis der Summenberechnung sollte entweder immer 130 oder 150 sein, aber niemals das Zwischenergebnis 140. Nutzer 1 Nutzer 2 Datenbankinhalt 1 Uwe 70 2 Ulli 60 UPDATE SET Gehalt=Gehalt+10 WHERE.MiNr=1 1 2 Uwe Ulli SELECT SUM(.Gehalt) INTO :X FROM UPDATE SET Gehalt=Gehalt+10 WHERE.MiNr=2 SELECT SUM(.Gehalt) INTO :Y FROM Abb. 10-4: Unrepeatable Read 1 Uwe 80 2 Ulli Transaktionssteuerung Um die im vorherigen Unterkapitel vorgestellten Probleme zu vermeiden, wird vom Datenbank-Managementsystem eine Transaktionssteuerung gefordert. Details dieser Steuerung kann der Nutzer dabei für seine Transaktionen einstellen. Generell soll der Nutzer das Gefühl haben, dass seine Transaktionen das 229

8 Atomicity Consistency Isolation Durability hier zu erklärende ACID-Prinzip nutzen. Der Standard überlässt es den Herstellern der Datenbank-Managementsysteme, wie sie dieses Prinzip durchsetzen. ACID ist dabei eine Abkürzung, die sich aus folgenden Forderungen zusammensetzt. Das A steht für Atomicity, zu Deutsch Atomarität. Transaktionen sind unteilbar, sie finden entweder ganz oder gar nicht statt. Innerhalb einer Transaktion kann eine andere Transaktion keinen Einfluss haben. Für die vorgestellten Probleme heißt das im Lost Update-Beispiel der Abb. 10-2, dass die Transaktionen hintereinander stattfinden, also zwar in beliebiger Reihenfolge, aber immer mit dem Ergebnis, dass das Gehalt auf 100 gesetzt wird. Bei dem Dirty Read-Beispiel in Abb müssen die beiden Transaktionen wieder in beliebiger Reihenfolge stattfinden. Das Ergebnis wäre immer, dass das Gehalt auf 90 gesetzt wird. Im Fall des Unrepeatable Read-Beispiels aus Abb würde das Ergebnis sein, dass der Nutzer 2 entweder in beiden Fällen 130 oder in beiden Fällen 150 berechnet. Das C steht für Consistency, zu Deutsch Konsistenz. Eine Transaktion geht von einer Datenbank aus, die alle Konsistenzregeln erfüllt. Wird die Transaktion dann ausgeführt, ist die Datenbank danach wieder in einem Zusatand, in dem alle Regeln erfüllt sind. Das I steht für Isolation, was zu Deutsch auch als Isolation übersetzt werden kann. Isolation garantiert, dass alle Zwischenergebnisse, die während einer laufenden Transaktion erreicht werden, von anderen Transaktionen nicht gelesen und verändert werden können. Das D steht für Durability, zu Deutsch Dauerhaftigkeit. Die Dauerhaftigkeit garantiert, dass Ergebnisse einer Transaktion persistent sind, also auf Dauer gespeichert werden. Die Ergebnisse einer Transaktion können nur durch eine andere Transaktion verändert werden. Der Nutzer kann die Genauigkeit der Transaktion steuern. Dazu kann beim Start der Transaktion ein so genannter Isolationsgrad mit SET TRANSACTION LEVEL <Nummer> gesetzt werden. Häufig werden statt der Nummern auch Schlüsselwörter genutzt, die aber in Datenbank-Managementsystemen variieren können. 230

9 10.4 Aufgaben Level Name mögliche Problemfälle 0 READ UNCOMMITED Dirty Read, Unrepeatable Read, Phantom Read 1 READ COMMITTED Unrepeatable Read, Phantom Read 2 REPEATABLE READ Phantom Read 3 SERIALIZABLE keine Abb. 10-5: Isolationslevel Gründe für niedrigen Isolationslevel Auswirkungen von Transaktionssteuerungen Die genauen Werte können der Abb entnommen werden. Die typische Standard-Einstellung ist der Wert 3, mit dem ACID-Transaktionen garantiert werden. Wenn man weiß, dass man nur lesende Zugriffe hat beziehungsweise kein zweiter Nutzer auf die gleichen Tabellen zugreifen will, kann es aus Performance-Gründen sinnvoll sein, einen anderen Isolationslevel für eine Transaktion einzustellen. Der Level muss typischerweise für jede Transaktion neu eingestellt werden, wenn nicht der Standardwert des Datenbanksystems genutzt werden soll. Aus Nutzersicht ist zu beachten, dass eine ordentliche Transaktionssteuerung einige Rechenzeit benötigt. Weiterhin kann es sein, dass eine Transaktion bei einem COMMIT lange warten muss bis sie endlich ausgeführt wird, da die Transaktionssteuerung auf das Ende einer anderen Transaktion wartet. Weiterhin ist es möglich, dass eine Transaktion abgebrochen oder trotz COMMIT ein ROLLBACK ausgeführt wird, da ein Konflikt mit einer anderen Transaktion vorliegt. Im Extremfall können sich Transaktionen gegenseitig blockieren, wenn z. B. die eine Transaktion die Tabelle A geändert hat und dann die Tabelle B ändern will und eine andere Transaktion B geändert hat und auf A zugreifen möchte. Man spricht dabei von einem Deadlock, der entweder vom Nutzer durch den Abbruch einer Transaktion oder vom Datenbank-Managementsystem durch den Ablauf einer Zeitschranke, in der eine Transaktion weiter voran schreiten muss, aufgelöst wird Aufgaben Wiederholungsfragen Versuchen Sie zur Wiederholung folgende Aufgaben aus dem Kopf, d. h. ohne nochmaliges Blättern und Lesen zu bearbeiten. 231

10 1. Was versteht man unter einer Transaktion? 2. Welche Steuerungselemente für Transaktionen gibt es? 3. Wie funktioniert das Schattenspeicherverfahren? 4. Beschreiben Sie anschaulich die drei typischen Probleme, die bei der parallelen Datenbanknutzung auftreten können. 5. Was versteht man unter dem ACID-Prinzip? 6. Was sind Isolationsgrade, wozu können sie genutzt werden? Übungsaufgaben 1. Ein Nutzer A führt auf einer Datenbank folgende SQL- Befehle aus: INSERT INTO T1(Name,Alt) VALUES('Heinz', 42); UPDATE T1 SET Alt=Alt+1 Ein zweiter Nutzer B führt auf der gleichen Datenbank folgende SQL-Befehle aus: INSERT INTO T1(Name,Alt) VALUES('Verena',33); UPDATE T1 SET Alt=Alt+1 Gehen Sie davon aus, dass die Tabelle T1 mit den Spalten Name und Alt erfolgreich angelegt wurde und leer ist, bevor A und B tätig werden, die am Ende COMMIT eingeben. a. Welche Endzustände können in der Tabelle T1 erreicht werden, wenn die Datenbank keine Transaktionssteuerung hat, dabei seien einzelne INSERT und UPDATE nicht unterbrechbar? b. Welche Endzustände können in der Tabelle T1 erreicht werden, wenn die Datenbank eine vollständige Transaktionssteuerung hat? 2. In Abb wird das Schattenspeicher-Verfahren vorgestellt. a. Überlegen Sie, welche Auswirkungen dieses Verfahren auf die drei Problemfälle hat. b. Überlegen Sie im nächsten Schritt einen möglichen Ansatz, mit dem man ACID-Transaktionen erreichen könnte. 232