Soft and Hard Database Recoveries
The Extensible Storage Engine (ESE), Exchange Server 5.5's database engine, performs a soft recovery each time the IS or Directory starts. Exchange Server maintains a checkpoint file (edb.chk) for each store. When the IS or Directory starts, Exchange Server reads the database's checkpoint file and determines whether it must commit any transactions in the store's log files to the database. Exchange Server replays these transactions, and the store completes its startup.
Automatically checking for transactions that the database is missing ensures that when the stores start, they are identical to the log files. Screen 3, page 123, shows the application log's record of Exchange Server replaying the contents of the edb007b1.log file to the IS. The time that replaying a transaction log requires varies from server to server and depends on CPU speed, disk I/O subsystem capacity, and the server's current workload. On small Pentium systems, Exchange Server processes log files in 15 seconds or less.
You use the IS's or Directory's transaction logs for a hard recovery after Exchange Server restores a database from a backup tape. Consider this scenario: You experience a disk failure or the IS reports Jet page errors. You decide to restore the database from a backup tape. After you restore the database, you discover that the database is missing transactions; those transactions are available in the logs. If you restore the logs Exchange Server created after the backup finished and make them available before the IS restarts, you will force Exchange Server to replay the transactions. Exchange Server will access each transaction log, verify whether the log contains data that Exchange Server needs to replay, and update the database. Exchange Server must have all the transaction logs for this process to complete successfully. An individual transaction might span two or more logs. For example, a message with a 12MB attachment extends across three logs. If one of the three logs is missing, part of the transaction won't be available. If Exchange Server encounters a missing log during replay operations, Exchange Server stops applying transactions, and you lose data.
Transaction logs are important. You must protect these logs in much the same way you protect the IS and Directory. Only foolhardy administrators ignore the finer details of transaction log management—the contents of these logs might save them one day. A hardware failure that reduces a database to a collection of useless bytes is horrible, but if the transaction logs that contain your data no longer exist, that hardware failure becomes much more serious.
Corrections to this Article:
- "Exchange Server Transaction Logs" incorrectly stated that the Eseutil tool is in the \exchsrv\bin directory. For Exchange Server 5.5 and later versions, you find this utility in the \windows\system32 directory.