Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.02.1983

Anatomie einer Katastrophe

Es begann alles ganz harmlos.

Am Freitagnachmittag wird die Datenbank turnusmäßig gesichert: Knapp 6,4 Gigabyte Datenbestände auf insgesamt 16 Platten werden auf Band gesichert, parallel auf acht Bandstationen. Dabei werden 48 Bänder benötigt. Zeit: zirka 4,5 Stunden, wenn keine Platten- oder Bandfehler auftreten.

In der Nacht und am Samstag läuft eine Reorganisation der Primär- und Sekundärindizes der Datenbank. Nach dem Auftreten schwerwiegender Fehler im Reorganisationsprogramm muß die Sicherung vom Freitag zurückgeladen werden. Der "Reload" dauert etwa fünf Stunden, wenn alles gut geht.

Am Montag um 7 Uhr beginnt der Dialogbetrieb mit der Datenbank. Um 9 Uhr ist klar, daß mit der DB etwas nicht in Ordnung ist. Nach umfangreichen Untersuchungen steht fest, daß beim "Reload" einige Datenblöcke nicht zurückgespeichert worden sind.

Während nun die Platten neu initialisiert werden (zwei Stunden) und der "Reload" läuft, wird ein Trickprogramm geschrieben, das die physische Konsistenz der Datenbank überprüfen soll.

Am Montagabend stellt das Prüfprogramm fest, daß die DB auch in diesem Reload-Lauf nicht ordnungsgemäß zurückgespeichert wurde. Die Untersuchung der Sicherheitsbänder ergibt, daß die physischen Inkonsistenzen schon auf den Bändern vorhanden sind, die jüngste Sicherung vom Freitag ist also wertlos.

In der Nacht zum Dienstag läuft nach erneutem Initialisieren der Platten der Reload der eine Woche zurückliegenden Sicherung.

Dienstagmittag steht fest: Auch diese Sicherung ist unbrauchbar.

Nachmittags wird die zwei Wochen zurückliegende Sicherung eingespeichert. Das Prüfprogramm findet keine Fehler, jedoch wurden vorher die Platten versehentlich nicht neu initialisiert.

Am Dienstagabend und in der Nacht zum Mittwoch wird der Reload mit Initialisierung wiederholt. Das Prüfprogamm weist die physische Konsistenz nach. Man atmet auf. Diese Sicherung ist zwar zwei Wochen alt, aber sie ist in Ordnung.

Mittwoch früh bleibt nur noch ein kleines Problem zu lösen: 19 Backup-Tapes müssen mit Hilfe des "Roll Forward Utility" des Datenbanksystems nachgefahren werden, um die Aktivitäten der verlorenen zwei Wochen auf der Datenbank nachzuvollziehen. Die Laufzeit wird auf 48 Stunden geschätzt, wenn alles klappt.

In den frühen Morgenstunden des Donnerstag bricht der Reload mit Bandlesefehlern ab.

Die Untersuchung des Bandabzugs ergibt, daß eine fehlgeleitete Console-Meldung den Originalblock während des Lesens zerstört hat, der Schreibring war nicht entfernt worden . . .

Es bleibt noch die Hoffnung auf die drei Wochen zurückliegende Sicherung, die letzte, die Oberhaupt noch vorhanden ist.

Acht Stunden später erweist sich diese ebenfalls als unbrauchbar. Von vier Sicherungen ist nur eine einzige physisch konsistent, die aber hat Lesefehler.

Nun wird versucht, das Band zu duplizieren, um über den Lesefehler hinwegzukommen und den - fehlenden 30-K-Block aus einem jüngeren Sicherungsband einzumischen, auf dem der Block noch vorhanden ist. Glücklicherweise gibt es keine Unverträglichkeiten der Datenbestände des einzumischenden jüngeren Blocks.

In der Nacht zum Freitag kann der Reload mit dem duplizierten, zusammengemischten Band wiederholt werden.

Dabei stellt sich heraus, daß beim Duplizieren (beide Bänder sind ganz durchgespult worden, sie mußten von Hand wieder eingefädelt werden) das Ausgabeband zu kurz gewesen sein muß: Die letzten 14 Blöcke fehlen.

Die ganze Prozedur des Duplizierens und Mischens wird wiederholt, diesmal mit einem verlängerten Ausgabeband.

Freitagmittag ist der Reload beendet.

In der Zwischenzeit ist das Prüfprogramm zu einem Sicherungsprogramm aufgerüstet worden, primitiv, aber wirksam. Damit wird die Datenbank jetzt gesichert.

Gegen Abend wird das Roll Forward Utility wieder gestartet.

Samstagmittag: Roll Forward stürzt ab; diesmal kann nach der Fehlerbehebung abends die Wiederanlauftechnik des Roll Forward genutzt werden, Daten sind nicht zerstört.

Sonntag gegen Mittag ist das Vorrollen der Datenbank und die anschließende Sicherung auf Band abgeschlossen. Bis zum Abend wird die DB durch Stichproben logisch überprüft und für gut befunden. Ab Montag früh steht sie wieder einsatzbereit zur Verfügung.

Happy End? Natürlich!

Es ist ja auch eine erfundene Geschichte.

Oder doch nicht!