1. Transaktionskonzept

1. Transaktionskonzept
Ein wesentliches Charakteristikum für (relationale) Datenbanksysteme stellt die
Unterstützung des Transaktions-Konzepts dar. Transaktionen sind Verarbeitungseinheiten, die vom DBMS ganz oder gar nicht ausgeführt werden (unit of work).
Das Transaktionskonzept besagt, dass Fehlerzustände durch ein DBMS behandelt
werden können, indem der konsistente Zustand zu Beginn der Transaktion wiederhergestellt wird (unit of recovery). Schließlich besagt das Transaktionskonzept,
dass gleichzeitige Zugriffe mehrerer Benutzer auf gemeinsame Daten durch das
DBMS koordiniert werden müssen, so dass jeder Benutzer den Eindruck hat, als ob
er alleine auf die Daten zugreift (unit of concurrency).
Zur Charakterisierung von Transaktionen wird häufig die Wortschöpfung ACID
herangezogen.
A (atomic): Transaktionen sind atomar (=>unit of work)
C (consistent): Transaktionen sind konsistenzerhaltend, d.h., ein konsistenter Zustand der Daten wird durch eine Transaktion in einen konsistenten Zustand übergeführt (=> unit of work, unit of recovery).
I (isolated): Während einer Transaktion hat der Benutzer den Eindruck, er arbeite
alleine mit den Daten (=> unit of concurrency)
D (durable): Nach Ende einer Transaktion sind die in der Transaktion durchgeführten Änderungen in der Datenbank festgeschrieben (=> unit of recovery).
1.1
Transaktionen als Verarbeitungseinheiten
Das Transaktionskonzept wird in SQL standardmäßig so umgesetzt, dass eine
Transaktion automatisch beginnt, wenn außerhalb einer Transaktion eine SQLAnweisung ausgeführt wird. Die folgenden SQL-Anweisungen sind bis zum Transaktionende dieser Transaktion zugeordnet (“Multi Query Transaction”). Eine
Transaktion wird beendet mit der SQL-Anweisung
commit work
im Erfolgsfall (d.h., die Änderungen werden in der Datenbank festgeschrieben),
ansonsten mit
rollback work
(d.h., die Änderungen werden durch das DBMS zurückgesetzt). Einige Datenbanksysteme bieten die Möglichkeit, Transaktionen nochmals zu unterteilen, indem in
der Transaktionen savepoints gesetzt werden, bis zu denen ein Zurücksetzen der
Änderungen möglich ist:
rollback work to savepoint S
Die Tatsache, dass der Beginn einer Transaktion nicht explizit im Source Code einer Applikation zu sehen ist, kann als Mangel hinsichtlich der Dokumentation ge-
Transaktionskonzept
-2-
sehen werden. Daher ist zu überlegen, ob man im Rahmen einer Datenbankzugriffsschicht Funktionen zum Beginnen und Beenden von Transaktionen zur Verfügung stellt.
Einige SQL-Entwicklungsumgebungen bieten die Möglichkeit zu entscheiden, daß
man standardmäßig mit “Single Query Transactions” arbeiten will:
set autocommit on
In diesem Fall müssen Beginn und Ende einer Transaktion explizit codiert werden!
Für den Fall, dass bei der Bearbeitung einer SQL-Anweisung ein Fehler auftritt,
liegt es in der Verantwortlichkeit des Entwicklers, zu entscheiden, ob die Transaktion zurückgesetzt werden soll oder ein Wiederaufsetzen innerhalb der Transaktion
erfolgen soll. Mit Ausnahme weniger Situationen, die in den folgenden Abschnitten
beschrieben werden, gibt es keinen Automatismus seitens des DBMS.
Rollbacks sollten vermieden werden, da sie einen unnötigen Ressourcenverbrauch
mit sich bringen.
1.2
Transaktionen: unit of recovery
1.2.1
Rollback und Recovery im laufenden Betrieb
Wie oben beschrieben, ist es Aufgabe des DBMS, dafür zu sorgen, daß Transaktionen ganz oder gar nicht durchgeführt werden.
Dies bedeutet zunächst einmal:
•
Änderungen, die innerhalb von Transaktionen durchgeführt werden, die erfolglos beendet wurden oder erkennbar nicht beendet werden, müssen zurückgesetzt werden.
Um einen Rollback einer Transaktion durchzuführen, müssen die Änderungen, die
im Rahmen einer Transaktion durchgeführt werden, rückgängig gemacht werden.
Um dies zu bewerkstelligen, werden während der Ausführung der Transaktion folgende Daten Protokolliert:
Before Images (Zustand der Daten vor einer Änderung)
After Images (Zustand der Daten nach einer Änderung).
Die After Images werden im Transaction Log (Änderungsprotokoll) des DBMS
protokolliert. Je nach Implementierung werden die Before Images ebenfalls im
Transaction Log protokolliert oder in einem eigenen Bereich (teilweise auch zusätzlich!). Der Rollback wird entweder durchgeführt, indem die Änderungen in der
umgekehrten Reihenfolge der Ausführung zurückgesetzt werden oder indem die
Before Images wieder in die Datenbank zurückgeschrieben werden.
Das Datenbanksystem muß sicherstellen, dass ein notwendiger Rollback auch ausgeführt wird!
Datenbanken
Transaktionskonzept
1.2.2
-3-
Fast Recovery
Ohne Verwendung von Data Caching (die Blöcke, auf die häufig zugegriffen wird,
werden auch nach Änderungen in einem dedizierten Hauptspeicherbereich gehalten, verwaltet mittels eines LRU-Algorithmus) wäre beim erfolgreichen Ende einer
Transaktion eigentlich nichts zu tun, da sämtliche Änderungen bereits physisch in
der Datenbank stehen. Aus Effizienzgründen wird jedoch mit Data Caching gearbeitet, d.h., es werden geänderte Blöcke über das Transaktionsende hinaus im
Hauptspeicher gehalten (fast commit). Dies bedeutet, dass beim Verlust des
Hauptspeicherinhalt (Ausfall des DBMS oder des Betriebssystems) die Änderungen
im Rahmen der Transaktion verloren wären, was dem Transaktionskonzept widerspricht. Daher werden die Änderungen im Rahmen der Transaktion und das Commit in das Transaction Log geschrieben, und zwar spätestens zum Zeitpunkt des
Commit. (Auf den ersten Blick mag es widersinnig erscheinen, dass aus Effizienzgründen die geänderten Seiten im Cache gehalten werden, auf der anderen Seite
aber zusätzlicher Aufwand durch das Protokollieren der Änderungen entsteht. Dies
ist jedoch so nicht richtig, da
•
Die After Images für die Media Recovery benötigt wird
•
Das Schreiben ins Transaction Log effizienter ist
Die zweite Aussage ist darin begründet, dass das Schreiben ins Transaction Log
sequentiell erfolgt und das zu schreibende Volumen wesentlich geringer ist. Ferner
wird die Effizienz des Schreibens ins Transaction Log noch gesteigert durch das
group commit – Verfahren, das dafür sorgt, dass mehrere Transaktionen mit einem
Zugriff auf das Transaction Log abgeschlossen werden können.)
Für den Fall eines Hauptspeicherverlusts muß das DBMS neu gestartet werden. Als
erste (automatische) Aktion im Rahmen des Restarts muß die Bereinigung der Änderungen im Rahmen von Transaktionen durchgeführt werden, die zum Zeitpunkt
des Systemausfalls aus Sicht des DBMS noch nicht endgültig abgeschlossen waren
(crash recovery). (Dies betrifft auch die bestätigten Transaktionen, für die noch
nicht gesichert ist, dass alle Änderungen schon in der Datenbank stehen!)
•
Es ist von einem stabilen Aufsetzpunkt auszugehen.
•
Für danach erfolgreich abgeschlossene Transaktionen müssen sämtliche
Änderungen ab diesem Punkt in der Datenbank festgeschrieben werden (redo recovery).
•
Für zu diesem Zeitpunkt offene oder danach begonnene Transaktionen, die
nicht erfolgreich abgeschlossen wurden, müssen sämtliche Änderungen zurückgesetzt werden (falls Blöcke, die von Änderungen betroffen wurden,
aus dem Cache ausgelagert wurden) (undo recovery).
Datenbanken
Transaktionskonzept
1.2.3
-4-
Checkpoints
Basis des oben genannten Verfahrens zur Crash Recovery ist ein stabiler Aufsetzpunkt, zu dem man weiß, dass der Zustand der Datenbank korrekt ist, d.h., mit dem
Zustand des Data Cache übereinstimmt.
Derartige Punkte werden als Checkpoints bezeichnet. Wenn ein Checkpoint
durchgeführt wird, werden sämtliche modifizierten Blöcke im Cache in die Datenbank zurückgeschrieben, für die sich dies als notwendig erweist. Checkpoints müssen regelmäßig durchgeführt werden, damit sich die Zeit für eine eventuell notwendige Crash Recovery in Grenzen hält.
Da während der Durchführung eines Checkpoints der “normale” Datenbankbetrieb
behindert wird, wird im Rahmen der Implementierung eines DBMS der Versuch
unternommen, Checkpoints so kurz wie möglich zu gestalten. Daher werden zwischen den Checkpoints asynchron modifizierte Blöcke aus dem Cache in die Datenbank geschrieben.
Die Implementierung der Checkpoints und des asynchronen Rückschreibens von
modifizierten Blöcken zwischen den Checkpoints ist von DBMS zu DBMS verschieden. Für sämtliche DBMS besteht hier relevantes Tuningpotential.
1.2.4
Lange Transaktionen
Das Transaction Log hat eine vorgegebene Größe, die zur Laufzeit nur für einige
DBMS modifiziert werden kann, und auch dies nur bedingt. Daher sollte man davon ausgehen, daß das Transaction Log nur eine gewisse Menge von Änderungsinformation aufnehmen kann, d.h., Bereiche, die nicht mehr für Rollbacks und ein
eventuell notwendiges Crash Recovery-Verfahren benötigt werden, müssen zum
Überschreiben freigegeben werden. Die Implementierung dieser Freigabe ist prinzipiell die gleiche, obwohl im Detail Unterschiede von DBMS zu DBMS bestehen.
Wir können uns das Transaction Log vorstellen als einen Ringpuffer, der in N gleiche Abschnitte unterteilt ist. Wird ein Checkpoint durchgeführt, so wird festgestellt, bis zu welchem Abschnitt zurück noch Änderungsinformationen zu offenen
Transaktionen stehen. Diese Abschnitte werden noch für eine evt. notwendige undo
recovery benötigt, falls der Rollback via Transaction Log durchgeführt wird, die
Abschnitte davor können freigegeben werden.
Die regelmäßige Freigabe von Abschnitten ist grundlegende Voraussetzung für
eine funktionierende Verwaltung des Transaction Log durch das DBS. Sie wird wie
oben angesprochen behindert durch lange Transaktionen (Länge= Differenz der
aktuellen Position im Transaction Log zum ersten Eintrag zu der Transaktion).
Lange Transaktionen können im Extremfall dazu führen, daß das DBMS neu gestartet werden muß!
Aus den o.g. Ausführungen ist abzuleiten, dass die Konfiguration des Transaction
Log zwischen der Datenbankadministration und der Anwendungsentwicklung abgesprochen werden muß. Aus Sicht der Anwendungsentwicklung ist die Zielsetzung zu verfolgen, Transaktionen so kurz wie möglich zu konzipieren. Aus Sicht
Datenbanken
Transaktionskonzept
-5-
der Datenbankadministration ist sicherzustellen, dass das Transaction Log (und ggf.
Bereiche, in denen Before Images verwaltet werden) hinreichend groß konfiguriert
werden.
1.2.5
Media Recovery
In Abschnitt 3.2.2 wurde die Rolle des Transaktionskonzepts für Fast Recovery
diskutiert, d.h., die automatische Recovery durch das DBMS nach einem Hauptspeicherverlust im Rahmen des folgenden Restarts.
In diesem Abschnitt soll die Situation betrachtet werden, dass ein Fehler in der Datenbank selbst auftritt. Ursache eines solchen Fehlers können sein:
•
Medienfehler
•
Physische Fehler in der Datenbank (Block Corruption)
•
Logische Fehler, die durch Anwendungen oder Datenbankadministration
verursacht werden
Die erste Fehlersituation, die früher der typische Fall für die Notwendigkeit einer
Media Recovery war (daher der Name!), lässt sich aus heutiger Sicht weitestgehend durch den Einsatz von Redundanz vermeiden (Einsatz von RAID-Systemen).
Falls diese Fehlersituation auftritt, muß jedoch eine Media Recovery erfolgen: Der
Zustand der Datenbank zum Zeitpunkt des Fehlers muß wiederhergestellt werden.
Falls physische Fehler in der Datenbank auftreten, gibt es prinzipiell die Möglichkeit des Patchens, die aber nicht immer greift. Dann muß eine Media Recovery erfolgen.
An dieser Stelle ist zu bemerken, dass man Fehlern auf der physischen Ebene dadurch begegnen kann, dass Redundanz auf einer höheren Ebene aufgebaut wird,
z.B. durch den Einsatz von Replikationsverfahren. Die Erfahrung zeigt, dass derartige Maßnahmen eine beachtliche Erfolgsquote haben, die aber nicht bei 100%
liegt. Daher lässt sich die Notwendigkeit einer Media Recovery nicht ausschließen.
Falls logische Fehler auftreten, ist eine Media Recovery im oben genannten Sinn
nicht ausreichend, da der Zustand der Datenbank zum Zeitpunkt der Fehlererkennung fehlerhaft ist. Hier müssen weitergehende Verfahren wie Point in Time – Recovery angewandt werden, d.h., man muß spezifizieren können, bis zu welcher
Transaktion bzw. zu welchem Zeitpunkt der Recoveryvorgang durchgeführt werden
soll.
1.2.5.1 Vorbereitungen für Media Recovery
Um eine Media Recovery durchführen zu können, müssen folgende Voraussetzungen erfüllt sein:
•
Es muß einen stabiler Aufsatzpunkt für die Recovery Maßnahme geben, eine Datensicherung. Die Datensicherung muß regelmäßig durchgeführt werden.
Datenbanken
Transaktionskonzept
•
Es müssen alle Änderungen seit der letzten Datensicherung vorliegen.
•
Datensicherung und Änderungsprotokoll müssen kompatibel sein.
-6-
Die Datensicherungsmaßnahmen können unterteilt werden in
•
Offline – Sicherungen
•
Online – Sicherungen.
Aus Gründen der Verfügbarkeit des Systems sind Online-Sicherungen vorzuziehen,
es ist jedoch zu beachten, dass der “normale” Datenbankbetrieb durch eine OnlineSicherung behindert wird.
Ferner ist zu unterscheiden zwischen
•
Sicherung durch Datenexport
•
Sicherungen auf Betriebssystemebene
•
Sicherung mit Mitteln des DBMS
Sicherungen durch Datenexport und Sicherungen auf Betriebssystemebene, die
nicht in Sicherungsverfahren des DBMS integriert sind, sind i.a. nur offline möglich und nicht kompatibel mit dem Änderungsprotokoll, d.h., es ist nur der Zustand
zum Zeitpunkt der Sicherung rekonstruierbar.
Liegt eine Sicherung mit Mitteln des DBMS vor, so bildet diese einen Ausgangspunkt für Media Recovery.
Dazu müssen sämtliche Änderungen seit der letzten Datensicherung vorliegen. Da
das Transaction Log nicht beliebig wachsen kann, müssen die Abschnitte des Transaction Log, die für eventuell notwendige Fast Recovery Maßnahmen nicht mehr
benötigt werden, archiviert werden. Die Voraussetzungen für diese Archivierung
müssen von der Datenbankadministration explizit geschaffen werden, standardmäßig arbeitet ein DBMS ohne Archivierung.
1.2.5.2 Durchführung der Media Recovery
Sind die Voraussetzungen für die Media Recovery gegeben, so kann diese durchgeführt werden, indem
•
die Sicherung eingespielt wird
•
die Änderungen seit der letzten Sicherung nachgefahren werden
Die Zeit für das Einspielen der Sicherung kann durch hinreichend kleine Sicherungseinheiten sowie Parallelität häufig stark reduziert werden. Das Nachfahren der
Änderungen seit der letzten Sicherung ist dagegen abhängig vom Änderungsaufkommen und daher häufig entscheidend für die Dauer der Recoverymaßnahme.
Sowohl die Sicherungseinheiten als auch das Sicherungsintervall sollten so gewählt
werden, dass die Anforderungen, die an Recoveryzeiten gestellt werden, erfüllt
werden können.
Datenbanken
Transaktionskonzept
1.2.6
-7-
Verfügbarkeit eines DBMS
Bei der Einrichtung von IT-Systemen mit Datenbankunterstützung findet man immer häufiger folgende Anforderungen vor:
•
Verfügbarkeit rund um die Uhr
•
Verwaltung sehr großer Datenmengen (VLDB: Very Large Data Base)
In dieser Umgebung ist es notwendig, Maßnahmen zur Steigerung der Verfügbarkeit (im wesentlichen Redundanz durch RAID-Systeme, externe Speichersubsysteme, Cluster, Replikation) zu kombinieren mit evt. notwendigen Recovery Maßnahmen oder sonstigen administrativen Maßnahmen.
Es werden immer häufiger Techniken eingesetzt, durch redundante Datenhaltung
Recovery-Maßnahmen zu vermeiden oder administrative Maßnahmen (z.B. Backup) auf einer (aus einem synchronen Zustand abgekoppelten) Kopie der Daten
durchzuführen, die dann wieder mit dem operativen Bestand synchronisiert werden.
Man sollte jedoch beachten, dass diese Maßnahmen zwar hilfreich sind, um administrative Maßnahmen abseits vom laufenden Datenbankbetrieb durchführen zu
können und physischen Fehlersituationen zu begegnen, aber bei logischen Fehlern
nicht ohne weitere Vorkehrungen eingesetzt werden können.
1.3
Transaktionen: unit of concurrency
Eine wesentliche Zielsetzung des Transaktionskonzepts besteht darin, dass der
Zugriff mehrerer Benutzer auf gemeinsame Daten durch das DBMS koordiniert
werden kann.
Findet eine derartige Koordination nicht statt, so können mehrere Phänomene auftreten, die i.a. nicht erwünscht sind:
•
Lost Update
•
Uncommitted Read
•
Non Repeatable Read
•
Phantom Bildung
Unter ”Lost Update” versteht man die Situation, daß zwei Benutzer die gleichen
Daten lesen und dann Änderungen an den Daten vornehmen. Ohne Koordination
durch das DBMS wird die erste Änderung durch die zweite überschrieben, unabhängig davon, ob Abhängigkeiten bestehen oder nicht.
Unter “Uncommitted Read” versteht man die Situation, dass ein Benutzer Auswertungen auf Daten durchführt, für die gerade eine Änderung ausgeführt wurde, die
jedoch zurückgerollt wird. Unter “Non Repeatable Read” versteht man die Situation, dass die gleiche Abfrage unterschiedliche Werte für die gleichen Datensätze
liefert, unter “Phantombildung”, dass die gleiche Abfrage zu unterschiedlichen Ergebnissen führt (durch neue oder gelöschte Einträge).
Datenbanken
Transaktionskonzept
-8-
Lost Updates sollten in jedem Fall vermieden werden, die übrigen Phänomene werden z.T. als akzeptabel betrachtet, da sie nur das Lesen betreffen.
1.3.1
Sperren zur Koordination des konkurrierenden Zugriffs
Um die o.g. Phänomene zu vermeiden, arbeiten Datenbanksysteme mit Sperren. Es
gibt mehrere Typen von Sperren, für ändernde Zugriffe werden exklusive Sperren
(X locks) verwendet, die nicht mit anderen X locks auf gleiche Daten verträglich
sind, bis zum Transaktionsende bestehen bleiben und auch sonst nicht konfigurierbar sind (bis auf das Sperr Granulat und die Reaktion auf Nichtgewähren der Sperre
– Warten oder Fehler, ggf. nach Timeout). Für lesende Zugriffe werden (gemäß
SQL 3) standardmäßig S (shared) locks eingesetzt, die mit anderen S locks auf
gleiche Daten verträglich sind, aber nicht mit X locks. S locks sind konfigurierbar!
Verträglichkeit
S lock
X lock
S lock
Ja
Nein
X lock
Nein
Nein
Unter Verwendung von Sperren werden Lost Updates vermieden:
Wenn Benutzer 1 Daten liest, benötigt er hierzu einen S lock, den er auch erhält.
Gleiches gilt für Benutzer 2. Wenn jetzt einer der Benutzer Daten ändern will, so
benötigt er hierzu einen X lock, den er aber nicht erhält, weil er mit dem S lock des
jeweils anderen Benutzers nicht verträglich ist.
Dies bedeutet, dass der Lost Update verhindert wird, aber um den Preis, dass beide
nicht weiterarbeiten können, weil sie jeweils auf den anderen warten. Diese Situation wird als Deadlock bezeichnet. Eine Deadlock Situation kann nicht von einem
der Benutzer aufgelöst werden, sondern nur durch das DBMS, das eine der beteiligten Transaktionen als “Opfer” bestimmt und i.a. diese Transaktion zurückrollt, wodurch die Sperren freigegeben werden und die andere Transaktion fortfahren kann.
1.3.2
Vermeidung von Deadlock Situationen
Deadlock Situationen sind unerwünscht, weil der Rollback durch das DBMS (oder
die Applikation) unnötig Ressourcen verbraucht. Daher sollte es Ziel der Applikationsentwicklung, speziell der Entwicklung von Datenbank Zugriffsschichten sein,
Deadlock Situationen zu vermeiden.
Um Strategien zur Deadlock Vermeidung zu erarbeiten, muß man zunächst analysieren, aufgrund welcher Zugriffsmuster Deadlocks entstehen. Es zeigt sich, dass
vor allem die folgenden Zugriffsmuster Deadlocks provozieren:
•
Read for Update
•
Lock Eskalation
•
Inkonsistente Änderungspfade
Datenbanken
Transaktionskonzept
-9-
1.3.2.1 Read for Update
“Read for Update” ist die oben diskutierte Situation, dass Daten gelesen werden mit
der Zielsetzung, anschließend Änderungen an den Daten vorzunehmen. Dies führt
dazu, dass bei parallelem Zugriff ein Deadlock entsteht.
Um “Read for Update” Situationen in den Griff zu bekommen, gibt es mehrere
Möglichkeiten:
•
Lesende Zugriffe ohne Sperren
•
Lesen und Schreiben werden nicht in der gleichen Transaktion durchgeführt.
•
“Read for Update” – Zugriffe mit stärkeren Sperren
•
Änderung der Anweisungsreihenfolge
Der SQL Standard sieht die Möglichkeit vor, Transaktionen bezüglich der Verwendung von Lese Sperren zu konfigurieren, indem man ein isolation level setzt. Es
werden im SQL Standard folgende isolation level vorgesehen:
•
Read uncommitted: Es werden weder Sperren gesetzt noch beachtet
•
Read committed: Es werden keine Sperren gesetzt, aber nur bestätigte Daten gelesen
•
Repeatable Read: Lese Sperren werden gesetzt und bis zum Ende der
Transaktion gehalten.
•
Serializable: Es findet keine Phantombildung statt.
(Die Tatsache, dass es diese isolation level gibt, zeigt, dass “Uncommited Read”,
“Non Repeatable Read” und Phantombildung durchaus als akzeptabel angesehen
werden!)
Darüber hinaus bieten einige DBS das isolation level cursor stability an, falls mit
einem cursor gearbeitet wird: Beim fetch wird eine Sperre auf die Zeile gesetzt, die
Sperre wird beim nächsten fetch zurückgenommen.
Eine weitere Möglichkeit, Lese Sperren zu konfigurieren, besteht in der Verwendung von update (U) locks. Die Verträglichkeitsmatrix sieht dabei folgendermaßen
aus:
Verträglichkeit
S lock
U lock
X lock
S lock
Ja
Ja
Nein
U lock
Ja
Nein
Nein
X lock
Nein
Nein
Nein
Datenbanken
Transaktionskonzept
- 10 -
Durch Verwendung von U locks für „Read for Update“ – Zugriffe (Pessimistisches
Locking) wird der Zugriff serialisiert. Damit werden Lost Updates und Deadlocks
vermieden, aber Wartezustände erzeugt, die der Benutzer beeinflusst, oder Fehler
wegen Nichtgewährung des U Locks beim Lesen.
Ein anderes Verfahren zur Behandlung von „Read for Update“ – Zugriffen ist das
optimistische Locking, das davon ausgeht, dass Konflikte selten auftreten werden
und in der Applikation behandelt werden können. Verwendet man die isolation
level read uncommitted bzw. read committed, so werden beim Lesen keine Sperren
gesetzt, und es gibt keine Konflikte zwischen Lese Sperren und X locks. (Dies gilt
ebenfalls, wenn Lesen und Ändern der Daten in unterschiedlichen Transaktionen
stattfinden.) Es besteht jedoch die Möglichkeit, dass zwischen dem Zeitpunkt des
Lesens und dem Zeitpunkt der Änderung die Daten geändert wurden. Dies ist in der
Datenzugriffsschicht zu behandeln, z.B. dadurch, dass vor dem Update ein erneutes
Lesen der Daten stattfindet (mit U Lock zur Deadlockvermeidung!) und überprüft
wird, ob eine Änderung stattgefunden hat, verbunden mit einer Wiedervorlage in
diesem Fall. Dieses Verfahren funktioniert sehr gut, falls wenig Konflikte auftreten,
ist aber sehr problematisch, wenn viele Wiedervorlagen auftreten.
Es soll an dieser Stelle noch darauf, hingeweiesen werden, dass es in einigen Fällen
die Möglichkeit gibt, lesende und schreibende Zugriffe zu vertauschen (mit entsprechender Anpassung) oder zusammenzufassen (z.B. bei Vergabe eines surrogate
key durch eine Datenbank Zugriffsschicht oder bei der o.g. Überprüfung im Rahmen des optimistischen Locking).
1.3.2.2 Lock Eskalation
“Lock Eskalation” ist eine Situation, die darauf basiert, dass es unterschiedliche
Sperr Granulate gibt:
•
Datenbank
•
Tabelle (Partition, Index)
•
Block
•
Zeile
Da jede Sperre Ressourcen benötigt und diese Ressourcen beschränkt sind, kann
ein DBMS auf das Erreichen einer Grenze entweder mit einer Exception reagieren
(z.B. Informix) oder mit einer Vergabe eines Locks für die nächst gröbere Ebene
(z.B. DB2). Dies bezeichnet man als Lock Eskalation. Nehmen 2 Benutzer Änderungen in einer Tabelle vor, so führt dies zunächst nicht zu einem Konflikt, findet
Lock Eskalation statt, so kann keiner den X lock auf die Tabelle erhalten, weil jeweils der andere Teile der Tabelle exklusiv gesperrt hat. Folglich liegt eine Deadlock Situation vor.
Um die hier genannten Situationen zu vermeiden, ist zu überlegen, ob man die
Zugriffe auf die Tabelle serialisiert, in dem man von Beginn an mit einer exklusi-
Datenbanken
Transaktionskonzept
- 11 -
ven Sperre auf Tabellenebene arbeitet. Diese kann explizit in der Applikation gesetzt werden:
lock table Tabellenname in [share / exclusive] mode
1.3.2.3 Inkonsistente Änderungspfade
Die gleichen Überlegungen wie für Lock Eskalation gelten für inkonsistente
Zugriffspfade bei Änderungen: Auch hier besteht die Möglichkeiten, dass ändernde
Transaktionen zunächst konfliktfrei arbeiten, aber später auf gemeinsame Daten
zugreifen und damit jeweils auf den anderen warten müssen, so dass wiederum eine
Deadlocksituation vorliegt.
Die Serialisierung der Zugriffe wie im Fall der Lock Eskalation kann hier eingesetzt werden. Auf der anderen Seite ist zu beachten, dass durch zentral koordinierte,
konsistente Zugriffspfade sowohl die Zielsetzung “Vermeidung von Deadlocks” als
auch die Zielsetzung “Steigerung des Duchsatzes” unterstützt wird.
1.3.3
Vermeidung von Lock Wait Situationen
Die wesentliche Zielsetzung bei der Verwaltung konkurrierender Zugriffe auf eine
Datenbasis ist es, einen hohen Durchsatz zu erreichen, indem das Warten auf die
Gewährung von Sperren minimiert wird.
Das lange Warten auf eine Sperre wird vom Anwender eines Systems oft sogar
negativer empfunden als eine Fehlersituation, wie sie im Fall des Deadlock auftritt.
Daher bieten Datenbanksysteme i.a. die Möglichkeit der Konfiguration, wie lange
auf eine Sperre gewartet werden soll. Derartige Spezifikationsmöglichkeiten bestehen i.a. zu Beginn einer Transaktion, aber auch im Kontext einzelner SQLAnweisungen wie “lock table”.
Führt eine derartige Maßnahme zu einer Fehlersituation, so ist es Aufgabe der Datenzugriffsschicht, auf den Fehler zu reagieren und z.B. die Transaktion zurückzurollen. Diese Reaktion bedeutet jedoch wieder eine Verschwendung von Ressourcen, so dass zu untersuchen ist, wie die Wartesituation an sich vermieden wird.
Hierzu kann man folgende Prinzipien anwenden:
•
Verwendung kurzer Transaktionen (KISS: keep it simple and short)
•
Keine Benutzerinteraktion in Transaktionen
•
Verwendung kleiner Sperrgranulate durch effiziente Zugriffspfade
•
Verzicht auf Lese Sperren
1.3.4
Sperren von Objekten auf Applikationsebene
Es gibt Situationen, in denen Datenbanksperren nicht das geeignete Instrument
sind, um den konkurrierenden Zugriff auf gemeinsam benutzte Daten zu koordinieren. Dies ist etwa zu berücksichtigen, wenn eine Koordination des Zugriffs über
Datenbanksperren zu komplex und / oder zu ineffizient ist oder Sperren länger
Datenbanken
- 12 -
gehalten werden müssen als für die Dauer einer Datenbank Connection und semantisch Objekte identifiziert werden können, auf die die Konkurrenzsituation beim
Zugriff reduziert werden kann. In diesem Fall wird häufig die Technik angewandt,
ein explizites Check Out - und Check In - Verfahren für diese Objekte zu implementieren. Dies kann über die Datenbank erfolgen, etwa durch Verwaltung der Objekte in einer Tabelle, in der nicht nur das Check Out / Check In dokumentiert ist,
sondern der Zustand des Objekts.
Es ist zu beachten, dass bei derartigen Verfahren sichergestellt werden muß, dass
der Zugriff auf die Objekte nur über die Applikation erfolgt und verhindert werden
muß, dass Objekte gesperrt bleiben, weil der für die Freigabe einer Sperre explizit
notwendige Check In nicht stattgefunden hat.
Datenbanken