Although transparent to the end user, Microsoft Exchange Server maintains several database files or stores. The information store consists of two databases: the private information store (Priv.edb) and public information store (Pub.edb). The Microsoft Exchange Server directory is stored in the Dir.edb file. The respective Microsoft Exchange Server services use transaction log files for each of these databases. The information store service manages both the public and private information store databases.
Microsoft Exchange Server implements log files to accept, track, and maintain data. All message transactions are written first to log files and memory, and then to their respective database files. This is done to optimize performance and recoverability.
Because log files are written to sequentially and Microsoft Exchange Server writes message transactions to log files immediately, Microsoft Exchange Clients experience a high level of performance. Log files are always appended to the end of the file. However, Microsoft Exchange Server database files are written to randomly.
To optimize recoverability, log files can be used to recover message transaction data if a hardware failure corrupts the information store or directory database files, provided you have backed up the logs or the logs are intact. Log files are typically maintained on a separate physical disk drive from the information store and directory database files.
If database files are damaged, a backup can be restored and any data that has not been backed up but has been recorded in the transaction logs, can be played back. These transactions are entered into the restored database file to bring the database up-to-date.
The directory and information store services use the following logs and files:
Transaction logs can be kept on a separate physical drive from that of their respective .edb files. By default, information store logs are maintained in the Exchsrvr\Mdbdata directory and directory service logs are maintained in Exchsrvr\Dsadata.
Each subdirectory contains an Edb.log file, which is the current transaction log file for the respective service. Both the information store subdirectory and the directory service subdirectories maintain a separate Edb.log file. Log files should always be 5,242,880 bytes in size. If log files are not this size, they are probably damaged.
Because transactions are first written to the Edb.log files and then written to the database, the current actual or effective database is a combination of the uncommitted transactions in the transaction log file, which also reside in memory, and the actual .edb database file.
When the Edb.log files are filled with transaction data, they are renamed and a new Edb.log file is created. Note that .log files are always 5 MB, regardless of how many transactions have been recorded in them.
When an Edb.log is renamed, the renamed log files are stored in the same subdirectory as the Edb.log file. The log files are named in a sequential numbering order (for example, Edb00014.log, Edb00015.log, and so on). Note that hexadecimal numbers are used.
Previously committed log files are purged by the Windows NT Ntbackup.exe program during an online normal (full) backup or an online incremental backup. However, not all previous log files are purged. After every 5 MB of transactions are written, a new log is created, but not necessarily committed. There may be several previous .log files that aren't committed that will not be purged.
When circular logging is enabled, a history of previous .log files is not maintained and therefore these .log files are not purged by backup operations. In fact, incremental and differential online backups are not permitted when circular logging is enabled. Note that transactions in log files are committed to the respective .edb file when the service is shut down normally. For example, when the information store service experiences a normal shutdown (that is, the service shuts down with no errors), any transactions that existed in log files and not in Priv.Edb and/or Pub.Edb files are committed to the .edb files. Note that .log files should not be manually purged while services are running. In general, it is best to purge logs by using the backup process.
Checkpoint files are used for recovering data from transaction logs into .edb files. The checkpoint is the place marker within the Edb.chk file that indicates which transactions have been committed. Separate Edb.chk files are maintained by the information store and directory services. Whenever data is written to an .edb file from the transaction log, the Edb.chk file is updated with information specifying that the transaction was successfully committed to the respective .edb file.
During the data recovery process, Microsoft Exchange Server determines which transactions have not yet been committed to the respective .edb file by reading the Edb.chk file or by reading the transaction log files directly. Note that the Edb.chk file is not required.
The information store and directory service each reads its Edb.chk file during startup. Any transactions that have not been committed are restored into the .edb files from transaction logs. For example, if a Microsoft Exchange Server computer experiences an outage, and transactions have been recorded into the transaction log but not yet to the actual database file, Microsoft Exchange Server attempts to recover this data on startup by recording transactions from the logs to the respective database files automatically.
The directory and information store services independently maintain two reserve files: Res1.log and Res2.log. These files are stored in the Mdbdata and Dsadata directories. If the directory and/or information store service is renaming the Edb.log file and attempting to create a new Edb.log file, and there is not enough disk space to create a new Edb.log file, the reserve log files are used. This is a fail-safe mechanism that is only used in the event of an emergency. When this occurs, an error message is sent to the respective service. The service will flush any transactions in memory that have not yet been written to a transaction log into the Res1.log file, and if necessary, the Res2.log file. When this is completed, the service shuts down and records an event in the Windows NT EventLog. Note that RES (reserve) transaction log files are always 5 MB in size, the same as all transaction log files.
The patch file mechanism was designed for the situation where transactions are written to a database during the backup process. A convenient feature of Microsoft Exchange Server is the ability to back up databases without interrupting service to end users. During the backup operation, data is read from the .edb files.
If a transaction is made to a section of the .edb file that has already been backed up, it is recorded in a .pat (patch) file. If a transaction is made to a section of the .edb file that has not yet been backed up, it is processed and does not need to be written to the patch file. A separate .pat file is used for each database: Priv.pat, Pub.pat, and Dir.pat. Note that these .pat files will only be exposed during the backup process. During an online backup operation, the following occurs:
A .pat file is created for the current database.
The backup operation for the current .edb file begins.
Transactions that must be written to sections of the .edb file that have already been backed up are recorded to the .edb file and the .pat file.
The .pat file is written to the backup tape.
The .pat file is deleted from the Mdbdata or Dsadata directory.
The Temp.edb file is used to store transactions that are in progress. Temp.Edb is also used for some transient storage during online compaction.