Guest Post: Identifying and handling blocked processes in SQL Server

Author Bio: Priyanka Chouhan is a technical writer in Stellar Data Recovery with 5 years of experience and has written several articles on SQL server & SharePoint. In her spare time she loves reading and gardening.

Identifying and handling blocked processes in SQL Server

Among other issues, blocked processes on the SQL Server (or SQL Server deadlocks) pose problems for database administrators (DBAs) since it is difficult to identify and monitor them. SQL Server DBAs often receive SOS calls complaining of slow running processes but before they can find out why, they receive information that everything is running fine again.

The real reason behind such a problem is one or many processes that block other tasks temporarily or for long periods.It may seem like a minor issue, but if server processes tend to slow down frequently, they might become a problem in the long run, disrupting the normal working of the server over and over again. It is thus crucial to identify processes that may be blocking the server and deal with the core issues that might be causing them.

SQL Server Deadlocks

The dictionary definition of a deadlock is “a standstill resulting from the action of equal and opposed forces”; in reality, this definition proves to be true in the case of SQL deadlocks. A deadlock on the SQL server is a result of two or more sessions inside the database engine waiting for access to locked resources held by each other. Meaning, session ‘A’ waits for a resource to be free by session ‘B’ which in turn is waiting for another resource to be freed by session ‘A’. So none of the sessions can continue to execute which results in an irresolvable state eventually leading to a halt in the processing inside the database engine.

It is assumed that when a deadlock situation arises on the SQL server, the DBA needs to intervene and abort one of the stuck processes to resolve the situation. However, the SQL server is designed such that it automatically detects and resolves deadlocks by using a background process called the Lock Monitor. This process is initiated when the server instance starts and it constantly monitors the system for deadlock sessions.

How the Lock Monitor helps resolve a deadlock

When the Lock Monitor detects two sessions stuck in a deadlock, one of the sessions (generally the one that requires the least amount of overhead to rollback) is selected and its current transaction is rolled back. When this happens, all the resource locks held by the aborted process are released thus allowing the other session in the deadlock to continue its work. On completion of the roll back, the aborted process’s session is terminated and a 1205 error message is returned to the originating client.

How is a deadlock different from a severe process block?

Yes, a deadlock and a sever process block are two different situations. A deadlock is when two or more sessions endlessly wait for each other to release resources such that none of the sessions can complete.

In contrast, a severe process block happens when one session requests a lock on a resource (a table, page or row) but SQL server cannot grant the lock because that resources has already been locked with a non-compatible lock by another session.

Thus, if the SQL server has become slow, instead of directly deducing that it is because of a deadlock, DBAs should first find out if it is in fact a deadlock or a severe process block. Fortunately, identifying and resolving deadlocks is not very difficult, thanks to the Lock Monitor described above. However, identifying and handling blocked processes is a totally different story.

Identifying blocked processes

In order to maintain data integrity within the database, locks are used on resources like tables, rows, pages etc. by any process that wishes to use them. This is done to ensure multiple process don’t alter the same resources at one time leading to data inconsistency. When a process wishes to lock a resource, it sends a request to the server and the server grants it. However, when a process requests lock on a resource that has already been locked by another process, the request is denied. The requesting process is thus placed on “hold” until the resource it is requesting for isn’t released. In this situation, the requesting process is called a blocked process, and such a process could put a halt on other subsequent processes and activities scheduled on the server.

Thus identifying a blocked process and releasing it requires a DBA team to check the application database blocking. Additionally, here are some other techniques that may be used to find out which processes are creating a block on the server:

1. Blocked Process Threshold

SQL Server has a configuration called Blocked Process Threshold for which you can set a value in milliseconds. Thereafter, SQL server will generate a report each time a process is blocked by this amount of time. The syntax for this is:

EXEC sp_configure ‘Blocked Process Threshold’, 5;
RECONFIGURE;
GO

As per this syntax, a blocked process report will be generated every time a process is blocked for more than 5 seconds. You can adjust the threshold time as per your servers.

2. SQL Server Management Studio Activity Monitor

To locate blocking processes, you need to find out the system process IDs (SPIDs) involved in blocking. With the correct SQL server permissions, you can use the SQL Server Management Studio Activity Monitor to find them as follows:

1. Open SQL Server Management Studio
2. Connect to the SQL Server instance you wish to monitor
3. After the connection is established, right click on the instance name and select ‘Activity Monitor’ from the pop-up menu.
4. When the Activity Monitor loads completely, expand the Processes section.
5. All processes in blocked state will display the SPID of the processes blocking them in the ‘Bloc By’ column.

3. Stored procedure “sp_who2”

1. Open SQL Server Management Studio
2. Connect to the SQL Server instance you wish to monitor
3. After the connection is established, right click on the instance name and select ’New Query’ from the pop-up menu.
4. When the New SQL Server query window opens type the following TSQL statement in the window and execute:
   

   USE Master
   GO
   EXEC sp_who2;
   GO

   This will display a list of processes and blocked processes will display the SPID of the processes blocking them in the ‘BlkBy’ column.

4. SQL Server Management Studio Reports

Another good way to monitor blocked processes is through SQL Server Management Studio reports that can be accessed as follows:

1. Open SQL Server Management Studio
2. Connect to the SQL Server instance you wish to monitor
3. After the connection is established, right click on the instance name and select ‘Reports’ from the pop-up menu
4. Select Standard Reports and then select Activity – All blocking Transactions

To use this method a DBA should have VIEW SERVER STATE permissions on the instance.

Final Words

To make sure SQL Server runs smoothly and provides the best experience for its users, a DBA needs to understand the queries and processes that are causing blocks. In addition to the above-mentioned ways to spot blocking processes, other stored procedures like sys.dm_exec_requests DMV and sys.dm_os_waiting_tasks can also be used to track blocking processes.

The post Guest Post: Identifying and handling blocked processes in SQL Server appeared first on SQL Hammer.