Im Laufe der letzten zwei Jahre hat Microsoft Watson Crash Dumps für Informationsspeicherabstürze überprüft, die automatisch von den Kunden-Servern hochgeladen wurden. Die Abstürze hatten eine ungeklärte Ursache, scheinbar ursächlich durch mögliche Datei-Korruption. Die Arten der Datei-Korruption variierte und sind aus den unterschiedlichsten Datenbanken, Servern, Exchange-Versionen, und Kunden gekommen. In fast allen diese Fälle war es so, das die Reparaturzählung auf der Datenbank kleiner gleich 0 war.
Wenn ESEUTIL / p ausgeführt wird, und eine Reparatur der Datenbank erforderlich ist, wird der Reparaturzähler um einen nach oben gesetzt und die Reparaturzeit wird in dem Header der Datenbank aufgezeichnet. Die in der Datenbank-Header gespeicherten Reparaturinformationen werden nach einer Offline-Defragmentierung beibehalten.
Die Reparaturinformationen in der Kopfzeile können mit Eseutil / MH ausgelesen werden.
[PS] C:\Program Files\Microsoft\Exchange Server\Mailbox\First
Storage Group>eseutil /mh '.\Mailbox Database.edb'
Extensible Storage Engine Utilities
for Microsoft(R) Exchange Server
Version 08.03
Copyright (C) Microsoft Corporation.
All Rights Reserved.
Initiating FILE DUMP
mode...
Database: .\Mailbox
Database.edb
File Type:
Database
Format ulMagic:
0x89abcdef
Engine ulMagic:
0x89abcdef
Format ulVersion:
0x620,12
Engine ulVersion:
0x620,12
Created ulVersion:
0x620,12
DB Signature: Create time:04/05/2015
08:39:24 Rand:2178804664 Computer:
cbDbPage:
8192
dbtime: 1059112
(0x102928)
State: Clean
Shutdown
Log Required: 0-0
(0x0-0x0)
Log Committed: 0-0
(0x0-0x0)
Streaming File:
No
Shadowed: Yes
Last Objid:
4020
Scrub Dbtime: 0
(0x0)
Scrub Date: 00/00/1900
00:00:00
Repair Count: 2
Repair Date: 04/05/2015 08:39:24
Old Repair Count: 0
Last Consistent: (0x0,0,0)
04/05/2015 08:39:25
Last Attach: (0x0,0,0) 04/05/2015
08:39:24
Last Detach: (0x0,0,0) 04/05/2015
08:39:25
Dbid: 1
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
Operation completed successfully in
0.78 seconds.
Nicht wieder korrigierbare Fehlerzustände in der Datenbank können zu einem instabilen System und einem Absturz der Datenbank führen. Aus dem Grunde hat Microsoft seine Policy dahingehend geändert, das bei einem Repair-Count von grösser 1 eine Evakuierung der Mailboxen (inkl. Public Folder) in eine neue Datenbank erforderlich wird. Damit wird sicher gestellt, das die Datenbankstruktur sich wieder in einem ordnungsgemäßen Zustand befindet.
Kommentar schreiben