Verständnis und Analyse von Exchange-Datenbankfehlern -1018,-1019 und -1022

Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.

Den englischen Originalartikel können Sie über folgenden Link abrufen: 314917
Dieser Artikel wurde archiviert. Er wird im vorliegenden Zustand bereitgestellt und nicht mehr aktualisiert.
Zusammenfassung
Dieser Artikel enthält Informationen, um zu verstehen und Analysieren-1018,-1019 und-1022 Exchange Database Errors. Dieser Artikel beschreibt die Unterschiede zwischen diesen drei Fehlern und die Arten von Problemen in der Datenbank, die dazu führen, dass jede dieser drei Fehler gemeldet werden.
Weitere Informationen
Exchange beinhaltet die Funktionalität, auf Dateiebene Schäden an Seiten in den Datenbanken zu erkennen. Die drei häufigsten Fehler, die auf Dateiebene Schäden an einer Exchange-Datenbank zugeordnet sind, lauten folgendermaßen:
  • -1018 JET_errReadVerifyFailure
  • -1019 JET_errPageNotInitialized
  • -1022 JET_errDiskIO
In einer Exchange-Datenbank können die folgenden drei Ebenen Fehler auftreten:
  • Auf Seitenebene (Dateisystem)
  • Auf der Datenbankebene (JET-Datenbankmodul)
  • Anwendungsebene (Exchange Information Store)
Das Dienstprogramm Esefile.exe werden in Datenbanken auf Seitenebene Fehler erkannt. Das Dienstprogramm Eseutil.exe kann erkennen und reparieren Probleme auf Seitenebene und Datenbankebene. Das Dienstprogramm Isinteg.exe erkennt und behebt Probleme auf Anwendungsebene.

Schäden auf einer niedrigeren Ebene (der Seitenebene) fast immer zu Problemen auf den höheren Ebenen (der Datenbank und der Anwendungsebene). Daher, nachdem Sie eine Datenbank mit "Eseutil" repariert haben, müssen Sie fast immer danach Isinteg nutzen.

Schäden auf der Datenbank- und Anwendungs-Ebene bezieht sich auf Probleme im Exchange-Code oder in Fremdanbieterprogrammen, die in Exchange integriert. Schäden auf der Seite wird normalerweise durch Treiber, Firmware oder Hardwareprobleme verursacht, obwohl auf Seitenebene Beschädigung auch in Exchange durch Probleme verursacht werden könnte.

Sie finden fast immer die eigentliche Ursache für einen-1018-Fehler in einer zugrunde liegenden Systeme, von denen Exchange abhängt, nicht im Exchange-code selbst. Es gibt sehr wenige Ausnahmen von dieser Regel. Ausnahmen wurden meldete Exchange zwar eine -1018-Bedingung nicht, weil Exchange selbst einen-1018-Fehler verursacht. Für weitere Informationen klicken Sie auf die folgenden Artikelnummern, um die Artikel der Microsoft Knowledge Base anzusehen:
237953Falsche-1018-Fehler während der Onlinesicherung zurückgegeben
230215 Backup Checksuming nicht auf Computern mit einzelnem Prozessor ausgeführt.
Obwohl die Mehrzahl der-1019- und -1022-Fehler werden auch durch einen Fehler in einer zugrunde liegenden System verursacht, können nicht Sie auszuschließen,-1019 und -1022-Fehler aufgrund eines Fehlers im Exchange-Code als schnell auftreten können.

Fehler-1018 ist die am häufigsten Fehler gibt an, dass eine Exchange-Datenbank auf der Dateisystemebene Schaden erlitten hat. Aus diesem Grund die meisten dieser Artikel schwerpunktmäßig Fehler-1018.

Es gibt drei grundlegende Möglichkeiten, Daten auf dem Datenträger beschädigt werden können:
  • Die falschen Daten werden auf das Speichermedium geschrieben.
  • Daten werden in der falschen Stelle auf dem Speichermedium geschrieben.
  • Daten ist beschädigt oder geändert werden, nachdem er gespeichert.
Es ist, zwar sehr schwierig, Vermeidung und Behebung von 100 Prozent aller Schäden ist es relativ einfach, ein Problem erkennen, die aufgetreten ist. Exchange erkennt falsche und falsch eingefügten Daten in die Datenbankdateien und meldet einen-1018-Fehler oder -1019-Fehler. Wenn eine Datei gravierend beschädigt und Teile davon gänzlich fehlen oder sind andernfalls nicht zugegriffen werden kann, wenn Exchange versucht, die Datei zu lesen, wird ein-1022-Fehler gemeldet.

Wie Exchange Prüfsummen und Zahlen berechnet Datenbankseiten

Um zu verstehen, wie funktionieren die Mechanismen, die-1018- und -1019-Fehler auslösen, müssen Sie verstehen, wie eine Exchange-Datenbank Datenseiten speichert.

Auf der niedrigsten logischen Ebene sehen Sie eine Exchange-Datenbankdatei als eine Reihe von 4 KB-Seiten, fortlaufend nummeriert. Daten lesen und jeweils auf eine Seite einer Exchange-Datenbank geschrieben.

Jede Seite, die Daten enthält, speichert ihre eigene Seitennummer zusammen mit einer Prüfsumme, die alle Daten auf der Seite berechnet wird. Der Prüfsummenwert selbst ist der einzige Teil der Seite, die in dieser Berechnung nicht enthalten ist.

Prüfsummenalgorithmen, einschließlich des Prüfsummenalgorithmus, die Exchange verwendet, sind leicht zu verstehen und relativ einfach. Sie sind so konzipiert, dass Chancen, die die gleiche Prüfsumme für zwei Seiten führen niedrig sind, auch wenn die Differenz zwischen den Seiten nur eine einzige ist Bit.

Obwohl ein Prüfsummentest ausreichend ist, um festzustellen, ob die Seite geändert wurde, seit sie geschrieben wurde, ist ein Prüfsummentest nicht genug, um sicherzustellen, dass die Seite in der richtigen Stelle befindet. Aus diesem Grund stempelt Exchange jede Seite mit seiner eigenen Seitennummer sowie eine Prüfsumme.

Die ersten zwei 4-KB-Seiten in der Datenbank sind für die Datenbank "Header". reserviert. Wenn die Datenbank gestoppt wird, können Sie das Dienstprogramm Eseutil/MH Switch, um diese Kopfzeile einzusehen. Die Kopfzeile enthält identifizierende Informationen über die Datenbank als Ganzes.

Nachdem diese ersten beiden Kopfzeilenseiten, alle anderen Seiten in der Datenbank Daten sind. Die Datenseiten weisen alle eine gemeinsame Struktur. Jede Seite verfügt über eine eigene Kopfzeile mit identifizierenden Informationen zu der jeweiligen Seite gefolgt von tatsächlichen Daten enthält.

Da die erste Datenseite in einer Exchange-Datenbank nach der ersten zwei Kopfzeilenseiten befindet, ist die physische Seite 3 in der Datenbank die logische Seite 1. 2 ist die logische Seitenzahl der physischen Seite 4 und So weiter.

Logische Seitenzahlen in der Datenbank werden nach folgender Formel direkt den physischen Seitenzahlen zugeordnet:
logische Seitenzahl = physische Seitenzahl - 2
Da die logischen und physischen Seitenstrukturen der Datenbankdatei so eng miteinander verbunden sind, kann Exchange leicht feststellen, ob jede logische Seite in den richtigen physikalischen Ort in der Datei ist.

Die einzigen Seiten in der Datenbank für die keine Prüfsumme berechnet wird, sind "nicht initialisierte Seiten". Dies sind Blöcke von Seiten, die erstellt werden, wenn die Datenbank vergrößert wird, um Platz für weitere Daten zu schaffen. Eine nicht initialisierte Seite ist eine, die Prüfsumme 0 und die Seitenzahl 0 hat. Jedes Byte einer nicht initialisierten Seite wird in der Regel mit Zeichen gefüllt. 0 x 00.

Nach eine nicht initialisierte Seite zum ersten Mal verwendet wird, gibt es nicht initialisierten Zustand zurück, auch wenn er geleert wird. Stattdessen wird ein Flag auf die Geleerte Seite festgelegt, um für die Wiederverwendung verfügbar zu kennzeichnen. Die Seite ist immer noch eine Seitenzahl und die Prüfsumme, auch wenn es leer ist.

Exchange Server 2003 Service Pack 1 (SP1) änderte den Prüfsummenalgorithmus und das Seitenformat, die verwendet werden. Exchange Server 2003 SP1 eingeführt Fehler Code (ECC)-Algorithmus zum Erkennen und Einzelbit-Fehler automatisch korrigieren korrigieren.Weitere Informationen zu dieser neuen Funktionalität klicken Sie auf die folgende Artikelnummer klicken, um den Artikel der Microsoft Knowledge Base anzuzeigen:
867626Neue Error-correcting-Code ist in Exchange Server 2003 Service Pack 1 enthalten.

Was bewirkt, dass einen-1018-Fehler

Exchange meldet ein-1018-Fehler, wenn eine initialisierte Seite in der Datenbank gefunden wird, mit einem der folgenden Bedingungen:
  • Die, die auf der Seite gespeicherte Prüfsumme entspricht nicht das Ergebnis der Prüfsummen-Neuberechnung, die ausgeführt wird, wie die Seite gelesen wird.
  • Die Seitenzahl, die auf der Seite gespeichert wird entspricht nicht die Seitenzahl, die auf der Seite der Seite Standort in der Datenbankdatei angegeben werden sollen.
Exchange kann einen-1018-Fehler generiert, wenn Exchange eine der folgenden ist sein:
  • Erstellt eine Seite, die falschen Prüfsumme.
  • Erstellt eine Seite richtig, aber weist das Betriebssystem auf die Seite an der falschen Stelle schreiben.
Nachdem ein Systemadministrator einen-1018-Fehler auftritt, wenn der Administrator führt den Diagnosetest auf dem Server und dabei keine Probleme, möglicherweise den Schluss, dass Exchange für das Problem verantwortlich sein muss, da die Hardware die erste Analyse bestanden.

Weitere jedoch Fällen haben Untersuchungen von Microsoft oder Hardwarehersteller Kreditoren ungedeckt geringfügige Fehler in Hardware, Firmware oder Treiber, die tatsächlich für die Beschädigung der Datenbankdatei zuständig sind.

Gewöhnlichen Diagnosetests erkennt möglicherweise nicht alle vorübergehenden Fehler aus mehreren Gründen. Problemen in Firmware oder Treibersoftware möglicherweise außerhalb der Möglichkeiten von Diagnoseprogrammen liegen. Diagnosetests möglicherweise nicht ausreichend langen Laufzeiten oder komplexen Belastungen simuliert werden. Außerdem kann das Hinzufügen der Diagnoseprotokollierung oder der Debugprotokollierung das System verhindern, dass das Problem erneut angezeigt verändert.

Die Einfachheit und Stabilität der Exchange-Mechanismen, die das Erstellen von Prüfsummen und Schreiben von Seiten in die Datenbankdatei ist ein weiterer Grund, den die Wahrscheinlichkeit, dass die Ursache für einen-1018-Fehlers ein Exchange-Problem ist gering ist. Die Prüfsumme und die falsche Seite Erkennungsmechanismen sind einfach, zuverlässig und sind im Grunde die gleichen geblieben seit der ersten Exchange-release geringfügige Änderungen zur Anpassung an die Seite Format Datenbankänderungen Datenbankversionen.

Um eine Prüfsumme für eine Seite generiert wird, der Datenträger, nachdem alle anderen Daten in die Seite geschrieben wurden geschrieben werden, weiter zu erklären, Nummer einschließlich der Seite selbst. Nachdem Exchange die Prüfsumme der Seite hinzugefügt hat, weist Exchange das Betriebssystem Microsoft Windows auf die Seite auf den Datenträger zu schreiben, unter Verwendung standardmäßiger, veröffentlichter Windows Application programming Interfaces (APIs).

Die Prüfsumme korrekt für eine Seite generiert werden kann, aber dann kann die Seite an den falschen Speicherort geschrieben werden, auf der Festplatte. Dies kann durch einen vorübergehenden Speicherfehler, wie z. B. einen "Bit Flip" liegen Genommen Sie an, dass Exchange eine neue Version von Seite 70 erstellt. Die Seite selbst ist einen Fehler nicht auftreten, aber die Kopie der Seitenzahl, die von den Festplattencontroller oder vom Betriebssystem verwendet wird nach dem Zufallsprinzip geändert. Dieses Problem kann auftreten, wenn 70 (binär 100110) durch eine instabile Speicherzelle zu 6 (binär 000110) geändert wurde. Die Prüfsumme der Seite wird noch richtig, aber der Speicherort der Seite in der Datenbank ist nun falsch. Exchange meldet einen-1018-Fehler für die Seite, wenn er feststellt, dass die logische Seitenzahl nicht mit den physischen Speicherort der Seite übereinstimmt. Eine andere Art von Fehler (verursacht durch Exchange) für die Seitennummerierung kann auftreten, wenn Exchange die falsche Seitenzahl auf der Seite selbst schreibt. Aber dies andere Fehler verursacht, nicht der-1018-Fehler. Wenn Exchange 71 in Seite 70 schreibt und dann die Prüfsumme auf der Seite korrekt führt ist, wird die Seite in Speicherort 71 geschrieben ist und übergibt die Seite Seitenzahlen-der Tests.

Häufig führt ein einzelner -1018-Fehler, der in einer Exchange-Datenbank gemeldet wird nicht die Datenbank zu stoppen oder dazu führen, dass ein Symptom als das Vorhandensein der-1018-Fehler selbst zu. Die Seite möglicherweise in einem Ordner, die nur selten zugegriffen wird (z. B. der gesendete oder gelöschte Ordner), oder in einer Anlage, die nur selten geöffnet oder gar leer ist.

Auch wenn ein einzelner -1018-Fehler zu umfangreichen Datenverlusten unwahrscheinlich ist, sind-1018-Fehler immer noch Anlass zur Sorge, da ein-1018-Fehler Beweis dafür ist, dass Ihr Speichersystem nicht zuverlässig speichern oder Abrufen von Daten mindestens einmal. Obwohl der-1018-Fehlers ein vorübergehendes Problem, das nie wieder auftritt handeln kann, ist es wahrscheinlicher, dass dieser Fehler eine frühzeitige Warnung für ein Problem ist, die immer schlimmer werden wird. Auch wenn der erste-1018-Fehler in einer leeren Seite in der Datenbank ist, können Sie nicht wissen welche Seite möglicherweise demnächst beschädigt wird. Wenn eine wichtige globale Tabelle beschädigt ist, die Datenbank, könnten nicht mehr starten lässt und die Reparatur der Datenbank ist möglicherweise nicht erfolgreich oder nur teilweise erfolgreich.

Nach dem ein-1018-Fehler protokolliert wird, müssen Sie berücksichtigen und Planen Sie die Möglichkeit, vor einem bevorstehenden Ausfall oder weiteren Beschädigung in der Datenbank bis zu finden und die Ursache beseitigen.

Wiederherstellen von-1018-Fehler

Exchange behandelt eine Seite, die nicht mit einem-1018-Fehler als vollständig unlesbar, um zu verhindern, dass die Aktion auf zufällige Daten in der Datenbank weitere Probleme verursachen.

Eine Seite, die mit einem-1018-Fehlers fehlschlägt, kann nicht repariert oder gerettet werden. Es muss aus der Datenbank gelöscht werden. Es gibt drei Methoden, mit denen Sie die Seite aus der Datenbank expunge:
  • Wiederherstellen Sie die Datenbank aus einer Onlinesicherung.
  • Verwenden Sie die Eseutil.exe/d -Schalter, um eine Offlinedefragmentierung der Datenbank durchzuführen.
  • Verwenden Sie die Eseutil.exe/p -Schalter, die Datenbank zu reparieren.

Die Datenbank aus einer Onlinesicherung wiederherstellen

Wenn während der Onlinesicherung ein-1018-Fehler gefunden wird, wird die Sicherung beendet. Dadurch wird sichergestellt, dass die beschädigte Seite in der letzten erfolgreichen Sicherung nicht vorhanden ist. Wenn die Umlaufprotokollierung deaktiviert ist, können Sie die neueste verfügbare vollständige Sicherung wiederherstellen und drehen Sie dann die Datenbank einen Rollforward aus den nachfolgenden Transaktionsprotokollen.

Verwenden Sie die Eseutil.exe "/ D" wechseln, um eine Offlinedefragmentierung der Datenbank durchzuführen

Diese Methode ist effektiv, wenn bei einer leeren Seite der-1018-Fehler gemeldet wird. Wenn der-1018-Fehler nur während der Onlinesicherung oder nächtlichen Onlinewartung auftritt, bedeutet dies, dass die Seite nur selten zugegriffen wird oder dass es sogar leer sein kann. Offline-Defragmentierung verwirft alle leeren Seiten und sekundären Indizes in einer Datenbank.

Verwenden Sie die Eseutil.exe "/ P" zur Reparatur der Datenbank wechseln

Eine beschädigte Seite wird nicht repariert werden, wenn Sie diese Methode verwenden, aber die beschädigte Seite verworfen. Wenn die Seite beteiligt ist eine "Einbandseite" handelt, tritt ein, Daten verloren. Ein Blatt in der Datenbank ist eine Seite, die echte Daten enthält. Innenseiten enthalten nur strukturelle und logische Informationen. In den meisten Fällen kann "Eseutil" eine Tabelle vollständig rekonstruieren, wenn eine Innenseite verloren geht. Allerdings sind die meisten Seiten in einer Datenbank Blattseiten.

Eseutil Funktionalität Reparaturarbeiten können gut und in den meisten Fällen eine Datenbank zum Betrieb mit minimalem Datenverlust wiederherstellen. Wenn viele Seiten beschädigt sind oder wichtige Systemtabellen verloren, der Datenverlust kann katastrophale oder die Datenbank möglicherweise nicht repariert.

Reparieren einer Datenbank ist in der Regel eine weniger vorteilhafte Vorgehensweise im Vergleich zu von einer Sicherung wiederherstellen und roll forward der Datenbank, da Reparatur in der Regel länger als die Wiederherstellung dauert und risikoreicher ist. Wählen Sie Reparieren aus, nur dann, wenn:
  • Sie haben eine Sicherung keinen.
  • Sie können nicht vollständig aus der Sicherung Rollforward.
Bevor Sie zu reparieren oder einer Datenbank wiederherstellen, stellen Sie immer eine Sicherungskopie der aktuellen Datenbankdateien. Wenn die Wiederherstellung nicht funktioniert, können Sie die vorhandene Datenbank reparieren. Wenn Reparatur nicht funktioniert, aber die vorherige Kopie der Datenbank noch gestartet werden kann wird, können Sie Daten retten möglicherweise, die andernfalls verloren wären.

Wichtig: Nachdem Sie eine Datenbank zu reparieren, müssen Sie den Reparaturzähler in der Datenbankkopfzeile überprüfen. Wenn der Zähler größer als 0 (null) ist, müssen Sie eine Offlinedefragmentierung mithilfe von Eseutil ausführen und dann müssen Sie die Datenbank auf der Ebene des Informationsspeichers mit dem Dienstprogramm "Isinteg" reparieren. Wenn Sie dies tun, können Benutzer auftreten, Fragen wie die Unfähigkeit, Nachrichten oder Anlagen oder Verweise in ihren Postfächern auf Elemente zu öffnen, die nicht mehr vorhanden sind.

Um den Reparaturzähler zu überprüfen, untersuchen Sie die Bildschirmausgabe, die generiert wird, wenn Sie den folgenden Befehl ausführen:
ESEUTIL/MH [Datenbank-Dateiname]
Um eine Offlinedefragmentierung der reparierten Datenbank auszuführen, führen Sie den folgenden Befehl ein:
ESEUTIL/D [Datenbank-Dateiname]
Um eine umfassende Isinteg-Fix nach einer Reparatur in Exchange 2000 ausführen, muss der Informationsspeicherdienst ausgeführt werden, jedoch muss die Datenbank, die Sie reparieren möchten aufgehoben werden. Führen Sie den folgenden Befehl für die Datenbank zu beheben:
ISINTEG -S [Servername]-FIX - TEST ALLTESTS
Dazu eine umfassende Isinteg beheben nach einer Reparatur in Exchange Server 5.5, den Informationsspeicher-Dienst angehalten werden muss. Führen Sie den folgenden Befehl ein, mit der entsprechenden Befehlszeilenoption (PRI - oder -PUB), je nachdem ob Sie für eine private oder Öffentliche Datenbank reparieren ausführen:
ISINTEG-PRI|PUB-FIX - TEST ALLTESTS
Hinweis Sie können "Eseutil" und "Esefile" raw-Datenbank-Dateien unabhängig von Ihrem jeweiligen Speicherorten ausgeführt werden. Die Datenbankdateien müssen auf einem Exchange-Server werden nicht einmal. Aber Sie müssen "Isinteg" ausführen, während die Datenbank auf einem vollständig konfigurierten Exchange-Server ist, weil "Isinteg" auf der Ebene des Informationsspeichers arbeitet und den Informationsspeicherdienst für den Datenbankzugriff verwendet.

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
244525Gewusst wie: Ausführen von Eseutil auf einem Computer ohne Exchange Server

Wiederherstellung aus ein-1019-Fehler

Ein-1019-Fehler (JET_errPageNotInitialized) wird gemeldet, wenn eine Seite, die verwendet werden soll wird deinitialisiert oder leer ist. Wenn Feld mit der Seitenzahlen auf einer verwendeten Seite 0 x 00000000 ist, wird ein-1019-Fehler statt einem-1018-Fehler gemeldet, obwohl die Seite die Prüfsummenüberprüfung auch fehlschlagen.

Die Methoden, um einen-1019-Fehler zu beheben sind identisch mit denen einen-1018-Fehler zu beheben. Beachten Sie, dass ein Problem-1019 länger als ein-1018-Problem unentdeckt kann da 1019-Probleme bei online-Sicherung nicht erkannt werden.

Obwohl die eigentliche Ursache eines-1018-Fehlers sehr wahrscheinlich außerhalb von Exchange ist, kann ein-1019-Fehler von Exchange verursacht werden, wenn logische Verweise oder Verknüpfungen zwischen Seiten ungültig sind.

Allerdings ist es üblicher, dass ein-1019-Fehler verursacht wird, da das Dateisystem beschädigt ist oder zugeordnete Seiten in die Datenbankdatei, die nicht in der Datei gehören.

Wiederherstellung nach einem-1022-Fehler

Wenn Exchange das Betriebssystem für eine Seite in der Datenbank fragt und ein Fehler auftritt, anstatt die Seitendaten zurückgegeben wird, führt ein-1022-Fehler (JET_errDiskIO). Der Fehler-1022 ist eine allgemeine Fehlermeldung, die angezeigt wird, wenn eine Festplatte Eingabe/Ausgabe (e/a) Problem verhindert, dass Exchange den Zugriff auf eine angeforderte Seite in der Datenbank.

Die häufigste Ursache für ein-1022-Fehler ist eine, die stark beschädigte oder abgeschnittene Datenbankdatei. Wenn dieses Problem auftritt, fordert Exchange eine Seitenzahl, die größer als die Anzahl der Seiten in der Datenbank ist und ein-1022-Fehler führt. Dieses Problem kann aufgrund von Problemen im Dateisystem oder unsachgemäße Transaktionsprotokollwiedergabe auftreten.

Exchange 2000 beinhaltet umfangreiche Sicherheitsvorkehrungen, um die Wiedergabe des Transaktionsprotokolls zu verhindern, die die Datenbank beschädigen könnten, aber in Exchange Server 5.5 es war möglich, einen unvollständigen Satz von Protokolldateien wiedergegeben und die Datenbank zu beschädigen. Dieses Problem kann beispielsweise auftreten, wenn Replay Protokoll Nummer 9 beginnen sollte, aber stattdessen Wiedergabe ab Protokoll 10 starten gezwungen ist. Solche Wiedergabe könnte erzwungen werden, wenn ein Administrator die Prüfpunktdatei und Protokoll 9 löscht. Wenn eine Transaktion in Protokoll 9 die Größe der Datenbank erweitert, sondern Protokoll 9 nicht in die Datenbank eingespielt wird, führt ein Verweis in Protokoll 10 auf den neuen Seiten, die die Datenbanken hinzugefügt werden, einen-1022-Fehler. Plötzliche Abstürze, hängen oder Meldungen, und Zugriffsverletzungen sind ebenfalls Häufige Symptome der Wiedergabe eine unvollständige Transaktion Protokollsatz in eine Datenbank.

Verstehen und Behandeln der Ursache eines-1022-Fehlers ist komplexer als die Behandlung von ein-1018 und -1019-Fehler. Wenn der Fehler durch einen Datenbankschaden im Dateisystem verursacht wird, müssen Sie überprüfen oder reparieren Sie das Dateisystem und dann Exchange aus einer Sicherung wiederherstellen. Reparieren der Datenbank noch eine Option ist zwar Reparatur wahrscheinlich weniger erfolgreich als bei anderen Fehlern, da ein-1022-Fehler häufig auf weitreichende Schäden hinweist.

Bei weitem die häufigste Ursache für ein-1022-Fehler bei einer intakten Datenbank eine andere Anwendung Dateien offen zu halten und durch den Informationsspeicherdienst verhindert service Zugang haben. In solchen Fällen möglicherweise auch 1032-Fehler (JET_errFileAccessDenied) angezeigt werden. Alle Exchange-Dienste neu starten oder Neustarten des Servers kann die Sperre entfernen.

Programme von Fremdanbietern, wie z. B. Virenscanner, können Exchange den Zugriff auf Exchange-Daten blockieren. Konfigurieren Sie immer auf Dateiebene Virenscanner, um Exchange-Datendateien aus Scanvorgängen auszuschließen. Es sind diverse Virenscanner erhältlich, die die Exchange Virus scanning Application programming Interface (API) zum scan von Nachrichten und Anlagen im Informationsspeicher nutzen.

Analysieren von-1018- und -1019-Fehler

Die Informationen in diesem Abschnitt richtet sich in erster Linie für den technischen Support und Ursachenanalyse für Mitarbeiter von Lieferanten Root beteiligt sind.

Nachdem ein Administrator einen-1018- oder -1019-Fehler findet, muss der Administrator mindestens drei Dinge wissen:
  • Was war auf der beschädigten Seite
  • Was ist die Wahrscheinlichkeit, dass erfolgreiche Reparatur
  • Die Ursache des Schadens in erster Linie
--1018 und-1019 können in der Befehlszeile auftreten, wenn Sie den Dienst im Ereignisprotokoll Anwendung oder in der Ausgabe von Exchange-Dienstprogrammen wie "Eseutil" starten. Ein-1018-Fehler im Ereignisprotokoll Anwendung möglicherweise nicht gemeldet werden, beim Ausführen einer Integritätsprüfung der Datenbank mit den Eseutil/g Befehl. In diesem Fall ist es wahrscheinlich, dass die beschädigte Seite leer ist.

In den meisten Fällen werden die Fehler in einem Formular gemeldet, mit dem Sie die Seite identifizieren, die das Problem meldet. Sie können auch die gesamte Datenbank mit "Esefile" zum Identifizieren von fehlerhafter Seiten scannen. Weitere Informationen zu "Esefile" klicken Sie auf die folgende Artikelnummer klicken, um den Artikel der Microsoft Knowledge Base anzuzeigen:
248406"Esefile" Support-Dienstprogramm für Exchange Server 5.5 und Exchange 2000
Die folgenden Beispiele sind typische-1018-Fehler-Beschreibungen aus dem Ereignisprotokoll der Anwendung für verschiedene Versionen von Exchange mit einer Analyse der Details zu jedem Fehler.
MSExchangeIS (248) Synchronous read page checksum error -1018((1:3106 1:3106)(0-310013)(0-312215)) occurred.Please restore the databases from a previous backup.					
Im vorhergehenden Beispiel können Sie die Nummern in Klammern wie folgt interpretieren:
  • (3106 3106 repräsentiert) die Seite in der Datenbank, die angeforderte (Seite 3106) und die Seitenzahl, die tatsächlich gefunden wurde, auf der Seite (Seite 3106) geschrieben wurde. 1: Gibt an, dass diese Datenbank 1, die ist "Priv.edb" für Exchange Server 5.5 ist. Datenbank 2 ist "Pub.edb".
  • (0-310013) stellt den Dbtime -Wert, der derzeit auf der Seite geschrieben wird. Der Dbtime -Wert ist eine 64-Bit-Wert, der auf jeder Seite geschrieben wird, die ungefähr korreliert mit, wie lange es seit die Seite geändert wurde.
  • (0-312215) stellt den aktuellen Dbtime -Wert für die Datenbank als Ganzes: wahrscheinlich die Dbtime -Wert, der auf dieser Seite geschrieben würde, wenn die Seite jetzt geändert wurde. Der Dbtime Wert bereits auf der Seite sollte immer kleiner als der aktuelle Dbtime -Wert sein.
Angesichts der Tatsache, dass die Seitenzahl der Seite korrekt abgelesen wurde und den Dbtime (mit dem ersten Dbtime Wert kleiner als der zweite liegen), wurde diese Seite nicht vollständig mit einer Seite von außerhalb der Datenbank oder eine andere Seite ersetzt.

"Esefile" können Sie die Seite mit einem ähnlich dem folgenden Befehl ausgeben:
Esefile/d database.edb 3106 > 3106.txt
Da diese Seite wird angezeigt, in Bezug auf die Struktur grundsätzlich intakt sein, können Sie auch "Eseutil" verwenden, um weitere logische Informationen zu der Seite anzeigen sein. Exchange 2000-Version von "Eseutil" können Sie Informationen über die Seite von Exchange 2000 und Exchange Server 5.5-Datenbanken anzeigen.

Warnung Verwenden Sie die Exchange 2000-Version von "Eseutil" für eine Exchange Server 5.5-Datenbank nicht in jedem Modus, der in die Datenbank schreibt. Um sicher zu sein, verwenden Sie nur die Schalter/m und nie die/p, / goder/r. Kopieren Sie Exchange 2000-Versionen von Eseutil.exe und Ese.dll auch nicht auf einem Exchange Server 5.5-Computer. In diesem Fall kopieren Sie diese Dateien an einen Remoteserver und stellen Sie einen expliziten Befehlszeilen (UNC = Universal Naming Convention) in die Datenbank, die Sie überprüfen möchten.

Ein Befehl ähnlich dem folgenden Befehl logische Informationen für eine Seite in eine Textdatei ausgegeben:
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.edb /p3106 > 3106.txtInitiating FILE DUMP mode...      Database: priv.edb          Page: 3106                        pgnoThis <0x02360004,  4>:  3106 (0x00000c22)                        objidFDP <0x02360018,  4>:  19 (0x00000013)                ulChecksumParity <0x02360000,  4>:  4269350574 (0xfe791eae)        ** computed checksum: 157180847 (0x095e63af)                   dbtimeDirtied <0x02360008,  8>:  310013 (0x000000000004bafd)                          cbFree <0x0236001c,  2>:  436 (0x01b4)                       ibMicFree <0x02360020,  2>:  3608 (0x0e18)                     itagMicFree <0x02360022,  2>:  3 (0x0003)               cbUncommittedFree <0x0236001e,  2>:  0 (0x0000)                        pgnoNext <0x02360014,  4>:  3108 (0x00000c24)                        pgnoPrev <0x02360010,  4>:  3088 (0x00000c10)                          fFlags <0x02360024,  4>:  2050 (0x00000802)                Leaf page                Primary page
In dieser Ausgabe sehen Sie sich, dass die Seite eine Einbandseite aufweist, d. h., dass es die eigentliche Daten enthält. Wenn Sie diese Datenbank reparieren, führt die Reparatur der Verlust mindestens dieser Daten. Weitere Informationen dazu, wie Sie herausfinden, welche Tabelle oder welchem Postfach die Seite gehört, klicken Sie auf die folgende Artikelnummer klicken, um den Artikel der Microsoft Knowledge Base anzuzeigen:
262196So stellen Sie fest, welches Postfach eine bestimmte Seite in einer Datenbank besitzt.
Wenn die Eseutil-Ausgabe nicht Blattseite aufgelistet, für die Seite, Chancen, die Reparatur wird Arbeit vollständig sind hoch. Die meisten Innenseiten oder Strukturseiten Seiten können durch eine Reparatur vollständig rekonstruiert werden.

Die Ausgabe könnte auch dies als eine "leere Seite". anzeigen In diesem Fall verwirft eine offline-Defragmentierung die defekten Seite aus der Datenbank.

Denken Sie daran, dass wenn eine Seite durch einen Block von Daten, die nicht in der Datenbank gehört, vollständig ersetzt wurden, die Eseutil-Ausgabe bedeutungslos sein kann.

Der folgende Fehler ist ein weiteres Beispiel:
MSExchangeIS ((247) ) Synchronous read page checksum error -1018((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred.Please restore the databases from a previous backup.
In diesem Beispiel entspricht die Seitenzahl, die tatsächlich von der Seite (3688618971) gelesen wird nicht die Seite, die angefordert wurde, was bedeutet, dass der Speicherort für die Seitenzahl Seitenkopfbereich beschädigt ist. Es ist wahrscheinlich, dass die Seitenzahl in der Datenbank noch nicht vorhanden ist. Um festzustellen, ob dies der Fall ist, multiplizieren Sie die Seitenzahl mit 4.096, und vergleichen Sie die Zahl der Byte-Größe der Datenbankdatei. In diesem Fall wird die Seitenzahl unwahrscheinlich, dass eine, die ursprünglich von Exchange geschrieben werden, es sei denn, die Datenbank 15 Terabyte Größe (3,688,618,971 x 4.096 = 15,108,583,305,216) ist.

Darüber hinaus Beachten Sie, dass der erste Dbtime -Wert auf die Seite wiederholt Nummer Muster genau. Wert, wenn Sie 3688618971 in eine Hexadezimalzahl (verwenden Sie Calc.exe im wissenschaftlichen Modus) konvertieren, 0xDBDBDBDB. In Exchange 2000 und Exchange Server 5.5 wird der 8-Byte Dbtime -Wert gespeichert, unmittelbar nach dem Wert der 4-Byte-Seitenzahl. Aus diesem Grund wissen Sie, dass mindestens zwölf aufeinander folgende Bytes für zwei unterschiedliche Felder mit einem bestimmten Muster überschrieben wurden. Wenn Sie "Esefile" verwenden, um direkt auf dieser Seite zu suchen, werden Sie wahrscheinlich feststellen, dass die gesamte Seite mit dem Muster 0xDB überschrieben wurde. Ein weiteres häufig vorkommenden ungültigen Byte-Muster ist 0xFF. Wenn dies der Fall für den oben genannten Fehler war, wäre der Dbtime Wert 4294967295.

Der folgende Fehler bietet Informationen zur Seite als Byte-Offset in die Datei und nicht als eine Seitenzahl:
Information Store (2160) The database page read from the file"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 897024 (0x00000000000db000)for 4096 (0x00001000) bytes failed verification due to a page checksummismatch. The expected checksum was 2651583211 (0x9e0bf2eb) and theactual checksum was 2651582996 (0x9e0bf214). The read operation willfail with error -1018 (0xfffffc06). If this condition persists thenplease restore the database from a previous backup.					
Sie können den ersten Offset auf eine Seite konvertieren, indem die drei abschließenden Nullen entfernen, 1 subtrahieren und das Ergebnis in Dezimalzahlen konvertieren. In diesem Beispiel also 0x00000000000db - 1 = 0xda = 218 dezimal. Sie können diese dezimale Seitenzahl mit "Esefile" oder "Eseutil" verwenden.

Hinweis Sie subtrahieren nur 1 anstelle von 2, um die zwei Kopfzeilenseiten in der Datenbank zu berücksichtigen, da die Offsets beginnen mit 0 x 0 statt 0 x 1 zählen. Wenn Sie die Kopfzeilenseiten mit "Esefile" oder "Eseutil" überprüfen möchten, verweisen Sie-1 und Seite 0.

Eine Exchange-Datenbank-Kopfzeile ist tatsächlich nur eine einzelne Seite erforderlich. Die zweite Seite ist eine "Schattenkopie" des Headers. Die Prüfsummen, die gemeldet werden, wenn Sie verwenden die Esefile/d Seite Dump-Funktion sollte immer gleich sein für die Seiten-1 und 0, nachdem die Datenbank ordnungsgemäß heruntergefahren wird. Wenn die Kopfzeile während eines Absturzes neu geschrieben wird, verwendet Exchange die Header-Kopie mit einer sauberen Prüfsumme beim Neustart von Exchange.

Im vorhergehenden Beispiel fortsetzen, werden die Prüfsummen tatsächlich sehr nahe beieinander stehen, unterscheiden sich hinsichtlich der nur zwei Zeichen. Wenn die Prüfsummen nah beieinander, dies an, dass die Änderungen auf der Seite nur minimal waren: vielleicht nur ein einziges bit Fehler. Es ist sehr wahrscheinlich, dass diese Seite immer noch genügend Bestandteile ihrer logischen Struktur enthält zu rechtfertigen Analyse mit Eseutil/m/p.

Die erwartete Prüfsumme in der Fehlermeldung ist die Prüfsumme, die tatsächlich von der Seite gelesen wird, wie sie jetzt in der Datenbank vorhanden sind. Die tatsächliche Prüfsumme in der Fehlermeldung ist die Prüfsumme, die Exchange dynamisch neu berechnet, sobald sie auf die Seite liest.

Wenn die tatsächliche Prüfsumme auf einer Seite 0x89abcdef ist, enthält die Seite alle Zeichen von 0 x 00. Wenn die tatsächliche Prüfsumme 76543210 ist, enthält die Seite alle 0xFF-Zeichen.

Im folgende Beispiel wird ein-1019-Fehler:
Information Store (3928) The database page read from the file"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 1675264 (0x0000000000199000)for 4096 (0x00001000) bytes failed verification because it containsno page data.  The read operation will fail with error -1019 (0xfffffc05).If this condition persists then please restore the database from aprevious backup.					
Während des normalen Betriebs Wenn eine Seite ein-1019-Fehler oder einen-1018-Fehler melden kann 1019-Fehler Vorrang und wird gemeldet. Denken Sie daran, dass ein-1019-Fehler tritt auf, wenn die Seitenzahl, die auf einer Seite geschrieben ist 0 x 00000000 ist, aber Exchange erwartet, dass die Seite verwendet wird. Es kann schwierig sein, ob ein-1019-Fehler verursacht wird, da das Dateisystem einen Block von Nullen in der Datenbankdatei zugeordnet, oder weil Exchange einen Fehler gemacht und auf die verwiesen wird einer nicht verwendeten Seite als "verwendet."

Sie können in dem vorstehend beschriebenen Fehler nicht erkennen, ob die Seite nicht initialisiert ist oder in einem anderen Zustand befindet. Sie müssen "Esefile" und "Eseutil" verwenden, um die Seite weiter zu untersuchen. In diesem Beispiel wird die Seitenzahl 408 Dezimal (abgeleitet aus 0 x 199).

Eseutil können Sie genauer ansehen, die Seite. PgnoThis -Wert muss die Seitenzahl, der abgefragt wird, und entsprechen der Wert UlChecksumParity meldet einen zusätzlichen ** berechnete Prüfsumme Wert, wenn die Prüfsumme auf der Seite falsch ist. Sie können die "Esefile" Schalters betrachten die rohe Seite bestimmen, ob es nicht initialisiert ist (alle 0 x 00 Zeichen) .

Falsche -1018-Fehler

Ein "False" -1018-Fehler tritt auf, wenn die Seite auf der Festplatte richtig ist, aber das e/a-System werden die Daten nicht korrekt abgerufen. Solche Fehler sind in der Regel vorübergehender Natur und schwer zu isolieren. Aber auch ein "false"-1018-Fehler sollte ernsthaft untersucht. Die Zuverlässigkeit des Speichersystems ist immer noch gefährdet, und das System möglicherweise in Gefahr weiterer Probleme oder Fehlfunktionen.

Wenn Sie vermuten, vorübergehende Lesefehler auftreten, in Ihrem System, verwenden Sie die "Esefile" / d -Schalter oder Eseutil/m/p auf die einzelnen Seiten zu überprüfen, die beteiligt sind. Wenn Sie entweder Dienstprogramm verwenden, um die gesamte Datenbank zu scannen, setzen Sie die Belastung für die e/a-System, das möglicherweise falsche Positivdiagnose mehr führt.

Exchange Server 5.5 Service Pack 2 (SP2) mit zusätzlicher Funktionalität, um vorübergehende Lesefehler identifizieren zu helfen. Exchange liest eine Seite 16 Mal nach dem ein Lesefehler aufgetreten. Wenn die Seite lesen Sie schließlich nach mehreren Versuchen erfolgreich ist, bedeutet dies, dass im Lesemodus zuverlässig von der Festplatte eine Systemproblem vorliegt. Auch wenn alle 16 Leseversuche fehlschlagen, beweist es nicht schlüssig, dass die Seite fehlerhaft ist. Führen Sie einen weiteren Test mit "Esefile" oder "Eseutil".

Unwiderrufliches Löschen

Unwiderrufliches Löschen soll, gelöschte Informationen in einer Exchange-Datenbank zu verschleiern, so dass nicht wiederhergestellt oder durch eine direkte Untersuchung der Datenbankdatei lesen. Weitere Informationen zu Unwiderrufliches Löschen klicken Sie auf die folgende Artikelnummer klicken, um den Artikel der Microsoft Knowledge Base anzuzeigen:
223161Information auf ESE Nullen
Wenn Unwiderrufliches Löschen der Datenbank aktiviert ist, Abschnitte leerer oder teilweise leerer Seiten mit bestimmten Zeichenmustern überschrieben werden, aber die Seite ist noch nicht initialisierten Zustand zurückgegeben.
VSAPI Virenscanner-API XADM

Eigenschaften

Artikelnummer: 314917 – Letzte Überarbeitung: 12/07/2015 08:26:53 – Revision: 2.0

Microsoft Exchange Server 2003 Standard Edition, Microsoft Exchange Server 2003 Enterprise Edition, Microsoft Exchange 2000 Server Standard Edition, Microsoft Exchange Server 5.5 Standard Edition

  • kbnosurvey kbarchive kbinfo kbmt KB314917 KbMtde
Feedback