DBA01_04

Es geht um die tatsächliche Reihenfolge in der die Operationen einer Transaktion ausgeführt werden. Die Operationen sollen in der korrekten Reihenfolge ausgeführt werden. Ein Scheduler erzeugt einen Schedule.
Serialisierbarkeit bedeutet, Anomalien bzw. Inkonsitenzen zu vermeiden. Die Ablaufpläne von überlappenden Operationen sind dann anzupassen.
Bei einem seriellen Schedule treten zuerst alle Operationen der einen Transaktion
gefolgt von allen Operationen der nächsten Transaktion usw. auf. Serielle Schedules führen zu einer schlechten Performanz des DBS. Ein Schedule S mit n Transaktionen ist dann serialisierbar, wenn er zu einem seriellen Schedule mit den gleichen n Transaktionen äquivalent ist. Zur Realisierung von serielen Tas wurden Sperrprotokolle entwickelt.

Eine Sperre ist ein temporäres Zugriffsprivileg auf ein DB-Objekt. Jede TA stellt vor einem Zugriff auf ein Objekt eine Sperranfrage und gibt die Sperre nach erfolgreichem Lesen bzw. Schreiben wieder frei. Die Einhaltung dieser Regeln führt zu legalen Schedules, die aber noch keine Serialisierbarkeit garantieren.

Wenn TAs gegenseitig auf die Freigabe von Objekten warten, bezeichnen wir diese Situation als Verklemmung (Deadlock). Wenn von mehreren parallel ablaufenden TAs eine einzelne TA nie eine angeforderte Sperre erhält, sprechen wir von Verhungern (Starvation).

Das wichtigste Protokoll zur Ablaufsteuerung von TAs ist das Zwei-Phasen-Sperr-protokoll. Eine TA folgt diesem Protokoll, wenn alle Sperranfragen (LOCK) vor dem ersten Entsperren (UNLOCK) der TA erfolgen. Jeder legale Schedule gemäß dem Zwei-Phasen-Sperrprotokoll ist serialisierbar.

Unter Sperrgranularität verstehen wir die Art der DB-Objekte (Feld, Datensatz, Plattenblock Datei oder Datenbank), die gesperrt werden. Eine grobe Sperr-granularität (größeres OB-Objekt) schränkt die Nebenläufigkeit stark ein, eine feine Sperrgranularität benötigt einen leistungsfähigen Sperrenverwalter.

Es gibt Protokolle, die nach Art des Zugriffs auf ein Objekt unterscheiden und z. B. mehrere lesende TAs auf das gleiche Objekt zulassen. Ein einfaches Protokoll mit Schreib-/Lesesperren ist das R/X-Protokoll. Legale, zweiphasige Schedules mit R/X-Protokoll sind serialisierbar.

Eine Recovery des DBS sorgt für ein korrektes Wiederherstellen (= letzter konsistenter Zustand vor Auftreten des Fehlers) bei Rechnerfehlern, Transaktionsfehlern, Ausnahme-bedingungen, Abbruch durch Nebenläufigkeitskontrolle, Plattenfehlern sowie physikalischen Fehlern oder Katastrophen.
Für eine saubere Recovery muss genau verfolgt, in welchem Zustand sich eine TA befinden und welche Operationen bereits ausgeführt wurden. Das ist die Aufgabe des Recovery-Managers.

Das Systemlog ist ein Hilfsmittelt, mit dem alle Informationen über eine Transaktion gesammelt werden.
Es gibt zwe iVarianten wie diese geführt werden:
- Logisches Log: Angaben über geänderte Tupeln
- Physische Logs: Angaben über geänderte Plattenblöcke
Im Log werden bei Änderungen in der DB sowohl die alten Werte (Before Images, BFIM) als auch die neuen Werte (After Images, AFIM) aufgezeichnet.

Recovery arbeitet mit den Grundoperationen UNDO und REDO. Beim UNDO werden die Änderungen rückgängig gemacht (AFIM (After Image = Neuer Wert) durch BFIM (Before Image = alter Wert) ersetzen), beim REDO werden die Änderungen erneut ausgeführt (AFIM in die DB schreiben). Damit die BFIMs und AFIMs immer im Log stehen, gibt es Regeln:
Die Commit-Regel für das REDO:
Das AFIM eines OB-Objekts muss vor dem Commit in den permanenten Speicher (entweder DB oder Systemlog) geschrieben worden sein. Falls die Regel nicht erfüllt ist, könnte im Fehlerfall das AFIM verloren gehen, ein REDO wäre dann nicht mehr möglich.
Die Log-Ahead-Regel für das UNDO:
Das BFIM eines OB-Objekts muss (spätestens) bis zum Commit in den permanenten Speicher geschrieben worden sein. Falls die Regel nicht erfüllt ist, könnte im Fehlerfall das BFIM verloren gehen, ein UNDO wäre somit nicht mehr möglich.