Individual Monitored Server Problems: Stuck Sessions/Alarms

I have a specific server on my list that has a few "frozen" elements.  4 Sessions are stuck from 3 days ago.  I've perused the server and found the SPID being employed for recent sessions, yet spotlight keeps these resident in the SQL Activity: Sessions list.  The same server also has alarms resident from this morning that I cannot Acknowledge, nor Snooze.  And finally, I am unable to Disable Monitoring on the SQL connection.  For Replication and Windows, the Disable Monitoring feature functions as expected.

In my research through the support sections, I was able to see a few loosely related types of entries that recommended stopping the Spotlight Server Diagnostic Service, but I would really prefer doing something connection specific here as pretty much everything else in my environment is performing as expected.

If anyone has any observations or advice, I'm all ears!

Thanks so much for any and all consideration.

Have a great week,


  • In lieu of any community response, I will relay the steps I took to address this.  I had to perform these actions on-the-fly while supporting a software update.  Not that I recommend doing this under a production roll-out, but necessity reigns.

    In order to return the SQL Connection to a functioning status, and without recycling the service on the Spotlight Server, affecting all monitored connections, I attempted to re-create the connection through the client.  I selected Configure, Connections, and right clicked the offending SQL connection.  Then I selected Delete, which removed the connection from our list.  I then followed the procedure for creating a SQL Connection, selecting the pre-existing Windows connection to associate.

    This yielded an error for the SQL Connection stating the listing already existed.  However, upon returning to the Spotlight Client and the connections list, the SQL connection to the problem server was refreshed, the hung sessions and alarms were no longer resident, and some basic alarms generated as when connections are usually established.  So it did appear to function correctly in re-establishing the listing.

    This wasn't perfect, as I would prefer not to have the conflict alarm in the process.  But as it was on-the-fly and seems overall successful, I am going to accept this as a solution.  I will update with further issues should they present.