Es kann bei dem Betrieb eines Exchange Servers immer wieder zu Probleme kommen. Wichtig ist in dem Fall nur, dass Sie die richtigen Entscheidungen treffen andernfalls verlieren Sie Zeit oder im schlimmsten Fall Daten.
Bevor Sie anfangen zu handeln, nehmen Sie sich einen Zettel und schreiben Sie sich folgende Informationen auf.
Systeminformationen sammeln
- letzte Sicherung vom ____._____.________
- Was sagt der Eventlog
- seit wann existiert der Fehler
- was passierte in dem Zeitraum an den beteiligten System (Exchange, AD, Domain Controller, DNS-Server)
- welchen Status hat die Datenbank (mounted/umounted)?
- Prüfen Sie den freien Speicherplatz auf allen Laufwerken und beteiligten Systemen
- Speichergruppen- oder Postfachproblem?
- Gibt es Fehler/Probleme bei der DNS oder Wins Auflösung?
- ist der Globale Katalog verfügbar (welcher DC hält den GC)
- liegt ein Hardware defekt vor?
- Reicht es ein Backup wiederherzustellen oder muss der aktuelle Datenbestand um jeden Preis gesichert werden
Nachdem Sie all diese Informationen zusammen getragen haben schauen Sie sich die betreffende Datenbank an.
1. Muss verhindert werden, dass weiterhin E-Mails auf dem betroffenen System eingehen?
Diese Frage ist gar nicht so uninteressant. Sollten Sie auf der Partition auf der die Log-Dateien liegen nicht mehr viel oder keinen Speicherplatz mehr haben, müssen Sie unter Umständen den Exchange Transport Dienst stoppen um zu vermeiden, dass die Festplatte ganz voll läuft oder Ihr Reparaturversuch, der unter Umständen einige Zeit dauern kann, gestört wird, weil auf einmal der Speicherplatz alle ist.
2. Dismounten Sie die Datenbank
Für fast alle Reparaturarbeiten ausgenommen einer Datenbank Wiederherstellung muss die DB offline genommen werden.
Machen Sie, insofern Sie genügend Speicherplatz haben, eine Sicherung der DB+check Datei sowie ALLER Logs der entsprechenden Speichergruppe. Achten Sie bei einem CCR darauf, dass Sie auch die E00.log erwischen, denn diese ist nur auf dem aktiven Knoten vorhanden. Eine Sicherung der Log-Dateien am passiven Knoten wäre damit nicht ausreichend!
3. Prüfen der Vollständigkeit der Transaktionslogs
Wenn alle Log-Dateien vorhanden sind, sieht die Ausgabe folgendermaßen aus:
C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /ml "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071E00" | find /V "OK" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Verifying log files... Base name: E00 No damaged log files were found. Operation completed successfully in 0.703 seconds.
Fehlt eine Log-Datei, so wird diese ausgegeben.
C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /ml "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071E00" | find /V "OK" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Verifying log files...
Base name: E00
Missing log file: C:Program FilesMicrosoftExchange ServerV14MailboxM ailbox Database 1030133071E0000000008.log Operation terminated with error -528 (JET_errMissingLogFile, Current log file mi ssing) after 0.734 seconds.
Je nach Anzahl der Log-Dateien, dauert dieser Vorgang seine Zeit.
3. Konsistenz der Datenbank prüfen
C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /mh "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Datab ase 1030133071.edb" | find /i "consistent" Last Consistent: (0x0,0,0) 03/11/2012 09:18:2
Das Datum ermöglicht Ihnen, festzustellen wann die Datenbank das letzte mal konsistent war. Dies kann für die Auswahl des Backups von interesse sein. Idealerweise war die DB beim letzten Dismounten konsistent.
4. shutdown status der Datenbank prüfen
C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /mh "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Datab ase 1030133071.edb" | find /i "shutdown"
State: Clean Shutdown
Ein Dirty Shutdown ist immer schlecht. Liegt dieser Fall vor, sollten Sie folgende Schritte versuchen
- Log-Replay
- Defragmentierung
- Soft Repair
- Hard Repair (es gehen sehr wahrscheinlich Daten verloren)
5. prüfen von wann das letzte Backup ist – ist es auch physikalisch noch vorhanden?
Die grün markierten Stellen sind noch einen Blick wert.
eseutil /mh "c:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Database: C:Program FilesMicrosoftExchange ServerV14MailboxMailbx Database 1030133071Mailbox Database 1030133071.edb DATABASE HEADER: Checksum Information: Expected Checksum: 0x010bb66b Actual Checksum: 0x010bb66b Fields: File Type: Database Checksum: 0x10bb66b Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,17 Engine ulVersion: 0x620,17 Created ulVersion: 0x620,17 DB Signature: Create time:03/11/2012 09:18:23 Rand:726187 Computer: cbDbPage: 32768 dbtime: 15941 (0x3e45) State: Clean Shutdown Log Required: 0-0 (0x0-0x0) Log Committed: 0-0 (0x0-0x0) Log Recovering: 0 (0x0) GenMax Creation: 00/00/1900 00:00:00 Shadowed: Yes Last Objid: 307 Scrub Dbtime: 0 (0x0) Scrub Date: 00/00/1900 00:00:00 Repair Count: 0 Repair Date: 00/00/1900 00:00:00 Old Repair Count: 0 Last Consistent: (0x0,0,0) 03/11/2012 09:18:26 Last Attach: (0x0,0,0) 03/11/2012 09:18:23 Last Detach: (0x0,0,0) 03/11/2012 09:18:26 Dbid: 2 Log Signature: Create time:00/00/1900 00:00:00 Rand:0 Computer: OS Version: (6.1.7601 SP 1 NLS 60101.60101) Previous Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Incremental Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Copy Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Previous Differential Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current Full Backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 Current Shadow copy backup: Log Gen: 0-0 (0x0-0x0) Mark: (0x0,0,0) Mark: 00/00/1900 00:00:00 cpgUpgrade55Format: 0 cpgUpgradeFreePages: 0 cpgUpgradeSpaceMapPages: 0 ECC Fix Success Count: none Old ECC Fix Success Count: none ECC Fix Error Count: none Old ECC Fix Error Count: none Bad Checksum Error Count: none Old bad Checksum Error Count: none
Last checksum finish Date: 00/00/1900 00:00:00 Current checksum start Date: 00/00/1900 00:00:00 Current checksum page: 0 Operation completed successfully in 0.109 seconds.
6. prüfen welche Logs für eine Konsistente DB benötigt werden
eseutil /mh "D:programmeExchsrvrMDBDATApriv1.edb" | find /i "Log Required" Log Required: 0-0 (0x0-0x0) eseutil /mh "D:programmeExchsrvrMDBDATApriv1.stm" | find /i "Log Required" Log Required: 0-0 (0x0-0x0)
In diesem Fall werden keine Log-Dateien benötigt. Steht bei „Log Required“ etwas anderes, stellen Sie sicher das die Log-Dateien alle noch vorhanden sind.
Sollten Sie wirklich keine Logs für eine konsistente DB benötigen und die Log Partition lediglich voll gelaufen sein, so ist es das beste die Log Datei Sequenz zurücksetzten.
7. Checksumme prüfen
Eine Überprüfung der Checksumme kann auch noch evtl. Fehler zu Tage befördern. Zudem kann man hier gleich die Lese-Performance der DB sehen.
C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /k "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating CHECKSUM mode...' Database: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb Temp. Database: TEMPCHKSUM4736.EDB File: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox D Checksum Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... 1026 pages seen 0 bad checksums 0 correctable checksums 667 uninitialized pages 0 wrong page numbers 0x3e45 highest dbtime (pgno 0xf7) 513 reads performed 32 MB read 1 seconds taken 32 MB/second 5172 milliseconds used 10 milliseconds per read 109 milliseconds for the slowest read 0 milliseconds for the fastest read
8. DB defragmentieren
Bei der Online-Wartung werden die freien Seiten innerhalb der Datenbank zwar gelöscht, jedoch werden diese nicht aus der DB entfernt. Eine Datenbank wird also immer größer, bis eine Offline Defragmentierung durchgeführt wird. Hierbei werden die leeren Seitenbereiche physikalisch wirklich entfernt.
C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /d "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating DEFRAGMENTATION mode... Database: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb Defragmentation Status (% complete)' 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Moving 'TEMPDFRG4596.EDB' to 'C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb'... DONE! Note: It is recommended that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup. Operation completed successfully in 3.156 seconds.
8. Log Replay
Um die Datenbank auf den aktuellen Stand zu bringen, können die Log-Dateien manuell eingespielt werden.
C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071>eseutil /R E00 /i /d"C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating RECOVERY mode... Logfile base name: E00 Log files: System files: Database Directory: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb Performing soft recovery... Operation completed successfully in 0.63 seconds.
Log Datei Sequenz zurück setzten
Um die Log Sequenz zurück zu setzten müssen Sie sicherstellen, dass die DB in einem „Clean Shutdown“ Status ist und keine weiteren Log Dateien benötigt werden. Anschließend verschieben Sie alle Log-Dateien sowie chk Dateien in einen anderen Ordner und mounten Sie die DB erneut. Exchange fängt nun an neue log-Dateien mit von bei Null an beginnenden Sequenznummer zu erstellen.
restore.env
Haben Sie eine Datenbank aus einer Sicherung wiederhergestellt und die Log-Dateien noch nicht replayed können Sie – insofern nur die wiederhergestellten Log-Dateien replayed werden müssen – dies anhand der restore.env machen.
eseutil /cc /T restore.env
soft repair (Eseutil)
- Heben Sie die Bereitstellung des Öffentlichen- sowie des Postfachspeichers auf.
- starten Sie dem soft repair Vorgang
eseutil /r E00 /l ..MDBDATA - Prüfen Sie den Status sowie die Checksumme der Datenbank erneut
- Informationsspeicher wieder bereitstellen
- Eventlog & Systemmanager überprüfen
Hard repair (Eseutil)
Das Hard repair sollte nur dann verwendet werden wenn:
nicht mehr alle Logfiles zur Reparatur vorhanden sind
sich die Datenbank trotz aller benötigten Logfiles nicht bereitstellen lässt
hard repair (eseutil)
Es gehen bei einem hard repair in der Regel Daten verloren!
- Heben Sie die Bereitstellung aller zu reparierenden Informationsspeicher auf.
- reparieren Sie die Datenbanken (Exchange 2007 hat keine stm-Dateien mehr)
eseutil /p ..mdbdatapriv1.edb /s ..mdbdatapriv1.stm
eseutil /p ..mdbdatapub1.edb /s ..mdbdatapub1.stm - Prüfen Sie den Status der Datenbanken
eseutil /mb ..mdbdatapriv1.edb - Anschließend die Dateien *.chk, *.log löschen so das nur noch die eigentlichen Datenbanken vorhanden sind.
- DB mit ISInteg auf Integrität prüfen
- Informationsspeicher wieder bereitstellen
- Eventlog & Systemmanager überprüfen
Integrität prüfen (ISInteg)
- Bereitstellung des Informationsspeichers aufheben
- Integrität prüfen (es wird an der DB nichts verändert)
isinteg -s -test alltests - Wenn Fehler gefunden wurden, dann reparieren
isinteg –s -fix -test alltests - Informationsspeicher wieder bereitstellen
- Eventlog & Systemmanager überprüfen
Hinweis zum CCR
- nur auf dem aktiven Knoten sind alle Log-Dateien vorhanden. Auf dem Passiven fehlt die E0x.log
- Ein Backup auf dem aktiven Knoten bei einer nicht konsistentes des CCR bringt Ihnen nichts außer einem Backup. Die Log-Dateien bleiben aller erhalten. Erst nach einer erfolgreiche Replizierung aller Logs auf den passiven Knoten werden die nicht mehr benötigten logs gelöscht.
- Haben Sie Probleme mit einer DB halten Sie zuerst die Speichergruppenreplikation an. Dies ermöglicht Ihnen auf dem aktiven Knoten das Problem zu lösen, während Sie auf dem passiven ein Backup der Daten haben. Dies geht allerdings nur, wenn die Log-Partition der entsprechenden Speichergruppe noch über ausreichend Plattenplatz verfügt.