Submit a ticketCall us

Solarwinds & Cisco Live! Barcelona
Join us from the 29th of January to the 2nd of February at Cisco Live 2018 in Barcelona, where we will continue to show how monitoring the network with SolarWinds will keep you ahead of the game. At our booth (WEP 1A), we will demonstrate how SolarWinds network solutions can help. As a bonus, we are also hosting a pre-event webinar - Blame the Network, Hybrid IT Edition with our SolarWinds Head Geek™, Patrick Hubbard on January 24th - GMT (UTC+0): 10:00 a.m. to 11:00 a.m. There's still time to RSVP.

Home > Success Center > Database Performance Analyzer (DPA) > Idle blocker visible in Blocking tab

Idle blocker visible in Blocking tab

Table of contents
Created by Mandeville, last modified by Melanie Boyd on Apr 17, 2017

Views: 2,208 Votes: 0 Revisions: 4


This article describes what it means when idle blockers are visible in the Blockers tab in DPA.  


  • All Orion Core products
  • Oracle or SQL Server monitored instance


Idle blocking occurs when you have a session that opened a transaction (establishing a lock on a resource) and then did not commit or rollback explicitly. The transaction stays open, even though no work is currently being done. Imagine you issue a begin transaction statement and then issue an update to a table. The results will come back, but you haven't closed the transaction yet. In another session, query against the table used in the first session, it will just spin until the lock has been released. The second session will start to accrue wait time in the LCK wait type and the scenario will show as idle blocker in the blocking tab.


Possible causes:

  • An abnormally terminated session that was doing the transaction initially that won't close it out.
  • Application logic that opens a transaction in the database, then goes external to do a piece of work. Like an OS command, parse a file, make a web service call, etc. Then based on the results of that external call, it will come back into the transaction and commit or rollback. If something occurs during that external call, the application may never come back into the transaction and complete it. (that external dependency is now impacting your database performance).


To find what that idle blocking session was doing, you will probably have to drill into DPA to see when the blocking had started and see what that session had been running just prior to the blocking condition. There are reasons why DPA may not have gotten what the blocker SPID was doing at the time and sometimes it’s difficult to determine exactly when the blocking session actually ran their transaction. We poll once a second for active sessions. If the transaction statement ran very quickly and happened between polls we may have missed it. We don’t leverage tracing.




Last modified