15.1 Verfahrensüberblick

15.1.2 Update-Propagierung

Zur Propagierung von Änderungen bestehen auch mehrere Alternativen, die in Abb. 15-2 klassifiziert sind. Man kann dabei zwei Arten der Update-Propagierung unterscheiden, nämlich eine vertikale und eine horizontale. Die vertikale Propagierung von Änderungen bezieht sich auf den Transfer von Änderungen zwischen Haupt- und Externspeicher, während die horizontale Propagierung den Transfer von Objekten zwischen den Rechnern betrifft.

Abb. 15-2: Alternativen zur Propagierung von Änderungen

Force vs. Noforce

Für die vertikale Update-Propagierung bzw. die Ausschreibstrategie bestehen die zwei gleichen Alternativen wie für zentralisierte DBS, nämlich ein Force- oder Noforce-Ansatz [HR83]. Die Force-Strategie verlangt, daß alle von einer Transaktion geänderten Seiten spätestens am Transaktionsende in die physische Datenbank auf Externspeicher ausgeschrieben werden. Dieser Ansatz bedingt i.a. ein sehr ungünstiges Leistungsverhalten, da die Schreibvorgänge zu signifikanten Antwortzeitverschlechterungen sowie hohem E/A-Overhead führen können. Auf der anderen Seite vereinfacht sich die Behandlung von Rechnerfehlern, da die Änderungen aller erfolgreicher Transaktionen bereits eingebracht sind, so daß eine Redo-Recovery entfällt. Für Shared-Disk ergibt sich ferner eine erhebliche Vereinfachung der Kohärenzkontrolle. Denn das Durchschreiben der Änderung garantiert, daß die letztgültige Version geänderter Seiten in der physischen Datenbank auf Externspeicher vorliegt! Da jeder Rechner direkten Zugriff auf die physische Datenbank hat, ist bei Force das Problem der Update-Propagierung somit bereits durch die Ausschreibsstrategie gelöst. Der Austausch geänderter Seiten zwischen Rechnern erfolgt also stets über die gemeinsamen Platten.

Die Noforce-Alternative erlaubt i.d.R. ein signifikant besseres Leistungsverhalten als Force, da geänderte Seiten erst verzögert und asynchron ausgeschrieben werden, so daß die Ausschreibverzögerungen am Transaktionsende wegfallen. Die E/A-Häufigkeit wird reduziert, da auch für Schreibvorgänge Lokalität im Puffer genutzt werden kann, um mehrere Änderungen verschiedener Transaktionen zu akkumulieren. Dafür ist jetzt für Shared-Disk eine aufwendigere Crash-Recovery (Kap. 13.3.4) sowie komplexere Kohärenzkontrolle zu unterstützen. Da die physische DB i.a. nicht auf dem aktuellen Stand ist, muß ermittelt werden, an welchen Rechnern die aktuellen Versionen geänderter Seiten vorliegen. Daneben ist eine explizite horizontale Update-Propagierung zu unterstützen. Eine weitere Schwierigkeit liegt darin, daß eine Seite in mehreren Rechnern als geändert gegenüber der Version auf Platte vorliegen kann. Damit kann eine Ausschreibkoordinierung erforderlich werden, um das Ausschreiben einer veralteten Seitenversion zu verhindern, da dies zum Verlust von Änderungen führen könnte.

Page-Owner-Zuordnung

Zur Lösung dieser Probleme wird üblicherweise das Konzept des Page-Owners eingesetzt. Dabei fungiert für jede (gegenüber der physischen Datenbank) geänderte Seite genau einer der Rechner als Page-Owner, der im wesentlichen zwei Aufgaben wahrnimmt. Zum einen versorgt er andere Rechner auf Anforderung mit der aktuellen Version der Seite. Zum anderen ist er für das Ausschreiben der geänderten Seite verantwortlich, wodurch eine Ausschreibkoordinierung mit anderen Rechnern entfällt. Beide Aufgaben entfallen offenbar, wenn sich die aktuelle Version der Seite in der physischen DB befindet, so daß in diesem Fall kein Page-Owner erforderlich ist (bzw. die Platte könnte als Page-Owner betrachtet werden).

Abb. 15-2 zeigt, daß für die Zuordnung der Page-Owner-Funktion zu den Rechnern ähnliche Alternativen bestehen wie für die GLA-Zuordnung für Sperrverfahren (Kap. 14):

Von diesen Alternativen ist die dynamische Page-Owner-Zuordnung am universellsten einsetzbar; ihre Realisierung wird in den nachfolgenden Kapiteln noch genauer betrachtet. Der erste Ansatz hat für Shared-Disk nur geringe Relevanz, liegt jedoch i.a. in Workstation/Server-Systemen vor, wo der Server-Rechner als zentraler Page-Owner für alle Workstations fungiert. Die zweite Alternative kann sehr effektiv mit dem Primary-Copy-Sperrverfahren kombiniert werden (s. Kap. 15.3).

Alternativen für Seitentransfers

Das letzte Klassifikationsmerkmal von Abb. 15-2 ist ebenfalls nur für Noforce relevant und betrifft den Austausch geänderter Seiten zur horizontalen Update-Propagierung. Dabei sind im wesentlichen zwei Alternativen zu unterscheiden, nämlich den Austausch geänderter Seiten über die gemeinsamen Externspeicher sowie der direkte Austausch über das Kommunikationsnetz. Wie Abb. 15-3 verdeutlicht, ist dabei der Seitenaustausch über Platte signifikant langsamer als der direkte Transfer. Denn im ersteren Fall schreibt der Page-Owner nach Eintreffen einer Seitenanforderung (page request) zunächst die Seite aus und signalisiert dann dem anfordernden Rechner, daß die Seite von Externspeicher gelesen werden kann. Somit sind neben zwei Nachrichten zwei synchrone Plattenzugriffe erforderlich, so daß Verzögerungen von über 30 ms zu erwarten sind. Beim direkten Seitentransfer dagegen entfallen die Externspeicherzugriffe, da die Seite bereits in der Antwortnachricht auf die Seitenanforderung zurückgeliefert wird. Ein solcher Seitenaustausch dürfte innerhalb von 1-5 ms abgewickelt werden, also um rund eine Größenordnung schneller[64].

Allerdings kann der Seitenaustausch über Externspeicher erheblich beschleunigt werden, wenn die gemeinsamen Platten mit einem nicht-flüchtigen Platten-Cache ausgestattet sind. Denn dann fallen für die Externspeicherzugriffe lediglich die Cache-Zugriffszeiten an, wodurch eine Gesamtverzögerung im Bereich von 4-8 ms erreicht werden kann. Noch kürzere Transferzeiten sind möglich bei naher Kopplung über einen schnellen, gemeinsamen Halbleiterspeicher (Kap. 13.4). Der Austausch geänderter Seiten über Externspeicher bringt zudem erhebliche Vorteile hinsichtlich der Crash-Recovery mit sich. Denn damit ist nach einem Rechnerausfall gewährleistet, daß eine Redo-Recovery auf die Änderungen des ausgefallenen Rechners beschränkt werden, welche in dessen lokaler Log-Datei protokolliert sind. Denn die Änderungen anderer Rechner sind aufgrund des Seitenaustauschs über Externspeicher bereits in der physischen DB enthalten. Bei direktem Seitenaustausch dagegen enthält die physische Datenbank i.a. noch nicht die Änderungen anderer Rechner (Abb. 15-3b). Diese müssen daher im Rahmen der Crash-Recovery ebenfalls wiederholt werden, was die Anwendung einer globalen Log-Datei verlangt (Kap. 13.3.4).

Abb. 15-3: Austausch geänderter Seiten

Neben Seitentransfers vom Page-Owner zu einem anfordernden Rechner können auch Seitentransfers zum Page-Owner notwendig werden. Dies ist bei zentralisierter und fester Page-Owner-Zurordnung notwendig, wenn die Änderung außerhalb des Page-Owner-Rechners stattfand. Für diese Transfers kommt nur die direkte Übertragung in Betracht (da ansonsten kein Page-Owner mehr benötigt würde). Daraus folgt, daß ein Seitenaustausch über Platte nur bei dynamischer Page-Owner-Zuordnung sinnvoll ist (Abb. 15-2).

[64] Direkte Seitentransfers erlauben auch eine Verbesserung des E/A-Verhaltens, da es schneller möglich ist, eine Seite im Hauptspeicher eines anderen Rechners anzufordern, als eine Seite von Platte zu lesen. Diese Seitentransfer können dabei im Prinzip auch für ungeänderte Seiten genutzt werden, sofern bekannt ist, an welchen Rechnern sie vorliegen. In einigen Systemen ist jedoch der CPU-Overhead für Seitenübertragungen zwischen Rechnern höher als für einen E/A-Vorgang.