Exchange Transaction Logs and Checkpoint Files

This topic describes how Microsoft Exchange Server 2010 uses transaction logs and checkpoint files, and how that affects backup applications that use the Windows Server 2008 Volume Shadow Copy Service (VSS).

Transaction Logs and Checkpoint Files

The Exchange store uses write-ahead transaction logs and checkpoint files to help prevent data loss. Transaction logs record all the changes that have been committed to the in-memory database, while checkpoint files record which logged transactions have been written to the on-disk database files.

Exchange 2010 maintains a single set of transaction log files for each database. Exchange 2010 does not include Storage Groups that existed in earlier versions of Exchange. The transaction logs play an important role in backup and recovery operations. It is important that you understand them to correctly implement a backup and recovery application that uses the Windows Volume Shadow Copy Service for Exchange 2010.

Exchange 2010 database transaction logs are stored on disk before the transactions are committed to the database file. In Exchange 2010, a transaction is defined as any whole operation that changes the state or contents of the database.

The transaction log files for an individual database record all the transactions performed on the database. Records of the transactions are written to the transaction logs before they are made in the database itself to ensure that all committed transactions can be recovered in the event of a database failure.

The recording of a log of the transactions before the database is updated is called write-ahead logging. To help ensure that the database is correctly brought back to the proper state, Exchange 2010 writes data into the database files by using page-based writes and checkpoints. During regular operations, the Exchange store first records database changes in the transaction logs, and then makes those changes on an in-memory copy of the database. The transaction logs record the beginning and end of each transaction. This ensures that sufficient information is available to later undo or roll back operations in the database.

When recovering from errors in which the database file on disk is damaged, but the transaction logs are intact, the restore application must first restore a known good copy of the database file from backup media.

The Exchange store first replays the transactions from the previously backed up transaction logs, and then replays any remaining transactions from the on-disk transaction log files. Note that sometimes transactions can be lost if the system fails between when the transactions are recorded in the transaction logs, and when they are actually written to the database files.

Periodically, the Exchange store checks the in-memory database image, and then determines which pages have changed. The Exchange store combines the pending changes, and then writes those pages to the database file on disk.

The checkpoint is advanced when all the database pages that have been modified by entries in the transaction logs are successfully written to disk. Because the checkpoint file records which transactions are already in the on-disk database image, the Exchange store only needs to replay transactions that occurred after the checkpoint. Depending on the time period between backups, this can greatly decrease the number of transactions that must be replayed into the database if a system failure occurs.