3.2 Exchange s storage workhorse - the store

3.2 Exchange’s storage workhorse—the store

At the core of every Exchange server lies the Information Store. Implemented in a single process (STORE.EXE), the Exchange Information Store is actually two key components that provide data storage. These two components can be broken apart by their function. The information store layer provides storage semantics to clients, and the database engine (ESE) provides the underlying transacted storage mechanism.

3.2.1 The information store layer

It would be very difficult for MAPI and other Exchange clients to understand low-level database structures such as records, indexes, tables, and pages. This would require the clients themselves to abstract what the user sees to what the database stores, and it would prevent Microsoft from changing the physical layout of the database to improve efficiency, performance, and security. Fortunately, Exchange Server provides this abstraction layer at the server. What Microsoft refers to as the “store” is really an abstraction layer built on top of a database engine. The store is a layer that abstracts raw physical database structures to structures such as messages, folders, tables, attachments, and so forth that clients utilize. Figure 3.4 illustrates how various database tables and subtables provide users with a view of an inbox, messages, folders, and attachments. As Figure 3.4 shows, there is a Folders table that has one row for each folder in the information store. Note that since the private and public information stores are separate databases, data is not shared or intermingled between the two. Next, there is one Message table with a message body for each message in the database. Since Exchange Server supports a feature called single-instance storage, each message residing in multiple user mailboxes is only stored in the Message table one time. In other words, no matter how many users to whom you send a message on an individual information store database, there will be only one copy of the message stored. The advantages of single-instance storage are obvious and result in substantial opportunities for reduced storage requirements when compared to some other messaging systems in which a copy of a message is stored for every recipient to which it is sent. The Message-Folder table is a structure that exists for every folder in the information store that maintains a sort order and holds a row for every message that resides in the folder. The database engine creates dynamic indexes against this table when users change their view to a folder. The Message-Folder table does not actually store the message since all messages are already stored in the Message table. The Message Folder table simply uses the message ID as a pointer (or key) to the Message table. Related is another fundamental and logical information store structure—the Attachments table. The Attachments table, as the name implies, holds all message attachments. Once again, with the single instance storage feature, each attachment is only stored once per database regardless of how many recipients have the attachment as part of their mailbox. In the case of attachments, even greater advantages can be seen for single instance storage. At least you can rest in the knowledge that the 20-MB PowerPoint presentation that your boss sent to his entire team is only stored once per database. There are other important tables that are part of the information store that are more database management related. These include Search tables (created by advanced finds initiated by clients) and Categorization tables (which keep track of views and which items are open and closed). Perhaps the most important table in the database is the Globals table that is a database wide table storing important information about the database itself such as version and database Globally Unique Identifier (GUID).

Figure 3.4: Exchange database logical view.

The trick with all of the various tables that make up the Exchange information store database is to organize these structures into something usable to even the most novice user and to present it all as a mailbox and folder view. This is accomplished in a high-speed and optimal manner through the use of views and indexes. Views allow you to change the way you look at different folders in your mailbox on the Exchange Server. Views are created and built on the fly based on the user’s needs. For example, if I want to see all the messages in my inbox by sender (FROM:) in alphabetical order, the operation is simple. Under the covers, however, Exchange Server is creating or, most of the time, reusing a specific view to allow me to see my messages this way, and it does so in a very optimal fashion that has minimal resource impact on the server. Indexes allow the entire information store database to be quickly and efficiently navigated. Indexes are also updated and created dynamically within the information store. For example, since my inbox is actually made up of several different tables, as I discussed earlier, Exchange server needs to quickly respond to my requests when I am manipulating messages within my inbox. When I double-click on a message, the server must pull together the message header, body, and any attachments and send them to my client (in my case, Outlook) for presentation. If the message has an attachment, Exchange Server must quickly find that attachment in the Attachment table when I need it. Indexes allow this to happen in the most efficient manner.

Let’s look at two examples of common client tasks that the Exchange Server information store must perform and the individual actions that occur in the background. Two common tasks are receiving a message and moving a message. Figures 3.5 and 3.6 illustrate the steps taken for each of these tasks by the Exchange Server Store process and underlying database engine.

Figure 3.5: Message receive actions for Exchange Server Store.

Figure 3.6: Message move actions for Exchange Server Store.