Defragmentation is a vital part of any exchange organization. There are two types of defragmentation that every administrator should be aware of, as well as their differences, online and offline.
The first one we’ll discuss is online defragmentation. Online defrag’s occur as part of each database’s (mailbox and public) maintenance interval. These setting is usually set for 2:00AM to 6:00AM on the databases as seen below:
Now, there are several process that occur as part of this maintenance interval, including online defragementation. As you have most likely guessed, this is a period of heavy activity for the exchange server. You most likely wanted to stagger this interval with your backup windows, especially if your using the traditional streaming backups for exchange. This maintenance does not have to be run daily, and can be set to run on the weekends or at some other time. If it does not complete in the amounted time given, it will stop, and then pick up where it left off the next interval. While you can set it to run weekly, you want it to complete weekly, so make sure you give it enough time.
Okay, so after a little rambling, back to an online defrag and what the hell it does. An online defrag will go through the database and see all the items that were deleted from the mailboxes or public folders, and actually remove them from database. It then marks this deleted space as re-useable space or “white space” in the database. White space you ask? Drinking on the job you ask? Not usually, and not in this case. Exchange is a database program, consisting of the EDB file and STM file in Exchange 2003, and just the EDB file in Exchange 2007. This files grow only. Meaning if you have a 10 GB database, and some user deletes 5 GB worth of emails, that file is going to stay at 10 GB.
The benefit is that online defrag will return that 5 GB as white space to the database. This means that if you have 5 GB of white space, and someone add’s 2 GB of data to it, the database stays at 10 GB. Magic? Nope, it just put the 2 GB of data in the 5 GB of white space so it didn’t have to grow the database, leaving another 3 GB of white space for future data. Get it?
The process will actually show you how much white space is found. If you go to the application log in Event Viewer, and filter for Event ID 1221, you’ll see what I am talking about. The source will tell you if it came from a mailbox database, or a public folder database:
Now, if you look, it tells us that the Mailbox Store, in Storage Group “First Storage Group”, on Exchange Server 32DCEX has completed its online defrag, and has found 1 MB of free space. Now this is a test server with very little activity, but you get the point. It show’s you how it has opened space up for new data to be written.
Now, you want to know how to shrink that Exchange database. Well, that’s a job for Offline Defrag, handled manually by using the ESEUTIL.
Eseutil is a command line tool, found by default in C:\Program Files\Exchsrvr\bin. Eseutil can be used for a lot of things, including database recovery and repair, but we’ll cover those in a later post. For now, let’s concentrate on the offline defrag.
First, let’s discuss how Eseutil actually does an offline defrag, and the issues we need to be aware of. First and foremost, Eseutil cannot work with a mounted exchange database. So to perform an offline defrag, your databases need to be dismounted, which means your users won’t be able to connect to their mailboxes. Be sure to configure a specified downtime for the defrag. Second, you need to have 110% of the current DB size, free on your hard drive. Meaning if you have a 100 GB database, you need 210 GB of free hard drive space. What!?! That’s nuts!! It has to do with what Eseutil does. It actually creates a new copy of the DB, and reads the data from the old one and transfers it to the new one. It doesn’t transfer the white space, thus shrinking the database. However, you do need this space on the disk. After it’s done with the defrag, it moves the new DB into the old ones position and removes the old one. Let’s see how this thing works!!
First, dismount your stores. Go to ESM, right click on a DB and select Dismount Store. You’ll get a warning about users being able to connect. Select Ok.
Now, open a command prompt. You’ll need to navigate to the C:\program files\exchsrvr\bin folder to start Eseutil. Now, your going to run the following command:
Eseutil /d . If you have left your databases in the default location, it should be the following:
Eseutil /d “c:\program files\exchsrvr\MDBDATA\priv1.edb“
Viola, all done. Note it created a temporary EDB and STM file (Exchange 2000/2003 only), and then moved them to the correct location. It also informs you that you should perform a Full Backup ASAP!! This is because all of the previous backups will not work because you have changed the DB files dramatically.
Almost done. Now, what happens if you don’t have the disk space?? That could very well be the reason your doing this defrag. Thanks a lot Paul, a whole article and nothing!! Hold your horses, I got you covered. You can actually specify a location to create the temp database file on. So if your C drive is full from the database, and you have a D drive with plenty of space for the defrag, you can create the temp file there, and have Eseutil move it back over. Yay!!
Here’s how. Again in Eseutil in the command prompt, we are going to run the following command:
Eseutil /d /t
(I always hated those example’s, impossible to comprehend, well here is something more real)
Eseutil /d “C:\program files\exchsrvr\mdbdata\priv1.edb” /tZ:\exchange\sample.edb
Now, what this above command did, was specify to Eseutil to create the temporary exchange files, on the Z drive, in a folder called Exchange, and name the temp file sample.edb instead of a random number. See the actual command below:
Notice that command line. It finishes the defrag, and note how its created a new EDB file and STM file (Again Exchange 2000/2003 only), on the Z drive where we specified it? Notice that it then copies the temp to the name of the original?
There you go, we are all set. The last thing to do is re-mount the database, and run a Full Backup. You are all set!!
It should be noted that there isn’t a terrible pressing reason to run an offline defrag, unless you have a significant amount of space to be reclaimed, or instructed to do so by Microsoft PSS. Just make sure you have a full backup before attempting. With big databases, this can take a while, Microsoft estimates usually between 6-7 GB per hour, so if you have a decent sized DB, it can take some time, make sure you plan accordingly.