Before Exchange 2003 SP2, database file headers did not contain any information about number of ECC fix-ups (which was an Exchange 2003 SP1 feature). Additionally, there was no way of telling how many corrections were made when specific database file was repaired and then offline defragmented, because offline defrag would reset the Repair Count database header value to zero. Knowing the above information can provide good historical information on what is going on with the database.
Starting with Exchange 2003 SP2, there are several added fields in database header. When running the ESEUTIL /mh command against the database on an Exchange 2003 SP2 server, the output will contain the following fields that are new:
Old Repair Count:
ECC Fix Success Count:
Old ECC Fix Success Count:
ECC Fix Error Count:
Old ECC Fix Error Count:
Bad Checksum Error Count:
Old bad Checksum Error Count:
The explanation of how those are populated follows:
Old Repair Count – starting with Exchange 2003 SP2, the Repair Count value survives the offline defrag on the database. For example if DatabaseA has a Repair Count of 2 and is then offline defragmented, the resulting DatabaseB will have a Repair Count of “2” and the Old Repair Count will be also set to “2”. Any subsequent repairs of DatabaseB will increment it’s Repair Count value. If the Repair Count value is higher than the Old Repair Count value, we can tell that the database had things repaired since the last offline defrag.
ECC Fix Success Count and Old ECC Fix Success Count – in Exchange 2003 SP1, we added the ability to fix certain ECC issues in database pages “on the fly”. The ECC Fix Success Count field shows how many times the ECC fixup was done successfully since Exchange 2003 SP2 was installed. The Old ECC Fix Success Count field gets populated during database repair and shows the value that the database had in the ECC Fix Success Count before the repair.
ECC Fix Error Count and Old ECC Fix Error Count – when the ECC correction is made on the database page, another more comprehensive test is run on the page. If that test fails, the ECC Fix Error Count is incremented and an event with a -1018 error code is logged in the Application log. The Old ECC Fix Error Count field gets populated during database repair and shows the value that the database had in the ECC Fix Error Count before the repair.
Bad Checksum Error Count and Old bad Checksum Error Count – this field contains the number of “real” -1018 errors in the database that we could not fix. For example, SP1 functionality lets us fix only single bit problems on the database page. If there are multiple bits on the page that are corrupt, the result is a “real” -1018 error that can not be fixed up automatically and Bad Checksum Error Count is incremented. The Old Bad Checksum Error Count gets populated during database repair and shows the value that the database had in the Bad Checksum Error Count before the repair.
The following table illustrates this:
New value name
On database repair
On database offline defrag
Old Repair Count
Preserve the value
Populate with value from original database’s Repair Count*
ECC Fix Success Count
Clear the value
Old ECC Fix Success Count
Populate with value from ECC Fix Success Count
ECC Fix Error Count
Old ECC Fix Error Count
Populate with value from ECC Fix Error Count
Bad Checksum Error Count
Old bad Checksum Error Count
Populate with value from Bad Checksum Error Count
* - it should be understood that the Repair Count value does not increment on every repair necessarily. The Repair Count value increases only if there was something repaired in the database during the repair. So – if for example the count is “0” and there are two things that need repairing in the database, after a single database repair the Repair Count value is going to be set to “2”.
For more information on the Exchange 2003 SP1 ECC changes, please see the following article:
867626 New error correcting code is included in Exchange Server 2003 SP1