For each storage group (SG), the Extensible Storage Engine (ESE) maintains a checkpoint file (e.g., e00.chk) that notes the current log-file position for the databases in that SG. The checkpoint file plays a primary role during a soft recovery, which occurs after a database closes down because of some system failure that doesn't corrupt the database. However, ESE doesn't write checkpoint files to backup because the files serve no purpose during a hard recovery, which restores databases and transaction logs to different locations; the ESE instance that controls a hard recovery uses the log information in the database header to determine which logs to replay.
During backups, ESE streams pages from the databases to the backup media. Because users continue to create and send messages during an online backup, transactions can occur in pages that already are committed to the database. The logs capture these transactions, however, so they affect the backup only when ESE can't fit all the data for a transaction into one page, resulting in a page split. (Message headers that contain more than approximately 20 recipients often need two or three 4KB pages to accommodate all the header information.) In Exchange Server versions earlier than Exchange 2000 Server Service Pack 2 (SP2), the ESE maintains a patch file (e.g., priv1.pat) for each database. When a page split occurs during a backup, ESE notes details of the page in the patch file. Patch files apply only to operations in the .edb files; changes made to .stm files don't cause page splits, so the data that ESE writes into the set of transaction logs is enough to ensure that ESE can reapply any changes. To make patch files available in a restore situation, ESE writes the files to the backup media at the end of the backup. The first step in a restore is to apply the changes noted in the patch file to the database to make the database consistent before rolling forward the transactions in the logs. All these processes happen automatically; administrators need do nothing to apply the contents of the patch files. However, Microsoft decided to eliminate patch files in Exchange 2000 SP2 and later and instead perform fix-up processing with the database restore code. This change simplifies restore operations.
