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.
About Paul Cunningham
Hi
first of all nice article
second, part of my design to migrate around 40,000 users dag and the whole thing is to “leave” one lun or two “spare” if i can(if i have enough disks after reconfiguring the storage to raid 5 instead of raid 10) so that i can always move mailbox(whole stores) online and get rid of any major white spaces.
these might happen since we have specific situation here were some group of users are always moved in and out of dedicated stores that are the only one with multiple site recoveries capabilities.
since databases are bigger then before i dont think defrag is the way to go anymore.
(but maybe its just me:))
Hi Paul,
I have the TrainSignal Exchange 2010 on order and wondering would you suggest I also get any reading material and if so what would be the books names? I have been out of the MS Exchange world since 2003 and really didn’t didn’t do much besides basic administrator and I am now looking to rehone my skills.
Kind Regards,
Kevin
The Exchange 2010 Best Practices Guide is excellent, as is Exchange 2010 Inside Out. I also like the Exchange 2010 PowerShell Cookbook.
I totally agree with you, defraging a database is sometimes risky, i had a very bad experience in past where my server got rebooted during the defrag process and the DB got corrupted, god knows how. And, the worst part was the backups were not current, the company had 2 months old backup. The local IT guy didn’t know that the backups are failing since last two months. Ultimately we have to convert OST’s to PST’s and mount a blank database. We had to import those PST’s back. It was doable because total number of users was only 40.
Quick question:
I have a database which is 1 TB in size (yes, really – inherited this environment). I have built new databases, and begun the process of taking these HUGE databases, moving all mailboxes off each one and redistributing them amongs these multiple new smaller databases. I have moved ALL but one user off the current database I’m working on, and am ready to reclaim 1TB of space and move on to the next one. HOWEVER, the one mailbox left on the database will NOT move. It hangs at 10% – I’ve even left the move request running overnight. It shows no corrupted items in the move process, and no good info in the event logs. Resarch online seems to indicate that there is simply some corruption preventing the mailbox from being moved, and the only way it seems this can be fixed is to export everything out and then import it back in to a new mailbox. I have run a mailbox repair and a database repair, and still no joy – if there’s corruption, it’s invisible corruption that doesn’t show up anywhere. That being said, I am debating on performing an offline defrag to reclaim the space, and just leave this fool mailbox where it is.
My question, now, is do I need over 1TB of space in order to do a defrag, when the single mailbox left on it (affecting the resultant database size) is only 2GB? I know in previous versions of exchange you needed 100%+ of the size of the database free someplace in order to do an offline defrag, and I am pretty sure there is not 1TB of space available anywhere for me to use for an offline defrag, even though I’d just be temporarily using it during the defrag process.
Thoughts? Anyone dealt with similar situation before, and if so what did you do to resolve (if not offline defrag). Any help would be appreciated.. Thanks!!
You need free space equivalent to 1.1x the predicted size of the new database.
You can use a temporary folder for the defrag if you need to.
I am really enjoying this forum and expert suggestions
Vis
So what about 3rd party software, like Go Exchange Maint that offer schedule defrag, is that a waist of money?
I’ve never heard of it, but it sounds like a waste of money to me.