14 Synchronisation in Shared-Disk-DBS

14.4 Verteilte Sperrverfahren mit dynamischer GLA-Zuordnung

Das Problem des Primary-Copy-Sperrverfahrens, eine möglichst geeignete DB-Partitionierung zu finden, entfällt bei dynamischer GLA-Zuordnung. Hierbei wird keine vordefinierte GLA-Zuordnung angewendet, sondern derjenige Rechner, der ein Objekt erstmalig referenziert, erhält automatisch die globale Sperrverantwortung. Da jeder Rechner weiß, für welche Objekte er die GLA hält, können für diese Objekte alle Sperranforderungen und -freigaben lokal bearbeitet werden. Für die sonstigen Objekte muß jedoch erst herausgefunden werden, ob und an welchem Rechner bereits ein zuständiger GLM vorliegt. Diese GLM-Lokalisierung erfordert i.a. zusätzliche Nachrichten gegenüber einem Ansatz mit fester GLA-Zuordnung, die allen Rechnern bekannt ist.

Nachdem ein Rechner die GLA für ein Objekt erhalten hat, behält er die GLM-Funktion i.a. mindestens solange, bis die von ihm vergebenen Sperren wieder freigegeben sind. Dies garantiert, daß die Sperrfreigabe (bzw. Sperrkonversion) vom gleichen Rechner vorgenommen wird wie die Sperrvergabe, so daß eine erneute GLM-Lokalisierung entfällt. Nach Freigabe der letzten Transaktionssperre kann die GLA für das Objekt auch aufgegeben werden, so daß bei späterer Referenz ein neuer GLM-Rechner bestimmt wird. Alternativ dazu kann die GLA beibehalten werden, um nachfolgende Referenzen am gleichen Rechner ohne Verzögerungen bearbeiten zu können. Sollte der spätere Zugriff auf das Objekt von einem anderen Rechner aus erfolgen, kann eine GLA-Migration an diesen Rechner vorgesehen werden, um dort eine lokale Verarbeitung zu ermöglichen. Generell wird es durch die Dynamik der GLA-Zuordnungen schwieriger als bei fester GLA-Zuordnung, durch die Lastverteilung ein hohes Maß an lokaler Sperrverarbeitung zu ermöglichen.

Zur GLM-Lokalisierung könnte - ähnlich wie bei fester GLA-Zuordnung - die Verteilungsinformation repliziert an jedem Knoten geführt werden. Damit muß jedoch jede Änderung in der GLA-Zuordnung im ganzen System propagiert werden, was einen enormen Aufwand verursachen kann. Günstiger erscheint daher, die GLA-Zuordnung in einem nicht replizierten Directory zu verwalten. Das Directory kann dabei zentral an einem Knoten oder partitioniert an mehreren Rechnern vorliegen. Im letzteren Fall kann etwa wieder über eine Hash-Funktion festgelegt werden, welcher Rechner für ein Objekt die GLA-Zuordnung führt. Diese Indirektion führt jedoch zu bis zu 4 Nachrichten für eine Sperranforderung. Denn zunächst ist der zuständige Directory-Knoten zu konsultieren, um den GLM-Rechner zu ermitteln (2 Nachrichten), bevor die eigentliche Sperre angefordert werden kann[60]. Die Anpassung der Directory-Information bei Aufgabe oder Migration der GLA erfordert i.a. ebenfalls zusätzliche Nachrichten.

Die Kosten der GLM-Lokalisierung sind jedoch auch stark davon abhängig, für welche Objektgranularitäten die GLA-Zuordnung erfolgt. Insbesondere kann im Rahmen eines hierarchischen Sperrprotokolls die GLA-Vergabe auf grobe Granulate wie Satztypen beschränkt werden. Damit können in dem Rechner, der die GLA für einen Satztyp (Relation) bekommen hat, sämtliche zugehörigen Seiten und Sätze lokal synchronisiert werden. An anderen Rechnern wird eine GLM-Lokalisierung zudem nur für Satztypen erforderlich; für die untergeordneten Objekte ist damit der zuständige GLM-Rechner bereits ermittelt. Allerdings kann die Verwendung grober GLA-Granulate leicht zu einer ungleichmäßigen Unterstützung der lokalen Sperrvergabe sowie ungleicher Verteilung des Sperraufwandes an den einzelnen Rechnern führen.

Beispiel 14-5

Im Szenario von Abb. 14-7 wird Relation A zunächst in R1 erstmalig referenziert. Dazu wird der für A zuständige Directory-Rechner R2 konsultiert, wobei festgestellt wird, daß für A noch kein GLM vorliegt. Deshalb überträgt R2 die GLA für A an R1 und erweitert seine Directory-Information entsprechend. In R1 können dann die Sperren für A fortan lokal bearbeitet werden. Im weiteren Verlauf der Transaktionsverarbeitung soll Relation A in Rechner R3 referenziert werden (Schritt 2 in Abb. 14-7). Für die zugehörige Sperranforderung werden 4 Nachrichten erforderlich, nämlich zwei zur GLM-Lokalisierung und zwei zum Sperrerwerb selbst. Wenn keine Sperren für A mehr vergeben bzw. angefordert sind, kann R1 die GLA aufgeben, wozu die Directory-Information in R2 zurückzusetzen ist. Bei einer Migration der GLA für A, z.B. nach R3, ist die Directory-Information in R2 ebenso anzupassen.

Abb. 14-7: Sperrszenario mit dynamischer GLA-Zuordnung

Ein solcher Ansatz mit dynamischer GLA-Zuordnung wird in DEC VaxCluster-Systemen unterstützt, und zwar durch den sogenannten Distributed Lock Manager (DLM) des VMS-Betriebssystems, der von den Shared-Disk-DBS genutzt wird [KLS86, ST87, Jo91]. Die GLM-Lokalisierung basiert auf einem über eine Hash-Funktion partitionierten Directory.

[60] Einsparungen ergeben sich, wenn Transaktionsrechner, Directory-Knoten und GLM-Rechner nicht verschieden sind.