When the Time Comes to Defrag
Because Exchange I/O operations to databases tend to be random, a large contiguous database file isn't as crucial to good I/O performance as would be the case if large sequential reads and writes were necessary. Still, if the volume that holds your Exchange database has a high level of fragmentation, you should defrag the volume. If you don't use specialized third-party disk-defrag software, you can run the standard Disk Defragmenter tool (under Start, All Programs, Accessories, System Tools).
Be sure not to run a disk-defrag program on a production Exchange server during working hours or while a database is mounted (in which case Windows can't defrag the file). Disk defrags are I/O-intensive operations and will affect the performance of the Exchange system: Exchange I/O operations will take inordinate amounts of time to complete. For the best results, take the following steps to perform a file-system defrag:
- Dismount the Exchange databases.
- Copy the databases to another volume.
- Perform the disk defrag on the original volume.
- Copy the Exchange databases back to the original volume. (The act of copying the database between volumes will implicitly defrag the database at the file-system level but won't affect internal white space.)
Database Changes in Exchange 2003 SP2
Exchange 2003 Enterprise Edition effectively has no upper limits on database size. However, Exchange 2003 Standard Edition has had an upper limit of 16GB on the single permitted Exchange database. This 16GB size limit is based on the actual size of the Exchange Database (EDB) file reported by the file system, so if you're approaching this limit, check the amount of white space in the database to determine whether an offline defrag might considerably reduce the database file size. (Bear in mind that an offline defrag operation that uses Eseutil requires that the volume have additional free space of as much as 120 percent of the database size to hold the temporary files created during the defrag.) . . .
Register
I'd like some clarification about two of the steps you listed for performing a file-system defrag when your Exchange stores are on a highly fragmented volume.
(step 2.) When you copy the stores to another volume, do you just simply make a straight copy of them, or is this really a cut-n-paste operation to remove the stores from the volume entirely?
(step 4.) When you copy the databases back to the newly defragmented volume, are you supposed to overwrite the original files?
Thanks!
- Kirstin
oohgodyeah January 18, 2006 (Article Rating: