I hope this helps people.
To apply this fix, connect to the SBSMONITORING instance using SQL Server Management Studio, and create the indexes as described.
Inappropriate indexes to support function GetAlertsPerID
SBSMonitoring will have a significant period of high processor usage every three minutes, using 100% of one CPU for about 30 seconds.
Investigation showed that the offending call was GetAlertsPerComputer, which does a Cross Apply with GetAlertsPerID
If you create this index to support GetAlertsPerID, the periods of 100% processor usage go away:
CREATE NONCLUSTERED INDEX [IDX_Alerts_GetAlertsPerID] ON [dbo].[Alerts]
(
[DefinitionID] ASC,
[ComputerID] ASC,
[DateOccured] ASC,
[IsSet] ASC,
[ID] ASC
)
With this index in place, the regular spikes in processor usage vanished.
Inappropriate indexes on WMICollectedData to support GetSecurityProductsPerComputer
Investigation of remaining activity showed that a large part was taken up with executing GetSecurityProductsPerComputer.
This uses a six-way join to get information about client computers. The estimated execution plan shows an inappropriate clustered index scan without seek on table WMICollected data on the subordinate branch of a nested scan. This is because there is no index on the join keys, WMIInstanceID and WMIPropertyID. There were also no indexes on the other foreign keys.
CREATE NONCLUSTERED INDEX [IDX_WMICollectedData_GetSecurityProductPerComputer] ON [dbo].[WMICollectedData]
(
[WMIInstanceID] ASC,
[WMIPropertyID] ASC,
[DateCollected] ASC,
[ID] ASC
)
create index IDX_WMIObjectInstances_ObjectID on WMIObjectInstances(ObjectID,ID)
create index IDX_WMIObjectProperties_ObjectID on WMIObjectProperties(ObjectID,ID)
Creating the first index took quite a while, but with these indexes in place, the processor and disk usage from SBSMONITORING instance of SQL Server dropped to virtually nothing.