In addition to defragmenting Microsoft Outlook .PST files for better performance, Mark Russinovich's
Exchange Server information store databases can get fragmented in one of two ways: internally or externally.
An internal fragmentation occurs when the data structures within the database file itself have become fragmented. The Exchange server typically addresses this kind of fragmentation on its own, usually during the 4 a.m. daily maintenance cycle.
It's possible to force an internal defragmentation of an Exchange information store database by using the ESEUTIL /D command, but this is not something you should do casually. Typically, this is only done as part of a disaster recovery operation, and is not something you need to do as regular maintenance.
An external fragmentation occurs when the physical files that make up the Exchange databases become fragmented -- i.e., the clusters that make up the database files are scattered across the disk.
If an external fragmentation occurs, does it make sense to defragment the Exchange database files using a tool like Contig? Here are some of the pro and con arguments for this scenario:
|Defragmentation Pros:||Defragmentation Cons:|
There are other nuances to the argument, such as the observation that file fragments greater than 64 MB don't tend to be problematic (and in fact the latest version of the command-line DEFRAG tool is programmed to ignore fragments larger than 64 MB for a single file by default).
But on the whole, it's OK to defragment the Exchange information store in a judicious way. Here are some best practices:
- Place the Exchange information store database files on a drive that is either empty (i.e., a dedicated physical spindle) or one that has already been decently defragmented. This will insure that the newly created database is not already broken up, and will give it room to grow without fragmenting.
- If you defragment the Exchange information store database files in a "dedicated" fashion -- i.e., by using Contig to defragment them specifically -- do so at off-peak hours and not more than once a week.
- Make sure the defragmentation process doesn't overlap with Microsoft Exchange's other administrative functions, such as the abovementioned 4 a.m. daily maintenance process. For instance, you could schedule the physical defrag for 3 a.m. or 5 a.m. one day of the week. Sunday morning is almost certainly a low mail-traffic time, so you could start there provisionally and see how it affects Exchange Server performance.
About the author: Serdar Yegulalp is editor of Windows Insight, a newsletter devoted to hints, tips, tricks, news and goodies for all flavors of Windows users.
Do you have comments on this tip? Let us know.
This was first published in July 2007