15 Kohärenzkontrolle

15.5 Unterstützung von Satzsperren

Bei der bisherigen Beschreibung wurde stets eine Synchronisation auf Seitenebene unterstellt. Wenngleich dies für viele Anwendungen ausreichen dürfte, kann das Ausmaß an Synchronisationskonflikten damit nicht generell niedrig genug gehalten werden. Viele DBS unterstützen daher Satzsperren sowie andere Maßnahmen zur Reduzierung der Konfliktrate.

Der Einsatz von Satzsperren in Shared-Disk-Systemen wirft jedoch besondere Kohärenzprobleme auf. Wie in Abb. 15-11 illustriert, können dann nämlich verschiedene Sätze derselben Seite in verschiedenen Rechnern geändert werden. Damit ist die Kopie der Seite an jedem der Rechner nur partiell aktuell; die Version der Seite in der physischen Datenbank enthält zunächst keine der Änderungen. Das Ausschreiben der partiell aktuellen Seiten ist nicht zulässig, da dies zum Verlust gültiger Änderungen führen könnte. Folglich muß eine Seite vollständig aktualisiert werden, bevor ein Ausschreiben erfolgt. Ein "Mischen" von Änderungen verschiedener Rechner ist jedoch nicht nur aufwendig, sondern oft gar nicht möglich, da Satzänderungen vielfach Änderungen in der Seitenstruktur verursachen (Löschen von Sätzen, Änderungen in der Satzlänge etc.).

Abb. 15-11: Kohärenzproblem beim Einsatz von Satzsperren

Die Probleme werden i.d.R. durch die Unterstützung beschränkter Formen von Satzsperren umgangen. Die einfachste Möglichkeit dazu besteht darin, Satzsperren im Rahmen eines hierarchischen Verfahrens nur innerhalb der Verarbeitungsrechner zu unterstützen, jedoch globale Sperranforderungen auf Seitenebene (oder gröberen Granulaten) zu stellen. Der Vorteil liegt darin, daß die Protokolle zur globalen Sperrverwaltung und Kohärenzkontrolle ungeändert bleiben können. Zudem wird vermieden, daß die Anzahl globaler Sperranforderungen zunimmt, wie bei der Verwendung eines feineren globalen Sperrgranulats zu erwarten. Dennoch wird durch die lokale Verwendung von Satzsperren bereits eine reduzierte Konflikthäufigkeit unterstützt. Dies gilt insbesondere im Zusammenhang mit einer affinitätsbasierten Transaktionsverteilung, mit der ein hohes Maß rechnerspezifischer Lokalität angestrebt wird. Denn in diesem Fall sind vor allem lokale Konflikte zu erwarten, denen bereits mit lokalen Satzsperren wirksam begegnet werden kann.

Eine weitere Reduzierung der Konflikthäufigkeit wird mit globalen Satzsperren erreicht, wobei jedoch zu einem Zeitpunkt Änderungen einer Seite stets auf einen Rechner beschränkt werden. Ein solches Verfahren wurde in [MN91] beschrieben. Neben transaktionsspezifischen Satzsperren muß dabei für Änderungen an dem betreffenden Rechner eine spezielle Update (U)-Sperre für die Seite vorliegen. Der Besitzer der U-Sperre fungiert zugleich als Page-Owner für die Seite. U-Sperren sind mit Lesesperren kompatibel, so daß eine geänderte Seite in einem anderen Rechner gepuffert und lesend bearbeitet werden kann (die Satzsperren garantieren dabei, daß unterschiedliche Sätze referenziert werden). Verschiedene Sätze einer Seite können sogar von mehreren parallelen Transaktionen an verschiedenen Rechnern geändert werden, wobei die Änderungen jedoch über die U-Sperre serialisiert werden. Die U-Sperre (Page-Owner-Funktion) kann dabei vor Aufgabe der Satzsperre einer Transaktion mit der geänderten Seite selbst an einen anderen Rechner weitergegeben werden.

Beispiel 15-7

Abb. 15-12 zeigt ein Szenario zu diesem Protokoll, in dem drei parallele Transaktionen in den Rechnern R1, R2 und R3 verschiedene Sätze derselben Seite B bearbeiten. Zunächst wird Satz r2 in R2 geändert, wofür eine Satzsperre für r2 sowie eine U-Sperre für B beim (nicht gezeigten) GLM anzufordern ist. Danach wird eine Leseanforderung in R1 für Satz r1 gewährt, wobei die zu diesem Zeitpunkt beim Page-Owner R2 vorliegende Version von B an R1 übertragen wird. Eine Änderung von Satz r3 in R3 wird ebenfalls zugelassen; die Anforderung der benötigten U-Sperre führt jedoch zu einem Konflikt mit R2 und resultiert in der Übertragung der Page-Owner-Funktion (U-Sperre) sowie der Seite an R3. Dort liegt nun die aktuelle Version der Seite vor, wobei aufgrund der Serialisierung der Schreibvorgänge kein explizites Mischen der Änderungen erforderlich war.

Abb. 15-12: Serialisierung von Seitenänderungen bei Satzsperren

Es ist zu beachten, daß die notwendige Erkennung von Pufferinvalidierungen auf Satz- oder Seitenebene erfolgen kann, etwa über ein On-Request-Invalidierungsverfahren. Die Erkennung auf Seitenebene verursacht einen geringeren Verwaltungsaufwand beim GLM, führt jedoch zu vermehrten Seitentransfers. So wird damit bei einem Zugriff auf Satz r2 in Rechner R1 eine Pufferinvalidierung festgestellt und die aktuelle Seite beim Page-Owner R3 angefordert, obwohl die in R1 vorliegende Seitenkopie den aktuellen Satz enthält.

Das skizzierte Verfahren erlaubt einen hohen Parallelitätsgrad, jedoch führen die globalen Satzsperren i.a. zu einem weit höheren Kommunikationsaufwand als mit Seitensperren. Dies wird dadurch verschärft, da die U-Sperre im Gegensatz zu Haltesperren nicht zur lokalen Sperrvergabe genutzt werden kann (da sie mit Lesesperren anderer Rechner verträglich ist). Der Transfer von Änderungen nicht beendeter Transaktionen hat auch Recovery-Implikationen, da bei einem Transaktionsabbruch die Undo-Recovery erfordern kann, bereits migrierte Seiten an den Transaktionsrechner zurückzuholen, um die Log-Daten anwenden zu können.

Ein unbeschränktes Sperren auf Satzebene ohne Serialisierung von Änderungen ist möglich für Änderungen, welche die Struktur der Seite unverändert lassen (z.B. Änderung bestehender Sätze oder Einträge) [Ra88b, MNS91]. In diesem Fall ist ein explizites Mischen der Änderungen notwendig, um die aktuelle Version der Seite zu erhalten. Das parallele Ändern einer Seite in verschiedenen Rechnern bedingt, daß ein dynamischer Page-Owner-Ansatz nicht mehr anwendbar ist, so daß eine feste Zuordnung der Page-Owner-Funktion erforderlich wird. Jede Satzänderung ist somit an den Page-Owner zu übertragen, so daß er stets die neueste Seitenversion besitzt. Wird der Page-Owner auch zur globalen Sperrbehandlung herangezogen, so können die Änderungen wiederum mit der Sperrfreigabe übergeben werden. Damit erfordert das Mischen keinen zusätzlichen Kommunikationsaufwand. Vorteilhaft ist ferner, daß nicht ganze Seiten, sondern nur Sätze zu übertragen sind, wodurch sich eine deutliche Senkung des Übertragungsumfanges gegenüber Seitensperren erreichen läßt.

Eine noch weitergehende Reduzierung der Konfliktgefahr als mit Satzsperren wird möglich durch spezielle Synchronisationsverfahren, welche die Semantik bestimmter Änderungsoperationen ausnutzen (z.B. Kompatibilität von Inkrement-/Dekrement-Änderungen auf numerischen Attributen) [ON86]. Die Übertragung solcher Verfahren auf Shared-Disk-Systeme wird in [Hä88b, MNS91] diskutiert.