HELP - DEFRAG EXCHANGE 2003 SBS DATABASE

I had only set the limit at 70GB but since it dismounted automatically and the edb and stm files together are almost 80 i assumed it was maxxed out.  I turned off retention yesterday to see if it would make a difference.

Sorry forgot the lnk: http://www.msexchange.org/tutorials/MF022.html

is it normal for this to take so long or could something be wrong?

I am afraid there is no simple answer to that, some people will quote 2-3 hours per GB others 5-7 per GB.

It really does depend on server hardware and if it's doing anything else.  It will normally crash with an error message if there is a problem.
See here: http://www.petri.co.il/defragment_exchange_2000_2003_server_databases.htm

Just also note that unless physical space is an issue for you there really is no need to do an offline defrag.

In 2003 with SP2 applied the database is dusmounted during the maintenance window, this does not stop you re-mounting it it just means the next time maintenance runs it will get dusmounted again.

This is not an easy issue. I think your defrag are way to slow. Your issue now are wheter you should wait or rely on your backup. As i mentioned, you should confirm that deleted items are not stored in the database. If the registry setting is 70 GB it should dismount on that level. When you get the server up and running, you could also export some of the worst users to pst. and store it outside the Exchange if possible it will buy you some time.

but isn't offline defrag meant to reduce the side of the db?  how do I know what my actual db size is?

Also dont forget to run the isinteg command after the defrag completes as there couls be some broken or misplaced pointers in the database and they can cause more issues like:- User see a mail in Outlook but when click get an error - reason broken pointers...... So better to run the command
Also as Demazter said that it runs at 4-5 GB approx but very much depends on the server performance ...... so just keep it light tilll the command is running and can take some time and might look like its stuck .... to check that its not stuck and running open the task manager and go to Processes tab and select columns for I\ORead, I\OWrite, I\OReadBytes and I\OWriteBytes and just monitor to see if its running in the background

isinteg -s {Exchange server name} -fix -test alltests

Once the Offline Defrag completes you would see the reduced size of the database  ..... you would only get the free space in the database at the time you ran the Offline Defrag..... do you know what the free space was ??

Have a look at this document from EE expert Mestha it explains in more detail what I have already said above: http://www.amset.info/exchange/event1221.asp

not sure how to find out...

As I already mentioned the physical size ofthe database does not matter, it's the logical size that the limit is set to.

If you reach the limit it will not stop you from mounting the database it will just be disjointed when the maintenance runs.

If you ever have to check the free space in the database you will have to dismount the database and run the command
eseutil /ms "location of the .edb file"
This would scan the entire database and give you number of free pages - multiply the number of free pages by 4 and that gives you total in KB now you can find the free space in MB or GB accordingly ..

OK,

You made a mistake starting that offline defrag if you are using Exchange 2003. As demazter points out, it will look at the logical size, which is basically the physical size of DB less the space reported in event 1221 in event logs.

You say that last night it was at 4% and this morning it is stil at 4%, so it is either stuck, or it has reached a point where it is not managing to complete 1% of the job in 8hrs. Either way, thats a major problem. At some stage you may have to make a decision to remount the original database from backup. Remember, you didn't need to defrag the file in the first place.

If it suddenly picks up, it is not going to take any less that a further 18hrs, and thats if it manages 4GB per hour, which is on the faster end of the process.

Perhaps you might need to bite the bullet and restore from backup, unless downtime in terms of days is better than the risk of cancelling and restoring from backup.

Shaun

guys thank you all for the useful information but I think I am going to have to cancel the defrag and restore last nights backup and try again tonight and let it go all weekend if needed. I am already getting grief from the client. what can I do to make the defrag faster?

You could consider copying the file to a faster/higher spec machine and running a defrag from there.

If it's getting stuck it may be down to corruption so you may want to run ISINTEG in it first.

You may be lucky and you don't have to restore from backup but before you try again do an ISINTEG and remember, when you do the offline defrag do it on a copy of the file or at least make a copy somewhere else before you start.

Also is a defrag really necessary? The information I proceed earlier about retention periods should suffice unless physicalspaxe is an issue.  Set the retention period to 1 day and then do some archiving.

Why does he need to do a defrag? He doesn't need to defrag the file, as the limit will be based on the logical size, so as long as online maintenance has been run against the database with retention set to 0, he will not need to run it?

Shaun

fyi: the server is a quad core 2.66 with 4gb ram.  hard drives are a raid1 sata 1tb.

holy cow, it just jumped to 8%...after 10 hours, it actually made some progress.  i am tempted to take the heat and  try to convince the client that they have to stick it out today with no email...what do you guys think?  is there any way i can make a calculation on how much time i have left based on what it is done already?  i started it at 1130pm last night.  now at 930am its still at 8%

ok, here's a theory...can i restore my backup to a different location and run that production database while this one defrags?

Hi Shaun, agreed.....isn't that what I said in my last sentence?

messy. You could do it for access to historical mail, but if they are using cached mode in Outlook they should have that anyway.

You can' make it fully live because then you won't be able to put the 'defragged' one back in production without transferring mail from the restored one to the defragged one.

Shaun

You may be wasting your time!
If you have no White space then te defrag will not reduce the size of the file, however now you have started it I would suggest you continue!

Check for the Event 1221 in the event viewer how much White space have you got?

The maths are 8% takes 10hrs so as an average 1% takes 1.25 hrs, so as an average 100% will take 125hrs, or 5-6days

Shaun

it just jumped to 10%...could this mean signs of life?

heres why i think i need to do this....if any of you have entourage clients on exchange you will know that the stm file inflates to a crazy size.  because of the webdav/mapi problem
1. a defrag also brings that STM file down to normal.  
2. i have done alot of archiving lately and cleaning out old boxes and need to reclaim that space.  
3. i cant get calls every morning that the db has been dismounted like it was yesterday.

i have checked event 1221 and it says hi have 4 gb of space or more...I have several like that...at least 6 or 7 of these messages with that size.  how far back do i go to know how much space is available?  only 1 event, or keep adding them up to the last backup?

The latest event will tell you the latest White space.

If it's only 4GB then it's not been very usefull.

You need to set the retention period on deleted items as per my previous posts this will create more whitespace.

If there was whitespace available then the store would not have dusmounted unless it was at 79GB.

That's what I am trying to say if the files are 120GB and you have 50GB of whitespace the store will not dismount.

i used to have the retention period at 30 and 60 days.  i changed them to 14 and 14 yesterday...how long does the transition take?

Also if you archived messages to PST this week then they will not fall into the 14 day period s as mentioned set them both to 0 and set the maintenance to run constantly (detailed in link I posted earlier) and this will produce whitespace straight away (within 15 minutes or so) which will stop the DB dismounting.

if i add up all my mailboxes it is only about 45 gb...why would it only say 4gb white space?

Probably because it's in the dumpster.

Set the retention to 0 run the maintenance and then the whitespace should increase.

up to 22%.  

You do realise your database physical size after the defrag is going to be no more than 4gb smaller right? So if it is 78GB now, by the end of the defrag it will be maybe 74GB

Shaun

I did mention this is comment ID: 25759831 but didn't get a response.

Sure, I was just reiterating...

Shaun

Fellas i do truly appreciate your comments and help thus far.  I spoke to the client and we have decided to wait it out because now its up to 32%...13 hours into the defrag...and i dont want to have to restore the large backup where they won't have mail the rest of the day anyway.  So we are going to let it ride and when it finishes i will post here how long it took and what the results were.  

However, i did ask a question i wish someone could answer:
If i add up all my mailboxes it is only about 45GB...why would my database be much larger than that?

This could be the whitespace that would be created if the dumpster was emtied as per the deleted items retention settings.

Either way the physical size of the database is allways going to be different to the cumulatve size of your mailboxes because of this.

Please note the physical size if the database is not the limit of the store!  As per previos post the physical size of the database could be 100GB but the logical size could be less than 75GB

the database doesn't stretch and grow it just grows (much like an access database).

Only if you perform an offline defrag will you recover the space that is reported by event 1221

Here's a follow-up comment.  I really appreciate all your help everyone.  I let the defragmentation run for 24hrs straight.  At almost exactly the 24hr mark it was at 86% and then it had an error and started itself again. I dont know how that was possible since no one can be at the server and I was working on it remotely.  But anyway.  I let it run another few hours and again it was stuck at like 2% so I decided to end it.  I figured I would have to run isinteg to repair the database or restore my backup,.but I thought I would try to mount it just to see what would happen.  It mounted successfully!  I guess the original database was left untouched and it was writing all the changes to the temporary one.  I deleted the temp defragged database and left it back to how it it was before.  What a waste of a 24 hour period!  Jeez.  I am still where I was at the beginning.  I actually added up all my mailboxes and I actually have 32GB of data in the boxes, but my database says it is 58GB and STM file is 22GB. I still do not understand how there can be such a discrepancy.  I woulld love an explanation.  In the mean time I will split the points to the most helpful comments.