Some people still believe that it is a good thing to run the ESEUTIL utility to defragment or rebuild an Exchange database. I can’t see why this myth persists, so here’s an attempt to drive a stake into its heart.
ESEUTIL is a blunt instrument that was badly needed in the early days of Exchange. By this, I mean Exchange 4.0 (1996), 5.0 (1997), and 5.5 (1998). Microsoft wasn’t too good in those days at reusing the white space that exists inside ESE databases and disk space was expensive. ESE databases swelled over time and the only way to recover disk space to the system was to run ESEUTIL. This approach worked and it had a nice side effect in that any lurking corruption such as a failed checksum that existed within the database might be fixed by ESEUTIL as it examined and validated each page from the source database before writing the page into the new database.
There are lots of articles to tell you of the wonders and benefits to be gained from a good database defragmention (for example, this one on msexchange.org). Most of these articles were valuable in their time but are now out of date and should be read with caution, even if you’re running Exchange 2003 or Exchange 2007. Best practice evolved over time and everyone you met at a conference was sure that running ESEUTIL was a great thing to do; it became a form of colonic irrigation for Exchange, something that flushed all the bad stuff out and made Exchange feel better all over.
In this context, “bad stuff” means corrupt pages – but of course, if the database rebuild dropped corrupt pages, it means that your brand new database has just lost some data; the dropped pages might be index pages or contain mailbox items. No one might notice, especially if the pages store old information that should really have been deleted a long time ago, but the sheer fact that data loss could occur when you rebuild a database should set a red flag for ESEUTIL.
A couple of things happened around 2003 to undermine this particular “best practice”. First, Microsoft got their collective act together and fixed the internal Store maintenance so that white space was used more efficiently. From Exchange 2003 onwards, I had no problems telling customers that they should not run ESEUTIL unless they were told to do so by Microsoft Support (and had received a very good reason for running the program – in other words, this couldn’t be a “Hail Mary” kind of last-gasp pass when the support professional had no other suggestions to offer and merely wanted to keep the customer busy while they figured out what to do next). The improvement has continued over Exchange 2007 and Exchange 2010 and today Exchange 2010 can do intelligent things like single page patching when databases are deployed in a Database Availability Group (see this post for more detail).
The steadily dropping price of storage is the second reason why ESEUTIL became a lot less important. In the old days, when people counted storage in megabytes and fretted over users who had the temerity to send a message containing a 1MB attachment, running utilities to recover disk space seemed like an excellent system management activity. Today, when terabytes are cheap and we’re all discussing 25GB mailboxes, the prospect of recovering a few hundred gigabytes seem a lot less attractive. I know that the smaller rebuilt databases are easier to backup but that forgets the salient point that a rebuilt database begins to swell back towards its original size as soon as you bring it back online.
Databases have a “natural” size of their own and the trick is to provide enough storage to allow databases to run without administrator interference for months at a time. In this respect, it’s interesting to point out that circular logging is no longer a bad thing for a production Exchange server (another best practice hits the dirt). If you run databases in a DAG and have at least three copies, you don’t need to disable circular logging as the databases are protected by having sufficient copies available to recover from most problem situations. (Public Health Warning: your mileage will vary – a database copy on a flaky server is worse than useless).
Deploying multiple database copies within a DAG is not an excuse to avoid backups! Do not believe the propaganda on this point. Although Exchange 2010 includes some very good high availability features, it’s no reason to lose all sense and wisdom of good system management practices by discarding the safety net that a solid backup regime provides. If things ever go south, you’ll be happy to have backups available. And if someone tells you that they don’t use backups anymore because they rely on database copies, look at them in the same way that you’d regard an errant child who you’ve just caught before they inserted a wet finger into an electricity socket. They are either smoking some interesting material or they have the extreme luxury of having the Microsoft Windows and Exchange development groups on hand to sort out any problems if their servers or disks explode.
So can there be good reason to run ESEUTIL to rebuild a database? Absolutely! It may be your only get-out-of-jail-free card to play to rescue a corrupt database, even if you end up losing some data. However, I would make sure that Microsoft support is happy with you running ESEUTIL before you actually do it. Remember too that rebuilding a database renders all transaction logs null and void because they won’t match the new database, so be sure to take a full backup immediately you have brought the new database online and made sure that everything works.
Another reason for running ESEUTIL to rebuild a database might be after you move or delete a heap of mailboxes out of a database. This happens in educational establishments where they remove student mailboxes every year and I can see good reason to “reset” a database after deleting all the mailboxes.
But apart from these instances, I can’t think of why I would want to take a database offline for several hours – even at a weekend (or most definitely at a weekend when there’s usually much better things to do) to reduce performance against SLA for user access in an attempt to create a slightly smaller and possibly perhaps maybe a more efficient database. It just doesn’t make sense. I’m sure that some others will propose good reasons for running ESEUTIL to rebuild a database and that’s just fine – as long as you have thought things through and concluded that this is absolutely the only way to accomplish your goal, then have at it… but don’t expect this utility to be the proverbial magic bullet that makes up for months or years of database neglect.
The latest Microsoft support article on running ESEUTIL is KB328804. If you’re interested in more diatribes against bad Exchange management practices, come along to the Exchange 2010 maestro training sessions, or just get a copy of my Microsoft Exchange Server 2010 Inside Out book.
In the case of customers who are vacating large percentages of users off databases in big blocks (e.g. EDU customers you mentioned), I have to wonder if the labor of the defrag doesn’t outweigh just vacating the whole DB, dropping in a new one and moving folks back on to it? Especially with online mailbox move this seems way easier.
True… Like everything, you have to weigh up the options. However, moving mailboxes around won’t release disk space to the system, so if you have a database that contains 2,000 student mailboxes that are now deleted, the database will stay the same size and that’s a big deal for some people.
What you do is move the mailboxes to a new store first, and then whack the old store (you probably want to take it offline and make a copy to tape, just in case you forgot to move someone…) That’s half the work Brian suggested. 🙂
Ah but you don’t want to simply whack a database as it might contain mailboxes such as federated mailboxes or discovery search mailboxes… It’s still not a reason to run ESEUTIL IMHO…
I am trying to figure out the best approach to shrink our current Exchange 2010 SP1 databases. We noticed it can take 12 hours to do a full DB restore and want to get that down to 4 hours. We want to take our current 2 DB’s housing 1900 users and move mailboxes from them to new DB’s to balance out the size of them. The two main DB’s are around 350 GB each and we would like to get this down. I am thinking of moving about 200 mailboxes per new DB which will allow the DB’s to be fairly small in size to start (60-70 GB). Any recommendations on how to accomplish this? Move all users from our (2) large DB’s and whack the DB or move all users and run ESEUTIL on those so I can move 200 users back to them? Thanks!
How much white space exists in the current databases? It seems like you’re saying that they are 350GB each and should be 60-70GB. If that’s true, it seems a tad excessive in terms of database efficiency and you’d wonder why such a state exists.
Hey Tony, I have a client who is in the process of purchasing a new system to upgrade their Exchange system. They currently have Exchange 2003. Storage is maxed out and running critically low on space. There is white space that I would like to reclaim. What is the best way to do this if ESUTIL is not a good option? Thank you. -Leo
They need to add more storage. If they are running low on storage now then a) it’s a far bet that this will happen again in the future, b) they will need extra storage to run ESEUTIL to recover whatever space they can, and c) I doubt that the space recovered through hours of ESEUTIL will make much difference in the long run as Exchange will simply fill up the white space with new transactions.