Exchange NOTFALL - Datenbank korrupt

Exchange nutzt zur Ablage von Nachrichten eine Datenbank. Dass dies nicht nur Vorteile bringt, bemerken Sie, wenn die Datenbank korrupt sein sollte. Dann sind nämlich in der Regel sehr viele Anwender oder der gesamte Server betroffen und Hilfe tut not.

Diese Beschreibung fokussiert sich auf Exchange 2000, aber ist vom Ansatz her auch für Exchange 5.5. nutzbar, da die Datenbank vergleichbar ist. Nur die Abschnitte zum Active Directory sind für Exchange 5.5 nicht relevant.

Bei einem guten Design und einer korrekten Installation ist eine korrupte Datenbank allerdings sehr gering, da Exchange in dieser Hinsicht sehr robust und zuverlässig ist und zusätzliche Sicherungsmaßnahmen (CRC Prüfsummen) eingebaut hat. (Siehe -1018 Fehler Ursache und Lösung).

Ehe wir zum Desaster Recovery einer korrupten Datenbank übergehen, sollten Sie die Funktion der Exchange Datenbank und Zusammenhänge der einzelnen Dateien verstanden haben. Lesen Sie dazu bitte den Abschnitt Datenbankgrundlagen komplett durch. Sie sind Basis für das weitergehende Vorgehen.

Microsoft stellt seinerseits sehr ausführliche (über 100 Seiten) Dokumente für das Recovery einer korrupten Exchange Datenbank bereit, die sehr lesenswert sind. Ich kann hier nur eine Schnellfassung für einfache Fälle liefern.

Ich kann hier nur sehr vereinfacht und verkürzt ein Recovery einer Datenbank beschreiben. Wenn ihre Daten sehr wichtig sind, dann sollten Sie unbedingt einen Fachmann vorab befragen, wie umfangreich und erfolgreich eine Wiederherstellung sein kann. Oftmals gibt es effektivere und einfachere Mittel, um die Daten ohne oder mit minimalem Verlust zu retten.

Setzen sie ESEUTIL nicht auf "Verdacht" ein,
sondern nur wenn es angebracht ist.

Oftmals wird zu schnell zu häufig "kaputt repariert". Für eine defekte Datenbank gibt es Gründe, welche erkannt und beseitigt werden müssen.

Vorabprüfung

Ehe Sie mit der Reparatur loslegen ist es an der Zeit zu rekapitulieren, warum die Datenbank in dem aktuellen Status ist.

Ehe Sie daher an irgend eine "Reparatur" der Exchange Datenbank denken, sollten Sie die Reparatur der Basis abgeschlossen haben. Sie können nicht ein Haus wieder beziehen, wenn das Fundament noch nicht wieder instand gesetzt ist.

Kontrolle der Header und Status

Zuerst geht es darum, den aktuellen Status der Datenbank und verbundener Dateien zu lesen. Dazu dient das Programm ESEUTIL. Starten Sie dieses Programm

ESEUTIL /MH c:\exchsrvr\mdbdata\priv1.edb >>status.txt
ESEUTIL /MH c:\exchsrvr\mdbdata\priv1.stm >>status.txt
ESEUTIL /MH c:\exchsrvr\mdbdata\pub1.edb >>status.txt
ESEUTIL /MH c:\exchsrvr\mdbdata\pub1.stm >>status.txt

Nun schauen Sie sich die Datei "status.txt" an. Wichtig sind folgende Einträge: (Auszug. Details siehe Exchange ESEUTIL und ESEFILE):

Ohne diese Protokolldateien können Sie die Datenbank nur noch "hart" in einen konsistenten Zustand bringen, was ohne Zweifel die letzte Option ist, da dabei immer mit Datenverlusten und einer logisch nicht fehlerfreien Datenbank zu rechnen ist..

Wenn Sie sich nicht sicher sind über die physikalische Korrektheit der Datenbank, dann hilft ein Test mit ESEFILE oder ESEUTIL weiter, bei dem die Prüfsumme der Datenbank kontrolliert wird.

C:\exchsrvr\BIN>eseutil /k c:\exchsrvr\mdbdata\priv1.edb

Microsoft(R) Exchange Server(TM) Database Utilities
Version 6.0
Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating CHECKSUM mode...
Database: c:\exchsrvr\mdbdata\priv1.edb
Streaming File: c:\exchsrvr\mdbdata\priv1.STM
Temp. Database: TEMPCHKSUM1998.EDB

Checksumming c:\exchsrvr\mdbdata\priv1.edb

Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................

10326 pages seen
0 bad checksums
3928 uninitialized pages
0 wrong page numbers

Checksumming c:\exchsrvr\mdbdata\priv1.STM

Scanning Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................

1024 pages seen
0 bad checksums
119 uninitialized pages

Operation completed successfully in 3.672 seconds.

Diese Beispiel zeigt, dass diese Datenbank zumindest physikalisch keine Fehler aufweist, d.h. die Daten auch so wieder gelesen werden können, wie sie damals geschrieben wurden. (Siehe auch -1018 Fehler Ursache und Lösung).

Soft Recovery  ESEUTIL /R

Wenn sicher ist, dass die Basis funktioniert und neben der Datenbank alle Protokolldateien vorhanden sind, dann ist das kontrollierte Roll Forward mit ESEUTIL der nächste Schritt. Idealerweise wird dazu das Diagnoseprotokoll auf dem Exchange Server für MSExchangeIS auf Maximum gesetzt, damit mögliche Fehler auch im Eventlog zu finden sind.

ESEUTIL /R startet ähnlich dem Exchange Store die Datenbank und arbeitet nacheinander alle fehlenden Protokolldateien ab. Danach sollte die Datenbank wieder in einem konsistenten Status sein (ESEUTIL /MH)

Hard Recovery ESEUTIL /P  und ISINTEG

Wenn ESEUTIL /R nicht mehr zum Erfolg führt, dann liegt das zumeist daran, dass Protokolldateien fehlen oder korrupt sind. In diesem Fall kann mit ESEUTIL /P die Datenbank zwangsweise konsistent gesetzt werden.

Nach der physikalischen Reparatur der Datenbanken ist es aber zwingend notwendig, dass die logische Struktur mit ISINTEG kontrolliert und repariert wird.
Zudem sollte Sie die alten Protokolldateien (edb*.log) entfernen, da diese nicht mehr benötigt und nicht mehr von Exchange benutzt werden.

Der Aufruf lautet: "ISINTEG -s Server -pub -fix -test alltests". Siehe auch Der Einsatz von ESEUTIL und ESEFILE

Weiterverwendung

Wenn Sie nach all diesen Aktionen ihre Exchange Datenbank wieder gestartet bekommen, dann stellt sich doch die Frage, ob die Inhalte darin komplett funktionstüchtig sind und ob die Datenbank wirklich in einem Status ist, der den problemlosen Weiterbetrieb ohne Überraschungen erlaubt. Wenn Sie nicht 100% sicher sind, sollten Sie möglichst bald darüber nachdenken, die Daten umzuziehen. Hierzu gibt es zwei Wege:

All das hilft aber nur dann weiter, wenn Sie die Ursache für ihre korrupte Datenbank gefunden und beseitigt haben.

Weitere Links

Keywords: Notfall