How to Defrag an Exchange 2010 Mailbox Database

Exchange Mailbox databases won’t get any smaller on your storage until you run an Offline Defragmentation

If you ever took a look at the space being used by an Exchange database on your storage you may have noticed that the databases only grow in their size, but they will never shrink.

I wrote in this article how you can purge soft-deleted mailboxes from Exchange 2010 databases and mentioned, that the space within the database will only be marked as free, but the database won’t get smaller on your storage until you run an Offline Defragmentation.

A few words before we get into things:

As we say in Germany „the name is program“, meaning that the name says what is meant:

Offline Defragmentation means that you have to take the database offline when running the defragmentation, users won’t be able to access their mailboxes until you bring the database online again. This is one of two cons against the procedure of Offline Defragmentation. A way to come along with this is to simply create a new database and move all mailboxes to this database and delete the old one. The other one is running an DAG:

If you run a DAG, take the database on one Member Server offline, run the defragmentation and bring the databse online again it will be in the state „failed, suspended“. DAGs don’t work with Offline Deframentation. But I’ll get back later on this.

At first you might be interested in seeing how big your databases are and how much space can be reclaimed:

 

 

 

As you can see DB3 uses 203.5GB and there is a white space of 115.6GB. This means that the database will have a size of about  88GB after defragmentation.

It should be nothing new to you that there are a few operations in Exchange which consume temporarily more disk space and should be thought twice before you start them (like moving mailboxes creates a lot transaction log files which consume extra space until the next backup).

During Offline Defragmentation Exchange creates a temporary database which consumes 1.1x the size of the space being used after defragmentation:

In our example this will be for DB3 88GB * 1.1 = 96.8GB temporary disk space. If you don’t have enough disk space available you could add the /t option to define a place for the temporary database, which could be a UNC path on another server for example.

/t\\anotherserver\temp\temp.edb

Offline Defragmentation is being done with eseutil in the Exchange Management Shell:

At first you have to dismount the database:

 

Then you can start the defragmentation:

 

As you can see DB3 consumes now 87GB on disk and there is nearly no AvailableNewMailboxSpace.

If you paid attention to the outpout of eseutil before, then you should now run a complete backup of your Exchange Server.

 

I mentioned earlier that you must now run this when running a Exchange DAG. But how to reclaim disk space in a DAG?

Again: If you run it in a DAG you will get a failed and suspended database copy. You have two options to shrink databases: Move mailboxes to a new database or remove the database copy from other member servers, take the database offline, defragment, bring online again and add the database copies again.

In small environments with only two member servers and the standard edition of Exchange (where you can only have 5 databases in a DAG) moving mailboxes to a new database might not be an option because the lack of disk space (remember the /t\\unc-path argument!) or already 5 mounted databases.

When dealing with these short comings then Offline Defragmentation might be the only option for you.

To remove the database copy before you proceed run the following command in EMC:

 

After defragmentation is completed you add the database copy again:

 

I added -activationpreference 2 to define that MX01 should hold the passive copy of DB3 because I use MX01 as a passive database server in my backup strategy for this DAG.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.