Exchange Server Cookbook: For Exchange Server 2003 and Exchange 2000 Server

2017-07-07 02:10:07

Recipe 6.16. Performing an Offline Defragmentation

Problem

You want to reclaim whitespace from your Exchange database, so you need to take it offline and defragment it.

Solution

Using a command-line interface

Dismount the Exchange Server database to be defragmented as described in Recipe 6.8.

Open a command window (cmd.exe).

Change to the directory where the database you want to defragment is located. This is optional, but it will save you some typing in the next steps.

Run the eseutil utility to defragment the database:
> eseutil /d /p "\pathToDBFile\dbName.edb"

Wait. Database size and the amount and location of whitespace affect the time it takes to defragment it.
- When defragmentation completes, remount the store as described in Recipe 6.7.
- Use the recipes in Chapter 11 to make a full online backup. When you defragment the database, its database signature changes, so previous log files can't be applied against the new EDB/STM pair.

Discussion

In normal operation, it is almost never necessary to defragment the database as it will simply grow again as more messages are sent and received. Some activities can return large amounts of space to the database whitespace pool. For example, moving large numbers of mailboxes off a server will mean that the space formerly used by those mailboxes is available; if you move enough mailboxes, this savings can be significant. To run an offline defragmentation, Microsoft recommends that you have 110% of the database size available as free disk spacefor a 40 GB database, then, you should have at least 44 GB free.

It is neither necessary nor desirable to frequently perform offline defragmentations, and there is no need to use products that attempt to do this for you.

When you use eseutil's /d option, it systematically scans through the EDB and STM files for the specific database, rearranging pages to make all of the tables, indices, folders, attachments, streamed objects, and messages contiguous. Normally, it does this by following a simple process:

A new pair of temporary database files is created. You can specify the location and name of these files with the /t option (which isn't followed by a space: /tG:\temp\defrag.edb is how you'd specify that you wanted to use g:\temp\defrag.edb as your temporary file). This option is useful if you don't have enough space on the volume where the databases are now. It's legal to use network-mapped drives (but not UNC paths) with /t, but beware the performance and bandwidth-consumption impact of the next two steps.

eseutil scans the source database, organizing pages on the fly and writing them to the temporary file. As you would expect, this is what actually takes up the bulk of the time in the defrag process. You should probably expect this step to process 4-10 GB per hour, although that figure may vary depending on your server and disk configuration and what else your server is doing.

When all pages in the database have been copied to the temporary file, eseutil copies the temporary file and overwrites the original. Once this step finishes, you can remount the database and use it normally.

Step 3 can take a significant amount of time, so you can instruct eseutil to skip it with the /p option. This forces eseutil not to copy the temporary file or overwrite the existing file; you'll have to do that manually before you can mount the database. Alternatively, you can use the techniques in Recipe 6.9 to change the database paths to point to the newly defragmented file.