SDConnex activity is spiking (server is labouring under high transaction load, becoming unresponsive, etc.)
Issue
The SDConnex is spiking (experiencing excessive transaction loads), which might occur after making a change in the SES.
Cause
The most likely cause is that the SES is generating a large number of commands to be pushed down to devices. Where a very heavy transaction load can become worse is if a substantial number of these transactions fail to complete, as the failed transactions will be added back into the queue so that they can be re-attempted, causing some extension of the duration of the problem.
RESOLUTION:
The following SQL scripts will provide a count of the pending commands.
If desired, the second script could permit you to remove all pending commands in order to re-set the system to a more "normal" workload. Removing all those command may fix the immediate transaction load issue, but since it will cancel all pending commands, it may be necessary to determine what might have been queued up so that these commands can be re-done in a more piecemeal fashion.
WARNING: Please shutdown all instances of SDConnex and SES console before running scripts.
To determine how many commands are active (queued up/waiting to be sent to endpoint devices):
SELECT COUNT(*) AS Expr1
FROM Computers
WHERE (Command > '')
To delete all active commands:
UPDATE Computers
SET Command = N'', CommandData = NULL
WHERE (Command > '')
Custom Fields
Operating System: Windows Server
Version: Affects all versions of SD