1

Looking to do my first offline defrag this weekend on Exchange 2003.

Our Exchange DB is on E drive and server1 is the temporary location where there is sufficient space.

Dismount the store and change to c:\program files\exchsrvr\bin

Does this look like the correct command to run?

eseutil /d "e:\exchdata\priv1.edb /t"\\server1\exchtemp\tempdfg.edb"

Is there anything I should be aware of such as backups running at the same time etc?

the-wabbit
  • 40,737
  • 13
  • 111
  • 174
Tom
  • 88
  • 1
  • 1
  • 5

2 Answers2

2

Everything I've read recommends copying the eseutil related binaries to the non-Exchange server and then copying the database and streaming file that you want to defrag to the non-Exchange server. I've never heard of anyone running eseutil over the network and I think it's a bad idea for a number of reasons:

  1. It's going to run considerably slower.

  2. The risk of corrupting or otherwise damaging the files would seem to be much greater.

Here's what I would suggest instead:

Get a USB drive large enough for the defrag (at least 110% of the size of the database) and set that as your temp location. Disable any AV software for the duration of the defrag and hold your Exchange backups until the defrag is complete.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • If the "USB drive" is going to be a flash drive, specific attention should be paid to what throughput it is able to deliver for write operations. I have seen 64 GB USB3 sticks writing at ludicrous 3 MB/s. – the-wabbit Nov 22 '12 at 15:51
1

Is there anything I should be aware of

You should seriously re-consider if you want to run an offline defrag. In most cases, you would not, unless:

  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.

Other than that, I personally have run offline defrags a couple of times over a network connection - it worked as expected. Your store is going to be offline for the time of the defrag and the database copy operation afterwards. Note this official statement from the Exchange documentation:

We do not recommend that you use a network drive to hold the temporary database. When you use a network drive for the temporary database, defragmentation will take longer, and any transient or permanent network error will end the process. Because defragmentation cannot be resumed, you would have to start over from the beginning.

Although the actual impact is rather limited. Server network connections do not tend to be interrupted all that often. And a defrag to a network location would presumably not run slower if your database file is located on a single hard disk or a RAID 1 array without a large write cache - the numerous read/write cycles caused by having the temporary file on the same drive would prevent large linear reads/writes and significantly reduce data throughput anyway.

the-wabbit
  • 40,737
  • 13
  • 111
  • 174