Entwicklung einer Datenbank zur Informationsverarbeitung und -verteilung im Projektmanagement

bankzustand und die gleichen Ausgabewerte wie die ursprüngliche Ausführung erzielt. Man spricht dann davon, dass serielle Ablaufpläne korrekt sind. Jeder Ablaufplan, der denselben Effekt, wie ein serieller erzielt, ist akzeptierbar. Ein Transaktionsschedule ist also serialisierbar, wenn er nach dem Ausführen einer Reihe gleichzeitiger Transaktionen das gleiche Ergebnis liefert wie ein möglicher serieller bzw. sequentieller Ablauf (nacheinander in einer beliebigen Reihenfolge) der zugehörigen Transaktionen. 19 Nicht serialisierbare Transaktionen müssen zurückgesetzt werden. Änderungen erfolgreich beendeter Transaktionen die verloren gehen, müssen wieder hergestellt werden. Folgende Regeln müssen eingehalten werden um die Serialisierbarkeit zu gewährleisten: 1. Vor jedem Objektzugriff muss die Sperre mit ausreichendem Modus angefordert werden 2. Gesetzte Sperren anderer Transaktionen sind zu beachten 3. Eine Transaktion darf nicht mehrere Sperren für ein Objekt anfordern 4. Spätestens bei EOT sind alle Sperren freizugeben Synchronisation und Korrektheit: Die Serialisierbarkeit wird auch als Korrektheitskriterium der Synchronisation bezeichnet. Die Synchronisation stellt mit verschiedenen möglichen Verfahren sicher, dass die Serialisierbarkeit eines Schedules erreicht wird. Das grundlegende Ziel der Synchronisation ist dabei ein logischer Einbenutzerbetrieb zur Vermeidung aller Mehrbenutzeranomalien. Um die Synchronisation durchzuführen unterscheidet man folgende Verfahren: 20 Optimistisches Verfahren (nichttransaktionsorientiertes System) nach dem EOT: Die TA kann bis zum Ende erfolgen und erst dann werden etwaige aufgetretene Konflikte ermittelt. Man geht davon aus, dass diese Konflikte relativ selten vorkommen, daher findet zunächst ein unsynchronisierter Zugriff statt. Pessimistisches Verfahren (transaktionsorientiertes System): Die Konfliktuntersuchung erfolgt bereits zu Beginn der Transaktion oder während der Transaktionsbearbeitung. Objekte werden dabei vor Zugriff immer gesperrt, um potentielle Konflikte zu vermeiden (z.B. 2PL – 2-Phasen-Sperrprotokoll). Dieses Verfahren wird noch unterteilt in: • Zeitmarkenverfahren (während Transaktion): Der Zugriff einer TA wird nur dann zugelassen, wenn die durch eine Zeitmarke festgelegte Verarbeitungsreihenfolge eingehalten wird. • Preclaiming Strategie (zum BOT): TA die in Konflikt kommen können, werden vorbeugend sequentialisiert. • Sperrverfahren (während Transaktion): Eine TA untersagt anderen den Zugriff auf Datenobjekte, diese werden schlichtweg gesperrt. Dadurch können TA Objekte für sich reservieren und vor konkurrierenden Zugriffen schützen. Dieses Verfahren ist universell einsetzbar und wird daher im Folgenden näher beschrieben. 5.2.5.1 Sperrverfahren Das Sperrverfahren soll den Zugriff auf eine Ressource einschränken. Sperren verhindern, dass Daten, die gerade von anderen Benutzern geändert werden, gelesen [...]

Beim Abarbeiten von Transaktionen treten im Allgemeinen Zugriffskonflikte auf. Der einfachste Weg zur Lösung wäre sicherlich die serielle bzw. sequentielle Abarbeitung der Transaktionen (= alle nach einander), dies ist aber aus Performance-Gründen nicht möglich. Um die Problemlösung der Zugriffskonflikte zu erläutern, muss man auf folgende Begriffe bzw. Verfahren eingehen: Transaktionsschedule, Isolierung, Serialisierbarkeit, Korrektheit und Synchronisierung. Transaktionsschedule: Unter einem Schedule versteht man die Verzahnung von Transaktionen und eine Beschreibung der Ablauffolge von Transaktionen durch diesen Ablaufplan. Der TA Schedule beschreibt dabei den zeitlichen Ablauf aller elementaren DB Operationen (Lesen, Ändern, Einfügen, Löschen) mehrerer Transaktionen. Isolierung von Transaktionen und Serialisierbarkeit: Serielle bzw. sequentielle Schedules sind ideal, da die Transaktionen unverzahnt nacheinander ablaufen. Dadurch wäre eine Isolation und Konsistenz der Daten garantiert, mit dem Nachteil der Verlangsamung. Die Konsistenz der Daten ist aber nach dem ACID-Paradigma unverzichtbar. Eine Konsistenz der Datenbank muss somit anderweitig durch die Isolierung von Transaktionen erreicht werden. Ziel ist, das jede Transaktion ohne Beeinträchtigung durch andere parallel laufende erfolgen soll. Um eine Isolation der Transaktionen zu erreichen, macht man die Transaktionsschedules serialisierbar.18 Die parallele Ausführung einer Menge von Transaktionen ist serialisierbar, wenn es eine serielle Ausführung derselben Transaktionsmenge gibt, die den gleichen Daten- [...]

die Veränderungen festgehalten sind, damit diese später nachgeholt werden können. • Log Datei: Das System funktioniert nur mit einem geeigneten Logging. Für jeden Transaktionsschritt wird dabei ein Eintrag in die Log-Datei gemacht, diese Einträge kommen in einen Pufferbereich im Hauptspeicher und von dort in einen separaten permanenten Speicher, der möglichst ausfallsicher ist. Jeder Eintrag enthält die Information, welche Transaktion welches Datum auf welcher Seite wie verändert hat (= redo- und undo-Information). • Write-Ahead-Logging: Dieses Protokollverfahren sorgt dafür, dass o.g. rechtzeitig geschieht, da jederzeit ein Fehler geschehen könnte. Es beinhaltet, daß alle Log-Sätze, die zu einer Datenbank-Seite gehören permanent (z.B. auf Band) gespeichert sein müssen, bevor die Seite selbst zurückkopiert wird. Nach einem Fehler können die Spuren nicht abgeschlossener Transaktionen auf der Seite wieder entfernt werden. Des Weiteren müssen alle Log-Sätze, die zu einer Transaktion gehören, vor deren Abschluss geschrieben sein. Dadurch können nach einem Fehler die Veränderungen abgeschlossener Transaktionen nachgeholt werden, die noch nicht auf dem permanenten Speicher stehen. Die Reparaturen werden durch den Recovery Manager vorgenommen (komplexeste System-Komponente des DBMS). Zum einen beseitigt er die Spuren nicht abgeschlossener Transaktionen (undo) und setzt die Veränderungen abgeschlossener Transaktionen durch (redo). Zum anderen stellt er nach jedem Fehlerfall wieder einen möglichst aktuellen konsistenten Zustand der Datenbasis her. Bei einem Verlust von Hauptspeicher und Hintergrundspeicher stellt er die Datenbasis mittels Archiv-Stände der Datenbasis und der Protokoll-Dateien durch das "Nachfahren'' aller protokollierten Transaktionen wieder her.17 [...]