Exchange DB maintenance work

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

This weekend I'll be doing some DB maintenance work... It will involve an ISInteg and potentially a DB defrag. Before proceeding with the maintenance I will be sure to make a backup of the database.

Do you guys have any recommendations? the database size is 375GB!!! which is insane! I am guessing the ISInteg might take a while? as I know for a fact a defrag will as well.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I think weekend might not be enough to be honest.
ESEutil took 17 hours (+ISINTEG) to go through 55GB database last time I was doing it.

Unless that was something unusual and I was just unlucky.

edit: Changed hours from 27 to 17 (typo)

 

Both took you 27 hours? or just the ESEutil? My guess is that they would both take roughly around the same amount of time to complete unless there are DB corruptions.

Also can you stop an ESEUtil and ISINTeg while it's running? or will it screw up the DB?

 

Sorry mate. Typo there 17 hours.

You should be able to kill the eseutil process (not sure about the consequences) but when restarted it will start again from a scratch (it won't start off where it left).

It took me 17 hours just for ESEUtil and about the same for ISInteg.
ESEUTIL and ISINTEG run at about the same speed which in theory is 4-6GB per hour (from my experience closer to 3-4 GB per hour). I guess the more messy database there is the longer it takes.

edit: We did have corruptions though

edit 2: For the record I was running it on Dell R710 - Quad core 2.4GHz - 32GB RAM running from 15k RPM SAS drives in RAID 1 (System was doing nothing but this and it was for testing purposes so out of production = no other load on the server)

 

I've just been told that if there's no errors in the database ISInteg can even run at 10GB/hour. Still with 375GB database you're looking at roughly 100 hours in total I reckon.

 

I see... I am pretty sure there are errors on our DB which makes me believe that it will take longer than expected...

 

As I said, ours was corrupted . Also the above timing are for corrupted database and ESEUTIL /P process as well as ISInteg -fix. I think defrag should take less time (not sure, never done it).

So in a shorter way the worst scenario. Would it be possible to grab a copy of the database and work on the copy first (stand-alone machine). This way you can run eseutil and isinteg tests during the week and check what's wrong before you commit to lenghty repair process (possibly unnecessary)?

 

With a DB that size, even with an excellent disk subsystem, running isinteg or eseutil is going to take at least two days for each - in a 'best case' scenario. You'll need to schedule two weekends - one to run isinteg and fix 'soft' errors and then, if that doesn't resolve your problems, the next weekend to run eseutil and fix anything at the low level. Be warned - make SURE you have a backup that works. ESEUTIL & ISINTEG aren't the b***ards they used to be - back in the day ESEUTIL especially seemed to destroy Exchange 5.5 DBs as regularly as it fixed them - but it's still a pretty destructive tool. If you're currently in the situation where Exchange still works, I'd argue that the best thing to do would be a migration to a new server. If you can't do that for budget reasons, at least make sure you take a full Exchange backup and verify it first before you do either an offline defrag or run isinteg -fix.

 

My colleague and I came across an article on experts-exchange stating that by moving a mailbox over to another exchange mailbox store, the exchange server will "cleanse" the mailboxes before moving them over, and if the mailbox is really corrupted the move won't happen. Can anyone confirm that?

 

Noted! thanks Zeb.

 

When moving to exchange 2007/2010 you specify how many corruptions are allowed eg 10 per mailbox.

Best advice is to get users to delete or archive mails, then dismount stores and back them up. Next do what Zen said mate.

 

Would anybody know if performing an ESEUTIL or a ISINTEG and then killing the process would damage the database?

 

Thanks bud!

 

nvm I figured it out... it might damage the db to a point where you can't mount it back on if we cancel it while it's writing to the db trying to fix it. However this is more of a hit or miss scenario because some people say they never had any issues after canceling.