Exchange Server 2010 – Shrink Database Size – OR – Reclaim Lost Database Storage Space

As mentioned in a previous post, if you’re Email Server is running out of hard drive space and you’re in a world of hurt, there are several steps you must take to get that space back. Even if you have your user’s tidy up their mailbox and you force delete out their RecoveryItems folders, you will essentially be creating free whitespace to store more messages but the size of your database will never shrink below it’s current state. To actually shrink size of the database file, you will have to do the following:

  1. Have the end users get rid of all their unimportant emails and empty their Deleted Items folder.
  2. Purge all of the user’s RecoveryItems folders. To learn how, read this.
  3. Either create a new mailbox database, mount it, move all the mailboxes to it, then dismount and delete the old database

    — OR —
    Dismount the databases and run the defrag utility

Either way, both scenarios are extremely time consuming so get your blanket and sun tan lotion because you’re never getting off that beach, just the way you never got into the NHL, ya jackass!

According to this little nugget, there are obviously pros and cons for each method. If your server can still send and receive mail (consider yourself lucky, YAY!), then moving the mailboxes would probably be the route to take so that users can still use their email, although I’m not entirely convinced that you could even do it this way because I’m thinking your transaction logs may possibly bleed your server dry of space.

If you weren’t so lucky (frownie face), then you had better pray to Jeebus that you’ve got ample storage out on a network share somewhere because you’re going to need it. As a matter of fact, straight from the Microsoft website, it says your going to need 110% the size of your database files to store the temp databases and at this point you may as well grab a burger and a nice toxin-laced carbonated beverage to tide you over.

Before you do anything, you should seriously debate over which path to take as some users say you can realistically defrag about 8GB or 9GB per hour. If your database is large, you do the math and figure out how long you want to be down.

When my server ran out of space and I got the backpressure error in the event log, the best/fastest solution I could come up with the least amount of downtime was to just add another hard drive to the server with enough space to cover the size of the databases with lots of room to spare, dismount the database, and physically move the database files to the other disk, edit the database paths in the “EdgeTransport.exe.config” in the “Bin” folder, and restart the Transport service for the time being. After that, you can proceed with deleting out your old database files and create new databases to move your mailboxes back into on the old drive. Another suggestion would be to edit the “MSExchangeMailboxReplication.exe.config” file located in the Bin folder of your server’s install directory, check out this page to figure out the values to edit to increase the maximum amount of move requests for the replication service, and then restart the service before you start. For instructions on how to do this, see this post.

To defragment a mailbox database, from the Exchange Shell, change into the location of the database directory and dismount it:

cd D:\PathToYourDatabaseFolder
Dismount-Database "YourDatabaseName"

With the database dismounted, you can now run the defrag command:

eseutil /d "YourDatabaseName.edb" /t\\YourNetworkShare\Folder\temp.edb

When finished, remount your database and hopefully you’re back in business!

Mount-Database "YourDatabaseName"

Leave a Reply