Log Signature Issue

[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at https://go.microsoft.com/fwlink/?linkid=34707.]  

Topic Last Modified: 2006-07-07

The Microsoft® Exchange Server Analyzer Tool compares the signature in the header of the current Exchange transaction log file on a server against the log signature in the storage group database file.

If the signature of the transaction log file does not match the log signature in any of the database files, the Exchange Server Analyzer displays an error.

This error indicates that one of the following conditions is true:

  • The current transaction log file does not exist.

  • The current transaction log file does not match one of the databases in the storage group.

This behavior may occur for the following reasons:

  • The transaction logs for the storage group have been manually deleted.

  • A database from another storage group has been restored or copied into this storage group.

  • Transaction log files from a different sequence or storage group have been copied into this storage group.

Whether this condition will prevent a database from mounting depends on whether a database file is in a Clean Shutdown or Dirty Shutdown state.

Note

A database may be in a Clean Shutdown state, but still be unable to mount because other databases in the storage group are unmountable. Use the Exchange Server Disaster Recovery Analyzer to diagnose and advise you about how you can mount the databases in these cases.

When an Exchange database shuts down correctly, all outstanding data is written to the database files. After ordinary shutdown, the database file set (.edb and .stm extensions) is considered consistent. Exchange then detaches the database file set from its log stream. This means that the database files are now self-contained, that is, they are completely up-to-date. The previous transaction logs are not required to start the database files.

Databases in a Clean Shutdown state have been detached from their log files and may be attached to a different log stream. Therefore, the mismatch between the log files and the database is not necessarily a problem.

Databases in a Dirty Shutdown state have been incorrectly detached from their log files. These databases must be recovered with their attached log files. If the attached log files cannot be located, the database cannot be mounted. You must restore from backup or repair the database before it will be mountable.

You can tell whether a database has been shut down cleanly if you enter the Eseutil /mh command and examine the file headers. In Microsoft Exchange 2000 Service Pack 1 and later versions, a line in the header reads either "State: Clean Shutdown" or "State: Dirty Shutdown." In earlier versions of Exchange, the same state is reported as "State: Consistent" or "State: Inconsistent."

For more information about Exchange Server transaction logging, see "Exchange Transaction Logging in Exchange Server 2003" in Using Recovery Storage Groups in Exchange Server 2003 (https://go.microsoft.com/fwlink/?LinkId=47589).