For example if you have a 20Gb mailbox database file and move 4Gb worth of mailboxes to another database, the file will remain at 20Gb in size.
However, the database itself will have 4Gb of “white space” in it, which is space that is available for new data to be written without growing the size of the file.
Your options to reclaim that space are to either:
- Create a new mailbox database and move all the mailboxes to that database
- Perform an offline defrag of the existing database to shrink the file
Each option has pros and cons. An offline defrag involves an outage for all users on that database, but may be more convenient if there is not additional storage available to allocate to the Exchange server to hold the new database.
On the other hand a mailbox migration has fewer risks, can be less disruptive as a whole, but will generate a lot of transaction logging that needs to be kept under control so it may take longer (ie several nights/weekends to migrate) as opposed to just one outage for a defrag.
Determining Free Space in an Exchange 2010 Mailbox Database
In Exchange 2010 you can see how big your mailbox databases are, and how much white space they have, by running the following command in the Exchange Management Shell.
[PS] C:\>Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto Name DatabaseSize AvailableNewMailboxSpace ---- ------------ ------------------------ MB-HO-01 18.26 GB (19,604,766,720 bytes) 9.544 GB (10,247,766,016 bytes) MB-HO-02 15.63 GB (16,785,670,144 bytes) 3.696 GB (3,968,761,856 bytes) MB-HO-Archive-01 648.1 MB (679,542,784 bytes) 134.6 MB (141,164,544 bytes)
In the example above the database MB-HO-01 is 18.26Gb in size but has 9.544Gb white space due to archiving that has occurred. If you want to reclaim that disk space then the file can be shrunk by using eseutil to defrag it.
Do not follow the procedure in this document if your Mailbox server is a member of a DAG. Before you defrag any mailbox database please read and understand the pros and cons of this operation and make the best decision for your specific situation.
Preparing to Defrag an Exchange 2010 Mailbox Database
The first thing to be aware of when planning a defrag is that you can only perform this task when the database is dismounted. This means that users with mailboxes on that database will not be able to access their email while you are defragging it.
The second thing to be aware of is that you need some available disk space to perform the defrag. This is because a new file is written during the defrag process, so for a period of time both the old and new files will exist, as well as a temporary file that eseutil creates.
So to plan for an Exchange 2010 mailbox database defrag you need an amount of free space equivalent to 1.1x the predicted size of the new file.
In this example that would be:
18.26 – 9.544 = 8.7
8.7 x 1.1 = 9.57
In other words, I’ll need about 10Gb of free disk space to run this defrag. Since I don’t have that much free space on the same drive as the database I will need to specify a different temporary location when I run eseutil. This can be another local drive or a UNC path, just be aware that if you are using a UNC path the defrag will take longer due to network latency.
Before proceeding you should be sure that you have a good, working backup that you can use for recovery if something goes wrong during the defrag.
Using ESEUtil to Defrag an Exchange 2010 Mailbox Database
Open the Exchange Management Shell and navigate to the folder containing the database file.
Dismount the mailbox database.
No run ESEUtil to defrag the file.
[PS] D:\Data\MB-HO-01>eseutil /d MB-HO-01.edb /t\\testserver\defrag\temp.edb Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.01 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating DEFRAGMENTATION mode... Database: MB-HO-01.edb Defragmentation Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Moving '\\testserver\defrag\temp.edb' to 'MB-HO-01.edb'... File Copy Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Note: It is recommended that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup. Operation completed successfully in 3788.218 seconds.
Mount the database again.
You can now see that the file is smaller, and all the white space is gone.
Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto Name DatabaseSize AvailableNewMailboxSpace ---- ------------ ------------------------ MB-HO-01 8.328 GB (8,942,190,592 bytes) 5.219 MB (5,472,256 bytes) MB-HO-02 15.63 GB (16,785,670,144 bytes) 3.696 GB (3,968,761,856 bytes) MB-HO-Archive-01 648.1 MB (679,542,784 bytes) 134.6 MB (141,164,544 bytes)
As you saw when ESEUtil completed you should run a full backup of the database at your next backup window.