Auswirkungen der Befehle "eseutil /p" und "edbutil /d /r" in Exchange

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 259851 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
259851 Ramifications of running the eseutil /p or edbutil /d /r command in Exchange
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Zusammenfassung

Wenn Sie die Befehle eseutil /p oder edbutil /d /r für eine Exchange Server-Datenbankdatei ausführen (zum Beispiel für die Datenbanken "Priv.edb", "Pub.edb" oder "Dir.edb), wird eine so genannte "harte" Reparatur ausgeführt. Bei diesem Reparaturvorgang wird die Datenbank Schritt für Schritt überprüft, wichtige Strukturen innerhalb der Datenbank (Systemtabellen, Anlagentabellen usw.) werden repariert und es wird geprüft, ob es in der Datenbank beschädigte Seiten gibt.

Wird bei der Reparatur eine beschädigte Seite gefunden (zum Beispiel eine ungültige Prüfsumme durch eine nicht von Jet vorgenommene Änderung der Seite), wird diese Seite gelöscht (-1018). In einem solchen Fall können wichtige Daten nach der Reparatur nicht mehr vorhanden sein. Bei solchen Daten kann es sich um Bestandteile einer E-Mail-Nachricht, einen Kalendertermin, eine Notiz, eine Anlage oder - im schlimmsten Fall - um Teile einer Systemtabelle handeln.

Sollte es sich bei dieser Systemtabelle um die Anlagentabelle handeln, können für alle Benutzer des Servers die Anlagen zu ihren jeweiligen E-Mail-Nachrichten verloren sein. Dies ist zwar nur ein mögliches Szenario, beim Vorhandensein beschädigter Seiten in der Datenbank kommt es nach einer "harten" Reparatur aber in jedem Fall zu Datenverlusten.

Wichtig: Der beste Weg ist immer, eine Wiederherstellung auf der Basis einer Sicherungskopie durchzuführen.

Durch eine Wiederherstellung auf der Basis einer Sicherungskopie stellen Sie sicher, dass Sie über eine funktionierende, saubere, stabile Datenbank verfügen, die auf Ihrem Server gestartet und ausgeführt werden kann. Es ist unter nahezu allen denkbaren Umständen schneller und zuverlässiger, eine Wiederherstellung auf der Basis einer Sicherungskopie durchzuführen, als eine "harte" Reparatur der Datenbank vorzunehmen. Dies liegt daran, dass die Reparatur mit einer Geschwindigkeit von 4 bis 6 Gigabyte (GB) pro Stunde ausgeführt wird und Sie nach der Reparatur noch den Prozess "Isinteg" ausführen müssen, dessen Geschwindigkeit 3 bis 6 GB pro Stunde beträgt. (Bei den Geschwindigkeitsangaben handelt es sich um Durchschnittswerte; die tatsächliche Leistung schwankt in Abhängigkeit von der Anzahl der erforderlichen Reparaturdurchgänge für Ihre Datenbank und der Leistungsfähigkeit Ihrer Hardware.)

Wenn Sie zum Beispiel das schnellstmögliche Hardwaresetup verwenden, erfordert die Reparatur einer 50-GB-Datenbank ca. 8 Stunden plus weitere 8 Stunden für den Prozess "Isinteg", also insgesamt 16 Stunden. Wenn Sie ein typisches, über Wide SCSI verbundenes, digitales lineares Tape (DLT) 35/70 verwenden, das die Wiederherstellung mit einer durchschnittlichen Geschwindigkeit von 3 Megabyte (MB) durchführt, nimmt die Wiederherstellung der gleichen Datenbank 5 Stunden in Anspruch. Dies bedeutet eine Zeitersparnis von 11 Stunden. Extrem schnelle "Snapshot"-Sicherungssysteme, wie das System von EMC, können eine Datenbank dieser Größe in wenigen Minuten wiederherstellen.

Falls keine Sicherungskopie zur Verfügung steht und Sie keine andere Möglichkeit haben, als eine "harte" Reparatur Ihrer Datenbank durchzuführen, gehen Sie folgendermaßen vor:
  1. Führen Sie eine "harte" Reparatur der Datenbank mithilfe von Eseutil /p oder Eseutil /d /r durch.
  2. Defragmentieren Sie die Datenbank mithilfe von Eseutil /d. Bei einer Offline-Defragmentierung wird automatisch eine neue Datenbankstruktur erstellt, in die die vorhandenen Daten verschoben werden.
  3. Überprüfen Sie die Konsistenz Ihrer Datenbank mithilfe von Isinteg -fix. Isinteg sollte so oft ausgeführt werden bis der Bericht keine Fehler mehr enthält.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
192185 Defragmentieren mithilfe des Dienstprogramms "Eseutil" (Eseutil.exe)
182081 XADM: Beschreibung des Dienstprogramms "Isinteg"

Das Dienstprogramm "Isinteg" behebt die logischen Probleme, die durch eine "harte" Reparatur entstehen können.
  • Für den privaten Informationsspeicher von Exchange Server 4.0 und 5.0 führen Sie den folgenden Befehl aus:
    isinteg -fix -pri
  • Für den öffentlichen Informationsspeicher von Exchange Server 4.0 und 5.0 führen Sie den folgenden Befehl aus:
    isinteg -fix -pub
  • Für den privaten Informationsspeicher von Exchange Server 5.5 führen Sie den folgenden Befehl aus:
    isinteg -pri -fix -test alltests
  • Für den öffentlichen Informationsspeicher von Exchange Server 5.5 führen Sie den folgenden Befehl aus:
    isinteg -pub -fix -test alltests
Hinweis: Sie können den Befehl "Isinteg -fix" nicht an die Dir.edb ausführen. Außerdem sollten Sie kein "hart" repariertes Verzeichnis in einer Produktionsumgebung verwenden.

Weitere Informationen zur Wiederherstellung eines Exchange-Verzeichnisses finden Sie im folgenden Artikel der Microsoft Knowledge Base:
162353 XADM: Wiederherstellen eines Exchange-Verzeichnisses
Nachdem Sie den Befehl eseutil /p oder den Befehl edbutil /d /r für die Datenbanken "Priv.edb" oder "Pub.edb" ausgeführt haben, können bei den Datenbanken die folgenden Symptome zu beobachten sein:
  • Der Informationsspeicher wird entweder nicht angehalten oder er reagiert nicht mehr.
  • Der Informationsspeicher nimmt keine E-Mail-Nachrichten vom Message Transfer Agent (MTA) mehr an.
  • E-Mail-Nachrichten verbleiben im Postausgang des jeweiligen Benutzers.
  • Das Programm "Store.exe" wird mit sehr hoher CPU-Auslastung bei keinerlei Belastung für den Server ausgeführt.
  • Das Programm "Store.exe" generiert eine Fehlermeldung zu einer Zugriffsverletzung, wenn die Belastung sehr hoch ist.
  • Benutzer können E-Mail-Anlagen oder E-Mail-Nachrichten nicht öffnen.
Nach der harten Reparatur einer schwer beschädigten Datenbank, sollten Sie sie zuerst im Offline-Modus mithilfe von Isinteg defragmentieren, bevor Sie sie wieder in einer Produktionsumgebung verwenden. Eine "harte" Reparatur Ihrer Datenbank sollten Sie also nur als allerletztes Mittel in Erwägung ziehen; sofern dies möglich ist, führen Sie eine Wiederherstellung auf der Basis einer Sicherungskopie durch.

Falls Sie Isinteg mehrmals ausführen und die Datenbank nicht repariert werden kann, müssen Sie das Tool "Exmerge" verwenden, um Daten von einer Datenbank zu extrahieren und in eine andere Datenbank zu importieren:
259688 XADM: wie Verwenden des Exmerge-Dienstprogramms, um Daten von einem Privaten beschädigten Informationsspeicher zu extrahieren

Weitere Informationen

Erstellen Sie mithilfe der folgenden Befehlszeile ein Header-Abbild, um zu ermitteln, ob eine "harte" Reparatur Ihrer Datenbank durchgeführt wurde (falls keine Reparatur durchgeführt wurde, weist die Reparaturzählung den Wert "Null" auf):
eseutil /mh x:\exchsrvr\mdbdata\priv.edb |more

eseutil /mh x:\exchsrvr\mdbdata\pub.edb |more
Im Folgenden sehen Sie ein Beispiel für einen Priv.edb-Header:
Microsoft(R) Windows NT(TM) Server Database Utilities
Version 5.5
Copyright (C) Microsoft Corporation 1991-1999. All Rights Reserved.

Initiating FILE DUMP mode...
Database: d:\exchsrvr\mdbdata\priv.edb

Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,2
Engine ulVersion: 0x620,2
DB Signature: Create time:4/5/2000 17:48:52 Rand:769046 Computer:
cbDbPage: 4096
dbtime: 556457
State: Consistent
Shadowed: Yes
Last Objid: 184
Scrub Dbtime: 0
Scrub Date: 00/00/1900 00:00:00
Repair Count: 1
Repair Date: 2/20/2000 10:48:50

Eigenschaften

Artikel-ID: 259851 - Geändert am: Donnerstag, 20. Oktober 2005 - Version: 6.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Keywords: 
kbinfo KB259851
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Disclaimer zu nicht mehr gepflegten KB-Inhalten
Dieser Artikel wurde für Produkte verfasst, für die Microsoft keinen Support mehr anbietet. Der Artikel wird deshalb in der vorliegenden Form bereitgestellt und nicht mehr weiter aktualisiert.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com