Is offline defragmentation considered regular Exchange maintenance?

Published Jul 08 2004 12:03 PM 10.5K Views

Every so often people ask us - "How often do you recommend we run the offline defrag?" Meaning - how often do we run it to have the server run OK?


The short answer would be - we do NOT recommend this to be run as any type of "regular" maintenance at all.


Looking at this closer - what really happens when you do an offline defrag?


  1. You need to take your databases offline in order to run ESEUTIL on them. So - you are looking at downtime.
  2. Defrag actually works by reading the original database, and copying used database pages into the brand new database file. When that is all done, we actually delete the original database file and rename the new one and copy it into original database file's place.
  3. Not only are the used pages read, but they are renumbered/rechecksummed too. All secondary indexes in the database are discarded as well.


Seeing that we have a new database, we have new database signatures. That then means that transaction logs from that point on will have this new database attached to them. So - if you needed to do a restore a backup before the defrag and play in the transaction logs up to the current log - you would have problems, as transaction logs now talk about new databases (based on the signatures) and not the ones that you restored, right? Their signatures will not match and you will not be able to reply the data back in.


There is no real way around this. It is as if you had created a brand new database. It no longer has any relation to the old database, except for having the same stuff in it. You might as well have moved mailboxes to a new database.


Long story short - if you need to defrag - do it - but make SURE that you perform a good full (online) backup immediately after that!


Because of the above - offline defrag is definitely not something to do on regular basis. And it is typically not needed either.


So when DO we recommend defrag? There are a few situations:


  1. If you have deleted a large amount of data out o the store and want to reclaim the hard drive space for whatever reason. This includes situations when databases reach the 16 GB limit on Standard versions of Exchange server.
  2. If you had to run a hard repair of the database (eseutil /p - and that's another thing that we do NOT recommend unless this is a last possible thing to do). After running a repair, you should always offline defrag the database to get a new database file that has not been repaired. For more on what to do after the repair, please go here.
  3. If you are experiencing a specific issue and have found a reference that says offline defrag will fix it.
  4. If you are working with PSS and resolving the issue requires an offline defrag.
  5. As a general rule, only defrag to reclaim space if you're going to reclaim more than 30% of the space. You can look for Event 1221 after nightly online defrag to get a conservative estimate of how much free space is in the database. For more info on Event 1221, please go here.


Some related reading:


256352 Online Defragmentation Does Not Reduce Size of .edb Files


255035 XADM: How to Recover Hard Disk Space from Exchange Server Databases


Best Practices for Exchange Database Management whitepaper:


- Nino Bilic

Not applicable
Nice article. I can say for sure I've never really considered doing an offline defrag at all... so I guess I never heard that it *should* be done. Good to hear I'm not doing anything wrong ;)
Not applicable
We do it once or twice a year. I work at a business school at a university, so we delete hundreds of accounts each year as students graduate. We usually reclaim quite a bit of space by doing so, so for us it makes sense to do so.
Not applicable
Scott, in your scenario it absolutely makes sense... though if you're running Exchange enterprise, you might consolidate all remaining users onto a store and simply delete/recreate the other (now empty) stores.

Nino.. thanks for putting this up. We often see this question in the newsgroups and occasionally someone will dredge up the 5.5 book contributed to by MCS which recommended doing this periodically. (Blech)

I do often run these utilities against databases while practicing my restores just to verify there aren't any issues, but have never run them against a production server (unless there was a real need) other than one time where I had a situation similar to the one Scott mentioned.
Not applicable
Seconding the first comment - good article, thanks Nino.

I can say that in the past I've usually looked to do a Mailbox Move into a new store, and there are a couple of reasons why I normally chose this over an offline defrag...

1. User downtime - mailbox move to a newly created store only involves downtime for each users mbx as they are moved, and a little time - around 15 to 30 minutes - afterwards (for prop replication around the Directory)
2.Transaction logs around the move process - if a store goes during the move process, then at least it's been online and the logs may be there for replay (unless your log disk went too, - here you may be better off reverting to a point in time before the move and re-planning)
3. Better chance of dealing with any corruptions - if a users mailbox contains some corrupt items, a mailbox move tends to skip it and continue on, allowing you to come back and deal with it later
4. More flexible - I might also be looking to move to a new volume and could kill two birds with the one stone by doing mailbox moves into the new store on the new volume right away.

Not applicable
As a consultant, I get this question from my clients quite a bit. Good to see it addressed here.

I would argue however, that points 3 and 4 in Nicks comments are better addressed by a offline defrag. The offline defrag will address any corruption issues so you don’t have to deal with them later. Also, using command line switched on eseutil, you can prevent the default behavior of renaming the temp database and replacing the old. So you could defrag the old database to the new volume and leave the new database there – accomplishing the database move much faster than the move mailbox method.
Version history
Last update:
‎Jul 01 2019 02:58 PM
Updated by: