Databases Reference
In-Depth Information
kann also gar nicht vorkommen, dass Inkonsistenzen durch die teilweise Aus-
führung einer Transaktion entstehen.
Eine einzige update -Anweisung kann sehr viele Datensätze ändern. Wenn die
Ausführung der Anweisung unterbrochen wird, benötigt das RDBMS für den
rollback Informationen darüber, welche Datensätze geändert wurden. Tatsäch-
lich zeichnet das RDBMS alle Änderungen am Datenbestand im so genann-
ten Transaktionsprotokoll auf. Im Transaktionsprotokoll sind nicht die SQL-
Anweisungen verzeichnet, sondern die Änderungen auf Datensatzebene. Falls
eine Transaktion abgebrochen wird, werden die zugehörigen Änderungen Daten-
satz für Datensatz aus dem Protokoll gelesen und rückgängig gemacht.
Das Transaktionsprotokoll leistet einen wesentlichen Beitrag zur Konsistenz des
Datenbestandes und darf daher nicht verloren gehen.
H2 verwaltet alle Daten, auch das Transaktionsprotokoll, in einer einzigen Da-
tei. Andere RDBMS speichern das Protokoll separat, so dass wir es auch sichern
können. Wenn wir eine Sicherung der Datenbank haben und uns ein vollständi-
ges Transaktionsprotokoll seit dem Zeitpunkt der Sicherung vorliegt, haben diese
RDBMS Werkzeuge, mit denen wir die Sicherung einspielen und die Einträge aus
dem Transaktionsprotokoll nachziehen können. Transaktionen, die dann noch of-
fen sind, werden zurückgerollt. So haben wir den aktuellen Stand der Datenbank
bis zur letzten abgeschlossenen Transaktionen wiederhergestellt.
In Abschnitt 20.4 sehen wir, dass es eine noch wichtigere Nutzungsmöglichkeit
des Protokolls für den Fall gibt, dass unser RDBMS einmal ausfällt.
Hinweis
Abschlossene Transaktionen werden im Transaktionsprotokoll dauer-
haft gespeichert.
17.5
Auch nach außen eine Einheit
Wir stellten bereits fest, dass Transaktionen eine Datenbank von einem konsis-
tenten Zustand in einen anderen Zustand transformieren. Während der Transak-
tion kann der Datenbestand natürlich inkonsistent sein. So haben wir zwar 100
 
nach dem ersten der beiden folgenden update -Anweisungen von Konto 23 ab-
gebucht, aber noch nicht auf dem Zielkonto eingebucht:
update konten set saldo=saldo-100 where id=23;
update konten set saldo=saldo+100 where id=42;
commit;
Ein Anwender, der nach dem ersten update die beiden Kontenstände mit der
folgenden select -Anweisung betrachtet, sieht inkonsistente Daten:
 
Search WWH ::




Custom Search