Problem

Nach einem unsanften Server-Neustart hatten wir im Eventlog den Fehler:

Event-ID: 412
Event-Source: ESE (ESE)
„E00.log konnte nicht gelesen werden. Fehler -501“

…und die Exchange-Datenbank wurde nicht mehr gemountet

Diagnose:
eseutil /MH gab das Ergebnis, dass die Datenbank einen Dirty-Shutdown hatte.
eseutil /ML gab das Ergebnis, dass die jüngste Log-Datei (E00.log) korrupt ist

eseutil /ML E00

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...

Verifying log files...
     Base name: E00
      Log file: C:\Program[…]\Database 1646089\E00000590AF.log - OK
      Log file: C:\Program[…]\Database 1646089\E00000590B0.log - OK
      Log file: C:\Program[…]\Database 1646089\E00000590B1.log - OK
      […]
      Log file: C:\Program[…]\Database 1646089\E00000590CC.log - OK
      Log file: C:\Program[…]\Database 1646089\E00.log
                ERROR: Cannot read log file header. Error -501.

Operation terminated with error -501 (JET_errLogFileCorrupt, Log file
is corrupt) after 2.637 seconds.

Deswegen konnte auch kein Soft-Recovery durchgeführt werden:

eseutil /R E00

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: E00
            Log files: <current directory>
         System files: <current directory>

Performing soft recovery...

Operation terminated with error -501 (JET_errLogFileCorrupt, Log file
is corrupt) after 0.63 seconds.

Abhilfe

Gemäß http://www.mcseboard.de/topic/182722-logdateien-für-postfach-können-nicht-gefunden-werden/?p=1125697

1. Daten gesichert
2. E00.log gelöscht
3. E00000590CC.log (=die jüngste korrekte Log-Datei) umbenannt in E00.log
4. E00.chk gelöscht –> somit wird dem Exchange die noch korrekte Log-Datei als letzte Log-Datei untergejubelt
5. eseutil /R E00 –> gab die Meldung:
   „Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info) after 167.748 seconds.“
   Da meckert eseutil, dass offensichtlich eine Transaktion mitten drin abbricht (kein Wunder, weil die Log-Datei ja fehlt).
6. Abhilfe: eseutil mit dem Parameter /i aufrufen:
   eseutil /R E00 /I –> gab die Meldung:
   „Recovery has indicated that there is a lossy recovery option.  Run recovery with the /a argument.
   Operation terminated with error -582 (JET_errCommittedLogFilesMissing, One or more logs that were committed to this database, are missing.  These log files are required to maintain durable ACID semantics, but not required to maintain consistency if the JET_bitReplayIgnoreLostLogs bit is specified during recovery.) after 2.356 seconds.“
7. Abhilfe: eseutil zusätzlich mit dem Parameter /a aufrufen:
   eseutil /R E00 /I /A
   –> lief erfolgreich durch und die Datenbank konnte wieder gemountet werden.

Nachtrag

Zwei Links:

• Zur richtigen Vorgangsweise bei einem Exchange-Datenbank-Recovery und
• Zu häufigen Fehlern beim Datenbank-Recovery – demgemäß wäre Punkt 6 mit dem Parameter /i nicht nötig gewesen…