Is Weekly Online Defrag of SBS 2003 Exchange Store Frequent Enough?

Question

(this post is a bit lengthy, so advTHANKSance for those who who stick with it to the end)

I have a client whose SBS 2003 server suddenly started crashing every night. The symptoms of the crash itself were weird. Generally the system would just freeze. I could still see the Windows interface on the screen, but the system itself was unresponsive to mouse and keyboard actions. Eventually I'd have to hard-boot the server in order to get it operating again (ugly).

After reviewing the system logs I noticed that the crashes were happening shortly after the online maintenance processes on system's Exchange the Private Store had begun. The online maintenance was scheduled to occur every night during off-hours. I believe it was set for 1am-4am.

Since the online maintenance processes were a precursor to a crash, I disabled them all-together until I could figure out the true underlying cause of the problem. For instance, I wanted to make certain that the problem wasn't related to faulty hardware.

A couple of weeks passed after disabling online maintenance and the server ran just fine, but I noted that the Exchange Store size was growing faster than usual. I chalked this up to the fact that things like online defragmentation weren't happening. I knew I'd need to eventually get the online maintenance tasks running again, but I couldn't schedule them to start on a weekday night because the server was required for production tasks first-thing every weekday morning.

One hunch I had about the crashes is that the online maintenance processes were butting heads with other scheduled tasks that were happening at about the same time (eg, VSS processes, backups, etc).

In order to test that hunch I set the online maintenance of the Private Store to occur during the wee hours Sunday morning and made certain that no other scheduled tasks were slated for the same period.

I fell asleep Saturday night fully expecting to wake up and find that the server had crashed by the time I woke Sunday morning. To my relief, it hadn't crashed. I checked the system logs and noted that the online maintenance processes had completed successfully.

So as it stands, I'm inclined to allow the online maintenance processes for the Exchange database on this particular server to run weekly (every Sunday morning) for a while. This will allow me an opportunity to see whether my hunch is correct or if there's some other underlying problem (like faulty hardware) that needs to be corrected.

My question is (and thanks for reading my 'novel' up to this point)... Is it adequate to allow online maintenance processes to occur once a week instead of every night? What's the downside of not performing this task every night?

Answer 1

The database maintenence process cleans up items that are beyond the retention date configured for the mailbox store as well as performing several other tasks. It allows new items to be created without having to grow the physical file size. I would look at the Deleted Item retention setting and make sure they're appropriate. As for the physical file size, an online defrag won't shrink the physical file, only an offline defrag will do that. If you think that the file growth is outpacing the database maintenence then you should look at reducing the deleted items retention time. As far as whether or not the mailbox store maintenence is causing the crash, it depends on how big the database is and how much work is being done cleaning it up. I can tell you from my experience that I think it's doubtful. If it is, it's possibly due to inadequate or faulty hardware. I manage an Exchange 2003 server (Enterprise Edition) with 4 mailbox stores all exceeding 100GB, comprised of 650 mailboxes and I run the mailbox store maintenence process with no problems.

The one point I would make is that you should schedule the mailbox store maintenance and your backups in different time windows as the two can't run at the same time. The malbox database maintenance process will stop when it detects a backup has started. If the two tasks conflict then your database maintenence process may never be completing. It will pick up the next time where it left off. You can check the Application event log for Event ID 1207 which signifies that the cleanup of items past the retention date is complete, Event ID 1209 which signifies that the maintenenace task is complete, and Event ID 1221 which signifies that the online defrag is complete.

Also note that the process will run for a minimum of 15 minutes and a maximum of 1 hour. The time you configure in the maintenance schedule is the time in which it CAN run, not the amount of time it WILL run.

Here's a rundown on what the process does:

http://support.microsoft.com/default.aspx?scid=kb;en-us;324358

Answer 2

Purely asking about the defragmentation, the answer would be "it depends." How fragmented is it in the first place? How heavily used is the mail server? A barely used mail server will hardly suffer much fragmentation in the first place.

I suppose you could get a ballpark estimate by looking at how long the job takes. Is the job fitting easily into the maintenance window you've allowed for the defrag?

If the defrag you run is fitting into the time you allot, and you're not running into performance issues between runs (or soliciting errors), then yes, it's enough to use your workaround scheduling to defragment the store.

Defragmenting isn't something that's meant to keep the Exchange store running. If you never defragment it the Exchange server won't die. Performance may degrade over time and eventually crawl but it won't just up and lose data or corrupt just because it's not defragmented.