1. Transaktionskonzept

Transkript

1 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 SQL- Anweisung 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-

2 Transaktionskonzept 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 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!

3 Transaktionskonzept 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).

4 Transaktionskonzept 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 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

5 Transaktionskonzept der Datenbankadministration ist sicherzustellen, dass das Transaction Log (und ggf. Bereiche, in denen Before Images verwaltet werden) hinreichend groß konfiguriert werden Media Recovery In Abschnitt 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 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.

6 Transaktionskonzept Es müssen alle Änderungen seit der letzten Datensicherung vorliegen. Datensicherung und Änderungsprotokoll müssen kompatibel sein. 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 Online- Sicherung 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 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.

7 Transaktionskonzept 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).

8 Transaktionskonzept Lost Updates sollten in jedem Fall vermieden werden, die übrigen Phänomene werden z.t. als akzeptabel betrachtet, da sie nur das Lesen betreffen 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 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

9 Transaktionskonzept 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

10 Transaktionskonzept 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) 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-

11 Transaktionskonzept ven Sperre auf Tabellenebene arbeitet. Diese kann explizit in der Applikation gesetzt werden: lock table Tabellenname in [share / exclusive] mode 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 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 SQL- Anweisungen 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 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

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.