Article ID: 248122 - View products that this article applies to.
This article was previously published under Q248122
In Microsoft Exchange 2000 Server and in Microsoft Exchange Server 2003, you can use the /ml option of the Eseutil utility to test the transaction integrity of transaction log files.
This test also detects "torn writes" in the E00.log file. A torn write is a repairable condition. Therefore, if the E00.log file fails the test, do not assume that you must discard the file.
To test a log file for suspected damage, run the following command:
eseutil /ml Log File NameFor example, to test a log file that is named E00123ab.log, type:
eseutil /ml e00123ab.logIf the log file passes the test, the following response appears: If the log file fails the test, the following response appears: 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 EnnIn 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.logA 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
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.
Article ID: 248122 - Last Review: October 25, 2007 - Revision: 2.3
Contact us for more help
Connect with Answer Desk for expert help.