Is offline defragmentation considered regular Exchange maintenance?

Every so often clients ask me - "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 - I 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 I 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

http://support.microsoft.com/?id=256352

 

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

http://support.microsoft.com/?id=255035

 

Best Practices for Exchange Database Management whitepaper:

http://www.microsoft.com/exchange/techinfo/administration/55/BestDBManage.asp

 

[You Had Me At EHLO...]