cancel
Showing results for 
Search instead for 
Did you mean: 

High Workload on SQL Cluster brings up Event 13360 and 6796 on each of our EV Servers

SutterKane
Level 4

Hello.

Since several days we are facing problems on each of our six Ev Servers (10.0.3).

The eventlog on each server is showing Event 13360 and 6796 continously. The SQL Server (Win2008R2, SqlServer 2008R2 clustered) is running nearly

at 100% continously and within the SQL Management  Studio you see huge Wait times of type LCK_MX (whatever this means).

This is happening during non-archiving times (from MS Exchange 2010) but with compliance archiving.

Please see the attached files for further details. Stopping all services on the EV servers will reduce the workload (naturally) but I still have no clue 
where this workload is coming from. I suspect our users to move elements from the PST files to their VaultCache and causing this huge workload.
The current number of active archives is ~24.000 and the  total size of archived itmes is ~67TB  and growing).

Can someone help me out or give a hint where to look for ?

 

Thanks,

 

SK

 

1 ACCEPTED SOLUTION

Accepted Solutions

Merv
Level 6
Partner
Looks like a load issue..you have 6 Ev servers Stop all your task, i.e. PST imports, mbx, journallling..and use a process on ALL SERVERS. Then check all the MSMQ servers. As JW has mentioned moved items could bd an issue or even manual archiving or Virtual Vault as you mentioned. So if moved items is the issue it could be lots of items in your A6 queue or pending items shortcut updates..it could be A1 or manual archive items A2 and journaling J1 and J2. Storage or sql waits will also affect Storage Archive queues. http://www.symantec.com/business/support/index?page=content&id=HOWTO37380 Also give the exact error on the 13360 message so we can isolate which sql statement fails or time outs and maybe next step would be a dtrace and sql profiler trace on that. The activity monitor in SQL server which show you which SP is running As JW mentioned..check the maintenance planes ...so a medium fo large setup like yours SQL maintenance should be runninv possibly multiple times a week. How many vault stores do you have and what are thier sizes and how many million items per VS? http://www.symantec.com/business/support/index?page=content&id=TECH74591 You should might want to prepare engage SQL DBA to scale up the sql server ..more cpu and memory or move to a bigger beast

View solution in original post

2 REPLIES 2

JesusWept3
Level 6
Partner Accredited Certified

What version of EV are you currently running?
Do you allow for Moved Items and updating retention categories for shortcuts based on the Archiving Policies?

Do you follow SQL best practices?
i.e. temp DB being on a disk seperate from other databases?
Are you rebuilding indexes and updating sql statistics accordingly?
 

https://www.linkedin.com/in/alex-allen-turl-07370146

Merv
Level 6
Partner
Looks like a load issue..you have 6 Ev servers Stop all your task, i.e. PST imports, mbx, journallling..and use a process on ALL SERVERS. Then check all the MSMQ servers. As JW has mentioned moved items could bd an issue or even manual archiving or Virtual Vault as you mentioned. So if moved items is the issue it could be lots of items in your A6 queue or pending items shortcut updates..it could be A1 or manual archive items A2 and journaling J1 and J2. Storage or sql waits will also affect Storage Archive queues. http://www.symantec.com/business/support/index?page=content&id=HOWTO37380 Also give the exact error on the 13360 message so we can isolate which sql statement fails or time outs and maybe next step would be a dtrace and sql profiler trace on that. The activity monitor in SQL server which show you which SP is running As JW mentioned..check the maintenance planes ...so a medium fo large setup like yours SQL maintenance should be runninv possibly multiple times a week. How many vault stores do you have and what are thier sizes and how many million items per VS? http://www.symantec.com/business/support/index?page=content&id=TECH74591 You should might want to prepare engage SQL DBA to scale up the sql server ..more cpu and memory or move to a bigger beast