We've recently implemented and are still an enterprise level email archiving solution on our exchange 2003 environment. this has (and still is) creating an enormous amount of space over 500GB so far in 13 databases totalling 1.2TB of space on the disk. the full backup of 1.2 TB is longer and slower than ideal and reducing this would be a benefit but not essential. We have the time overnight, but I’m interested in the other advantages of offline defrags and trying to justify the downtime (more than the effort, I’m personally prepared to do the actual work) and need to be able to answer a few questions, any help would be great if huge amounts of data have been removed from large full databases in a very short period is this likely to create large levels of fragmentation as the white space (which isn't at the end of the file) is filled? - should a database be defragged to allow growth at the end and thus will it help performance of exchange? I’ve seen attempts to quote XX GB/hour defrag speed dependant on hardware used, I can see and understand the complications of trying to predict such a figure accurately without testing on the hardware in question. Does anyone have experience required to know if an offline defrag is faster in a DB of x GB size with 25% whitespace versus a database of the same size with 10% whitespace? I’m assuming, if restoring from tape it will take longer to restore, check and mount a database with large amounts of whitespace than it will to do same for the same amount of data held on a smaller database file? Do public folder databases also benefit in the same way from offline defrag I’ve heard the risks of corruption caused by an offline defrag in Exchange 2003 are very slim are there any major costs, other than the obvious downtime and my implied loss of weekend privileges as a resulting attempt to limit the business impact of this factor?

nightly online maintenance runs to do an online defragmentation, garbage collection etc and at the end you will see event id 1221 which will tell you how much white space there is within a db. Typically unless you are going to gain over 10% of space back on a fairly active database its probably not worthwhile because the DB will grow again to the 10% mark because of all the transactions. it really depends upon the database, disk, memory etc. I usually quote 4GB per hour for an entire process, i.e. defrag and integrity check(lower if you are using a network location for the work space, i.e. if you don't have 110% free space on a local drive you have to use a remote location and that will slow things way down) however that said on a fast box, fast disk etc have seen as high as 12 GB per hour Yes that's true, i.e. backing up and restoring a 1.2GB physical file will take longer then restoring a 800MB file Yes, however it really depends on the rate of data change, i.e. MB databases are in constant flux of items being added, changed, deleted etc whereas a PF db adds data but it doesn't change as much. Look for the 1221 Event ID and let that determine your path One thing you will want to do post defrag is take the time to run isinteg -s <var>servername</var> -fix -test alltests against each database you defragged and you need to repeat the isinteg -s <var>servername</var> -fix -test alltests process until the results show that it didn't correct any errors. Warnings are ok but if you see an error corrected at the end of the process you need to run it again. Plan on running it at least twice The down side here is that you will have some considerable downtime and of course there are always risk whenever you do anything to the database so backups are critical, i.e. before you take it offline, as soon as its offline you should make a copy as well in case something goes wrong and as soon as all maintenance tasks are complete you need to run a full online backup. The upside is that you will have a compact and more efficient database when complete. The other option is to create a new MB database and do mailbox moves. The upside is less downtime for all users, although on the downside A. during the move the user cannot access the mailbox. B. You will create a tone of logs during this process so you may need to enable circular logging temporarily C. You will need to modify your backup process to backup the old and new DB until all moves are done. in regards to corruption that can happen but that's usually caused by a hardware issue (most of the time the storage system) so best to check your event logs in advance to ensure there are no errors lurking about. In the Application log look for 1018, 1019 which are events that tell you the DB is already damaged and if you see these its very bad and needs to be addressed ASAP else the DB's are sure to fail and the more stress you put on them the faster the chance of failure, i.e. backups, defrags etc are not recommended at all until you solve the hardware issue Troy Werelius www.Lucid8.com Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDB's and Live Exchange Servers with Lucid8's DigiScope

Troy thanks for the information, it's a massive help, sorry for taking a long time to reply, i've been busy archiving. 1. 33% whitespace average accross all databases now, 10 of 13 are over 10% whitespace and some mailboxes are not yet within policy so this will increase. which, given your advice above (10% also seems to be the echoing consensus everywhere) means i have a lot of work ahead of me. 2. that doesnt sounds good. our 265 GB public folder is now 86% white space... i want that space back, i want to take it off the backups etc. 265gb @ 4 GB/hour = almost 3 days. i can only hope we have a faster machine than that. some of our teams' processes are very reliant of PF, hence it growing so large in the first place. 4. i think it's needed, if for nothing more than to regain the space that's being taken up. 5. how long does this check take? as this is before remounting it the downtime is extended (though i do see the advantages in verifying and fixing a dB after defrag 6. this is going to take some time and is going to need to be planned carefully but your information ahs been very helpful 7. discussing this with my Boss, this might be the easier move for most mailboxes, expicially once PF have been shrunk we'll have a lot of extra space for log files to build up, though our backup staff won't thank me for continuing to make enormous amounts of logs (archiving email also likes writing logs as well) 8. good to know, i'll be looking for these events before pushing forwards. Thanks again for your help and advice Mike

Thanks for the update and yeah 87% white space on the PF means you definitely are in need of a defrag to get that size down to a management level and to recover disk space. You know if you want an automated solution you should check out a few of our products which i think you might find interesting and if you want to reach me via email you can do so via Troyw at Lucid8 dot com GOexchange - Preventative maintenance tool: http://www.lucid8.com/product/preventative.asp DigiScope - Discover, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDBs and Live Exchange Servers: http://www.lucid8.com/product/digiscope.asp Exchange Protection Manager - High Performance SinglePass™ Protection & Granular Recovery: http://www.lucid8.com/product/epm.asp Troy Werelius www.Lucid8.com Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDB's and Live Exchange Servers with Lucid8's DigiScope