Topic Last Modified: 2005-11-18

The Microsoft® Exchange Server Analyzer Tool has determined that the log signature in one or more of your log files does not match other log files in the same folder.

This problem does not occur unless log files have been manually moved, deleted or disarranged.

Each Exchange transaction log file is stamped with a signature called a Log Signature. This signature identifies individual log files that belong to the same series of logs. Each Exchange database records the Log Signature of the transaction log series to which the database was last attached.

Exchange databases also have a signature called a DB Signature. The DB Signature is generated when a database is first created. If you use Eseutil to defragment or repair a database, this signature will change because the repair and defragmentation processes make changes to the database files without logging those changes to the transaction logs. For logging purposes, the database that results from a repair or defragmentation operation is a new or different database.

Unlike DB Signatures, Log Signatures never change during the lifetime of a series of log files.

Log files record the DB Signatures of all databases attached as the log is created. Databases record the Log Signature of the most recent log series to which the database has been attached. Therefore, DB and Log Signatures are useful to match databases with transaction log files.

You can detach an Exchange database from one set of logs and attach it to another. You can do this by moving the database to a different storage group or by removing all the transaction logs for a storage group and starting a new series of logs.

If a database is in a Dirty Shutdown state, only transaction log files that have signatures matching the Log Signature in the database header can be replayed into the database successfully. In a Dirty Shutdown state, a database is still attached to a particular log stream and can only perform recovery with that log stream.

If a database is in a Clean Shutdown state, you may be able to play transaction log files that do not have signatures matching the current Log Signature in the database header. This will succeed only in the following circumstance:

1. The database was shut down correctly at the end of a previous sequence of log files.
   
   
2. The database was then attached to a new sequence of transaction log files and you have access to the transaction log in which the database was first attached to the new set of logs.
   
   

To correct this error

• You must know the history of the database and under what circumstances the transaction logs were generated with regard to the database.

• In this situation, before you attempt recovery, always make a copy of both the transaction logs and the database files. A mistaken recovery attempt may change transaction log or database files in such a way that another recovery attempt may be unachievable.

• Replay only one set of transaction logs at a time with the database. Move other transaction logs out of the recovery folder.

• If the database is in Dirty Shutdown state, you must first successfully replay the transaction logs to which the database is attached and bring the database to a Clean Shutdown state. Then you may be able to play the second set of log files with the database.

• If the database is in a Clean Shutdown state, you cannot examine the logs or the database to conclusively verify which set of transaction logs is the right one to replay first.

© 2009 Microsoft Corporation. All rights reserved.