Community Pick: Many members of our community have endorsed this article.
Editor's Choice: This article has been selected by our editors as an exceptional contribution.

Exchange Offline Defrag

Glen KnightLead Techical Consultant
CERTIFIED EXPERT
Published:
With Exchange 2003 Enterprise, Exchange 2007 and Exchange 2010 there is no need to run an offline defrag of the Exchange database.  All of these versions will allow the creation of another mailbox store.  Once you have another mailbox store you can simply move the mailboxes from the fragmented store to the new one.  This will provide you with a fully defragmented and error free mail store with the added bonus of no down time.

In Exchange 2003 Standard Edition with Service Pack 2 there is a soft database limit that can be set up to 75GB.  Many believe that simply running an offline defrag of their data store will help them to stay below the limit.  This is simply not true.

The 75GB limit in Exchange 2003 is a soft limit and it is based on the LOGICAL size of the database not the PHYSICAL size. The logical size of the database can be loosely calculated by taking the combined size of the EDB and STM files minus the free space reported in Event 1221 in the Application Event Log.   Guidance on finding the true size of the stores can be found here: http://technet.microsoft.com/en-us/library/aa996139(EXCHG.65).aspx

By default, Exchange 2003 will run online maintenance every day, normally at around 5am.  Part of this maintenance is to run an online defrag of the database.  Details of what other tasks are run as part of the online maintenance can be found here: http://support.microsoft.com/kb/324358

Once the online maintenance has been completed there will be an event 1221 generated in the Application event log.  There will be one for each store.  The description will say “The database "<storage_group>\<mailbox_store> (<server_name>)" has <nnn> megabytes of free space after online defragmentation has terminated” this event shows how much free space is in the EDB file (it does not include the STM file).

Creating “white space”

The free space that is reported by Event 1221 is often referred to as “white space”.  This free space will be used by Exchange before expanding the physical size of the database.  If your database has reached the 75GB limit then you will need to create free space to bring the logical size of the database below the limit.

The easiest way to do this is to delete any unwanted mailboxes and ask your users to archive some mail or delete mail that is no longer required.

Depending on your deleted item retention period, this may take a long time to be seen as free space.  If you are trying to alleviate an immediate problem, then you can speed this process up by setting the deleted item retention periods to 0.  This will make any items that are deleted, permanently deleted rather than sent to the dumpster, where you can recover them with the tools, Recover Deleted Items option in the Deleted Items folder within Outlook.

This will then hopefully bring you below the logical limit of your database.

Only if PHYSICAL storage on your server is a problem should you perform an offline defrag of the database to recover the free space reported by Event 1221.  If there is no free space reported by Event 1221 then an offline defrag is a complete waste of time.

Offline Defrag

If you have read all of the above and you are still convinced you need to perform an offline defrag of the Exchange database then I would recommend you follow these guidelines:

To run ESEUTIL you need to open a command prompt and change the folder to "C:\Program Files\Exchsrvr\Bin".  This is the same for all the commands listed below
Perform a FULL backup of the Exchange Information store using either Windows Backup or a 3rd Party Backup product.  It must be an Exchange aware backup and it must be a FULL backup of the store not a brick level backup.  This will ensure all the transaction logs are flushed.
Dismount the store and make a copy of the STM and EDB Files to another drive.  Consideration needs to be taken for the fact that the defragmentation process needs a minimum of 110% of the size of the store in free space.  So if your store is 75GB you need an extra 83GB of free space.  If the drive that the store is on does not have enough space then move it do a different volume and perform the defrag there.  Alternatively you can direct the temporary database to a different volume using the following command: ESEUTIL /d "C:\Program Files\Exchsrvr\MDBDATA\Priv1.edb" /tD:\Priv1Temp.edb
Run the ESEUTIL /d “C:\Program Files\Exchsrvr\MDBDATA\Priv1.edb” command to start the defragmentation.
Please note that depending on the specification of the server and any other additional tasks that it may be performing, you should expect a defragmentation of a database to run at a rate of between 4 and 7 GB per hour.  So if you have an 80GB file it could take up to (and probably longer) 20 hours to perform a full defrag.  During this time the Exchange Server will be unavailable to users.
23
13,172 Views
Glen KnightLead Techical Consultant
CERTIFIED EXPERT

Comments (6)

very good info.  
Wesley MillerInformation Technology Practitioner
CERTIFIED EXPERT

Commented:
A better guide How to defragment Exchange databases
 is here: http://support.microsoft.com/kb/328804
Alan HardistyCo-Owner
CERTIFIED EXPERT
Top Expert 2011

Commented:
@wmiller - this article is about determining the need for defragmenting an Exchange Database not the "How To" process of defragmenting it.  Each article has a distinct purpose and they should not be compared as such.

Alan

Commented:
Good article demazter!
Great article. So creating a new database and migrating users is a better solution than running eseutil against the database.

View More

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.