Intensive query on discovery_probes_tracker whn using counting jobs - Known Error

Intensive query on discovery_probes_tracker whn using counting jobs Description Starting Z, Discovery migrated to a new counting mechanism for discovery statuses. It includes 2 jobs to update the statuses regularly instead of updating for each ECC queue.

Since the old mechanism is still there, we need to check whether the status in question is using the old\new counting mechanism so the correct one will update the counts.

This check is in multiple places, which then called a lot of times and involves a query to discovery_probes_tracker, which in some use cases may be expensive

Steps to Reproduce

Run any discovery. You may see the below slow query

(SELECT discovery_probes_tracker00040."sys_id", 'discovery_probes_tracker0004' AS "sys_table_name" FROM discovery_probes_tracker0004 discovery_probes_tracker00040 WHERE discovery_probes_tracker00040."discovery_status" = 'ba95bb7733bf6210076d82382e5c7b76') UNION ALL (SELECT discovery_probes_tracker00050."sys_id", 'discovery_probes_tracker0005' AS "sys_table_name" FROM discovery_probes_tracker0005 discovery_probes_tracker00050 WHERE discovery_probes_tracker00050."discovery_status" = 'ba95bb7733bf6210076d82382e5c7b76') UNION ALL (SELECT discovery_probes_tracker00060."sys_id", 'discovery_probes_tracker0006' AS "sys_table_name" FROM discovery_probes_tracker0006 discovery_probes_tracker00060 WHERE discovery_probes_tracker00060."discovery_status" = 'ba95bb7733bf6210076d82382e5c7b76') UNION ALL (SELECT discovery_probes_tracker00070."sys_id", 'discovery_probes_tracker0007' AS "sys_table_name" FROM discovery_probes_tracker0007 discovery_probes_tracker00070 WHERE discovery_probes_tracker00070."discovery_status" = 'ba95bb7733bf6210076d82382e5c7b76') UNION ALL (SELECT discovery_probes_tracker00000."sys_id", 'discovery_probes_tracker0000' AS "sys_table_name" FROM discovery_probes_tracker0000 discovery_probes_tracker00000 WHERE discovery_probes_tracker00000."discovery_status" = 'ba95bb7733bf6210076d82382e5c7b76') UNION ALL (SELECT discovery_probes_tracker00010."sys_id", 'discovery_probes_tracker0001' AS "sys_table_name" FROM discovery_probes_tracker0001 discovery_probes_tracker00010 WHERE discovery_probes_tracker00010."discovery_status" = 'ba95bb7733bf6210076d82382e5c7b76') UNION ALL (SELECT discovery_probes_tracker00020."sys_id", 'discovery_probes_tracker0002' AS "sys_table_name" FROM discovery_probes_tracker0002 discovery_probes_tracker00020 WHERE discovery_probes_tracker00020."discovery_status" = 'ba95bb7733bf6210076d82382e5c7b76') LIMIT 1 OFFSET 0

Workaround Make sure any file you change is marked as replace on upgrade!

Navigate to DiscoveryStatusMonitor script include Locate shouldUseOptimizedCountingForStatus function Replace it with the below implementation: function shouldUseOptimizedCountingForStatus(discoveryStatus) { if (!discoveryStatus) throw new Error(sn_i18n.Message.getMessage('global-discovery', 'value_to_be_sysid_gliderecord', { value: discoveryStatus, tableName: 'discovery_status' })); var statusSysId = discoveryStatus.sys_id || discoveryStatus; // Try g_status first if available and matches - Cheap check. No need optimizeCounting condition if (typeof g_status !== 'undefined' && g_status && g_status.sysID == statusSysId) return g_status.scratchpad.isOptimizedCounting; // Fall back to querying the status record var discoveryStatusGr = getDiscoveryStatusRecord(discoveryStatus); return discoveryStatusGr.scratchpad.isOptimizedCounting; } Related Problem: PRB1938058