15.3 On-Request-Invalidierung

15.3.3 Feste Page-Owner-Zuordnung

Die feste Zuordnung der Page-Owner-Funktion zu einem oder mehreren Rechnern verlangt, daß eine Seitenänderung an den zuständigen Rechner übertragen wird, damit dieser anderen Rechnern die aktuellen Objektversionen zur Verfügung stellen kann. Dieser Mehraufwand gegenüber einer dynamischen Page-Owner-Zuordnung kann jedoch durch eine noch bessere Kombination von Synchronisation und Kohärenzkontrolle kompensiert werden. Dies trifft für Sperrverfahren zu, bei denen die globale Sperrverantwortung fest unter den Verarbeitungsrechnern oder dedizierten GLM-Rechnern aufgeteilt wird. Wird nämlich für die Page-Owner-Zuordnung die gleiche DB-Aufteilung wie für die GLA-Zuordnung gewählt, lassen sich sämtliche Seitentransfers mit Sperrnachrichten kombinieren:

Besonders bedeutsam im Vergleich zu dynamischer Page-Owner-Zuordnung ist der zweite Punkt, da nun Seitenanforderungen keine zusätzlichen Verzögerungen mehr verursachen. Weiterhin sind in der globalen Sperrtabelle keine Angaben mehr zum aktuellen Page-Owner zu führen, und die mit der Migration des Page-Owners verbundenen Komplikationen entfallen.

Beispiel 15-4

Abb. 15-8: On-Request-Invalidierung mit fester Page-Owner-Zuordnung

Abb. 15-8 zeigt für unser Beispiel die Propagierung geänderter Seiten bei einer solchen auf die GLA-Verteilung abgestimmten, festen Page-Owner-Zuordnung. Dabei sei Rechner R2 sowohl GLM als auch Page-Owner für Seite B. Damit wird mit der Freigabe der Schreibsperre durch R3 die geänderte Seite an R2 übergeben und dort im Puffer aufgenommen. Dies hat auch Auswirkungen auf die Verwendung von Invalidierungsvektoren zur On-Request-Invalidierung. Wie gezeigt, wird jetzt I auf den Wert 100 gesetzt, da in R2 durch die Übernahme der aktuellen Seitenversion keine Invalidierung für B möglich ist. Bei der Sperranforderung von R1 wird die Invalidierung erkannt und die aktuelle Seite direkt mit der Sperrgewährung zurückgeliefert. Ein Vergleich mit Abb. 15-7 zeigt, daß zwei Nachrichten eingespart werden und die mit der Sperranforderung zusammenfallende Seitenanforderung wesentlich schneller bearbeitet wird. Dafür ist der Aufwand der Seitenübertragung bei Freigabe der Schreibsperre in Kauf zu nehmen.

Bezogen auf die Anzahl zur Kohärenzkontrolle benötigter Nachrichten ist das Verfahren optimal, da weder zur Erkennung von Pufferinvalidierungen noch zur Update-Propagierung zusätzliche Nachrichten anfallen. Weiterhin können Seitenanforderungen mit minimalem Aufwand bearbeitet werden. Demgegenüber verursachen die Seitenübertragungen zum Page-Owner einen Zusatzaufwand, da natürlich die Übertragung einer "großen" Nachricht einen höheren Kommunikationsaufwand verursacht als eine einfache Nachricht zur Sperrfreigabe. Diese Merkmale gelten sowohl für eine Page-Owner/GLA-Aufteilung unter den Verabeitungsrechnern als auch bei dedizierten Rechnern. In letzterem Fall verursachen die Seitentransfers jedoch ein besonders hohes Übertragungsvolumen. Denn dabei muß jede Seitenänderung zum Page-Owner/GLM-Rechner übertragen werden, obwohl sie dort für die Transaktionsverarbeitung nicht genutzt werden. Der Aufwand hierfür ist ähnlich dem einer Force-Strategie, wo auch alle Seitenänderungen am Transaktionsende zu propagieren sind (allerdings auf Platte). Die ständige Aufnahme neuer Seitenänderungen verlangt weiterhin ein ständiges Ausschreiben zuvor gepufferter Seiten und kann dazu führen, daß nur relativ wenige Seiten vom Page-Owner/GLM-Rechner direkt mit der Sperrgewährung an den anfordernden Rechner bereitgestellt werden können. Dies gilt natürlich vor allem bei nur einem Page-Owner/GLM-Rechner (zentraler Page-Owner), der zudem leicht zum Systemengpaß wird.

Günstiger ist dagegen die kombinierte Page-Owner/GLA-Verteilung unter allen Verarbeitungsrechnern, da sich dann Lokalität im Referenzverhalten auch zur Einsparung von Seitentransfers nutzen läßt. Dies trifft vor allem für das Primary-Copy-Sperrverfahren (Kap. 14.3) zu, bei dem eine logische DB-Aufteilung zur GLA-Allokation verwendet wird. Durch ein darauf abgestimmtes affinitätsbasiertes Transaktions-Routing kann damit rechnerspezifische Lokalität direkt zur Einsparung von globalen Sperranforderungen genutzt werden. Wird nun dieselbe DB-Partitionierung zur Page-Owner-Zuordnung verwendet, erfolgen idealerweise die meisten Zugriffe auf eine DB-Partition bereits am zuständigen GLM/Page-Owner-Rechner. Für diese Zugriffe entfallen somit die Seitenanforderungen, da der eigene Rechner als zuständiger Page-Owner bereits die aktuelle Seite hat oder diese von der physischen DB gelesen werden kann[66]. Für Änderungen, die am zuständigen Rechner erfolgen, entfallen ebenso die Seitentransfers bei Freigabe der Schreibsperre. Ein weiterer Pluspunkt ist, daß die Anzahl der Pufferinvalidierungen reduziert wird, da diese nur noch für Seiten möglich sind, die zur Partition eines anderen Rechners gehören.

[66] Die Bezeichnung "Primary Copy" ist nunmehr berechtigt, da der GLM-Rechner sämtliche Primärkopien seiner DB-Partition führt und verwaltet.