Within the Service Desk Manager stdlog, there are may be frequent messages regarding "usp_conflict" or "usp_conflict_chg" and references to "refreshing cache" or "update_complete" in the SDM \log\stdlogs. For example, you may see messages that contain one of the following:
- refreshing cache for table 'usp_conflict' rows ALL
- refreshing cache for table 'usp_conflict_chg' rows ALL
- Message external_update_complete received for usp_conflict (producer chgcnf)
- Message external_update_complete received for usp_conflict_chg (producer chgcnf_chg)
If you're an SDM Administrator, you may be wondering:
- Why are these messages so frequent?
- What causes them to be written?
- Why are they written?
- Do I need to do anything about them?
Overview of Message Impact
- These messages are typically harmless.
- They record that a "mass update" has occurred to the system.
- They do not indicate a fault.
- The "Edit in List" feature can trigger them.
Example of Messages
Here is a typical example of log entries written. Note these factors:
It may draw the eye to the log entries if it writes frequently and to many processes. On large systems with many domsrvrs, the above chunk can be quite large.
If you were to put on a SQL Profiler Trace, you may see entries in time like so:
- exec sp_executesql N'DELETE FROM usp_conflict WHERE usp_conflict.source_change = @P1 OR usp_conflict.conflict_change = @P2',N'@P1 int,@P2 int',<<Number>>,,<<Number>>
- exec sp_executesql N'DELETE FROM usp_conflict_chg WHERE usp_conflict_chg.change = @P1 OR usp_conflict_chg.conflict_change = @P2',N'@P1 int,@P2 int',,<<Number>>,,<<Number>>
- exec sp_executesql N'SELECT DISTINCT chg.open_date, chg.sched_start_date, chg.sched_end_date, chg.id, chg.risk, chg.chg_ref_num, chg.id FROM chg, usp_conflict, usp_conflict_chg WHERE ( chg.assignee = @P1 AND usp_conflict_chg.change = chg.id AND usp_conflict_chg.conflict = usp_conflict.id AND usp_conflict.is_resolved = 0 AND usp_conflict_chg.change = chg.id AND usp_conflict_chg.conflict = usp_conflict.id AND usp_conflict.del = 0) AND ( chg.tenant IS NULL OR chg.tenant IN (SELECT ca_tenant_group_member.tenant_id FROM ca_tenant_group_member WHERE ca_tenant_group_member.tenant_group = @P2) ) ORDER BY chg.open_date DESC',N'@P1 varbinary(16),@P2 varbinary(16)',<<Number>>
Where the first two correspond to the cache refresh and the latter to the "update_complete." These are examples only - the content of these messages will vary depending on the nature of the update being done.
Frequency of Messages
These messages are not seen in the same frequency on all SDM systems. Some sites will be very familiar with these entries in the SDM , while others will rarely see them.
A site prone to these messages may see around 2,000 writes to the stdlogs each day (or more), and still be considered to be operating normally.
An example from a real site is every minute during peak times, every 5 - 10 minutes during business hours, and every four hours during off-peak.
A quick profile of such a site may be:
* High volume of updates.
* Large number of users.
* Many data integration points. Eg pdm_load, Web Services, bop_cmd.
Cause of Messages
These messages are caused by any "mass update" to the Service Desk Manager "domsrvr."
There are two typical database update paths in Service Desk Manager.
- Single update.
The first is typified by doing an edit to a single Incident via the web client "Edit" feature.
Information to update is entered by the user, the domsrvr then works directly with its cache.
There is no need to refresh the cache, because the cache is already in memory and the changes may be done directly.
No message is written to the stdlog as this is a typical activity.
- Mass update.
This encompasses all multiple writes to the database.
Service Desk Manager has a large number of integration point:
* Many CA products
* Web Services
* Bop_cmd, AHD.dll
* GRloader, pdm_load
Rather than having a separate update routine for each, a single "mass update" routine is maintained.
This is for simplicity and quality of code maintenance in this important area.
The mass update code bypasses the domsrvr during the mass update. It therefore needs to notify the domsrvr of the update, so that domsrvr can update its cache.
The mass update writes a "SIGNIFICANT" message to the SDM stdlog to record this.
These messages can prove very useful in correlating to performance issues, among other things.
This does lead to an unexpected use case:
* The SDM web client 'Edit in List' feature also uses the "mass update" code.
This is because multiple records may be updated at once - it is the main purpose of this feature.
So on sites where there are a large number of users, and their business process flow involves using the "Edit in List" feature, you may see a large case of the above messages.
Can the Messages be Suppressed?
No. Nor would it be entirely desirable to do so.
Changing the writing of these message would mean either writing a special subcase for the "mass update" routine, or would require extra overhead within the current mass update routine to determine source of update. The latter would add extra overhead to every update, the former causes a split in the code line which is desirable to avoid.
The messages themselves do contain significant information:
* Domsrvr bypass
* Mass update
* Cache refresh
any of which can be useful diagnostically.
Further, these messages have proven themselves useful in actual performance issues, where the messages pointed to a performance problem.
The messages led to a performance problem with the Edit in List and the code was optimised to resolve this.
In short, the messages are staying, barring strong user support for an "Idea" in the CA Technologies, SDM Global Community.
Does anything need to be done regarding these messages?
Typically no, for reasons above. These messages are informational only. There is no overhead associated with their writing.
However, if you have performance issues, then working back from the performance problem may make use of these messages.