Exchange Server 2003 performs a daily automated defragmentation as a part of its scheduled maintenance. While this online defragmentation helps to keep the database performing well, it does nothing to shrink the database's physical size. Instead, it leaves empty space within the database, which Exchange can later reuse. The only way to get rid of this white space and shrink the database size is to take the database offline and run the ESEUTIL /D command.
The question is whether performing an offline defragmentation is really worth the effort. There is nothing complex about running an offline defragmentation, since it only involves entering a single command. But it does tend to be rather time consuming.
I can't tell you exactly how much time an offline defragmentation of your database would take, because it really depends on your hardware. What I can tell you is that, in the real world, I have seen offline defragmentations process anywhere from 1 GB an hour on a really old server to 5 GB an hour on a high-end server.
Although downtime is certainly a big consideration, you must also think about the risk to your databases. In Exchange 5.0, it was not at all uncommon for a database to become corrupt during a defragmentation. Therefore, the general rule was that you should only defragment if absolutely necessary.
Over the last few versions of Exchange, however, Microsoft has made the database much more stable. If you are running Exchange Server 2003, the chances of an offline defragmentation corrupting your databases are pretty slim -- but it does still happen occasionally. So, if you are considering an offline defragmentation, I strongly recommend backing up your server first. You should also make sure that you know how to restore the backup and are prepared to do so if the defragmentation does trash your database.
Ultimately, whether or not the defragmentation process is worth the risk and effort really depends on what you wi...
To continue reading for free, register below or login
To read more you must become a member of SearchExchange.com
ll get back in free disk space. If you are running Exchange Server 2003 Enterprise Edition, it's unlikely that you will find yourself in a situation that justifies an offline defragmentation, because there is no database size limit.
If you are considering defragmenting because you are running low on disk space, then you probably don't have enough free disk space to defragment anyway. The process requires you to have free space on your hard disk equivalent to the database size plus 10%. If you don't have that, your only options would be to upgrade your hardware, so that you have more storage space, or move the databases to a different location.
If you are running Exchange Server 2003 Standard Edition, things are a little bit different because you need to stay below the 16 GB database size limit. If your database size is approaching 16 GB, then defragmenting might seem like an obvious way of staying within Exchange's limits.
Before you go through the trouble of defragmenting though, check and see how much disk space you will really gain as a result. There are a couple of ways of doing this. One way is to search your application log for Event ID 1221. This event will tell you how much free space exists within the database. For a more current estimate, run the ESEUTIL/MS command. This command will produce a cumulative value when it completes. Multiply the value by 4,000 and it will tell you how many bytes of white space currently exist within your database.
In my opinion, about the only situation that justifies an offline defragmentation is if you have deleted a lot of mailboxes from your server, and those mailboxes are not going to be replaced. This would mean that the database probably contains a lot of empty space that is not likely to be reused anytime soon. Aside from that situation, you are usually better off avoiding offline defragmentations.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
MEMBER FEEDBACK TO THIS EXCHANGE SERVER TIP
While running Exchange 2003, you can create a new mailbox store on the same server. Moving all accounts to the new database will recover the free space. Each user will be minimally impacted as they are moved. You can schedule the moves for off hours. Delete the vacant database when done.
—Bryant W.
******************************************
A speaker at TechEd 2004 Europe talked about this along the same lines, but went into a lot of detail on how an unnecessary defrag can actually degrade the performance of Exchange in minor ways. This is because Exchange can make more efficient use of the white space freed up within a database that has been defragged via the online processes.
When a database is defragged and shrunk offline, it then has to use extra processing power to expand the database again with each transaction committed from the log files. Other reasons were also mentioned, but I can't find my notes...
—James T.
******************************************
What does Brien really recommend?
In this article he states, "You are usually better off avoiding offline defragmentations."
In another article titled Exchange Server Standard Maintenance Checklist he recommends, "performing an offline defragmentation once every one to two months."
Personally, I don't believe in doing an offline defragmentation, and would certainly agree with this article. The costs of doing one rarely, if ever, outweigh the benefits. In my opinion, recommending that someone should perform this task every one or two months is very poor advice to be given by anyone, much less an MVP.
Maybe Brien learned the error of his ways sometime between writing the articles? What's the real scoop?
—Jeff J.
******************************************
At the time that I wrote the article Exchange Server Standard Maintenance Checklist, I advised an offline defragmentation every couple of months, because that was the advice I had always been given by various Exchange experts. Later, I became curious about just how much of a benefit you really see from doing an offline defragmentation, so I did a little experimentation and research.
The result was this article that I wrote, "Is an offline defragmentation really worth it?" My current opinion about offline defragmentation is that, in most cases, doing one won't hurt anything; but you will only see a huge performance gain in extreme cases.
—Brien Posey, tip author
******************************************
I fully agree with this article. We recently had some databases with 4GB of white space free -- that is a lot of space (if you add all the space up) to just leave on a server. In this case, we ran an offline defrag, saved the disk space and moved on.
—Eugene V.
******************************************
Are there any "gotchas" on freeing up white space on an Exchange Server 2003 Enterprise cluster (active/passive)?
—Mino F.
******************************************
I don't know of any "gotchas," but I have never tried an offline defragmentation of a clustered disk, and I don't seem to recall anyone ever mentioning that they tried it.
—Brien Posey, tip author
******************************************
Good article; it's very useful. I have a related question:
We are beginning to see end-user performance problems on Exchange Server 2003 Enterprise Edition. It has been suggested internally that disk fragmentation may be a cause. However, having witnessed database corruption following an offline defragmentation in the past (Exchange 5.5), I'm apprehensive to perform offline defrags on our 118 live Exchange stores.
We have not recently deleted a large number of mailboxes and the online defrag appears to be doing its job well. Do you think database fragmentation is the likely cause of this poor end-user performance?
Also, you mention the command ESEUTIL /MS. Will this only report the amount of fragmented space available to recoup or will it give a more detailed report indicating how badly fragmented a store is? Is there an alternative command that will report the amount of fragmentation (preferably as a percentage, similar to results achieved by Windows defrag tools)?
—Paul S.
******************************************
Fragmentation could be a possible cause for end-user performance problems, but I would recommend checking the Exchange server's memory resources too. Memory is more often the culprit.
I can understand why you are apprehensive about running an offline defragmentation. Exchange Server 5.5 was notorious for introducing corruption during offline maintenance. Exchange Server 2003 is MUCH less prone to corruption than Exchange 5.5 was. There is usually nothing to worry about, unless corruption already exists.
As for your question about ESEUTIL, I do not know of an alternate command.
—Brien Posey, tip author
******************************************
The one thing I haven't seen mentioned regarding offline vs. online defragmentation is that you are able to maintain the "Keep deleted items for 'x' days" information.
[IMAGE]
When you move a user to another Exchange information store, you lose that data. It may not mean much to some companies, but it may be something to consider for others -- especially ones running differential backups.
—Tyler H.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip is via the rating scale below Do you have a useful Exchange Server or Microsoft Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
