Tools and tips to help you decide whether to rebuild Exchange Server 5.5 databases
Like all databases, Exchange Server's Information Store (IS) grows over time. Messages, documents, and other items flow into and out of the IS's mailboxes and public folders. Some items remain in public folders permanently, but users eventually delete most of the IS's data. These deleted items leave empty space, or white space, in the database. Microsoft attempts to restrict the IS's demand for disk space by reusing the database space that deleted items occupied before users deleted them.
Background Maintenance
Microsoft designed Exchange Server 5.5 to perform online maintenance at least once a day. You can set the interval at which maintenance occurs by selecting a server in the Microsoft Exchange Administrator program, selecting the File menu's Properties option, and clicking the IS Maintenance tab, which Screen 1 shows. Administrators typically schedule Exchange Server database maintenance when user demand is lightest, because of the load that maintenance activities generate. I recommend scheduling maintenance to start at about midnight. (To speed up the maintenance activities, I don't run online backups and maintenance activities at the same time.) The maintenance period that Screen 1 shows lasts from midnight until 3 a.m., which is enough time for database maintenance activities to complete on all but the largest servers.
A set of threads that execute within the IS process (store.exe) perform this background maintenance. The threads perform two major tasks: rearranging the contents of IS pages to free space within the database (i.e., defragmenting the database) and removing deleted items that have passed their retention date. The threads also perform tasks such as monitoring mailbox quotas and expunging tombstone entries. (Tombstones are entries in the Directory that represent deleted mailboxes or custom recipients.)
Database defragmentation. Internally, Exchange Server organizes its databases in 4KB pages. As transactions occur, Exchange Server writes data into these pages. Exchange Server releases pages when users delete the pages' contents. Some pages store message headers; others hold message content and attachments. When a new message arrives, Exchange Server inserts the message's header into one page and saves the message's text and attachments in one or more other pages. A message's text often fits into one 4KB page, but attachments are typically much larger than 4KB, so Exchange Server stores them across multiple pages.
Obviously, the database is most compact and efficient when it fully utilizes all of its pages, but an Exchange Server database is in this state only when you first create it or after you rebuild it. At all other times, the pages are in a state of flux, because users are interacting with the database.
As users delete messages, the pages in which Exchange Server saves the messages become free for reuse or defragmentation. A page is a candidate for defragmentation when Exchange Server removes some but not all of its content. A message header occupies approximately 400 bytes, so one page in the IS might contain 10 message headers. Pages that hold message headers are the private IS's most obvious candidates for defragmentation, because users partially empty many message-header pages as they delete messages during a workday.
Through defragmentation, Exchange Server moves message headers between pages to fill some pages and release others for reuse. For example, if one page is 30 percent full and its neighbor is 60 percent full, Exchange Server moves the data from the 30 percent-full page into the 60 percent-full page so that one page is 90 percent full and one is empty and available for reuse.
Exchange Server performs background defragmentation of the public IS (pub.edb), then the private IS, then the Directory store (dir.edb). Screen 2 shows an event 179 log entry, which notifies you that an online defragmentation pass has begun for a database. In the event-log entry that Screen 2 shows, store.exe is processing the private IS. Because priv.edb holds user mailboxes, it is usually the largest database on an Exchange Server system and takes the longest to process. Unless defragmentation encounters an error, you'll see event 180, which tells you that the defragmentation pass is complete, sometime after you see event 179. On the morning that I captured Screen 2, event 180 for the server's private IS occurred at 12:57 a.m. Screen 2 shows that event 179 registered at 12:16 a.m., so I can calculate that the server took 41 minutes to process a 3GB private IS. This calculation tells me that the system (a dual 200MHz Pentium server with 256MB of memory) took roughly 14 minutes to process each gigabyte. The speed of processing depends on the system's load and power. The speed of a system's disks and controller affect every database operation, so fast disks and controllers can substantially reduce maintenance times.
If you see event 183 in an Exchange Server's application event log, Exchange terminated maintenance before it finished defragmenting a database because the scheduled maintenance period (such as the period that Screen 1 shows) expired. To solve this problem, extend the maintenance period until you no longer see event 183 in your log files.
Prev. page
[1]
2
3
next page 
