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.

– Tony

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.