| Legal Information |
|
The .edb and .stm files are the final repositories for all database information. For most purposes, treat these two files as if they are a single file; back up and restore these files in tandem. These files must stay synchronized chronologically with each other; an .edb file that is backed up on one day cannot be matched with a streaming file that is backed up on another day.
An Exchange 2000 or an Exchange 2003 server can support up to four storage groups, and each storage group can support up to five databases. A storage group is a set of databases that share a common set of transaction log files. Microsoft Exchange Server 5.5 can support a maximum of one storage group, which supports up to two databases (the private and public information stores).
As changes are made to the database, the changes are first written to the current transaction log file, and then to an in-memory cache. As soon as changes are present in the cache, those changes become visible to users. Pages in the cache are flushed to the database file when it is convenient to do so. The checkpoint marks the point in the log file sequence up to which all transactions have been physically flushed to the database file. It is normal for the checkpoint to lag three or more log files behind the current log file.
To avoid confusion about which log files belong to each storage group, Exchange logs that belong to a given storage group are named with a unique log prefix, which is the first three characters of the file name. Valid log prefixes for the four storage groups that are supported on an Exchange 2000 or Exchange 2003 server are E00, E01, E02, and E03. Throughout this article, the log prefix for a storage group is designated as E0n. The current log file for a storage group is always E0n.log.
Transaction logs are a uniform 5 megabytes (MBs) in size. When the current log file is full, it is renamed with a hexadecimal sequence number, called the log generation number, and a new current log file is generated. Log files are numbered as E0n00001.log, E0n00002.log, and so on. Throughout this article, numbered log files are designated generically as E0nxxxxx.log.
If a database is stopped abnormally, the checkpoint file (E0n.chk) records the transaction log from which recovery must begin replay to restore the database to consistency. This process is called "soft recovery."
Soft recovery can be contrasted with "hard recovery," which is the process by which log files are replayed after the restoration of an online backup. The most important difference between soft and hard recovery is the interpolation of patch file data into the log file replay process during hard recovery.
An inconsistent Exchange database file is a file that all of the outstanding transactions have not been written to yet. During normal operation, Exchange database files are inconsistent because there is information in the cache that has not yet been physically written to the file. In general, an Exchange database file can be considered consistent only after a normal shutdown of the database service.
Nonetheless, the database, taken as a whole (considered as the sum of the information in both the transaction logs and database files), is always consistent unless necessary log files are prematurely deleted.
The information in this article applies to:
| Search Knowledge Base | Feedback |