Chapter 9: Configuring the Information Store

In Exchange Server 2003, the Information Store is the service responsible for storing data in the proper places and maintaining the integrity of that data once stored. Unlike Exchange Server 5.5, which supported only one private storage database and one public storage database per server, Exchange Server 2003 allows for the creation of multiple stores of each type on a server and the grouping of those stores into storage groups. It is these changes to the storage architecture that provide Exchange Server 2003 with much greater scalability and flexibility than previous versions. Also, these changes make new methods of accessing data ‚ such as from standard Windows applications ‚ possible.

This chapter provides a brief overview of how storage groups and stores interact and what you can do with them. It then looks at the creation, configuration, and management of both storage groups and stores. Finally, it examines a form of content indexing known as full-text indexing, which Exchange uses to provide greater search capabilities within the Information Store.

Overview of Storage Groups and Stores

Exchange Server 2003 Enterprise Edition supports up to four storage groups on a server and up to five stores in each storage group , providing great flexibility in the storage design and planning. Before we get started with the actual process of creating and managing storage groups and stores, though, it is important to become familiar with the major components in the Exchange storage system and the method Exchange uses to store data.

Note ‚  

This chapter deals mainly with the procedures for creating and managing storage groups and stores. Although this overview provides a brief look at how Exchange storage works, it is also important that you are familiar with the architectural concepts discussed in the ‚“Information Storage ‚½ section of Chapter 2, ‚“Microsoft Exchange Architecture. ‚½

Main Storage Components

The Information Store is a Windows service that provides storage management on an Exchange Server 2003 server. It is an actual process, named Store.exe , that runs on the server. The Information Store is responsible for making sure that data is placed into transaction logs, that transaction log entries are committed to actual Exchange database files, and that routing maintenance is performed on those files.

A store is a logical database that is actually made up of two database files: a rich-text file (*.edb) and a streaming media file (*.stm). You learned about these files in Chapter 2, so we won ‚ t go into too much detail about them here; in short, the rich-text file is used for holding standard Exchange content (such as messages), and the streaming media file is used for holding other types of content in its native format so that Exchange does not have to spend time converting it.

There are two types of stores that you can create on an Exchange server: public and private. Public stores are used to hold public folders that are generally accessible by multiple users. Private stores are used to hold mailboxes that are normally accessible only by a specified user . Unlike previous versions of Exchange, Exchange Server 2003 allows you to create multiple stores of each type on a single server.

This ability to create multiple stores leads to several benefits:

• User downtime in the event of a failure is decreased because a failure in one store does not affect users of another store.

• Backup and restore routines are typically faster and more flexible because you can back up or restore a single store at a time without affecting other stores. For example, backing up one out of four 10-GB stores at different times of the day is often better than backing up a single 40-GB store.

• You can assign different general settings to different stores. For example, you might configure one private store for general use and another for use only by executives. The general store might have certain limitations placed on it that the executive store would not.

  Note ‚  

  Exchange Server 2003 Enterprise Edition supports multiple mailbox stores and multiple private stores on a single server. Exchange Server 2003 Standard Edition supports only two databases in a single storage group. In addition, the single mailbox store allowed in the Standard edition is limited to 16 GB in size, while the Enterprise edition allows mailbox stores of any size .

A storage group is a logical grouping of stores that share the same set of transaction log files, as shown in Figure 9.1. You can create up to four storage groups on a single server, and each storage group can hold up to five stores. The primary reason behind the use of storage groups is to reduce the amount of server overhead that would be caused if every store had its own set of transaction logs, resulting in greater scalability. There are some additional advantages to using multiple storage groups:

• You can manage the stores in a storage group as a group or individually.

• You can configure different properties for the transaction logs of different groups. For example, suppose you have one storage group that contains only public folders that would not be impacted too much by the use of circular logging. You could then configure another storage group to hold more critical mailbox stores for which circular logging would be disabled.

  
  Figure 9.1: Storage groups hold stores that share a single set of transaction logs.

Exchange Storage Methods

When data is to be written to one of the Exchange databases, the database engine does not write the data to the database file immediately. The data is first committed (or written) to a transaction log file and then later committed to the database through a background process. This method has two advantages, one of which is performance. When data is written to a transaction log file, it is entered sequentially, always at the end of the file. This can be done very fast. When data is committed to a database file, however, the database engine must search for the appropriate location to place the data. This is much slower than the simple sequential method. The second advantage is fault tolerance. If a database file becomes corrupt, a transaction log file can be used to re-create the database file.

As transactions in transaction log files are committed to the database files, a checkpoint file (EDB.CHK) is updated. The checkpoint file keeps track of which transactions in the sequential list still need to be committed to a database by maintaining a pointer to the last information that was committed. This tells the engine that everything after that point still needs to be committed to a database. If a server shuts down abnormally, Exchange can read the checkpoint file to learn where in the transaction logs it needs to start recovering data. Thus the checkpoint file assists in the fault tolerance of Exchange.

Transaction log files can contain up to 5 MB of transactions, and they are always 5 MB in size no matter how many transactions they contain. This is because the engine creates them as 5 MB files and then proceeds to fill them with transactions. The current log file being written to is named EDB.LOG. When it is filled with 5 MB of transactions, it is renamed to EDB nnnnn . LOG (where nnnnn is a hexadecimal number), and a new, empty EDB.LOG file is created. Therefore, the log files will accumulate on the hard disk. A way to minimize this is to perform regular full or incremental backups of the databases. During a full or incremental backup, fully committed log files are automatically flushed (deleted) because the data in them is backed up. This prevents the number of log files from growing until they take up the entire disk.

Circular Logging

Transaction log files can also be configured to recycle themselves to prevent constant accumulation on the hard disk. This process is called circular logging . Instead of continually creating new log files and storing the old ones, the database engine ‚“circles back ‚½ to the oldest log file that has been fully committed and overwrites that file. Circular logging minimizes the number of transaction log files on the disk at any given time. The downside is that these logs cannot be used to re-create a database, because the logs do not have a complete set of data. They have only the data not yet committed. Another disadvantage of circular logging is that it does not permit a differential or incremental backup of the databases.

Circular logging is disabled by default and can be enabled or disabled on a store ‚ s General property page (discussed later in the chapter). Table 9.1 presents a summary and comparison of when circular logging is enabled and disabled.

Reserve Log Files

One other feature of the transaction-based databases is the use of reserve log files . Exchange creates two reserve log files (RES1.LOG and RES2.LOG) for each database. They are used if the system runs out of disk space. If that happens, Exchange shuts down the database service, logs an event to the Event Log, and writes any outstanding transaction information into these reserve log files. These two files reserve an area of disk space that can be used after the rest of the disk space is used.

Table 9.1: Circular Logging Enabled vs. Disabled

Circular Logging Enabled	Circular Logging Disabled (default)
Transaction log files are recycled.	Old transaction log files are stored.
The re-creation of a database is not permitted.	The re-creation of a database is permitted.
Differential or incremental backups are not permitted.	Differential and incremental backups are permitted. A full or incremental backup automatically deletes old transaction log files.