All about Defrag the exchange database

Eseutil /D Defragmentation Mode

Eseutil's /D switch can be used to defragment and compact a database offline. The defragmentation option makes used storage contiguous, eliminates unused storage, and compacts the database thereby reducing the database's size.
Eseutil's /D switch can be used to defragment and compact a database. During typical 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 put in service, but eventually the database size stabilizes.
Under typical conditions, performing an offline defragmentation will not permanently recover significant disk space. The file will usually grow again to its previous un-defragmented size. Special circumstances, such as moving many mailboxes out of the database, may make it worthwhile to defragment the database offline. By default, during typical operation, the database is logically defragmented nightly. This does not reduce the size of the file on disk, but does make the database perform efficiently.
Note:
You can use the Eseutil utility to defragment the information store and directory in Microsoft Exchange Server 5.5 and to defragment the information store in Microsoft Exchange 2000 and newer versions.

How Does Eseutil Defrag Work?
When Eseutil defragments a database by eliminating unused storage and compacting the database, Eseutil actually creates a new database that contains all the information from the original database. When defragmentation is complete, the original database is deleted or saved to a user-specified location, and the new version is copied over the original. If the utility encounters a serious logical problem in the database, defragmentation stops. The database must then first be repaired with Eseutil /P before it can be defragmented.
When an offline defragmentation is performed, Exchange makes temporary copies of the database file (.edb file) and the streaming database file (.stm file). Tables from the .edb file are preserved and copied into the temporary database, but empty pages and indexes are discarded. Because this causes physical page numbers in the database to be changed, pages are not copied unaltered; the page links between them are all updated, and all pages left in the database undergo integrity checks. All pages in the .stm file that has information on them are preserved in the temporary .stm file, and references to the pages are updated in the .edb file.
How Long Does it Take to Defragment a Database?
The time length 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 GB database that contains 10 GB of data takes about the same time as defragmenting an 11 GB database that contains 10 GB of data.
By default, after defragmentation is completed, the temporary database automatically becomes the new production database, and the original production database 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 put 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 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.
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 exactly predict how much disk space will be reclaimed, you should leave a recommended 110% of free disk drive space to be safe. For more information about how to determine the amount of disk space for defragmentation, see the Microsoft Knowledge Base article 195914, "Determining database free space with Exchange 5.5 Service Pack 1 and later versions of Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=195914).

When to Run Eseutil /D?
There are several situations where it is appropriate to run Eseutil /D to defragment an Exchange database. The following includes a list of those situations:
· There is a significant amount of white space in the database that can be reclaimed and which will not be reused. An example can be when the number of mailboxes in the database has been significantly reduced.
· An event is repeatedly logged in the Application log advising you to defragment the database offline. This may occur rarely when typical online defragmentation is no longer able to efficiently defragment the database.
· When the 16 GB database size limit is reached on the Standard version of Exchange and white space must be reclaimed in order to mount the database. If you are running Exchange Server 2003, then Service Pack 2 (SP2) should be installed to raise the limit to 75 GB. For more information about increasing the database size limit, see Microsoft Knowledge Base article 828070, "Exchange Server 2003 mailbox store does not mount when the mailbox store database reaches the 16 GB limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

Note:
After defragmenting the database using Eseutil, we recommend that you perform a full backup of the database. A full backup is needed because the database defragmentation creates new database files which have new database signatures. Log file replay after the restore depends on database signatures to match the expected values recorded in transaction log files. Any database backups that are taken before the defragmentation will contain database files that have signatures different from the new defragmented database. If an older database is restored, the new transaction logs which are bound to the new defragmented database files will not replay.

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 includes a list of those situations:
· Eseutil defrag 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. There is no reason to periodically run an offline defragmentation unless special circumstances apply.
· Eseutil defrag cannot not be run when the database is not in a consistent state.
Note:
As a rule, unless you expect more than 20 percent of available space to be recovered, defragmentation will likely not cause permanent shrinkage of the database files.