CA Service Desk Manager Performance Problems - Quick Checklist

Document ID : KB000009692
Last Modified Date : 14/02/2018
Show Technical Document Details

This document provides points for quick verification in situations where CA Service Desk Manager (SDM) is hitting performance issues.


By performance issues understand: delay on getting response from SDM by editing, visualizing, saving, creating information or navigating the tool.

This behavior can produce an hourglass running or a message (such as "Delayed Response from the Server") when performing the operation

Note this document will not point out all the many factors that can cause the performance problem. The intent here is to provide a quick verification list that can help resolve the problem and/or maintain the environment in good shape.


1. Run periodic archive and purge on session log and activity notification tables.

They can grow very quickly. If they are already highly populated, you should not do it all at once, but schedule short archive periods until you are able to have them small enough to run archives/purges once a month, for example. In some situations, and depending on the table, it is better if the tables are deleted directly in the database. For this the DBA should be engaged and, most importantly, CA should be contacted to validate if that table should be touched directly.

You can set a permanent archive job in Archive and Purge for Auditing, Event_Log, Knowledge Search Log, Notify and Session Log tables. The Attachments table can be put in this maintenance as well.

The frequency of that will depend on how fast these tables grow or the availability to runt he proceeding - which should not be done during working hours.

2. Depending on the MDB size, have periodic maintenance done to it, such as reorganizing tables and indexes.

If running SQL Server, don't forget to have the transaction log file shrinked.

For other types of verification and maintenance to be done on the MDB, you should contact the DBA.

3. Avoid having contacts with duplicate userids on ca_contact table.

The following query can be used to find them:

SELECT userid, 
COUNT(userid) AS NumOccurrences 
FROM ca_contact 
GROUP BY userid 
HAVING ( COUNT(userid) > 1 ) 

You run it and found some. Now what? 
Never, ever delete them. You can cause inconsistencies to your environment.
If it is the same user, you can deactivate one of them.
Now, no matter if the user is the same or not, the userid should be changed. Even having the contact deactivated doesn't mean it won't be found.

4. Running BOXI to generate your reports? Consider running "offline reports" if you are having performance issues. 

Refer to the Additional Information section below for instructions on how to proceed.

5. Avoid having wrong email addresses set to users. 

This may cause an overheard in SDM processing if there are many contacts hitting this condition.

6. Avoid having a notification method set without an email.

This may cause an overheard in SDM processing if there are many contacts hitting this condition.

7. The user should always disconnect from SDM, not simply close the browser in the X.

Most of the sessions will be closed by timeout, but it is possible that a few will not be cleared by SDM. This is Best Practice!

8. Traces should not be left active without need. It is possible one is active in the environment and you may not even know it. 
One simple way to check it is to run the following on the prompt:
pdm_logstat -vL

It should return a blank line.
If not and you don't remember of having this activated by any reason, you should contact CA Support to deactivate it.

Note there are other types of traces that can be used. If you suspect there are any active, you should contact CA Support to check if you have them active.

9. In case the SDM has been recently upgraded, it is necessary to check Monitor Joins variable. It's certainly active.

Refer to the Additional Information section below for instructions on how to proceed.

The document will also explain its effects on SDM, and in case you are really facing performance problems, it is necessary to uninstall it in Options Manager under Administration tab.

10. Verify whether or not SREL_BLOCKS_TIMEOUT is installed. 

Initially, the fact that this variable doesn't exist may not affect the environment.

But after some time using SDM, users may experience a delay when running basic activities and it is possible to verify under Administration Tab -> System, locks on SREL tables.

To resolve this situatin the SREL_BLOCKS_TIMEOUT option needs to be installed.

Refer to the Additional Information section below for instructions on how to proceed.

11. Keep the Knowledge Base in good shape.

You can make your Knowledge base usage much "happier" by running pdm_k_reindex periodically.

Additional Information:

There are other factors which can impact performance. See below other points to be considered:

1. Monitor_Joins variable installed.




3. Occurrences of Delayed Server Response.


4. Performance testings performed by CA on SDM 12.9 and 14.1.


5. WEB Services can also be a point of impact, and there are Best Practices to be considered.


6. Business Objects can also play a role in performance issues with SDM.

  • SDM R12.9 and R14.1: For more information about creating a replicated database for offline reporting, see the sample documentation and scripts delivered in the NX_ROOT\samples\reporting directory. The information on the Greenbook can be used for reference as well.

The information in this article has been included in our product documentation. You can find further details here: