Maintaining Exchange's Information Store

Last month I began a two-part introduction to the Microsoft Exchange Information Store. The Information Store comprises the private information database (the private store) and public information database (the public store) in Exchange. I discussed the Information Store databases' internal structure, how they process transactions, and what happens when they experience problems. This month I'll show how you can maintain the Information Store to optimize performance and resilience, two requirements of a database application in a production environment. Specifically, I'll show you how to protect, maintain, compress, and repair the Information Store. Then I'll describe how you can optimize the Information Store's unique dynamic buffer allocation and deleted items recovery features.

Protecting Exchange Databases
Installing the best possible I/O subsystem and then maintaining it properly is fundamental to success with Exchange. The situation is simple: Either you think the Exchange databases are important and take every step to protect them, or you don't. Systems that are well configured and managed experience fewer problems than systems that are poorly configured and managed.

I've never encountered a situation in which a software bug has corrupted the Information Store. I'm not saying the Exchange Server software is perfect. I am saying that hardware problems cause most database corruption. The most common hardware problems causing database corruption are hard disk failures and controller failures. You can take the following actions to prevent hardware problems and safeguard your Exchange databases.

Perform a backup every day. Back up daily, and if possible, make your daily backup a full backup. Full backups will make any restore operations you perform much easier.

Isolate transaction logs from databases. Never keep the Information Store's database transaction logs on the same hard disk that houses the databases. Go further and use separate controllers for the hard disks on which you keep Exchange transaction logs and databases. As I emphasized last month, the Information Store's transaction logs are as important as the databases.

Use RAID data storage. Protect Exchange databases by placing them on a RAID-5 volume with a controller that supports hot-swappable disks, battery backup, and mirroring for write-ahead cache. Safeguard this configuration with a UPS. RAID0+1 is an effective alternative to RAID-5 that delivers better I/O throughput for any given disk configuration. However, there is a cost to using RAID0+1: reduced storage capacity.

Review event logs regularly. Review event logs for database problems every day. Check for disk outages during each daily review.

Practice regular maintenance. Understand and use Exchange's maintenance tools. Schedule time for regular maintenance operations.

Shut down correctly. Never power down a server without first cleanly shutting down the information store service. A graceful shutdown ensures that Exchange can write transactions in the log files to the appropriate .edb file, thereby keeping all databases current. The power-off button is for emergencies only and is not the best or the fastest way to close down a server.

Information Store Online Maintenance
Microsoft designed Exchange Server for continuous operation: You can keep the Information Store running, with users connected as you perform backups and maintenance operations. Exchange's online maintenance feature performs background database housekeeping chores that are vital to the smooth and efficient operation of the Information Store. Microsoft put considerable effort into improving online maintenance in Exchange 5.5. For example, online maintenance in Exchange 5.5 does a better job of defragmenting internal database structures than earlier versions did.

The time at which Exchange performs online maintenance is a server property. Systems administrators usually schedule online maintenance to occur when the load on a server is relatively light, as Screen 1 shows. You can schedule online maintenance so that it's active around the clock, but doing so will tie up some system resources that otherwise could be devoted to users.

The variable and unpredictable nature of messaging transactions in Exchange presents a challenge to online maintenance. Exchange messaging is an unusual database application compared to the uniform transactions of, for example, a traditional financial database. Messages in Exchange come in all shapes and sizes, with and without attachments, and with large and small distribution lists. In addition, when messages arrive in a user's mailbox, they are often quickly deleted. During online maintenance, a number of background threads walk through the leaf nodes of the binary tree within the Information Store, comparing adjacent data pages in order to fill the pages completely. The frequent user deletions that characterize Exchange transactions make filling data pages a difficult task.

To fill data pages, Exchange's online maintenance continually shuffles data from one page to another. To understand how Exchange fills data pages, consider message headers. One message header contains about 400 bytes, and online maintenance can store about 10 headers on one data page. Exchange performs best when it views folders in chronological order, so online maintenance stores message headers close to one another on data pages and in chronological order. As new messages arrive in the database, Exchange inserts the message headers at the end of the binary tree. However, users continually delete items throughout the tree. Over time, user deletions cause data pages to become less full, and if online maintenance lets these deletions continue without adjusting data pages, Exchange performance will steadily degrade. Therefore, online maintenance continually moves headers between adjacent data pages to pack the headers closely together. In addition, if two data pages contain less than the content of a full data page, online maintenance merges them. For example, online maintenance will merge a data page that is 30 percent full with a data page that is 60 percent full to create one data page that is 90 percent full and one data page that is empty. Over time, page merging creates a number of empty pages, known as white space, in the database. White space increases the size of the database, which takes up disk space and slows backups.

Exchange 4.0 and 5.0 perform standard page merging. Exchange 5.5 takes data-page processing further by shuffling individual records from adjacent pages to form data pages that are 100 percent full, which is the most efficient form of storage. Exchange 4.0 and 5.0 can't merge data pages that contain message and attachment content because the data pages' content varies greatly from message to message. Instead, user deletions gradually empty the data pages, which become candidates for reuse only when they are completely empty.

Exchange 5.5 reuses empty data pages more efficiently than earlier versions, and therefore it doesn't expand the size of the database as readily. However, Exchange 5.5 does not arrange pages that contain associated information (for example, grouping all the headers for messages in a large folder) in a contiguous manner, as Exchange 4.0 and 5.0 do.

Currently, no version of Exchange can eliminate white space in the data pages. Microsoft is working to solve this situation, but until the solution appears, you can choose between two methods of managing the size of Exchange databases. The first method is to keep the Information Store on online maintenance around the clock--and therefore allow database white space (and thus the Information Store) to grow gradually. The second method is to take the Information Store offline periodically and run a utility to compress the store (which rebuilds it) and eliminate all white space. Offline compression is the only way you can reduce the size of the Information Store. Compressing the Information Store will create disk space and speed backups.

Compressing the Information Store
Compression is CPU-intensive and makes heavy demands on the disk I/O subsystem. Multiple-CPU systems fare better during compression than other systems fare, but even the fastest system can't process data during compression faster than 2GB per hour. If you have Exchange Server 4.0 or 5.0, consider compressing the Information Store every 3 months. If you have Exchange Server 5.5, you can compress less frequently.

Any reduction in the size of the Information Store by compression will vary from one server to another and depends on how much time has elapsed since the last compression and on the nature of most Exchange user transactions on the server. After you compress the Information Store, the rebuilt Information Store database will usually be smaller than the old one, but in some cases it can be the same size. Typically, a compressed Information Store database is between 25 percent and 35 percent smaller than the original database. However, because Exchange 5.5 reuses deleted data pages more efficiently than Exchange 4.0 or 5.0, a compressed Information Store in Exchange 5.5 will not reduce to the same extent as an Information Store in versions 4.0 and 5.0.

In all versions of Exchange, you'll gain more disk space by compressing the private information store than you will by compressing the public information store, because items are more transient and shorter-lived in the user mailboxes in the private store than the items in the public folders in the public store. The exception to this generalization is a system that directs Network News Transfer Protocol (NNTP) feeds to public folders. The data in NNTP feeds are similar to ordinary email messages and are not retained for long periods.

Compressing with the EDBUTIL and ESEUTIL utilities. You can use the EDBUTIL and ESEUTIL utilities to compress the Information Store. EDBUTIL is a utility in Exchange 4.0 and 5.0, and ESEUTIL is a utility in Exchange 5.5. ESEUTIL is an improved version of EDBUTIL and is multithreaded and able to work on the unlimited store. However, you can't use ESEUTIL for earlier versions of Exchange. Administrators often use the ISINTEG utility with ESEUTIL. ISINTEG checks the integrity of the internal contents of the Information Store, whereas ESEUTIL works with the raw data of the store. You can find information about ISINTEG and ESEUTIL in the Microsoft Knowledge Base (http://www.microsoft.com/kb/support). You can find documentation for ISINTEG and ESEUTIL in the \server\support\utils directory on the Exchange CD-ROM.

Both EDBUTIL and ESEUTIL use a temporary database, tempdfrg.edb, during compression of the Information Store. EDBUTIL reads data pages from the source database and writes them into tempdfrg.edb. After EDBUTIL processes all the pages, Exchange renames tempdfrg.edb, which then becomes the new active database. ESEUTIL uses tempdfrg.edb to maintain working information about the Information Store as ESEUTIL compresss and rebuilds the store.

ESEUTIL has to rebuild the Information Store database somewhere; therefore, you must have at least the same amount of disk space available to run ESEUTIL as the original database occupies. For example, if you plan to compress a 1GB Information Store database, you must have at least 1GB of free disk space. You can use the /T switch to rebuild the database off the current disk, if necessary.

Always make a backup before and after you compress the Information Store. You must take a full backup after compression, because when you compress the Information Store, you nullify the Information Store's transaction logs. Therefore, transactions in the logs cannot be read and committed into the new database during compression because the database's internal structures change as they are rebuilt.

To rebuild a database in the Information Store, shut down the appropriate service and invoke EDBUTIL if you're running Exchange 4.0 or 5.0, or invoke ESEUTIL if you're running Exchange 5.5. For example, to compress the private store in Exchange 5.5, invoke ESEUTIL by typing at the command prompt

c:> \exchsrvr\bin\eseutil /d /n /ispriv

The /D switch instructs ESEUTIL to rebuild the store, and the /ISPRIV switch identifies the target store.

Specifying /ISPRIV (private store), /ISPUB (public store), or /DS (directory store) forces ESEUTIL to extract the location of the selected database from the system Registry. You can substitute a filename instead of the database specifications (e.g., C:\exchsrvr\mdbdata\priv.edb). If you do, you must specify the /L qualifier to tell ESEUTIL where the transaction logs are. The /N switch instructs ESEUTIL to output details of what it has done to a file called dfrginfo.txt. If you don't want to rebuild a database (e.g., if you just want to check it for internal errors), you can use the /G switch to scan for logical or physical corruptions.

   Previous  [1]  2  Next