14 Synchronisation in Shared-Disk-DBS

14.3 Verteilte Sperrverfahren mit fester GLA-Zuordnung

Die restlichen Sperrverfahren, die noch zu behandeln sind, verwenden keine dedizierten Rechner zur globalen Synchronisation, sondern führen diese auf allen Verarbeitungsrechnern durch. Dies ergibt eine homogene Systemarchitektur, was Vorteile hinsichtlich Lastbalancierung und Verfügbarkeit ergibt; insbesondere entfällt bei der Behandlung von Rechnerausfällen die Unterscheidung zwischen Verarbeitungsrechner und GLM-Rechner. Ein weiterer großer Vorteil liegt darin, daß eine lokale Bearbeitung von Sperranforderungen und -freigaben für diejenigen Objekte möglich wird, für die der Verarbeitungsrechner die globale Sperrverantwortung besitzt. Dies wird sowohl von einer festen als auch der dynamischen Zuordnung der GLA unterstützt.

Der Ansatz mit einer festen GLA-Zuordnung wird in [Ra86b] als Primary-Copy-Sperrverfahren bezeichnet, obwohl das Verfahren nur bedingt mit dem gleichnamigen Verfahren für replizierte Datenbanken (Kap. 9.2) vergleichbar ist[58]. Wie in Abb. 14-6 gezeigt, existiert dabei in jedem Rechner ein GLM, der für eine Partition der Datenbank die globale Sperrverantwortung (GLA) besitzt. So können in Rechner R2 sämtliche Sperren auf der lokalen Partition B ohne Kommunikation behandelt werden. Anforderungen für Objekte der Partitionen A und C dagegen sind an die zuständigen Rechner R1 bzw. R3 zu stellen. Die GLA-Verteilung ist vorab festgelegt und allen Rechnern bekannt.

Abb. 14-6: GLA-Aufteilung beim Primary-Copy-Sperrverfahren

Ein einfacher Ansatz zur GLA-Allokation ist wieder die Nutzung einer Hash-Funktion, die jeden Objektbezeichner auf einen der N Rechner (GLM) abbildet. Damit sind jedoch nur relativ geringe Kommunikationseinsparungen möglich, da im Durchschnitt nur 1 von N Sperranforderungen lokal behandelt werden kann, so daß im Mittel 2 - 2/N Nachrichten pro Sperranforderung anfallen. Der Anteil lokaler Sperren läßt sich erhöhen, wenn GLA-Aufteilung und Lastverteilung aufeinander abgestimmt werden. Dies erfordert i.a. eine logische DB-Partitionierung, bei der die GLA-Zuordnung für Satztypen bzw. horizontale Fragmente (Kap. 5.3) erfolgt. Weiterhin ist ein darauf abgestimmtes affinitätsbasiertes Routing (Kap. 13.3.3) vorzunehmen, so daß Transaktionen vorzugsweise an den Rechnern bearbeitet werden, an denen die meisten ihrer Sperren lokal bearbeitet werden können. Die damit unterstützte und auf die GLA-Verteilung ausgerichtete rechnerspezifische Lokalität bewirkt direkte Kommunikationseinsparungen und ermöglicht eine weitgehend lokale Transaktionsverarbeitung.

Es ist möglich, das Primary-Copy-Verfahren mit Schreib- und Leseautorisierungen zu erweitern, ähnlich wie in Kap. 14.2 vorgestellt. Damit wird auch an den Verarbeitungsrechnern, die nicht die GLA für ein Objekt besitzen, eine lokale Synchronisierung möglich, sofern eine ausreichende Autorisierung vorliegt. Allerdings wird damit der Nutzen einer lokalen GLA abgeschwächt, da dann auch Sperranforderungen auf der lokalen Partition nur mit Kommunikationsverzögerungen bearbeitet werden können, wenn zuvor extern vergebene Autorisierungen zurückzunehmen sind[59].

Beispiel 14-4

Im Beispiel von Abb. 14-6 habe Rechner R2 eine Schreibautorisierung für Objekt A1 von Partition A sowie eine Leseautorisierung für Objekt C1 von Partition C. Damit können sämtliche Zugriffe auf A1 in R2 lokal bearbeitet werden, obwohl R1 die GLA für dieses Objekt besitzt. Dafür müssen auch im GLA-Rechner R1 Zugriffe auf A1 verzögert werden, bis R2 die Schreibautorisierung zurückgegeben hat. In R2 können daneben Lesezugriffe auf C1 lokal behandelt werden, obwohl R3 für dieses Objekt zuständig ist. Ein Entzug durch R3 wird erst bei einer Schreibanforderung veranlaßt, wodurch auch für Transaktionen in R3 Verzögerungen entstehen können.

Der Einsatz von Schreib- und Leseautorisierungen empfiehlt sich generell bei einem einfachen, hash-basierten Ansatz zur GLA-Verteilung, da hierbei über eine lokale GLA nur geringe Einsparungen möglich werden. Soll dagegen mit GLA- und Lastverteilung ein hohes Maß an lokaler Sperrverarbeitung erreicht werden, ist v.a. der Einsatz von Schreibautorisierungen nicht zu empfehlen, da diese - wie die Nutzung einer lokalen GLA - auf rechnerspezifischer Lokalität aufbauen. Das Konzept der Schreibautorisierungen weist jedoch den Nachteil der Instabilität auf, da eine solche Autorisierung entzogen wird, sobald ein anderer Rechner auf das Objekt zugreifen will. Die GLA-Zuordnung dagegen ist stabil, so daß ein Objekt am GLA-Rechner stets lokal synchronisiert werden kann, unabhängig von der sonstigen Referenzverteilung im System. Zudem entfallen analoge Nachrichten und Verzögerungen wie beim Entzug von Schreibautorisierungen, da die GLA-Zuordnung nicht entzogen wird.

Die Vergabe von Leseautorisierungen erscheint demgegenüber auch für das Primary-Copy-Sperrverfahren empfehlenswert (für Objekte mit vorwiegendem Lesezugriff). Dieses Konzept erfordert nämlich keine rechnerspezifische Lokalität. Es ist vielmehr in der Lage, die Abhängigkeiten zur günstigen Partitionierbarkeit der Transaktionslast und der Datenbank zu reduzieren [Ra93d]. Insbesondere können die gleichen Objekte in mehreren Rechnern parallel bearbeitet und lokal synchronisiert werden, solange Lesezugriffe vorliegen.

Der Hauptnachteil bei der Nutzung einer lokalen GLA im Rahmen des Primary-Copy-Sperrverfahrens liegt darin, daß ähnlich wie für Verteilte DBS bzw. Shared-Nothing-Systeme eine DB-Partitionierung gefunden werden muß, die eine weitgehend lokale Verarbeitung von Transaktionen auf N Rechnern zuläßt. Es ist jedoch zu beachten, daß diese logische DB-Partitionierung nur für Synchronisationszwekke verwendet wird, daß jedoch weiterhin jeder Rechner auf die gesamte DB zugreifen kann. Dies erleichtert zum einen die Anpassung der Partitionierung, z.B. bei geänderter Rechneranzahl oder stark wechselndem Transaktionsprofil, da hiermit keine physische Umverteilung der Daten einhergeht. Zudem bleibt das hohe Lastbalancierungspotential der Shared-Disk-Architektur bestehen, da weiterhin jeder Knoten alle DB-Operationen ausführen kann.

[58] Eine bessere Rechtfertigung für den Namen ergibt sich bei Berücksichtigung der Kohärenzkontrolle (Kap. 15.3.3).
[59] Die Vergabe von Schreib- und Leseautorisierungen ist nur für Rechner notwendig, die für das Objekt nicht die GLA halten, da der GLM-Rechner generell lokal über die Sperrvergabe entscheiden kann.