15 Kohärenzkontrolle

15.4 Einsatz von Haltesperren

Ein Buffer-Purge-Ansatz vermeidet in Verbindung mit Sperrverfahren Pufferinvalidierungen, da gepufferte Seiten am Transaktionsende (vor Freigabe der Sperre) aus dem Puffer eliminiert werden. Das E/A-Verhalten eines solchen Ansatzes ist jedoch nicht akzeptabel, da er eine Force-Strategie impliziert (hoher Schreibaufwand) und die Puffer nur schlecht zur Einsparung lesender Plattenzugriffe genutzt werden. Ein besserer Vermeidungsansatz ist dagegen, Seiten auch nach Transaktionsende im Puffer zu belassen, sie jedoch durch spezielle Haltesperren (retention locks) vor der Invalidierung durch andere Rechner zu schützen [HR85, Ra88b, CFLS91, DY92]. Somit muß für jede gepufferte Seite entweder eine reguläre Transaktionssperre oder eine Haltesperre bestehen. Eine durch eine Haltesperre geschützte Seite kann nicht unbemerkt in einem anderen Rechner geändert werden, da die hierfür erforderliche Schreibsperre mit der in der globalen Sperrtabelle vermerkten Haltesperre in Konflikt gerät. Der Konflikt führt dazu, daß der GLM die Aufgabe der Haltesperre verlangt. Durch Eliminieren der Seite vor Freigabe der Haltesperre wird die Invalidierung der Seite verhindert. Damit werden von Invalidierungen betroffene Seiten noch früher aus dem Puffer entfernt als bei einer Broadcast-Invalidierung.

Das Konzept der Haltesperren läßt sich vorteilhaft mit der Verwendung von Lese- und Schreibautorisierungen (Kap. 14.2.1) verknüpfen. Denn diese Autorisierungen werden für gesperrte Objekte auch nach Transaktionsende vom jeweiligen Rechner beibehalten, um Lokalität im Referenzverhalten zur lokalen Sperrvergabe zu nutzen. Die Autorisierungen sind ebenfalls beim GLM vermerkt und müssen bei einem Konflikt mit anderen Rechnern explizit zurückgenommen werden. Da Haltesperren sich auf Seiten beziehen, können diese nun durch Schreib- und Leseautorisierungen auf Seitenebene realisiert werden. Daraus resultieren zwei Arten von Haltesperren, die neben der Vermeidung von Pufferinvalidierungen auch die lokale Vergabe und Freigabe von Seitensperren erlauben:

Zur Update-Propagierung beschränken wir unsere Diskussion auf den kompliziertesten Fall, nämlich Noforce mit dynamischer Page-Owner-Zuordnung. Dabei hängt das Zusammenspiel zwischen Page-Owner sowie Haltesperren davon ab, ob geänderte Seiten über Externspeicher oder direkt ausgetauscht werden. Beide Fälle sollen im folgenden genauer betrachtet werden.

Austausch geänderter Seiten über die gemeinsamen Platten

Bei diesem Ansatz, der im Shared-Disk-System von Oracle verwendet wird, entspricht der Page-Owner dem Besitzer einer WA-Haltesperre. Der GLM braucht daher in der globalen Sperrtabelle neben den Haltesperren den Page-Owner nicht zusätzlich zu führen. Aufgrund der Semantik der WA-Haltesperre kann eine geänderte Seite nur in einem Rechner gepuffert sein, nämlich beim Page-Owner, wo die Änderung stattfand. Ein Seitenzugriff in einem anderen Rechner führt dazu, daß der GLM die Aufgabe der WA-Haltesperre sowie einen Seitentransfer über Platte verlangt. Der Page-Owner schreibt daraufhin die Seite aus und gibt danach die WA-Sperre sowie die Page-Owner-Funktion auf. Im Rechner, der den WA-Entzug veranlaßt hat, kann die aktuelle Seite dann von Platte eingelesen werden. Ein Vorteil liegt darin, daß Seitenanforderungen stets mit dem Entzug einer WA-Haltesperre zusammenfallen und somit keine zusätzlichen Nachrichten verursachen.

Eine RA-Haltesperre ist bei diesem Ansatz nur möglich, wenn die Seite in keinem der Rechner geändert vorliegt. Damit garantiert die RA-Haltesperre nicht nur die Aktualität der gepufferten Seitenkopie, sondern auch der Seitenversion in der physischen DB.

Beispiel 15-5

Das zur Illustrierung der On-Request-Invalidierung verwendete Szenario soll nun auch zur Verdeutlichung des Haltesperreneinsatzes dienen (Abb. 15-9). Zunächst lag eine ungeänderte Kopie der Seite B in den Rechnern R1 und R3 vor, was jetzt erfordert, daß diese Rechner eine RA-Haltesperre für die Seite halten. Die Durchführung einer Seitenänderung in R3 verlangt daher zunächst den Entzug der RA-Haltesperre in R1, wobei die Seite vor Rückgabe der Haltesperre aus dem Puffer eliminiert wird, um ihre Invalidierung zu vermeiden (Abb. 15-9a). R3 erhält vom GLM eine Schreibautorisierung/WA-Haltesperre und wird damit auch zum Page-Owner für B. Die Freigabe der Schreibsperre ist eine lokale Aktion in R3. Die Anforderung einer Schreibsperre in R1 führt zum Entzug der WA-Haltesperre in R3, der zugleich mit einer Seitenanforderung verbunden ist. Nach Ausschreiben der Seite eliminiert R3 die Seite aus dem Puffer (um ihre Invalidierung durch R1 zu vermeiden) und gibt die WA-Haltesperre zurück. Der GLM vergibt eine WA-Haltesperre und damit die Page-Owner-Funktion an R1, der jedoch vor der Durchführung seiner Änderung zunächst die Seite von Platte einlesen muß (Abb. 15-9b).

Abb. 15-9: Haltesperreneinsatz bei Austausch geänderter Seiten über Platte

Direkter Austausch geänderter Seiten

Der Hauptunterschied zum vorhergehenden Fall liegt darin, daß beim Entzug einer WA-Haltesperre die Seite vom Page-Owner nicht ausgeschrieben wird. Stattdessen wird die Seite direkt zum anfordernden Rechner übertragen, was eine wesentliche Beschleunigung gegenüber dem Seitenaustausch über Platte ergibt (Einsparung von zwei Plattenzugriffen). Im Beispiel von Abb. 15-9b kann so der Seitentransfer von R3 nach R1 parallel zu den Nachrichten zur Mitteilung des WA-Entzugs sowie der Sperrgewährung erfolgen.

Eine Folge des direkten Seitenaustauschs ist, daß eine geänderte Seite im System vorliegen kann, auch wenn keine WA-Haltesperre vergeben ist. Dies ist etwa beim Entzug der WA-Haltesperre aufgrund eines Lesezugriffs der Fall. So kann für eine geänderte Seite am Page-Owner-Rechner auch nur eine RA-Haltesperre vorliegen, während beim Seitenaustausch über Platte eine RA-Haltesperre nur für ungeänderte Seiten möglich ist. Diese Änderungen machen es notwendig, in der globalen Sperrtabelle den Page-Owner explizit zu führen, unabhängig von der Vergabe der Haltesperren.

Beispiel 15-6

In Fortsetzung des vorherigen Beispiels liegt in der Ausgangssituation von Abb. 15-10 Seite B geändert in R1 vor; R1 ist Page-Owner und besitzt eine WA-Haltesperre. Eine Leseanforderung von R3 bewirkt nun einen direkten Seitentransfer von R1 nach R3. R1 muß die WA-Haltesperre aufgeben, jedoch ist eine Konversion in eine RA-Haltesperre möglich, da B in R3 nur gelesen wird. Daher behält R1 auch die Page-Owner-Funktion, und die Seite bleibt in R1 gepuffert. Wenn anschließend in R3 eine Änderung der Seite vorgenommen werden soll (Abb. 15-10b), ist zuvor ein Entzug der RA-Haltesperre in R1 notwendig, wobei die Seite auch aus dem Puffer entfernt wird. Die Page-Owner-Funktion geht nach R3 über. In diesem Fall ist mit der Page-Owner-Migration kein Seitentransfer verbunden, da R3 bereits die aktuelle Version der Seite vorliegen hat

Abb. 15-10: Haltesperreneinsatz bei direkten Seitentransfers
 .

Die Beispiele zeigen zur Illustrierung der Funktionsweise Worst-Case-Szenarien im Hinblick auf den Nachrichtenbedarf, während bei entsprechender Lokalität im Referenzverhalten jedoch viele Nachrichten entfallen. Bei den Haltesperren ist zudem zu beachten, daß nur wenige Nachrichten über die zur Synchronisation mit Lese/Schreibautorisierungen benötigten hinaus erforderlich sind. Die zur Vermeidung der Pufferinvalidierungen erforderliche vorsorgliche Eliminierung von gepufferten Seiten fällt stets zusammen mit dem Entzug einer Lese/Schreibautorisierung. Auch fallen der Entzug der Page-Owner-Funktion sowie Seitenanforderungen meist mit dem Entzug von Autorisierungen/Haltesperren zusammen[67]. Um das Ausmaß der aufwendigen Entzugsvorgänge zu reduzieren ist eine freiwillige Rückgabe einer Haltesperre angebracht, sobald die Seite aus dem Puffer verdrängt wird. Denn dies zeigt an, daß die Seite schon längere Zeit nicht mehr referenziert wurde. Bei direktem Seitenaustausch kann zudem eine RA-Haltesperre ohnehin nicht mehr zur lokalen Sperrbehandlung genutzt werden, nachdem die Seite verdrängt wurde. Denn in diesem Fall ist die Gültigkeit der Seite in der physischen DB nicht gewährleistet, so daß der GLM-Rechner ohnehin zu befragen ist, ob die Seite von einem anderen Rechner anzufordern ist.

[67] Dies ist bei Austausch geänderter Seiten über Platte stets der Fall. Bei direktem Seitenaustausch sind separate Seitenanforderungen nur für Lesezugriffe erforderlich, wenn der Page-Owner lediglich eine RA-Haltesperre hält.