9 Replizierte Datenbanken

9.4 Schnappschuß-Replikation

Die Forderung, sämtliche Replikate eines Objektes stets auf demselben Stand zu halten, verursacht v.a. in geographisch verteilten Systemen sehr hohe Änderungskosten. Weiterhin führen die erweiterten Synchronisationsanforderungen i.a. Mehraufwand an Kommunikation ein. Diese Kosten können durch eine schwächere Form der Datenreplikation, sogenannte Schnappschüsse (snapshots), signifikant reduziert werden [AL80]. Ein Schnappschuß entspricht dabei einer materialisierten Sicht, die durch eine DB-Anfrage spezifiziert wird. Das Ergebnis der Anfrage wird als eigenständiges DB-Objekt unter einem benutzerspezifizierten Namen gespeichert. Der Zugriff auf einen Schnappschuß erfolgt mit der jeweiligen DB-Anfragesprache, wobei jedoch nur Lesezugriffe zugelassen werden.

Eine mögliche Schnappschuß-Definition in der Bankanwendung sieht folgendermaßen aus:

               CREATE  SNAPSHOT   Underflow  AS
                   SELECT  KNR, KTONR, KTOSTAND
                   FROM KONTO
                   WHERE KTOSTAND < 0
               REFRESH EVERY DAY
Diese Anweisung ermittelt alle überzogenen Konten und speichert das Ergebnis in einer eigenen Relation Underflow. Das Ergebnis entspricht einer Kopie auf einer Teilmenge der KONTO-Relation, deren Gültigkeit sich auf den Auswertungszeitpunkt bezieht (Schnappschuß). In [AL80] wurde vorgesehen, daß der Benutzer bei der Definition eines Schnappschusses (mit der REFRESH-Option) ein "Auffrischen" der Kopie in bestimmten Zeitabständen verlangen kann (stündlich, täglich, wöchentlich etc.). Neben einer derart automatischen Aktualisierung kann auch über eine eigene REFRESH-Anweisung die Schnappschuß-Aktualisierung explizit veranlaßt werden. Für unser Beispiel wird dies erreicht durch die Anweisung 

                  REFRESH SNAPSHOT Underflow.
Das Schnappschuß-Konzept ist relativ einfach und effizient realisierbar und dennoch flexibel. Zur Spezifikation eines Schnappschusses steht die volle Auswahlmächtigkeit der DB-Anfragesprache zur Verfügung, so daß die "Kopien" keineswegs auf Teilmengen der Datenbank beschränkt sind, sondern auch aggregierte Informationen, Verknüpfungen mehrerer Relationen etc. enthalten können. Ebenso kann der Benutzer bzw. DB-Administrator die Aktualisierungsintervalle in flexibler Weise an die Bedürfnisse der jeweiligen Anwendung anpassen. Weiterhin wird ein sehr gutes Leistungsverhalten unterstützt, da Zugriffe auf einen lokal gespeicherten Schnappschuß ohne Kommunikation erledigt werden und eine Lastbalancierung unterstützen (Entlastung des Rechners mit der "Primärkopie"). Weiterhin wird durch die relativ seltene Aktualisierung von Schnappschuß-Kopien der Änderungsaufwand sehr klein gehalten. Ein weiterer Vorteil liegt darin, daß das Synchronisationsproblem replizierter Datenbanken entfällt, da auf Schnappschuß-Relationen nur Leseoperationen zulässig sind.

Auf der anderen Seite ist natürlich die "Qualität" einer Schnappschuß-Kopie geringer als die einer Kopie bei allgemeinen replizierten Datenbanken. Insbesondere sind auf einem Schnappschuß keine Änderungsoperationen möglich und die Informationen sind i.d.R. veraltet (wenn auch in einem kontrollierten Maß). Dies reduziert auch den Wert der Kopie im Fehlerfall (Ausfall des Rechners mit der Primärkopie). Dennoch ist diese schwächere Form der Replikation für viele Anwendungen ausreichend. Man denke etwa an Verzeichnisse wie Ersatzteillisten bei KFZ-Betrieben, Buchkataloge in Bibliotheken oder Telefonbücher. Auf solche Daten wird häufig und vorwiegend lesend zugegriffen, so daß sich eine Replikation zur Einsparung von Kommunikation lohnt. Zudem reicht in diesen Fällen eine periodische Aktualisierung der Kopien vollkommen aus.

Die skizzierte Form von Schnappschuß-Replikation wurde im Prototyp R* realisiert [AL80]. Effiziente Techniken zur Aktualisierung von Schnappschüssen werden in [Li86] vorgestellt. Eine zunehmende Anzahl kommerzieller Produkte unterstützt eine Schnappschuß-Replikation, u.a. von IBM (DataPropagator), DEC (Data Distributor), ASK/Ingres (Replicator), Oracle, Software AG (Entire Transaction Propagator), HP (Allbase/Replicate) etc.

Ein den DB-Schnappschüssen verwandtes Konzept ist das der Quasi-Kopien [ABG90], das jedoch für eine Kopienhaltung bzw. Pufferung von Objekten in Workstation/Server-Umgebungen vorgesehen wurde. Die Idee dabei ist, anwendungsspezifisches Wissen zu verwenden, um die Aktualisierung replizierter Objekte zu steuern. Zum Beispiel könnte so verlangt werden, daß Änderungen einer Preisliste nur dann propagiert werden sollen, sobald sich Preisunterschiede von über 5% ergeben oder sich mehr als 10% aller Preise geändert haben.