There seem to be 2 schools of thought on offline defrags. Some say they should be performed at regular intervals to ensure the integrity of your exchange databases, whereas others say they are a risky procedure that should be undertaken carefully and only when absolutely necessary. So, what is the recommended practice?
Event 1221 in the application log will show how much white space exists in your exchange databases. This appears once per mailbox store at the end of the online maintenance period:
Event Type: Information
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1221
Date: 08/08/2006
Time: 06:00:02
User: N/A
Computer: S05010025
Description:
The database "1st Storage Group\Mailbox Store (S05010025)" has 39368 megabytes of free space after online defragmentation has terminated.
Personally I would not worry about a few gigs of white space as it will be reclaimed fairly quickly. As WAN and Broadband links become stronger, Exchange is more abused as a method of sending and storing large files. 40Gb of free space (as above) is worth reclaiming though. Bringing the database size down by 40Gb will significantly reduce the backup, and more importantly, restore times, and reduce the number of tapes used from week to week (and therefore the overall cost of Exchange to your company). There are a few other instances where you might carry out an offline defrag:
- When your mailbox indexing is completely hosed
- If your disks are extremely fragmented, and your server is too busy during the online defrag period to make much difference.
In my last company, users were using public folder trees as a ‘check in, check out’ document management system. This caused very heavy fragmentation of the database until we moved the folder trees to their own server which had more spindles.
Before launching an offline defrag, make sure you have a good backup of your store. Also ensure you have enough free space on your drive (110% of the size of your store). Then dismount it (there is no need to stop the information store service), and open a command prompt window to issue the commands:
eseutil /d e:\path\to\priv1.edb /s e:\path\to\priv1.stm
Note: by default it will create temp files on your C: drive and these could potentially get very large. If you don't have a large C: drive, use the /t and /f switches to specify the locations for your temporary files.
eseutil /d e:\path\to\priv1.edb /s e:\path\to\priv1.stm /t F:\temp\temp.edb /f F:\temp\temp.stm
You should see something like this:
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating DEFRAGMENTATION mode...
Database: priv1.edb
Streaming File: priv1.stm
Temp. Database: TEMPDFRG3940.EDB
Temp. Streaming File: TEMPDFRG3940.STM
Defragmentation Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
.................
Remember to mount your store again once the defrag has finished. If it has worked you should see a message like this one:
Moving 'TEMPDFRG3940.EDB' to 'priv1.edb'... DONE!
Moving 'TEMPDFRG3940.STM' to 'priv1.stm'... DONE!
Note:
It is recommended that you immediately perform a full backup
of this database. If you restore a backup made before the
defragmentation, the database will be rolled back to the state
it was in at the time of that backup.
Operation completed successfully in 5210.484 seconds.
In this instance it took 1 hour and 26 minutes to defrag a 23Gb database file.
Technorati Tags: Exchange 2003, Exchange Admin