To test a log file for suspected damage, run the following command:
eseutil /ml Log File Name
For example, to test a log file that is named E00123ab.log, type:
eseutil /ml e00123ab.log
If the log file passes the test, the following response appears:
Integrity check passed for log file: Log File Name
If the log file fails the test, the following response appears:
CORRUPTION DETECTED in log file: Log File Name
Operation terminated with error -501 (JET_errLogFileCorrupt, Log file is corrupt)
You can use a single command to test all the log files in a folder. To do this, open a command prompt window, and then change to the folder where the log files are located. Type the following command:
eseutil /ml Enn
In this command, "Enn" signifies the log prefix. The log prefix is the first three characters of the log file name that are shared by all logs that belong to a particular storage group. For example, the
eseutil /ml E00 command scans all transaction log files in a folder that share the same log prefix. Additionally, the command reports if any transaction log files are damaged, out of sequence, missing, or mismatched with the other log files.
Torn writes and E00.log
A torn write is an incomplete physical write that is left in the E00.log file after the database service suddenly stops. A torn write may be caused by a power failure, by an operating system crash, by invoking End Process on the database process, or by using a termination utility such as Kill.exe. A torn write causes checksums on the affected transactions in the log file to be calculated incorrectly, and the log is then detected as damaged by Eseutil.
Torn write detection is a sophisticated process whereby Exchange determines whether a transaction was damaged because of a torn write or because of other factors. If a torn write is the problem, Exchange repairs the log file when the database is restarted.
Exchange cannot repair damage to log files that is the result of factors other than torn writes. Hardware failures that randomly damage a log file cannot be overcome because the lost data cannot be reliably reconstructed.
Torn writes only occur in the E00.log file because the E00.log file is the only log file that is open and is being written to. When an E00.log file is full, it is closed and renamed with a sequential number. Exchange cannot repair a log file that has been closed and numbered (for example, E00123ab.log).
There is no risk of causing additional damage to the database when you try to replay an E00.log file that the
eseutil /ml command reports is corrupted. If the problems in the log file are only torn writes, they will be corrected. If the problems cannot be repaired, the database rejects the data instead of applying the data, and an event that is similar to the following is logged in the application log:
Event Type: Error
Event Source: ESE98
Event Category: Logging/Recovery
Event ID: 465
Date: 12/9/1999
Time: 2:48:48 PM
User: N/A
Computer: Computer_Name
Description: Information Store (2428) Corruption was detected during soft recovery in log file E:\exchsrvr\THIRD\E00123ab.log. The failing checksum record is located at position 8189:328. Data not matching the log-file fill pattern first appeared in sector 8195.
This event indicates that there is damage that cannot be repaired. In such a case, you can use one of the following recommended solutions:
- Locate a good copy of the damaged log file. Another copy may exist either on an Exchange online backup or on a recent server backup.
- Discard the damaged log file together with all the log files that are newer than the damaged log file. Then restore a known good online backup of the Exchange database. You will lose any data that was logged after the damaged log file was created.
If these solutions are not workable, you can repair the database by using the "hard repair" (
/p) functionality of the Eseutil utility. Before you do this, make sure that you back up all the database files in a storage group (*.log files, *.edb files, and *.stm files), and then contact Microsoft Product Support Services (PSS) for additional advice. Hard repair always causes at least some data loss.
In versions of Exchange that are earlier than Exchange 2000, checksums on log files were not reliably calculated. If the log files became damaged, it was possible to replay that damage into the database files. There was no way to reliably check a log file for damage: not only was there no utility to do so, but the nature and the format of the log files made it impossible to do so even in theory.
Log files were seldom damaged before Exchange 2000, but when the log files were damaged, disaster recovery became very difficult. Because damage was not detectable, the damage might be replayed into the database. Frequently, there was no way to know that something was wrong until the database crashed or otherwise failed soon after startup. In this situation, you had to completely restore the database, discard some log files, and hope that the outcome was correct.
Exchange 2000 and Exchange 2003 are vastly improved in this respect, and it is now extremely difficult to replay a damaged log file or the wrong log file into a database. In addition to matching up databases and logs by signatures, Exchange 2000 and Exchange 2003 also record a checkpoint value in the database header so that a wrong E00.chk result does not cause you to replay the wrong logs. Additionally, Exchange 2000 and Exchange 2003 include both "before" and "after" dbtime values so that a transaction that is newer cannot be played into the database before any skipped transactions are played.