Exchange NOTFALL - Datenbank korrupt

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/

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.

  • WAS ist passiert
    Ist der Server einfach nurt abgestürzt, oder hat ein Wurm ihre Datenbank aufgebläht. Ist ihnen einfach nur der Festplattenplatz ausgegangen oder hat jemand am SCSI-Kabel gewackelt ?
    Lesen Sie ihre Eventlogs, um den Fehler zu finden und beseitigen Sie die Ursache.
  • Active Directory und DNS
    Exchange 2000 kann nicht ohne ein funktionierendes Active Directory arbeiten. Ist in dieser Hinsicht alles OK ?. NETDIAG und DCDIAG melden alle Tests "passed" ?. Oder ist der Defekt des Server zugleich auch ein Defekt beim Active Directory ?
    Prüfen Sie den Status des Active Directory
  • Server
    Exchange nutzt die Hardware sehr viel intensiver als ein Arbeitsplatz. IDE-Festplatten mit Software RAID sind auch mit Exchange möglich, aber egal welche Hardware Sie einsetzen, sie muss ZWEIFELSFREI sein. Leider gibt es keine allgemeinen Tests zur Überprüfung der Hardware. Mit Tools wie dem Festplatten und Speichertest der Zeitschrift c't (http://www.heise.de/ct), der S.u.s.e-Linux Startdiskette oder DT und IOMETER (www.intel.com) kann ein Server trotzdem etwas unter Last gebracht werden.
    Kontrollieren Sie auf jeden Fall das Eventlog auf -1018-Fehler.
  • Datenbank
    Ihre Datenbank lässt sich nicht mehr mounten, aber wissen sie, welchen Status sie hat ? Was ist denn der genaue Fehler beim Start ?. Fehlt einfach nur eine Protokolldatei oder stimmen Pfade nicht mehr oder ist der Fehler schwerwiegender ?

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):

  • State: Consistent
    Der State sagt und den Status der Datei. Ideal ist "consistent". Aber meist wird uns ein "Dirty Shutdown" angezeigt, was so viel heißt, dass der Store nicht sauber herunter gefahren wurde und die Protokolldateien notwendig sind.
  • Log Required: 39-42
    Dieser Eintrag nennt uns die Nummern der Protokolldateien, welche notwendig sind. Diese Dateien sind laufend durchnummeriert und müssen am passenden Platz liegen. Achtung die Zahlen sind dezimal, die Protokolldateien aber hexadezimal, d.h. sie müssen "umrechnen" um die passenden EDBxxxxx.LOG -Dateien zu finden.

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

  • Q182081 XADM: Description of the Isinteg utility
  • Q301460 XADM: Exchange 2000 Command-Line Parameters für the Isinteg.exe Tool

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:

  • Export und Import der Inhalte über PST-Dateien
    z.B. mit EXMERGE kann der Inhalt aller Postfächer in einzelne PST-Dateien exportiert werden.
    Nach der Neuanlage der Datenbanken können die Inhalte wieder eingespielt werden. Berechtigungen und der "Single Instance Store" sind natürlich nicht mehr vorhanden.
  • Zweiter Server in der Site
    Über einen zweiten Server könnten die Postfächer auf diesen verschoben werden und optional nach dem Neuaufbau des ersten Servers auch wieder zurück.

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

Weitere Links

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/