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.
Process to defrag Exchange Server 2016, 4 databases in DAG?
Hi Paul,
Thank for this post.
I have two Exchange 2013 servers, member of a DAG.
The C drive of the first one is runing out of space.
I’ve tried to delete all log file as I can, but it still runing out of space (This file in this case : C:\inetpub\logs\LogFiles ).
I also moved all the mailbox from the C drive database to D drive database but no space were gained.
Is there any solution to get rid of this issue. I’ve currently 0MB of free space on C drive.
Thank you.
Hi Dear
How to defrag exchange 2016 (and 2019) dag database best practice or best solution?
Thanks.
Greetings Paul,
I have an Exchange 2013 environment and I am trying to keep the DBs at a standard 400GB size. I have about 30 DBs right now and I do have the space to create more DBs and/or increase the size of each DB. It is my personal preference not to have DBs larger than 400GB for recovery or reseeding purposes. We also have alerts that let me know (and my boss and his boss) when we get below 10 percent in drive space. I have a couple of DBs that are below that now – I’ve moved mailboxes and have whitespace – but that doesn’t get rid of the alerts. I could change my standard to 450GB – but that would probably lead to 500GB and so on.
We have maintenance weekends and I could take the outage to do a defrag and reclaim the space. What would be your advice? I understand it is personal choice – but the advice of an expert would be appreciated.
Thanks,
Jack
I’d suggest to maintain your 400GB standard and simply create a new DB with DB copies and use that one up until you reach 400GB again.
Hi Paul ‘ve seen enough feedback on scenarios EX 2010 about DAG in Exchange 2013 works like ?
Now in my environment I have EX 2013 DAG 9 BD which together account for 524GB and running a powershell command to see how much space would be my gain after defragmenting said to be 23 GB. what do you recommend me…
The Real Person!
The Real Person!
Nothing. 23GB is a trivial amount of space for that size environment.
Hello Paul;
So what should i do if i need to Defrag the mailbox DB in exchange 2010 DAG, what is the steps exactly?
The Real Person!
The Real Person!
Create a new database, add database copies, migrate mailboxes, remove old database.
Hi Dear
How to defrag exchange 2016 (and 2019) dag database best practice or best solution?
Thanks.
I have a EX2010 in which I’ve started to split the mailbox databases, so now I have the original @ 250GB, and 3 others at 80-90 each. Once I’ve moved the last mailbox out of the original do I just delete it? Is there anything else that needs to be done re the search functions or anything else?
Thanks
Nu
Hi,
I have a 270 GB mbx database, with 257 GB whitespace in it, which is hosted in a DAG member but not replicated. The DB hosts only disconnected mailboxes that cannot be deleted due to compliance reasons for the next 2 years.
If I understand correctly, defragmenting this DB will not affect the resilience of any other DB copy on the server, can you confirm that please?
Thanks.
Kind Regards,
Gabriele
So I run the defrage on my test environment and closes the powershell before the process ended. How do I get the status bar back? Is there a command to show me the %% of the running defrag?
Thanks
The Real Person!
The Real Person!
Eseutil is an interactive process… if you closed the window that likely killed eseutil.exe and the defrag would have stopped.
You are absolutely right 🙂 found this in the hard way.
Thanks. Love your posts. Easy, clear, cut to the chase.
Also,
Assuming my colleague logged in to the Exchange with his username and started a defrag process, can I, from my profile review the progress of the defrag? is there kind of a status command for this?
Thanks
The Real Person!
The Real Person!
No I don’t think so.
Great Post, Although in my situation I have a DAG and 18 DBs (all 1 TB Drives) that seem to be filling up fast, we migrated from 2007 to 2010 last year. One particular DB seems to be growing 1-2GB per day, I’ve no idea how this is happening and spent ages googling, so I’m going to move all mailboxes to a new DB I’ve created, then in effect delete the huge edb file on the original and then migrate other mailboxes on DB’s that are also getting large to that DB, Does this sound OK? any better suggestions?
I do not recall if I ever did it with Exchange 5.5, but I might have done it with EX2003 and/or EX2007. I guess I did prefer moving the mailboxes to a new DB. In EX 5.5 days we had been badly attacked through the default MS-ftp service running and poorly protected on windows servers – ok in 2001 I was completely new to Exchange servers and I took over from a collegue who had left – so I was not even aware that this service was running on most of our windows servers. So I rebuilt most of the windows servers from scratch and amongst them three Exchange 5.5 servers spread across 3 remote sites and connected through a dedicated line (modems in those days). I installed a fresh server, adding it to the existing Exchange Organisation, created new DBs on it and moved all mailboxes on it. Then I removed the three hacked servers from the EX Organisation, built them up from scratch and redistributed the mailboxes on them. If I am not mistaken, to avoid moving the mailboxes over the slow lines, I moved to the remote sites with my new Exchange server to do it on the local lan or vice-versa, moved the remote servers into my office to do it over a week-end down-time. I do not recall exactly whether I really moved the mailboxes or whether I simply restored all DBs to my fresh server from Tape or every DB to its rebuilt server. But either technique is good in disaster recovery scenarios.
I remember also having repaired a DB once or twice with 5.5 and probably also with 2003. But again, the down-time might not be worth the work, as you are quicker creating new DBs and moving the mailboxes over on them.
With EX07 I moved mailboxes and then deleted and recreated the DB with the same name. I do not remember if I took the effort of moving back the mailboxes. Probably not, as we had to do it because we might have suspected a corruption in it preventing Free/Busy Times from being updated correctly. So we probably used the new DB with its original filename and location on disk to create new mailboxes on it.
In another case, still with EX07, we had reached the available space on disk. So we had to move the mailboxes onto a new DB on a bigger SAN-Disk. But as the DB Disk was roughly 100 GB and the LOG-Disk only 20 GB, we hardly experienced that Exchange was doing its job very well, Transaction-logging every data move including the data moved into its log-files! So the Log-Disk filled up with the first 20 mailboxes moved or so. Hence we had to move about 15 mailboxes per night, then wait for the Backup-Task to finish and purge the transaction logs and start over next night with another 15 mailboxes.
Ok, we learned by doing, as the installation was made by a specialized Exchange-Firm, we blindly trusted them, and I never had noticed that moving mailboxes would make the transaction logs grow. Maybe this had changed from earlier EX versions or my Log-Disks were always big enough then. But in those days SAN-Disks began to become more comfortable, so that you could enlarge and grow up your disks dynamically without down-time. So this is really what is becoming the real reason why you do not have to defrag your DBs any more. They are re-fragmented anyway if you have high activity as we do with roughly 20’000 Mailboxes.
With EX2010 finally, we are experiencing another fancy case: moved mailboxes to a new DB, deleted the old one, and BINGO: our HP Data Protector Granular Recovery Extension reports an error and stops, saying the original Database is no longer in the Exchange Topology!
So again, be careful with those operations. For the moment being, I do not know whether I can simply create a new DB with the deleted one’s file name or whether the DBs get unique IDs in the Active Directory and could hence be restored only through a major restore of the whole Exchange and AD at a given point in time. But as more than a day has already passed, a major restore is not acceptable any more. We must find a solution to restore the deleted DBs in case one of our users makes a request to do so. If anyone knows whether we can apply the same trick which worked with EX07, recreating the DB with the same filename, let me know.
Rosario
First of all best wishes from India and thank you very much Paul sir, for sharing these great articles, i am a beginner to Microsoft Exchange Technollogy and initially i found it very difficult, however, since i have been following you and going through your articles, it seems easy to me and i am very much confortable with it now,
i will hightly apprecaite sir, if you can suggest me few tips, as i have recently started my career and want grow with this Technology.
Thanks and regards
Showkat Mir
Relevant to this topic (defrag or not defrag?), I noticed event ID 629 on our mailbox servers and the first thing that most people suggested after a quick google search,
Possible Cause: either a HW issue or a SW issue (third party plugin, etc), I thought could be SW since we have outlook plugins like CRM.
Possible Fix: increase the maintenance window, offline defrag, move mailboxes, delete DB and create a new one.
Here’s the event
Log Name: Application
Source: ESE
Date: 2/16/2014 6:42:09 PM
Event ID: 629
Task Category: Performance
Level: Warning
Keywords: Classic
User: N/A
Computer: mailbox server 1
Description:
Information Store (5560) DB2: Database ‘G:DB2DB2.edb’: While attempting to move to the next or previous node in a B-Tree, the database engine skipped over 16121 non-visible nodes in 51 pages. In addition, since this message was last reported 3 hours ago, 0 other incidents of excessive non-visible nodes were encountered (a total of 0 nodes in 0 pages were skipped) during navigation in this B-Tree. It is likely that these non-visible nodes are nodes which have been marked for deletion but which are yet to be purged. The database may benefit from widening the online maintenance window during off-peak hours in order to purge such nodes and reclaim their space. If this message persists, offline defragmentation may be run to remove all nodes which have been marked for deletion but have yet to be purged from the database.
Name: MSysObjects
Owning Table: MSysObjects
ObjectId: 2
PgnoRoot: 4
Type: 2
Unversioned Deletes: 16121
Uncommitted Deletes: 0
Committed Deletes: 0
Non-Visible Inserts: 0
Has anyone seen this before? Any words of wisdom would be highly appreciated!
Thanks as always!!!
The Real Person!
The Real Person!
“…offline defrag, move mailboxes, delete DB and create a new one.”
Kind of pointless to defrag if you’re then going to move the mailboxes and delete the DB 🙂
You could try an ISInteg to fix the DB but if you’ve got the storage available then I’d just move the mailboxes to a new DB and delete the suspect one (since ISInteg requires an outage etc)
Thanks for the quick response.
My bad, I meant to say either offline defrag or move mailboxes, delete and create new DB 😉
In the end decided to delete and create a new DB, so far so event 628 or 629. Have not moved any mailboxes yet but will do slowly (in batches). I have also decided to update CRM outlook plugin for our CRM users (still deciding between RU 15 and RU 16, for MS CRM 2011).
Hope that makes these events go away, fingers crossed!
So what about 3rd party software, like Go Exchange Maint that offer schedule defrag, is that a waist of money?
The Real Person!
The Real Person!
I’ve never heard of it, but it sounds like a waste of money to me.
Hi Paul,
excellent articles you have written here on the blog. I follow it regularly and it had helped me a lot in difficult situations and a big thank you for that.
Now, I am surprised again 🙁 and I would like ask you for advise. The problem is a shortage of free space. We run a Exchange 2010 system on 2 local servers with DAG. Normally we have circa half of the volume free and I must not worry much about free space. Recently however, we did a lot of moving and migration of mailboxes so suddenly the free space amount drop dramatically below the dangerous level.
After initial investigation, the problem turns out to be one “old” database, which most of its mailboxes are already moved into an another database, but its size remains unchanged (of course). It is around 700 GB big with only above 100 GB free on the volume left.
Now, my question is what might be my best strategy to get the free space back:
– Moving all the mailboxes of it into a new DB one, on another volume then drop the old database? or
– Doing an offline defragmentation and shrink the old database in place?
Normally I would chose option 2, but because the mentioned database is a DAG member, I have some reservation. The whole process maybe to complex and take too long so on the next business day, users mailboxes maybe not available.
Option 1 will however create additional Logs (on the old, free space ridden volume) if I understand it correctly. So by about 100 GB of free space remains, the risk is not minimal either.
What would you advise me as my best option?
Many thanks.
I am really enjoying this forum and expert suggestions
Vis
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!!
The Real Person!
The Real Person!
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 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.
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 Real Person!
The Real Person!
The Exchange 2010 Best Practices Guide is excellent, as is Exchange 2010 Inside Out. I also like the Exchange 2010 PowerShell Cookbook.
Pingback: Should You Defrag Exchange Server Mailbox Databases? « MidThought's
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:))