Wie bei Twitter schon gemeldet: Am Wochende „erfreute“ uns ein Kundensystem mit einer defekten Exchange-Datenbank. Nach einem automatischen Neustart des Rechners (updatebedingt) fuhr zwar der Rechner wieder hoch, der Start der Exchangedatenbank brach jedoch ab, der Zugriff auf die Jet-Datenbank sei gescheitert, Code -1018.

Der Code deutet eigentlich auf ein Plattenproblem hin. Bei einer virtuellen Maschine und korrekt arbeitendem Host ist das jedoch wohl nicht die Ursache, zumal sich die virtuellen Festplatten korrekt verhielten.

Microsoft bietet im Falle einer defekten Exchange-Datenbank zwei Werkzeuge, die in Kombination zu verwenden sind: eseutil.exe und isinteg.exe, beide im BIN-Verzeichnis des Exchange zu finden. Microsoft warnt jedoch vor dem Einsatz dieser Werkzeuge, da diese evtl. (defekte) Teile der Datenbank löschen und empfiehlt dringend, im Problemfall die letzte Sicherung der Exchange-Datenbank einzuspielen.

Wir haben uns, da diese Sicherung einige Stunden älter war als der Absturz der Exchange-Datenbank, dafür entschieden, nicht die Sicherung zu verwenden, sondern die Reparatur zu versuchen. Durch die Verwendung der Sicherung wären auf jeden Fall die Mails der Zeit zwischen der Sicherung und dem Absturz verloren gegangen.

Unser Vorgehen:

  1. Alle Exchange-Dienste beenden.
  2. Die Datenbankdateien kopieren.
  3. eseutil.exe /p durchführen, also im Exchange-Bin-Verzeichnis den Befehl „eseutil.exe /p PFAD-ZUR-EXCHANGE-DATENBANKDATEI“ ausführen
  4. eseutil.exe /d durchführen, also im Exchange-Bin-Verzeichnis den Befehl „eseutil.exe /d PFAD-ZUR-EXCHANGE-DATENBANKDATEI“ ausführen

Microsoft empfiehlt nun, nachdem auf der Tabellenebene die Daten repariert wurden, die Integrität mit isinteg.exe zu überprüfen. Wir haben hierzu:

  1. Von den mit den eseutil.exe reparierten Dateien erst einmal eine Kopie gemacht.
  2. Die noch vorhanden Log-Dateien der Exchangedatenbank (Transaktionslogs) verschoben.
  3. Den Exchange-Dienst gestartet, da isinteg.exe über den Exchange-Dienst auf die Datenbank zugreift und und nicht direkt zugreift.
  4. Die mit eseutil reparierte Datenbank kurz im Manager verbunden aber direkt wieder abgemeldet. Hierdurch steht die Datenbank im „Offline-Modus“ zur Verfügung.
  5. Nun kann „Isinteg –fix –test alltests“ aufgerufen werden, die Bedienung erfolgt interaktiv. Achten Sie auf die Meldungen, nach der Ausführung sollte die Datenbank fehlerfrei sein (was Sie bei uns auch war), aonsonsten ist isinteg ggf. nochmals aufzurufen.
  6. Die Datenbank kann dann wieder mit dem Exchange-Server verbunden werden und alles läuft hoffentlich wieder. Bei uns war das der Fall.
  7. Eine Überprüfung der Log-Dateien von eseutil.exe und der Ausgaben von isinteg.exe ergab, dass keine Daten vernichtet wurden. Ein Stichprobentest der E-Mail-Konten bestätigte dies.
  8. Um Sicher zu gehen, dass alle Mails wirklich vorhanden sind, haben wir die Sicherung auf einem anderen Exchange-Server eingebunden und mit einem eigenen Programm jede E-Mail aus der Sicherujng via IMAP ausgelesen und überprüft, ob diese auch in der wiederhergestellten Version vorhanden ist.

Below is a snapshot of a write a thesis for me https://prothesiswriter.com part of the graphic featuring the most useful operators.
Dr.-Ing. Martin H. Ludwig

Von Dr. Martin H. Ludwig

Dr. Martin H. Ludwig ist Geschäftsführer der ima GmbH, leidenschaftlicher IT-ler und Datenschutzexperte. Wenn er Zeit findet, schreibt er über IT-Probleme oder -Besonderheiten im Blog.

Schreibe einen Kommentar