One of the questions that I am asked most often about Exchange is why the database size doesn't change after an administrator deletes a bunch of old mailboxes or public folders.
Unfortunately, there is no easy answer to this question. The answer is that the database size does change, but the file size doesn't.
When you delete mailboxes or public folders, you are actually removing records from the database, thus freeing up space within the database and decreasing the actual database size. This doesn't, however, do anything to shrink the database's file size. You can change the file size only through defragmentation.
You are probably familiar with defragmentation as it relates to file systems. When you create and delete files on a hard disk, the disk becomes fragmented over time. Read and write performance is decreased by fragmentation because Windows is not able to perform a single read or write operation when reading, creating or modifying a file. Instead, the read and write heads must jump around the disk reading various file fragments or writing data wherever gaps of free space are found.
What you might not realize is that fragmentation occurs within databases, too. As mailboxes are created and deleted, the database itself becomes fragmented in a similar manner to the way that a file system would become fragmented. Just as a fragmented file system performs poorly, so too does a fragmented database.
Defrag automatically
To help boost performance, Microsoft has enabled an automatic defragmentation feature in Exchange 2000 and Exchange 2003. This feature automatically defragments the various Exchange databases each night between 1 and 5 a.m.
Automatic defragmentation offers several useful features. First, you don't have to defragment the databases yourself (you still have to defragment the file system, though). Second, the databases remain online during the defragmentation, so mail is still accessible. Third, if the defragmentat
To continue reading for free, register below or login
To read more you must become a member of SearchExchange.com
ion interferes with some other operation, you can reschedule it.
If you want to change the automatic defragmentation schedule, just open the Exchange System Manager, right click on the desired database, and select the Properties command from the resulting shortcut menu. When you do, you will see the database's properties sheet. Now, select the properties sheet's Database tab and click the Customize button found in the tab's Maintenance Interval section. This will let you customize the defragmentation schedule. You need to set the defragmentation schedule individually for each database.
Backup before and after
Now that I have explained how automatic defragmentation works, let's go back to the original question. Why doesn't the file size change when you defragment an Exchange database?
The reason why the file size doesn't change has to do with the database itself. The database's header allocates a specific amount of space to the database file. Defragmenting a database moves the records within the database around so that the database will perform better, but it does not condense the database. The database file is still consuming unnecessary disk space.
The only way to reclaim this lost disk space is to manually perform an offline defragmentation. The reason why an offline defragmentation isn't performed automatically is because doing so requires the databases to be taken offline, which means that mail is not available during the defragmentation.
Before I explain how an offline defragmentation is performed, I want to give you a few words of caution. You must perform a full backup both before and after an offline defragmentation. It's important to perform a full backup prior to a defragmentation because the defragmentation process actually rewrites the database and there is a lot of room for things to go wrong. You need to have a full backup ready to fall back on should something go horribly wrong.
It is also necessary to perform a full backup after defragmenting because an offline defragmentation will render incremental and differential backups invalid. If you try to perform an incremental or a differential backup after an offline defragmentation, the backup will attempt to back up records that have moved and the backup will be invalid.
How to perform offline defragmentation
To perform an offline defragmentation, simply take the database offline and run ESEUTIL with the \D switch. In Exchange 2000, the ESEUTIL program is located in the \SUPPORT\UTILS folder of the Exchange 2000 installation CD. In Exchange 2003, ESEUTIL gets installed to the server's hard disk automatically and may be found in the \Program Files\EXCHSRVR\BIN folder.
One thing that you need to know about defragmenting with ESEUTIL is that ESEUTIL creates a brand new empty database, copies the necessary data to it and deletes the old database. This saves disk space, but it also means that if something goes wrong then you don't have your old database to fall back on.
I recommend using the \P switch in conjunction to the \D switch. The \P switch tells ESEUTIL to preserve the old database. You can then manually delete the old database once you are sure that the new database is functioning correctly. Just make sure that your server has sufficient space to store both databases before attempting an offline defragmentation.
For more information on offline defragmentation, check out Microsoft Knowledgebase article number 192185.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the 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, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have a useful Exchange tip to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
