Wenn Sie dachten, dass Transaktionsprotokolldateien nur eine Möglichkeit sind, die Prozesse im Auge zu behalten, wird dieser Artikel Ihr Denken verändern. Transaktionsprotokolldateien spielen eine entscheidende Rolle für das reibungslose Funktionieren der Exchange database, so dass Inkonsistenzen in ihnen dazu führen können, dass Exchange abrupt funktioniert oder gar nicht erst startet. Lassen Sie uns dies mit einer kurzen Einführung über ihre Rolle in Bezug auf den Exchange-Server erklären.
Die entscheidende Rolle, die Exchange-Transaktionsprotokolldateien spielen
Exchange-Transaktionsprotokolle verfolgen jede Änderung, die in der Database vorgenommen wird. Die Daten, die in den Benutzer-Mailboxes aktualisiert werden sollen, werden zunächst in den Protokolldateien registriert und dann in die Database geschrieben. Da die Größe der Protokolldatei festgelegt ist, wird, sobald die Protokolldatei voll ist, eine neue mit der nächsten Sequenznummer erstellt.
Transaktionsprotokolldateien erweisen sich als nützlich, wenn die Database von einer älteren Version wiederhergestellt werden muss. Exchange-Administratoren wird daher immer empfohlen, keine Protokolldateien dauerhaft zu löschen. Stattdessen sollten sie sicherstellen, dass die Protokolldateien an sicheren Orten ordnungsgemäß gesichert werden und nur dann verworfen werden, wenn sichergestellt ist, dass eine ältere Version der Database nicht mehr benötigt wird.
Wie wichtig sind sie aus der Sicht von Exchange Dirty shutdownError?
Nur wenn die Exchange-Database ordnungsgemäß heruntergefahren wird, kann Exchange Server problemlos gestartet werden. Damit die Database ordnungsgemäß heruntergefahren werden kann, muss sichergestellt sein, dass alle Daten im Transaktionsprotokoll in Datenbankdateien gespeichert sind. Wenn alle Transaktionsprotokolldaten übertragen wurden, gilt die Database als “losgelöst” von diesen Protokolldateien, was ein grünes Signal für ein sauberes Herunterfahren ist. Wenn der Server hochfährt, überprüft er den Zustand der Database, und wenn er sich als “angehängt” an die Protokolldateien erweist, wird die Datenbank als “Dirty shutdownstate” betrachtet. Infolgedessen “trennt” der Server zuerst die Datenbank, indem er die verfügbaren Protokolldateien wiedergibt, und fährt dann mit anderen Aufgaben fort.
Ein bisschen mehr über Dirty shutdownError
Die Microsoft Exchange Server Database verwendet im Kern die Extensible Storage Engine (ESE), auch bekannt as JET-Engine. Die Jet-Engine verwendet den Mailbox-Database-Cache, um die Anzahl der Input-Output-Operationen zu reduzieren. Es ist dieses Triebwerk, in dem Transaktionsprotokolldateien gespeichert werden.
Wenn also eine Änderung oder Operation an der Database in den Cache-Speicher geladen wird, aber nicht an die Database gebunden ist, wird sie von der Jet-Engine als “Dirty” markiert. Bis zum Zeitpunkt, an dem nicht alle Dirty-Transaktionen aufgelöst werden, gilt die Database als inkonsistent. Wenn der Exchange Server unerwartet heruntergefahren wird, während die Database inkonsistent ist, wird der Dirty shutdownError empfangen.
Nacheffekte von Dirty shutdownError
Das Blinken des Dirty shutdownError zeigt an, dass Exchange Database Dateien (EDB- or STM-Dateien) beschädigt werden können. In einem solchen Fall, wenn Sie versuchen, mit ESEUTIL die Database Dateien mit diesem Befehl zu reparieren: Eseutil /k
Sie werden möglicherweise Fehler wie diese erhalten:
- FEHLER: Database wurde nicht sauber heruntergefahren (dirty shutdown).
- Vorgang wurde mit Error-550 abgebrochen (JET_errDatabaseDirtyShutdown, Database wurde nicht sauber heruntergefahren. Die Recovery muss zuerst durchgeführt werden, um die Database ordnungsgemäß zu vervollständigen.
- Exchange kann die von Ihnen angegebene Database nicht einbinden.
Wie repariert man Dirty shutdownError
Vergewissern Sie sich in einem ersten Schritt, dass sich der Austausch im sauberen Abschaltzustand oder im verschmutzten Abschaltzustand befindet. Öffnen Sie dazu die Eingabeaufforderung und geben Sie die folgende Syntax ein: Eseutil /mh “Pfad der Database”.
Wenn der DB-state auf dem Ergebnisbildschirm als “Clean Shutdown” angezeigt wird, wird die Database aus dem Transaktionsprotokoll entfernt und ist konsistent. Wenn der DB-Zustand jedoch “Dirty Shutdown” anzeigt, ist die Database weiterhin an die Protokolldatei angehängt und inkonsistent.
Je nach Szenario können die folgenden Methoden verwendet werden, um den Fehler HR=0X80004005 oder Dirty shutdownError zu beheben.
1. Wenn die DB mit sauberen Protokolldateien konsistent ist.
Wenn sich die Protokolldateien im sauberen Zustand befinden, sollte eine sanfte recovery der database in der Lage sein, den Fehler zu beheben. Bei der Soft-Recovery werden nach einem unerwarteten Stopp der database Transaktionsprotokolle wiedergegeben, um die database neu zu mounten. Dazu wird das Befehlszeilenprogramm ESEUtil mit dem Schalter /ml verwendet, um zunächst den Zustand der Protokolldateien durch die Syntax zu testen: eseutil /ml “Path of the log files\log prefix
Und dann wird die sanfte Recovery über die Syntax durchgeführt: eseutil /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i
2. Wenn sich die Protokolldateien nicht im sauberen Zustand befinden oder nicht verfügbar sind.
Wenn Protokolldateien nicht zugänglich sind, nicht verfügbar sind oder sich nicht im sauberen Zustand befinden, sollte eine recovery der harten database versucht werden. Bei der harten recovery werden die Transaktionsprotokolldateien wiedergegeben, indem die database aus dem Online-Backup recovery wird. Dies ist der einzige Unterschied zwischen harter und weicher Erholung.
Wenn eine gültige und aktuelle database Sicherung verfügbar ist, können EDB, LOG and STM-Dateien daraus wiederhergestellt werden. Sobald dies abgeschlossen ist, wird automatisch eine Datei namens ‘restore.env’ in einem temporären Ordner mit dem Namen’C:\Temp’ erstellt.
Wichtig: Sie müssen sicherstellen, dass Sie eine Kopie von restore.env und Protokolldateien aufbewahren. Hard-Recovery-Prozesse führen manchmal zum Verlust von Daten und deshalb ist es besser, sicher zu sein.
Hier ist die Syntax für Hard Recovery: Eseutil /cc “Pfad der restore.env mit Ordner”. Sobald der gesamte Vorgang abgeschlossen ist, ist der temporäre Ordner mit restore.env leer.
3. Wenn ein gültiges Backup nicht verfügbar ist
Wenn keine der oben genannten Methoden möglich ist, verwenden Sie ESEUtil wie folgt: eseutil /p
Klicken Sie auf ‘OK’ im folgenden Popup-Fenster, das angezeigt wird, und dann beginnt der Prozess. Wenn der Prozess abgeschlossen ist, führen Sie eseutil mit \mh switch aus, um die Konsistenz der database erneut zu überprüfen. Diesmal sollte die Abschaltung sauber sein. Die Defragmentierung der database sollte nun den Fehler beheben.
Offline-Defragmentierung
Als letzten Schritt wird die Database-defragmentierung durchgeführt, um die database auf dem Server anzuordnen, und unbenutzte Seiten werden entfernt, um den Festplattenspeicher zu reduzieren. Es entsteht eine neue, kompakte database, die frei von alten Daten und ungenutzten Seiten ist. Die verwendete Syntax ist: eseutil /d Database_Name
Empfohlene Lösung
Wenn Sie eine andere Methode als ESEUtil verwenden möchten oder den gesamten Prozess einfacher und risikoloser gestalten möchten, verwenden Sie die professionelle Exchange database repair Software Stellar Repair for Exchange. Es repariert beschädigte EDB-Dateien und extrahiert alle Mailbox-Inhalte im PST-Format. Die neu erstellte PST kann dann in Outlook und dann auf einen anderen, gut funktionierenden Server importiert werden. Mit einem einfachen 3-Schritte-Verfahren bringt dieses Produkt beschädigte MS Exchange databases wieder in den Betriebszustand.
Diese kompetente Anwendung ist kompatibel mit MS Exchange 2019, 2016, 2013, 2010, 2007, 2003, 2000, and 5.5.
