Defragment Exchange information store database files

In addition to defragmenting Microsoft Outlook .PST files for better performance, Mark Russinovich's

    Requires Free Membership to View

    Login

Contig utility can be used to defragment Microsoft Exchange information store database files.

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.

More on Microsoft Exchange defragmentation:

Using an external hard drive to defrag Exchange databases

Running ESEUTIL to compact an Exchange information store

Exchange Defragmentation Reference Center

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:
  • Fragmentation is fragmentation, and the less of it the better. If you defrag the Exchange database files, you'll be doing yourself a favor anyway.
    		•
  • Exchange database files are accessed in a fairly random way, so defragmenting them does not guarantee better performance.
  • Exchange database files may be randomly accessed, but if they're in one area of a given disk as opposed to scattered hither and yon, that's that much less thrashing the disk has to do in the first place.
    		•
  • The process of defragmentation creates a lot of I/O overhead -- so much so that a particularly busy Exchange server may experience slow performance.
  • You can run the Exchange information store defrag process during off hours and nobody will be any the wiser for it.
    		•
  • You're better off putting the database files on their own spindle where they are not competing with anything else instead of defragmenting them.

    • 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

    Join the conversationComment

    Share
    Comments

      Results

      Contribute to the conversation

      All fields are required. Comments will appear at the bottom of the article.

      Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

      Back to top