13.3 Neue Realisierungsanforderungen

13.3.4 Logging und Recovery

Jeder Verarbeitungsrechner protokolliert die DB-Änderungen der bei ihm ausgeführten Transaktionen in eine lokale Log-Datei. Mit der lokalen Log-Datei können dann sowohl Rücksetzungen einzelner Transaktionen als auch die Recovery nach Ausfall eines Rechners vorgenommen werden. Das Führen der lokalen Log-Datei kann mit den aus zentralisierten DBS bekannten Techniken erfolgen [GR93]. Die Behandlung von Plattenfehlern und ggf. auch von Rechnerausfällen verlangt jedoch zusätzlich die Erstellung einer globalen Log-Datei, in der sämtliche Änderungen im System in chronologischer Reihenfolge protokolliert sind. Dies ist erforderlich, da eine bestimmte Seite i.a. an mehreren Rechnern geändert wird. Zur Rekonstruktion des neuesten Seitenzustands im Fehlerfall sind daher die an verschiedenen Rechnern vorgenommenen Änderungen in der ursprünglichen Reihenfolge zu wiederholen.

Beispiel 13-1

Im Szenario von Abb. 13-5 werden die drei DB-Seiten 1, 2 und 3 von drei Transaktionen verschiedener Rechner geändert, wobei die Serialisierungsreihenfolge T1 < T2 < T3 sein soll. So ändert zunächst T1 die Seiten 1 und 2 (neue Versionen 1' und 2') in Rechner R1, danach T2 die Seiten 2 und 3 in R2; abschließend ändert T3 in R3 alle drei Seiten. Die Änderungen werden jeweils in den lokalen Log-Dateien der Rechner protokolliert. Die physische DB enthält noch die alten Seitenversionen, da unterstellt wurde, daß geänderte Seiten direkt zwischen den Rechnern ausgetauscht werden. Nach einem Ausfall der gezeigten DB-Platte sind somit alle Änderungen seit dem letzten Einlesen zu wiederholen. Dies verlangt die Anwendung der Log-Daten aller lokalen Log-Dateien in der ursprünglichen Reihenfolge, wie es mit einer globalen Log-Datei unterstützt wird.

Selbst die Crash-Recovery erfordert aufgrund des direkten Austauschs geänderter Seiten die Anwendung der globalen Log-Datei. Fällt etwa R3 aus, so sind die dort ausgeführten Änderungen erfolgreicher Transaktionen zu wiederholen. Dazu genügt es jedoch nicht, lediglich die lokalen Log-Daten anzuwenden, da die Änderungen in R3 auf zuvor ausgeführten Änderungen der anderen Rechner basieren, die jedoch noch nicht in der physischen Datenbank reflektiert sind. Daher müssen diese zuvor auch wiederholt werden, wie mit einem globalen Log möglich.

Abb. 13-5: Beispiel-Szenario zur Recovery in SD-Systemen

Die direkte Erstellung einer globalen Log-Datei auf Plattenspeicher ist i.a. zu aufwendig, da zusätzliche Schreibvorgänge am Transaktionsende notwendig würden und zudem das aktuelle Log-Ende aufgrund der hohen Schreibfrequenz leicht zum Engpaß würde. Daher ist es vorzuziehen, die globale Log-Datei asynchron zur Transaktionsverarbeitung durch Mischen der lokalen Log-Dateien zu erstellen. Die Mehrzahl existierender SD-Implementierungen sieht hierfür einen Offline-Ansatz vor, bei dem der Systemverwalter durch Starten eines Dienstprogrammes die Erstellung bzw. Vervollständigung der globalen Log-Datei veranlaßt. Von Nachteil dabei ist jedoch, daß im Fehlerfall manuelle Eingriffe notwendig werden und lange Zeit vergehen kann, bis die benötigten globalen Log-Daten vorliegen. Eine bessere Verfügbarkeit wird mit einer Online-Erstellung der globalen Log-Datei erreicht, bei der im laufenden Betrieb bereits das Mischen der Log-Daten erfolgt. Ein solcher Ansatz ist jedoch schwer zu realisieren und beeinträchtigt das Leistungsverhalten im Normalbetrieb (zusätzliche Kommunikations- und E/A-Vorgänge, großer Log-Umfang).

Um ein korrektes Mischen zu ermöglichen, sind die Log-Sätze der lokalen Log-Dateien mit geeigneten Zeitstempeln oder Änderungszählern zu kennzeichnen. Ein in IBM-Systemen verfolgter Ansatz ist die Nutzung einer speziellen Hardware-Uhr (Sysplex Timer), welche von allen Rechnern zugreifbar ist und systemweit eindeutige Zeitstempel liefert, die in die Log-Sätze aufgenommen werden. Damit brauchen die Log-Sätze nur noch nach diesen Zeitstempel sortiert zu werden. Von Nachteil sind dabei jedoch die relativ hohen Kosten für die Uhr. Ein alternativer Ansatz besteht im Führen seitenspezifischer Änderungszähler, die bei jeder Änderung inkrementiert werden. Damit lassen sich ohne Spezial-Hardware die Änderungen für jede Seite auch systemweit ordnen, allerdings nicht seitenübergreifend [Lo90]. Eine weitere Alternative besteht darin, an jedem Rechner einen lokalen Änderungszähler zu führen, der mit den Zählern anderer Rechner synchronisiert wird [MN92b, DYJ94]. Ein Ansatz dazu ist, bei jedem Seitentransfer von Rechner A nach B den aktuellen Zählerstand von A mitzuübergeben. Liegt er über dem Zählerstand von B, wird dieser auf den höheren Wert von Rechner A gebracht. Dadurch ist sichergestellt, daß alle Seitenänderungen in B einen höheren Zeitstempel erhalten als die zuvor in A vorgenommenen Änderungen. Ein solcher Ansatz entspricht der von Lamport vorgeschlagenen Methode zur Uhrensynchronisation in verteilten Systemen [La78].

Die Recovery nach Ausfall eines Rechners muß, um eine möglichst störungsfreie Fortsetzung der Verarbeitung zu erlauben (Freigabe gehaltener Sperren u.ä.), von einem oder mehreren der überlebenden Rechner mit der lokalen Log-Datei des ausgefallenen durchgeführt werden. Dabei sind alle durch den Rechnerausfall verlorengegangenen DB-Änderungen erfolgreich beendeter Transaktionen zu rekonstruieren. Diese Redo-Recovery muß - wie das Beispiel gezeigt hat - ggf. mit einer globalen Log-Datei erfolgen. Transaktionen, die durch den Rechnerausfall unterbrochen wurden, sind mit der lokalen Log-Datei zurückzusetzen (Undo-Recovery), wobei ggf. gehaltene Sperren freizugeben sind. Während der Crash-Recovery müssen außerdem ggf. verlorengegangene Datenstrukturen rekonstruiert werden, um eine korrekte Fortsetzung von Synchronisation und Kohärenzkontrolle zu gewährleisten. Die Einzelheiten dafür hängen natürlich stark von den jeweils verwendeten Protokollen ab [MN91, Ra91a].

Die Katastrophen-Recovery für Shared-Disk-Systeme kann im Prinzip wie in Kap. 9.5 dargestellt mit einem geographisch entfernten Backup-System erfolgen. Dabei empfiehlt sich jedoch die Übertragung der globalen Log-Daten, um die DB-Kopie im Backup-System nachführen zu können. Dies setzt eine Online-Erzeugung der globalen Log-Datei voraus.