Microsoft KB Archive/253325

= XADM: How to Detect Header Damage in Databases, Log Files, Patch Files, and Checkpoint Files =

Article ID: 253325

Article Last Modified on 2/21/2007

-

APPLIES TO


 * Microsoft Exchange Server 5.5 Standard Edition
 * Microsoft Exchange 2000 Server Standard Edition

-



This article was previously published under Q253325



SUMMARY
The Esefile utility, available in the Support folder of Service Pack 3 for Exchange Server 5.5 can be used to detect damage to file headers for Exchange Server 5.0, 5.5, and Exchange 2000 Server.

Damage to 5.5 log files is often reported as a -514 or 0xfffffdfe (JET_errBadLogVersion). If you have not recently upgraded Exchange Server or are very sure you don't have mixed versions of files, the procedures in this article allow you to determine whether or not the problem is actually a damaged file header.



MORE INFORMATION
The primary function of Esefile is to verify the checksum integrity of every page in a database file. All log file headers are checksummed by the same method that database pages are checksummed, so Esefile can be used to verify headers, even in transaction log files.

The header page is the first physical 4 kilobyte (KB) page in the file. The second page in the file is a "shadow header" which is an exact duplicate of the first header page.

NOTE: Transaction log files do not have shadow headers. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

253111 XADM: Event: Unable to Write a Shadowed Header for File. ..

Esefile can scan Exchange Server 5.0, 5.5, and Exchange 2000 files. Use the /X option to scan a 5.0 file, the /S option to scan a 5.5 file, and the /S option to scan an Exchange 2000 file.

Type the following commands at a command prompt:  To scan a 5.0 database file:

esefile /x priv.edb

 To scan a 5.5 log file:

esefile /s edb.log

 To scan an Exchange 2000 checkpoint file:

esefile /s e00.chk



Esefile scans files in physical page order. Esefile reports the header page as page -1 and the shadow header as page 0. Because the header is scanned first, you can press CTRL+BREAK to quit Esefile after several seconds. If you haven't seen a reference to page -1 or 0 by the time the first progress dot appears on screen, the header pages are good. Esefile lists only pages that have a problem. Output of Esefile for a bad header will look similar to the following:

F:\exchsrvr\mdbdata>esefile /s priv.edb

Checksumming

0   10   20   30   40   50   60   70   80   90  100          |||||||||||          ERROR: page -1 checksum failed ( 0xae125a0 / 0xa4b25a0 ) ...................................................

To test a log file, set the Screen Buffer Height on your command prompt window to a large value such as 9999. Log files use a different checksumming scheme than database files, except for the 4-KB header. Therefore, every page in a normal log file except the header page will fail the Esefile test, and Esefile will rapidly generate hundreds to thousands of lines of output. Scroll back to the beginning of the output. If the log file is good, it will look similar to the following:

F:\exchsrvr\mdbdata>esefile /s edb00005.log

Checksumming

0   10   20   30   40   50   60   70   80   90  100          |||||||||||          ERROR: page 0 checksum failed ( 0xc87592d0 / 0x9003 ) ERROR: page 1 returned page 2937857 ERROR: page 1 checksum failed ( 0x9df4d425 / 0x200000e ) ERROR: page 2 returned page 1845520640 ERROR: page 2 checksum failed ( 0xac2a96a / 0x72007400 ) ERROR: page 3 returned page 7209061 ERROR: page 3 checksum failed ( 0xcbfa14fa / 0x760045 )

Notice that there is no page -1 listed above. Because there is no shadow header, it is not meaningful that page 0 fails the test. A bad log file, on the other hand, will look similar to the following:

F:\exchsrvr\mdbdata>esefile /s edb00006.log

Checksumming

0   10   20   30   40   50   60   70   80   90  100          |||||||||||          ERROR: page -1 checksum failed ( 0x7f31fff5 / 0x7f91fff5 ) ERROR: page 0 checksum failed ( 0x28c0beee / 0x8603 ) ERROR: page 1 returned page 2937857 ERROR: page 1 checksum failed ( 0x6bedb508 / 0x2000005 ) ERROR: page 2 returned page 7602286 ERROR: page 2 checksum failed ( 0x2dba8e76 / 0x49000a ) ERROR: page 3 returned page 1946182912 ERROR: page 3 checksum failed ( 0x765bd648 / 0x72007000 )

If a log file header is damaged, it cannot be repaired--another copy of the log file must be found. For files with shadowed headers, as long as one copy of the header is still good, the bad copy can be automatically "patched," and the problem is usually detected and fixed before you know it exists.

If both copies of a database or patch file header are damaged, another copy of the file must be found. If a checkpoint file is irreparably damaged, it can be re-created dynamically. A checkpoint file is nothing but header. All versions of Exchange Server quickly repair a damaged checkpoint file by either patching it, if one copy of the header is still good, or by reconstructing it from scratch.

IMPORTANT NOTE: Do not delete the checkpoint file arbitrarily, especially if the database is stopped at the time of deletion.

As the database starts, the checkpoint file controls which transaction log files, if any, will be replayed. If you have in any way altered the contents of the data directories since the last time the database was stopped, you may cause irreparable damage to the database by beginning log file replay at the wrong point.

Exchange 2000 adds new safeguards to prevent improper log file replay, regardless of any tampering with files. But even with Exchange 2000, deleting the checkpoint may still result in a startup failure.

It is not recommended that you delete the checkpoint file while the database is running. If the checkpoint file is missing, Exchange Server re-creates it the next time that it is accessed (usually within a few seconds or minutes). Nonetheless, deleting the checkpoint file while the database is running is not entirely risk free: if the database were to crash after deletion and before the file had been re-created, you would be in the same situation as if you had deleted the checkpoint file while the database was stopped.

Additional query words: 514, fffffdfe

Keywords: kbinfo KB253325

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.