MSMQ query.
Hi All,
Questions for the Symantec techs: Has the issue in the following article been rectfied? https://www-secure.symantec.com/connect/forums/msmq-not-clearing
Let me give some background:
We run EV 8 SP2 on W2K8 connected to SQL 2005 (Cluster). Recently ,we modified the archiving policy from 90 days to 60 days & ticked the box :Delete Orphaned shortcuts. We found the that archiving tasks was clearing all the queues except A5 where it would do about 10 mailboxes and then the CPU on the SQL server would sit at 100% until the DBA's rang and said to kill the tasks. This would happen everyday for about 2 weeks until I found the above article.
I originally thought the problem was the store_proc issue as outlined here: https://www-secure.symantec.com/connect/idea/enhancement-request-evault-stored-proc as found by our DBA's.
I'd like to know people's thoughts on the actual cause. I have rolled back the archiving policy ( 2 days ago) and removed the "Delete Orphaned shortcuts" check box (Today). I have a sneaky suspicion that the latter is the cause.....
I'll report more tomorrow after the tasks have run overnight.
As an afterthought, is it safe to purge queue A5?
Cheers,
Dave
Comments
A5 is purely to tell the
A5 is purely to tell the archive task what mailboxes to archive next, so what will happen is when the task starts it will put every single enabled mailbox in that queue for that task, and as it processes it , it will remove it.
After the queue has been processed, and if the task is still in schedule, EV will then re populate the A5 queue with any mailboxes that still had items to archive after the 1000 items per pass (unless you're using quota based archiving)
it is safe to pure the queue, you may want to stop the services, purge the queue and then purge the admin queue, otherwise you will get events saying that the queues have been purged for each item.
As for the Update shortcut locations, you should hopefully expect better performance around this area in EV8 SP4.
Also make sure you run regular maintenance as the queries are all very index intensive
Hmm. it was the Orphaned Shortcuts!
24 hours later and the DBA's are my friends again.
After removing the check box for the "Delete Orphaned shortcuts" all the queues have cleared and the SQL servers are running normally. No need to purge the queue.
JW2 - You mention regular maintenance, could you expand on your comment please, I don't quite follow. Are you referring to the SQL tables?
Is there a release date for EV8 SP4? I haven't heard anything about it yet.
Cheers,
Dave
I come from a land Down Under...
EV8 SP4 is coming ..soon,
EV8 SP4 is coming ..soon, thats the best i can tell you as with all things dates come and go based on the QA process so "when it's done" is when it will be done, but soon, i promise!
and regular maintenance, i'm talking about updating statistics, rebuilding or defragging the indexes (SQL indexes) etc
Hi. Nice to hear that this is
Hi.
Nice to hear that this is addressed in the next servicepack.
I too had the issue with items in the A5 queue. As soon as all items in the A5 queue where processed the number immedialtly jumped up to the same amount as the number of enabled mailboxes, and this behaviour continued regardless of the lenght of the archiving window.
After a long supportcase with many different trial and error approaches we finally removed the setting for "Remove orphaned shortcuts" and the problem was solved.
So simple....
It's amazing such a simple setting can cause so much trouble.
Thanx for your help!
I come from a land Down Under...
Would you like to reply?
Login or Register to post your comment.