Go to the BlocksTracer download page
While Locks are required in any database system that serves more than a single user in order to protect the data and prevent problems this is not the case when it comes to Blocking Locks.
The term “Blocking Lock” refers to the situation where a process (connection) needs to acquire a lock on a resource in order to proceed with it’s task but there is already another lock held on that resource by another process and so that the lock cannot be acquired and the process ends up waiting for the lock needed to be released before it can proceed. This process is now being “blocked”. Short duration blocks are normal and exist in any database that is not in a read only state and as long as the duration of the blocks are short there is no negative impact and no further action required. However, when your processes are blocked for a duration that can be measured in seconds you typically want to know about it.
Blocking Locks is some thing you would like to know about for various reasons. One common reason is that Blocking Locks have a negative impact on the application response time. It directly affects your users experience while using your application, be it a client server application or a browser browsing your site. Another common reason is that a Blocking Lock can cause the statement executed to exceed the time out defined at the client library which in terns causes the connection to disconnect/ terminate. For any time out or disconnections experienced you definitely need to isolate a Blocking Lock as a potential cause to such a failure. If you are a BlocksTracer user then all you need to do is issue a simple query against the BlocksTracer database and immediately confirm if it is a Blocking Lock that is the cause to the failure. If a Blocking Lock is not the reason then you gain that important information within a minute and now you know you need to search in other directions and if it is a Blocking Lock then you have all the information along such as what Host issued the Blocking statement, what Application, the exact statement that got blocked and the statement blocking, the duration, the number of times and so on.
BlocksTracer puts a spot light on those dark areas in the database that suffer from low concurrency.
BlocksTracer allows you to focus on those areas and be a "hero" improving application response time with the minimal possible effort.
BlocksTracer offers you one single source of information to all blocking and concurrency issues in your environment.
BlocksTracer can answer questions like which stored procedure is being blocked most on the entire server level or at a specific database. Which stored procedure is the number one blocker and what is the actual statement within that procedure that is responsible for the block. What is the longest wait on lock that any process has waited and what is the average block wait time. The same type of questions can be answered for other dimensions such as Host Name, Program Name, Database Name and Logins. In addition a comparison between the servers monitored can also be done.
BlocksTracer configuration is very flexible. For example, you can configure to detect and receive Blocking Locks information from server1 for any block that lasts for more than 5 seconds but server2 is not that important and you would like to pay attention only to locks that last more than 60 seconds. In addition you can define that any block on server1 should be notified at real time by email while a block on server2 will trigger a notification email only if it exceeds 120 seconds.
BlocksTracer is reliable and has a foot print that can hardly be measured. Installation and configuration is quick and most important nothing needs to be installed on the SQL Severs being monitored ("Agentless" installation).
BlocksTracer is a professional tool at a low cost price.
For additional details see the BlocksTracer ReadMe file
Go to the BlocksTracer download page