• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1235
  • Last Modified:

Using Disk Defragmenter to defrag a partition with an exchange .stm and .edb on it.

I'd like to defragment the partition that is currently storing my .stm and .edb files on it to improve performance.  (not using exchange to defrag the store.)  At the same time, not really interested in destroying my exchange server.

I've done some research and seem to find a: very little on the topic, and b: opinions on both sides of the fence.

So I'm looking for someone who has used defrag.exe on their exchange databases, and what your results / findings are.

Please, if you have an opinion back it up with some facts / experiences.  Not just a "ya, do it," or a "no never do it."

This is running on a SBS2003.

Thanks all,

  • 2
1 Solution
Let me preface this with "I've never done this."

However i'll explain why.

The exchange databases are jetfile databases. The utility to compact, defragment, repair, etc these files are isinteg and eseutil. They operate a bit differently regarding whitespace than other types of windows based files.

Basically white space occurs naturally in mdb and edb files, and actually improves database performance in most situations. Every night your exchange server run database maintenance during which deleted messages are removed (after deleted item retention expires) and white space created. Other operations may occur depending on settings you've added to mailbox manager, however that is the minimum. When these mail items are removed, white space is created. This white space is then organized in the database to sit at the "end" of the database, ready for new data to be written to it. This is all done with the database mounted and online, aka "Online maintenance". This whitespace is empty, but still is allocated and accounted for within the database pages and tables, allowing for very rapid addition of data the next day into this whitespace.

If the database grows past this amount of whitespace provided, then diskspace has to be allocated to the database, which works fine, but has a poorer performance than merely writing to available whitespace that is already allocated to the database. The ONLY way to remove this whitespace and properly maintain the integrity of the jetfile database is to run an eseutil /d, followed by an isinteg to confirm proper logical consistency in the pages.

By running the file-level defrag, are you going to simply move whole files around on the disk, or are you going to defragment the files themselves? If you can't answer this question conclusively, then i would say the risk is not worth it. Or simply exclude your exchange files from this work.

In addition, defragging your exchange database themselves isn't going to improve performance (unless you're still running 5.5, which you aren't) and in fact may degrade performance slightly. You should have an event in your exchange server's app log at some point during the week (i can't remember the exact id) that tells you that maintenance has completed, and how much whitespace you have in your database. This will tell you if its worth reclaiming that whitespace with an eseutil /d.

Good luck, and hope this helped!
CoreyMielkeAuthor Commented:
Very good advice and it makes sence...thank you.

When I view the analyse of the defrag it's showing that the partition is 60% fragmented.  Just about the only things on the partition are the exchange database files.  So the files fragments would be moved around, not the complete files.  

The online defrag is running every night, and there is plenty of "white space," in the database files.

Anyone else?  I'm looking for both sides of the debate.  So far score one for not doing it.
CoreyMielkeAuthor Commented:
Oh, ps....the priv.edb is in about 165 fragments.  Just seems like alot to me, even though it's an 18gb file.

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now