File Structure of the Exchange Store

You manage the Exchange store by working with its logical components. However, Exchange Server 2003 actually stores data in a specialized set of data files. Unless you are backing up or restoring data, you will rarely interact with the files directly.

Each storage group corresponds to an instance of the Extensible Storage Engine (ESE). The ESE is a method that defines a low API to the underlying database structures in Exchange Server 2003. On each Exchange server, Exchange Server 2003 creates a data directory for each storage group. Each data directory contains the database files for each of the stores in the storage group and the log files for the storage group. The following figure shows the file structure that corresponds to a specific logical structure as defined in Exchange System Manager.

Logical structure of the storage groups and stores on a single server and the resulting file structure

The storage group files perform the following functions:

• Database files (.edb and .stm)

With Exchange Server 2003, each Exchange Server 2003 database is contained in two linked files—the .edb and the .stm. The .edb file contains folders, tables, and indexes for messaging data and MAPI messages and attachments. The .stm file contains native Internet content. When performing backup and restore procedures, you must always treat these two files as one file.

• Log files (.log and .chk)

Exchange Server 2003 writes each store transaction (such as creating or modifying a message) first to a log file for the appropriate storage group, and then to the store. This approach guarantees that all completed and in-progress transactions are logged, in case of a service interruption. The stores in a storage group share a single set of transaction logs.

Checkpoint files store information that indicates when a transaction is successfully saved to the database files on the hard disk. Exchange Server 2003 uses checkpoint files to allow an instance of ESE to automatically replay log files into an inconsistent database when recovering from a service interruption, starting with the next unwritten transaction.