ojacobs
asked on
Outlook clients and Blackberrys are very slow after exchange 2003 isinteg and offline defrag.
Hi, We are running Exchange 2003 SP2 on Windows 2003 SP2 on an HP DL380 G4. We have historically been experiencing performance issues where outlook periodically displays the error "Outlook is trying to retrieve data from the exchange server myserver.fqdn.mydomain." and as such have patched the server to comply with the BPA.
This weekend we have just run an Isinteg and offline defrag on both of our db's. The DB's are 58gb and 36gb after the defrag. The isinteg returned errors on both db's but was rerun again and on the 2nd pass and returned no errors. The defrags ran OK and the databases mounted successfully so I was very happy!
Since then we are now experiencing the above error a lot with random outlook clients experiencing long delays when trying to open messages etc. Has anyone experienced similar issues post isinteg & offline defrag, if so, your help will be very much appreciated.
Many thanks
Oliver Jacobs
This weekend we have just run an Isinteg and offline defrag on both of our db's. The DB's are 58gb and 36gb after the defrag. The isinteg returned errors on both db's but was rerun again and on the 2nd pass and returned no errors. The defrags ran OK and the databases mounted successfully so I was very happy!
Since then we are now experiencing the above error a lot with random outlook clients experiencing long delays when trying to open messages etc. Has anyone experienced similar issues post isinteg & offline defrag, if so, your help will be very much appreciated.
Many thanks
Oliver Jacobs
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The performance is definitly improving as the day goes on. Mostly accessing older data seems slow. Do you think that array accelorator caching could be improving performance?
We carried out the offline defrag and decided that an integrity check was also a good plan due to the "Outlook is trying to retrieve data..." error . The large DB retruned 3 errors in the folder test with thousands of fixes and the small db returned 2 errors in the folder test, also with lots of fixes reported. The 2nd isinteg on each db retruned 0 errors so we deemed the db's fit for a live environment.
Its not so much a smoking gun but we do need to understand why the performance issues are occurring since the defrag. I'll run some counters. Which specific counters would you run?
With regard to the growth of the DB's, I know in SQL you can configure the DBs to grow by an amount or a percentage and if you have a db that grows often you can increase the growth increment to reduce overheads on the sever. Can the equivalent be done on an exchange db?
Thanks
We carried out the offline defrag and decided that an integrity check was also a good plan due to the "Outlook is trying to retrieve data..." error . The large DB retruned 3 errors in the folder test with thousands of fixes and the small db returned 2 errors in the folder test, also with lots of fixes reported. The 2nd isinteg on each db retruned 0 errors so we deemed the db's fit for a live environment.
Its not so much a smoking gun but we do need to understand why the performance issues are occurring since the defrag. I'll run some counters. Which specific counters would you run?
With regard to the growth of the DB's, I know in SQL you can configure the DBs to grow by an amount or a percentage and if you have a db that grows often you can increase the growth increment to reduce overheads on the sever. Can the equivalent be done on an exchange db?
Thanks
ASKER
Hi,
For information, we have descovered that our installation of McAfee Groupshield 7 SP1 was the cause of the bottle kneck. Now we have to hammer McAfee for a resolution.
Moral of the story; always eliminate 3rd parties first!
Thanks for your help.
Olly
For information, we have descovered that our installation of McAfee Groupshield 7 SP1 was the cause of the bottle kneck. Now we have to hammer McAfee for a resolution.
Moral of the story; always eliminate 3rd parties first!
Thanks for your help.
Olly
ASKER
Paka, many thanks for the advice. While it wasnt the actual cause of our issue it was definitely useful to know for future offline defrags and very likely a factor early in the revival phase. Thanks again. Olly
ASKER
Is there any way for us to be sure that this is definitely the issue? Also, can we manage the growth of the exchange DB as you can in SQL?
Thanks again,
Olly