Microsoft Exchange Server is designed to write all the database transactions to certain log files and commit them later whenever the system allows. The transactions also exist in system memory, but get lost in the event of crash. If the Exchange Server undergoes unexpected crash, these transaction logs serve as the crucial recovery method. For this reason, the transaction lof files should be kept on a reliable system. The log file header contains information like file signature, base name, creation time, checkpoint etc. At times, your Exchange Server indicates as it is unable to read this information. These are critical situations that may compel you to restore the data from an online backup or perform hard recovery for your databases. However, it is highly recommended that you try to move Exchange mailboxes on another server or use an Exchange Recovery product to repair the database.

To exemplify, consider a situation when you receive the below error with your Exchange Server database:

"Unable to read the log file header."

The error is logged as event 412 in application event log. The ESE error code that displays in Description section of this event gives detailed information of the root cause.

Cause

As the error suggests, it occurs when Exchange database engine cannot read the log file header. This indicates that log file has a mismatching signature, has corrupted header information or is corrupt. You can deduce the exact cause by the ESE error code the event shows:

1.Jet_errLog fileCorrupt or error -501: The header of the log file is corrupt

2.Jet_errBadLogSignature or error -530: The log files signature mismatch. The log file signature ensures the correct replaying of log files set and is included in each database header. The error occurs when they mismatch.

3.Jet_errDiskIO or error -1022: A disk I/O issue for requested page in transaction log or database. Generally, -1022 error occurs because of severe database corruption. For a log file, the cause is corruption of log file header.

Solution

You need to use any of the below procedures:

1.Check for the last online backup and restore

2.In case of valid backup unavailability, you can run eseutil /p command and later isinteg -fix command. It is a hard command and data loss is likely as will delete database pages. Thus, for your production database, it is recommended to use another Microsoft Exchange Recovery method like moving the mailboxes to other database or using an Exchange Recovery software.

Stellar Phoenix Mailbox Exchange Recovery is a reliable and efficient solution for repairing corrupted Exchange databases created using Exchange Server 5.5, 2000 and 2003. The advanced Exchange Server Recovery tool can extract all mailboxes and store them in individual .pst files. The software uses intensive scanning algorithms for database corrupted due to any reason.