Submit a ticketCall us

Training ClassThe Orion® Platform Instructor-led Classes

Provided by SolarWinds® Academy, these trainings will introduce users to the Orion Platform and its features, management, and navigation. These courses are suitable for users looking to discover new tips, tricks, and ways to adapt their Orion products to better suit their monitoring needs:
Deploying the Orion Platform
Configuring Orion views, maps, and accounts
Configuring Orion alerts and reports

Reserve your seat.

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,708 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