Microsoft Exchange Server Overview

Exchange Server is a complex beast, to say the least. It's just a fact of life that we can't escape and if one is to work with Exchange it's just best to accept it and move on. As easy as Exchange 2000 is to work with, it's still not the easiest or most pleasurable thing to do on a Saturday afternoon (or any day for that matter). Understanding the underlying processes and construction of Exchange can go a long way towards increasing your happiness factor-which is, after all, the only thing that really matters in life!

The Databases
Everything these days requires a database of some sort. The Internal Revenue Service, Active Directory, even the local supermarket-they all use a database. Databases are great, but they are not always easy to understand. Figure 1 shows an example of what the Exchange Server database looks like.

Figure 1 - The current database (from Chapter 28 of the Exchange 2000 Server Resource Kit).

As you can see from Figure 1, there are actually three files that make up a current Exchange database for a storage group, as explained below.

• The .edb file contains all the folders, tables and indexes for messaging data and MAPI messages and attachments.
• The .stm file (new to Exchange 2000) contains Internet content in its native format.
• The .log files (transaction logs) maintains a record of every message stored in a storage group and provides fault tolerance in the event that a database must be restored. Exchange 2000 log files are always 5MB in size (5,252,880 bytes) and if not, then they are damaged. Each storage group also reserves to log files, Res1.log and Res2.log that are placeholders for extra disk place that can be used if the service runs out of space.

The Checkpoint File
In addition to the files previously mentioned, there is one other file of special note that plays a big role in keeping your Exchange Server database in order. The checkpoint file (edb.chk) tracks which entries in the transaction log files have already been recorded, and thus which ones will need to be replayed during a restoration situation. The checkpoint file thus speeds up recovery by telling the ESE exactly which log file entries need to be replayed and which do not-thus preventing extra writing during the restoration process.

Circular Logging
Typically, when a log file is filled, Exchange renames it and moves on to another, fresh log file. In this way, log files are not erased and thus continue to use space in 5MB increments. As the number of transactions grows, a set of log files is created. If a database fails, the transactions can be recovered by restoring the data from the log files. When circular logging is enabled, the first log file is overwritten and reused after the data that it contains has been written to the database. Circular logging is available to you, but is disabled by default. Should you enable circular logging, you cannot recover anything more recent than the last full backup. For this reason, circular logging is not normally recommended for use in a mission-critical production environment, with the possible exception of the Public folder that will house your NNTP news feeds, where log file sets are not required.

The Checksum
The concept of a checksum is not a new one. Checksums have been used for years to enable determination of file validity. Exchange Server makes use of checksums to verify the validity of the .edb files. Every .edb file is made up 4-KB pages and the integrity of each page is verified through a checksum and a 4-byte page number in the header of the database page. On each page in the database, the first 82 bytes contain the header information, which contains flags for the type of page and information about what kind of data the page contains. When the pages are read out of the database, they are compared for the correct page number and for the checksum. The checksum is calculated to ensure that the page being read is undamaged. If damage is detected, an error is returned, the database is stopped and an event is written in the to the event logs, thus ensuring that the database is operating with optimal integrity.