Check Transaction Log and Torn Writes by Help of ESEUTIL

MS Exchange Server, the mail server application, maintains the record of actions executed by the database software in transaction log files. Transaction files help in ensuring the atomicity and durability of the database. When a database shuts down abnormally, a check is done in the transaction log files to see for pending or unexecuted database queries.

If there is any pending query it is executed again; partially committed queries are aborted. In some circumstances, the transaction log file itself becomes corrupt. In this situation Exchange database reports as damaged and inaccessible.

ESEUTIL utility provided in MS Exchange can be used to check integrity of transaction log files. To test a log file for corruption, run command: ESEUTIL /ml <transc_log_file_name>.Run ESEUTIL /ml E<nn> command to check all transaction log files. All the transaction log files with prefix <nn> are checked.

ESEUTIL utility can also test torn write transactions (transactions that are in repairable condition) in E00.log file.

Understanding Torn writes and E00.log File

‘Torn write’ can be defined as a write operation that is partially left in the E00.log file. There can be several reasons for torn write- power failure, system crash, End Process or KILL command on database. In torn write checking process, the Exchange verifies the log file to see if the database damage was due to torn write or something else. Exchange repairs the E00.log file when restarted, if torn write is detected. Other types of damages are not repaired by MS Exchange.

If the corruption is due to some hardware failure, the damaged data can not be reconstructed and hence cannot be repaired. Only E00.log files store torn writes because they are the current log files in all the database transactions.

If there is some other issue other than torn write in the log file, it is not repaired and error message is displayed. In such a case, you can use a working backup copy of the damaged log file or reject the damaged log file and all the log files that were created after the damaged log file. After this, restore the Exchange server from a working backup. All the data saved after the log file is lost from the recovered exchange.

You can also try hard recovery of Exchange server if you don’t have a backup file ready with you. Before hard recovery it is advisable to take a whole backup of exchange server. To perform hard repair, run ESEUTIL /p command. Data loss is eminent after hard repair of exchange database.

Checksum calculation method used for error detection in log files in Exchange Server versions earlier than 2000 was not trustworthy. If at any instance, the log files became damaged, there was no way to find the damage but replay of the damage into the database files was possible. Log file corruption was not a common event before Exchange 2000. And if any how they got damaged, their recovery was very difficult. This was because there was no method like ESEUTIL/mh, to determine that a log file or database has got damaged.

Only a database crash can tell that there is damage in the database. When ever the Exchange database got damaged, full recovery had to be done to restore the database to working state. Microsoft improved Exchange 2000 and later versions in respect of error detection. In Exchange 2000 and later versions you can not replay a damaged or erroneous log file into a database. Exchange server 2003 does a match of databases and logs by their signatures.

It also records a checkpoint value in the database header. Like this, E00.chk result prevents you from replaying the wrong transaction log files. Before and after ‘dbtime’ values is included in Exchange 2000 and Exchange 2003. This prevents transaction that is newer than any skipped transaction to get played into the database.

If the above solution does not solve your problem, you can try third party software to repair Exchange Server.