9 Replizierte Datenbanken

9.2 Primary-Copy-Verfahren

Primary-Copy-Verfahren [AD76, St79] zielen auf eine effizientere Bearbeitung von Änderungen ab, indem eine Änderungstransaktion bei einer Modifikation nur eines der Replikate, die sogenannte Primärkopie (primary copy), zu ändern braucht. Die Aktualisierung der anderen Replikate wird dann asynchron vom Primary-Copy-Rechner aus durchgeführt, i.a. erst nach Ende der ändernden Transaktion ("as soon as possible"). Dabei können Nachrichten eingespart werden, indem der Primärkopien-Rechner mehrere Änderungen gebündelt an die kopienhaltenden Rechner weiterleitet. Dies geht dann jedoch zu Lasten einer verzögerten Anpassung der Replikate. Im allgemeinen werden die Primärkopien unterschiedlicher Objekte an verschiedenen Knoten gespeichert sein, um einen zentralen Engpaß zu vermeiden. Zur Reduzierung von Kommunikationsvorgängen empfiehlt sich dabei natürlich die Zuordnung einer Primärkopie an den Rechner, an dem das Objekt am häufigsten geändert wird.

Insgesamt bestehen mehrere Alternativen bei der Realisierung eines Primary-Copy-Protokolls. Ein Ansatz besteht darin, wie beim ROWA-Protokoll Änderungssperren verteilt bei allen kopienhaltenden Rechnern anzufordern. Am Transaktionsende wird jedoch nur die Primärkopie synchron aktualisiert, so daß eine schnellere Bearbeitung von Änderungstransaktionen als mit dem ROWA-Ansatz erreicht wird. Nach Aktualisierung der Primärkopie geht die Schreibsperre dann quasi in den Besitz des Primary-Copy-Rechners über, der diese bis nach der Aktualisierung der Replikate hält. Das verteilte Sperren aller Kopien bringt den Vorteil mit sich, daß Leser wie im ROWA-Verfahren ein beliebiges Replikat referenzieren (sperren) können, nicht also notwendigerweise die Primärkopie. Die verzögerte Aktualisierung der Replikate kann dafür vermehrte Sperrkonflikte verursachen.

Die Alternative zu diesem Ansatz besteht darin, Schreibsperren nur noch zentral beim jeweiligen Primary-Copy-Rechner anzufordern, um den Aufwand verteilter Schreibsperren zu umgehen. Für Leser besteht jetzt jedoch das Problem, daß die lokalen Kopien aufgrund der verzögerten Aktualisierung möglicherweise veraltet sind. Für die Behandlung der Lesezugriffe bestehen im wesentlichen drei Alternativen, die sich dadurch unterscheiden, wo die Objektzugriffe erfolgen und wo die Sperren angefordert werden (zentral beim Primary-Copy-Rechner oder verteilt/lokal):

  1. Lesezugriff auf Primärkopie
    In diesem Ansatz referenzieren und sperren Lesetransaktionen die Primärkopie, um den aktuellsten, konsistenten DB-Zustand zu sehen. Damit werden jedoch die Replikate kaum noch genutzt, so daß dieser Ansatz nur in Kombination mit einem der anderen von Interesse erscheint.

  2. Lesezugriff auf lokale Kopien, Sperranforderung beim Primärkopien-Rechner
    Im Gegensatz zur vorherigen Alternative werden nur die Lesesperren zentral beim Primärkopien-Rechner angefordert, der Objektzugriff erfolgt dagegen lokal. Damit kann der Kommunikationsumfang für Leseoperationen reduziert und der Primärkopien-Rechner entlastet werden. Bei der Anforderung der Lesesperre kann gleichzeitig überprüft werden, ob die für den Lesezugriff vorgesehene Objektkopie bereits auf dem aktuellen Stand ist. Falls nicht, kann entweder auf den Abschluß der Aktualisierung gewartet oder auf eine bereits aktualisierte Kopie ausgewichen werden (z.B. die Primärkopie).

  3. Lokale Abwicklung von Lesezugriffen
    In diesem Ansatz greifen Leser auf lokale Objekte zu, ohne eine Synchronisierung über den Primärkopien-Rechner vorzunehmen. Die Aktualität der lokalen Kopien ist dabei nicht mehr gewährleistet, wenngleich die Daten i.a. höchstens wenige Sekunden veraltet sein dürften [Gr86]. Gravierender ist jedoch, daß Leser in diesem Fall eine inkonsistente Sicht auf die Datenbank haben, da sie i.d.R. für verschiedene Objekte unterschiedliche Änderungszustände sehen[37]. Dies kann nur in einfachen Fällen umgangen werden, z.B. wenn eine Transaktion nur ein Objekt oder nur Objekte mit lokaler Primärkopie referenziert. Anderenfalls bleibt für Lesetransaktionen, die den Zugriff auf eine konsistente DB-Version benötigen, eine der beiden vorgenannten Möglichkeiten. Alternativ dazu ist es möglich, das Synchronisationsverfahren so zu erweitern, daß Leser zwar u.U. einen leicht veralteten, aber dennoch konsistenten DB-Zustand sehen (etwa im Rahmen eines Mehrversionen-Konzepts [Wa83]).

Beispiel 9-3

Für die Situation aus Beispiel 9-1 (Abb. 9-1) nehmen wir an, daß die Primärkopien der Kontosätze an den jeweiligen Filialrechnern liegen, das heißt, R1 hält die Primärkopie von A und R3 von B. Damit können in diesen Rechnern sämtliche Lese- und Schreibzugriffe auf lokale Konten ohne Kommunikation abgewickelt werden. Kommunikation fällt lediglich für die Kontenzugriffe in der Zentrale R2 an. Dort vorzunehmende Kontoänderungen erfordern Kommunikation zum Sperren und Aktualisieren der jeweiligen Primärkopie. Die Behandlung von Lesezugriffen in R2 differiert für jede der drei Strategien. Strategie 1 verlangt das Sperren und Lesen der Primärkopie und somit Nachrichten für Objektzugriff und Commit, während Strategie 2 lediglich Nachrichten für die Sperranforderung und -freigabe erfordert. Mit Strategie 3 greift R2 unsynchronisiert auf die lokalen, möglicherweise veralteten Objektkopien zu, was für globale Auswertungen durchaus ausreichend sein kann.

Im Falle einer Netzwerk-Partitionierung können in der Partition mit dem jeweiligen Primary-Copy-Rechner Objekte weiterhin gelesen und geändert werden. In den anderen Partitionen ist i.a. kein weiterer Zugriff möglich; lediglich bei der obigen Strategie 3 ist ein Lesezugriff auf die ggf. veralteten Kopien zulässig.

Der Ausfall eines Rechners macht die an ihm vorliegenden Primärkopien unerreichbar, so daß keine Änderungen bis zur Reintegration des Knotens mehr möglich sind. Um diese lange Unterbrechung zu vermeiden, kann vorgesehen werden, einen neuen Primärkopien-Rechner zu bestimmen. Dies setzt jedoch voraus, daß die neue Primärkopie auf den neusten Stand gebracht werden kann. Im Falle einer Netzwerk-Partitionierung ist dabei darauf zu achten, daß für ein Objekt höchstens in einer der Partitionen ein neuer Primärkopien-Rechner bestimmt wird (z.B. in der Partition mit mehr als der Hälfte aller Kopien).

[37] Allerdings wird in der Praxis selbst in zentralisierten DBS Lesetransaktionen aus Leistungsgründen meist keine konsistente DB-Sicht gewährt, da Lesesperren i.a. nur kurz gehalten werden. Es liegt dabei jedoch meist eine Wahlmöglichkeit für den Programmierer vor, ob eine derartige Einschränkung der Konsistenz zugelassen wird.