{"id":113,"date":"2010-04-13T09:41:27","date_gmt":"2010-04-13T08:41:27","guid":{"rendered":"http:\/\/blog.imagmbh.de\/?p=113"},"modified":"2019-01-13T23:12:24","modified_gmt":"2019-01-13T22:12:24","slug":"defekte-exchange-datenbank-reparieren-der-beschrittene-weg","status":"publish","type":"post","link":"https:\/\/blog.imagmbh.de\/index.php\/defekte-exchange-datenbank-reparieren-der-beschrittene-weg\/","title":{"rendered":"Defekte Exchange-Datenbank reparieren: Der beschrittene Weg"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

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\u00f6schen und empfiehlt dringend, im Problemfall die letzte Sicherung der Exchange-Datenbank einzuspielen.<\/p>\n

Wir haben uns, da diese Sicherung einige Stunden \u00e4lter war als der Absturz der Exchange-Datenbank, daf\u00fcr entschieden, nicht die Sicherung zu verwenden, sondern die Reparatur zu versuchen. Durch die Verwendung der Sicherung w\u00e4ren auf jeden Fall die Mails der Zeit zwischen der Sicherung und dem Absturz verloren gegangen.<\/p>\n

Unser Vorgehen:<\/p>\n

    \n
  1. Alle Exchange-Dienste beenden.<\/li>\n
  2. Die Datenbankdateien kopieren.<\/li>\n
  3. eseutil.exe \/p durchf\u00fchren, also im Exchange-Bin-Verzeichnis den Befehl „eseutil.exe \/p PFAD-ZUR-EXCHANGE-DATENBANKDATEI“ ausf\u00fchren<\/li>\n
  4. eseutil.exe \/d durchf\u00fchren, also im Exchange-Bin-Verzeichnis den Befehl „eseutil.exe \/d PFAD-ZUR-EXCHANGE-DATENBANKDATEI“ ausf\u00fchren<\/li>\n<\/ol>\n

    Microsoft empfiehlt nun, nachdem auf der Tabellenebene die Daten repariert wurden, die Integrit\u00e4t mit isinteg.exe zu \u00fcberpr\u00fcfen. Wir haben hierzu:<\/p>\n

      \n
    1. Von den mit den eseutil.exe reparierten Dateien erst einmal eine Kopie gemacht.<\/li>\n
    2. Die noch vorhanden Log-Dateien der Exchangedatenbank (Transaktionslogs) verschoben.<\/li>\n
    3. Den Exchange-Dienst gestartet, da isinteg.exe \u00fcber den Exchange-Dienst auf die Datenbank zugreift und und nicht direkt zugreift.<\/li>\n
    4. Die mit eseutil reparierte Datenbank kurz im Manager verbunden aber direkt wieder abgemeldet. Hierdurch steht die Datenbank im „Offline-Modus“ zur Verf\u00fcgung.<\/li>\n
    5. Nun kann „Isinteg \u2013fix \u2013test alltests“ aufgerufen werden, die Bedienung erfolgt interaktiv. Achten Sie auf die Meldungen, nach der Ausf\u00fchrung sollte die Datenbank fehlerfrei sein (was Sie bei uns auch war), aonsonsten ist isinteg ggf. nochmals aufzurufen.<\/li>\n
    6. Die Datenbank kann dann wieder mit dem Exchange-Server verbunden werden und alles l\u00e4uft hoffentlich wieder. Bei uns war das der Fall.<\/li>\n
    7. Eine \u00dcberpr\u00fcfung 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\u00e4tigte dies.<\/li>\n
    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 \u00fcberpr\u00fcft, ob diese auch in der wiederhergestellten Version vorhanden ist.<\/li>\n<\/ol>\n