Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2009-03-16

You can use the Exchange Server Database Utilities (Eseutil.exe) /D switch to defragment and compact a database offline. The defragmentation option makes used storage contiguous, eliminates unused storage, and compacts the database, which reduces the database file size.

For instructions about how to use the Eseutil /D syntax, see How to Run Eseutil /D (Defragmentation).

During normal operations, database files never shrink below their current size. As space in the database is freed by deletion of items, existing pages are reused where possible. Typically, a Microsoft Exchange Server database will grow for several months after it is placed in service, but eventually the database size stabilizes.

Under normal conditions, performing an offline defragmentation does not permanently recover significant disk space. The file will tend to grow again to its previous size before defragmentation.

How Eseutil Defragmentation Works

As part of the defragmentation process, Eseutil creates a new database that contains all the information in the original database. When defragmentation is complete, the original database is deleted or saved to a user-specified location, and the new version is renamed as the original. If the tool encounters a bad record, it stops and displays an error message.

When an offline defragmentation is performed, Exchange makes a temporary copy of the database file. Tables from the database file are preserved and copied into the temporary database, but empty pages are discarded and indexes are rebuilt. Because this action causes physical page numbers in the database to be changed, pages are not copied unaltered. The page links between pages are all updated, and all pages left in the database undergo integrity checks.

Length of Time to Defragment a Database

The length of time required to complete defragmentation depends on how much of the database is empty and not on the size of the database file. For example, defragmenting a 100-gigabyte (GB) database containing 10 GB of data takes about the same time as defragmenting an 11-GB database containing 10 GB of data.

By default, after defragmentation is complete, the temporary database automatically becomes the new production database, and the original production database file is deleted. The time that defragmentation takes can be significantly reduced if you have as much free space on the same logical drives as the size of the original database files. In this case, the temporary database can be placed on the same logical drive, and the final copy will complete almost instantly.

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

Note:
You only need as much extra logical drive disk space as the final size of the files after defragmentation. Although it is impossible to precisely predict how much disk space will be reclaimed, you should leave a recommended 110 percent of free disk drive space.

How to Determine the Amount of Free Space in a Database

The amount of free space that is available in an Exchange database file is displayed in an event that is logged in the event log after an online defragmentation of the database is performed. The online defragmentation is performed automatically during normal database maintenance. In addition, the event is logged in the event log even if the associated logging level is set to None.For mailbox or public folder databases, an event similar to the following event is logged in the event log:

Event Type: Information

Event Source: MSExchangeIS Mailbox Store

Event Category: General

Event ID: 1221

Date: 8/16/2006

Time: 9:15:00 AM

User: N/A

Computer: Computer Name

Description: The database "storage_group\mailbox_database" has nnn megabytes of free space after online defragmentation has terminated.

Note:
In Exchange Server 2007, the event ID 1221 message description contains the following text: The database "storage_group\mailbox_database" has nnn megabytes of free space after online defragmentation has terminated. Storage_group is the name of the storage group, mailbox_database is the name of the mailbox database, and nnn is the amount of free space that is available in megabytes. The Computer Name is the name of the Exchange Server computer.

For queue databases (transport databases that reside on Exchange Edge Transport or Hub Transport server roles), an event similar to the following is logged in the event log:

Event Type: Information

Event Source:MSExchangeTransport

Event Category: Components

Event ID: 7007

Date: 8/16/2006

Time: 1:00:02 AM

User: N/A

Computer: Computer Name

Description: Online defragmentation has completed for database mail.que. The database has nnn free bytes.

Note:
In the preceding description, nnn is the amount of free space available in bytes. The Computer Name is the name of the Exchange Server computer.

Another method to determine the amount of free space is by running a space dump with Eseutil /ms against an offline database file. (For example, run the following command: eseutil /ms Mailbox Database.edb.) The space dump outputs a table. From the table, take the number in the Availablecolumn and multiply it by the page size to determine the free space for the database file. For more information about the Eseutil file dump mode, see Eseutil /M File Dump Mode.

When to Run Eseutil /D

There are several situations where it is appropriate to run Eseutil /D to defragment an Exchange database. The following list describes some of those situations:

  • There is a significant amount of free space in the database that can be reclaimed and that will not be reused.

  • There are ESE -1018 errors affecting the indexes of a database file. In such instances, offline defragmentation rebuilds the indexes. Running an offline defragmentation effectively eliminates this corruption.

  • A database file has been repaired using Eseutil /P. After running repair, Eseutil offline defragmentation should be performed on the database file.

  • A mail storm occurs on a queue database file residing on an Exchange 2007 Hub Transport or Edge Transport server. A mail storm is a large amount of mail that fills up the transport queue faster than the transport service can process the e-mail messages. This behavior causes the queue to fill with mail, and the Queue database expands when it needs to. When the mail from the storm has been processed, and an online defragmentation has been run on the database, some amount of free space remains in the database. To reclaim this free space and shrink the database, run Eseutil /D to perform an offline database defragmentation.

When Not to Run Eseutil /D

There are situations where it is not appropriate to run Eseutil /D to defragment an Exchange database. The following list describes some of those situations:

  • Eseutil offline defragmentation should not be run as any kind of standard maintenance. Exchange runs an automatic online defragmentation nightly that handles the day-to-day maintenance of Exchange. For day-to-day, month-to-month, or year-to-year maintenance, there is no reason to run an offline defragmentation.

  • Eseutil defragmentation should not be run when the database is not in a consistent state.

  • Eseutil offline defragmentation should not be run when there is an available database to which mailboxes could be moved. Doing so will cause less downtime for end users. Because offline defragmentation is done offline, users will not have access to their mailboxes during defragmentation. We recommend that to reduce the impact to the end user, you move the mailboxes to a different database if available by performing a Move Mailbox operation. For more information, see Moving Mailboxes.

  • Eseutil offline defragmentation should not be run when ESE -1018 errors affect the data portion of a database file. In such cases, offline defragmentation will detect the error and not proceed.

For More Information