Every so often there is a question: “Should we run file-level defragmentation software on Exchange servers?”
Usually, this comes from confusion that file system defragmentation actually helps Exchange as – well, Exchange databases get fragmented too.
The process of Exchange database fragmentation is a completely different story though – it is the defragmentation of the “white space” or empty database pages within the Exchange database. There are 2 types of defragmentation of Exchange databases:
ONLINE defragmentation – this is what happens as part of online maintenance which is by default run on nightly basis. Here we rearrange the data (database pages really) within the database to have more contiguous white space. Typically you will want to make sure that your backup schedule does NOT interfere with online maintenance schedule, as starting of online backup will stop the online defrag.
OFFLINE defragmentation – this is what happens when you run ESEUTIL utility with the /d switch – therefore you need to take the database offline to do it. This is typically done only when there is a specific reason to do it – such as reclaiming huge amounts of hard drive space, if instructed to do so by Support Services when troubleshooting a specific problem, or after a database hard repair (which is another thing that we should never do).
So – that being said – what about file system defragmentation?
I would never do it on running production server databases. The reason for it is simple actually – file system defrag is a very intense I/O operation. So the disc will be very busy. I have seen some cases here in Support Services, where our database engine has actually started logging warnings that the write to the disc was successful, but it took “unusually long” to complete, and it was suggesting that hardware might be at fault. Sure enough – a disk defrag kicked off just before this started happening as witnessed by the Application log. That right there is enough reason for me not to do it in real life.
The bottom line really is – you do not HAVE to file-level defrag the Exchange database drives. Exchange reads and writes to it’s databases in very random fashion. Large sequential reads and writes will see much more improvement from file system defrag than Exchange databases will. But if you really WANT to do it – I would do it the old-fashioned way: move the databases off to some other volume, file system defrag the drive and then move the databases back… Or at least make sure you have a good backup, dismount the databases and file-system defrag then.
Few related things to read:
328804 How to Defragment Exchange Databases
192185 XADM: How to Defragment with the Eseutil Utility (Eseutil.exe)
256352 Online Defragmentation Does Not Reduce Size of .edb Files