Submit a ticketCall us

WebinarUpcoming Webinar: Know What’s Changed – with NEW Server Configuration Monitor

Change management in IT is critical. But, even with a good change management process, changes are too often not correctly tracked, if at all. The configuration of your servers and applications is a key factor in their performance, availability, and security. Many incidents can be tracked back to an authorized (and sometimes unauthorized) configuration change, whether to a system file, configuration file, or Windows® Registry entry. Join SolarWinds VP of product management Brandon Shopp to discover how the new SolarWinds® Server Configuration Monitor is designed to help you.

Register now.

Home > Success Center > Database Performance Analyzer (DPA) > DPA - Knowledgebase Articles > 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,471 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