Cross-Matching Exchange Databases and Log Files in Exchange Server 2003
The previous sections emphasize that you need to gather all the needed log files—and only the needed log files—for transaction log replay. This section explains how to determine which files belong together.
The procedures described here need not be done every time you run recovery. In typical restore and recovery scenarios, all log files are present. But in complicated recovery scenarios in which you have manually moved log files or databases from one location to another, you can use the following procedures to ensure that you have matched logs and databases correctly.
The key to matching log files and databases is the signature. You can view log file signatures by using the Exchange Server Database Utilities (Eseutil.exe) tool and viewing the log file header with the command Eseutil /ml [log filename]. You can view database (.edb) and streaming database (.stm) file signatures by viewing the file header with Eseutil /mh [database filename].edb.
A typical log file or database file signature looks like this:
Signature: Create time:12/17/2002 18:1:44 Rand:81060559 Computer:
When Microsoft® Exchange Server 2003 creates a new log file series (starting with log file number 1), it generates a new signature. All subsequent log files in the series will have the same signature as the first log file. With this signature, you can identify immediately whether two log files belong to the same series. The signature never changes unless you delete all the log files, and start again with log file number 1.
When a new database file set is created (.edb and .stm files), Exchange again generates a new signature. This signature is not the same as the log file signature. Both the .edb and the .stm files share the same signature.
When you mount a database, thereby attaching it to a particular log stream, Exchange writes the database signature into the log file and the log file signature into the database header. You can disconnect from a database, thus detaching it from the log stream, and mount it on a different server or in a different storage group. The next time the current log fills and a new one is generated, however, the detached database will not appear in the new log file's header. The database header instead reflects the signature of the log stream to which it is now attached.
Note
When a new series of logs is created, log Enn000001.log does not list any database signatures in its header. Enn000002.log is the first log to list databases in the header. When a database is attached to an existing log file, Exchange does not write the database signature to the log file header, but lists it in an attach record in the middle of the log file. Exchange generates a log file header at the moment a log file is created, and never updates it after that. A newly attached database appears in the header of the next log file because Exchange records in the log header only signatures of databases attached at the moment a new log is created.
A single stream of log files may have multiple databases attached to it at various times. The log signature stays constant regardless of how many databases are attached to the series of logs. Typically, Exchange interleaves operations bound for multiple databases within a given transaction log file. During log file replay, each database applies only the transactions applicable to itself.
Unlike a log signature, database signatures can change over the lifetime of the database. A database's signature changes if the database is repaired (Eseutil /p) or if an offline defragmentation (Eseutil /d) is performed. The signature is deliberately changed after these operations to prevent replay of log files associated with the old database signature. As far as log file replay is concerned, repairing or defragmenting a database with Eseutil.exe results in a different database than existed before the operation.
Suppose now that you have a database and a set of log files. To find out if these logs are associated with this database:
Examine the database header with Eseutil /mh, paying particular attention to these three lines:
DB Signature
Log Signature
Log Required
Use the information you found in Step 1 to determine which log file is most likely the first one needed for replay. If you cannot find a matching numbered log file, check the lGeneration value of the Enn.log file to discover if it is a match.
Match the signature of this log file against the Log Signature value from the database header. If it is a match, it is likely that this is the log file needed. (This is not a completely reliable test, but it is almost always valid. If an administrator were to mount multiple copies of log files and databases against each other, and then mix the file sets in the right way, a log file that was not a match but that passed the tests could be generated.)
Verify that subsequent available logs all belong to the same series. Use the command Eseutil /ml Enn to scan the current folder for all log files whose names begin with Enn and report damaged logs, creation time/prev gen time mismatches, and missing log files.
Another way to do this is to examine each log header and verify that all signatures match in all logs, that the lGeneration values inside the log headers are in unbroken sequence, and that the Creation Time value in each header matches the Prev Gen Time for each subsequent log.