Should You Defrag Exchange Server Mailbox Databases?

In a recent article I demonstrated how to defrag an Exchange 2010 mailbox database. Since publishing that post a discussion has been ongoing in the comments about some of the pros and cons of defragging databases, as well as the implications for databases in an Exchange 2010 DAG (because my article specifically said not to follow the instructions for DAGs).

So, first things first…

Should Database Defragmentation be Regular Maintenance?

For the answer to that question I’m going to refer to the most authoritative source on Exchange Server – Scott Schnoll, Principal Technical Writer at Microsoft.

What was I doing when he tweeted that to me? I was defragging some mailbox databases

But was I doing that as part of regular maintenance? No I wasn’t, and neither should you  In my case I was defragging some databases in a site where we have more than 200 mailbox databases. If I defragged 3-4 of those per week each database would still only get defragged once a year.

Of course I’d prefer that I never had to defrag them at all. For one thing it means working on a Friday night. Regular defrags would also probably suggest we’re not managing our capacity properly.  But there are other reasons not to as well.

Reasons Not to Defrag Mailbox Databases

So why shouldn’t you defrag a mailbox database? Well let’s consider what is involved in a defrag.

First the database is dismounted. Then the offline defrag occurs, which in effect writes a brand new database file of the data within the database, excluding the white space. Then the database is remounted again and, ideally, a backup is taken immediately.

So you can already see three pretty good reasons not to defrag databases.

• It requires an outage (at best this is an inconvenience for the business, at worst it may impact SLAs)
• There is the risk of corruption as the new database file is written
• It complicates your backup/recovery scenarios for periods before and after the defrag

Reasons to Defrag Mailbox Databases

But despite those reasons sometimes we have to be realistic about these things, and a defrag is necessary. Often in my case there are considerations such as:

• No additional storage available to create a new database to migrate the mailboxes to (or only available at significant cost)
• Migrations would take several days of minor outages for groups of users, instead of one single outage for all users on that database
• There are active alerts for low free space on the storage for that database that need to be cleared

So in some cases a defrag is the best (or only) course of action.

What about Exchange Server 2010 DAGs?

So why did I say in my previous article not to follow that procedure for mailbox databases on servers in a DAG?

The main reason is that it breaks the resilience of the DAG for that mailbox database. When you defrag a mailbox database you also then need to reseed it to all of the other mailbox servers that host a copy of that database. So for that period of time between the database being defragged, and the reseed completing, your database is not protected by the continuous replication of the DAG.

The second reason is that moving mailboxes within an Exchange 2010 environment can be performed almost as a no-outage scenario for the end user. In previous versions of Exchange Server if you moved mailboxes instead of defragging databases the end users still experience an outage either way. However in Exchange Server 2010 the client experience is much better thanks to online mailbox moves.

One commenter actually contacted Microsoft Support to see if there was a way to run the defrags on passive mailbox database copies. To my surprise Microsoft actually did have a process for this, but as you can see it is quite complex and in my opinion is more effort and risk than it is really worth.

What do you think?

What do you think about defragging mailbox databases? Is it something you do regularly? Or do you avoid it in favour of other methods of achieving the same outcome?

Leave a comment below with your thoughts.

Update – two good discussions going on about this in the Exchange Server Pros and MSExchange.org groups on LinkedIn.