Submit a ticketCall us

Webinar: Web Help Desk for HR, Facilities and Accounting Departments
This webinar will focus on use cases for HR, Facilities and Accounting.

Having a unified ticketing and asset management system for all the departments in your company can provide end-users with a seamless experience and make things easier for your IT team. Yet, with different business tasks and objectives, many departments don’t fully understand the capabilities of Web Help Desk and how the software can be customized for effective use in their departments.
Register Now.

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: 1,058 Votes: 0 Revisions: 4

Overview

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

Environment

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

Detail

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
12:49, 17 Apr 2017

Tags

Classifications

Public