阻塞会话

In this article, we will study how to recognize and resolve the SQL blocking chain by determining and troubleshooting the root cause.

在本文中，我们将研究如何通过确定根本原因并进行故障排除来识别和解决SQL阻塞链。

Every SQL Server database connection is represented by a unique Session ID (SPID) and is authenticated and authorized with a SQL login and appropriate access role. A SQL Server session is often called a process, each client connection to the SQL Server uses system database structure and consume the system resources that can be identified with the help of system DMV.

每个SQL Server数据库连接均由唯一的会话ID（SPID）表示，并通过SQL登录名和适当的访问角色进行身份验证和授权。 SQL Server会话通常被称为进程 ，每个与SQL Server的客户端连接都使用系统数据库结构，并消耗可以借助系统DMV识别的系统资源。

A client application refers to a CMD, backend application, application services, SQL Server Management Studio, or any other tool which allows access to the database and manipulation of the data. A single client application can have multiple connections, and there is no distinction between multiple connections from a single client application or multiple connections from more than one client application. SQL Server will execute client requests and complete each client connection, but unfortunately, that connection can block each other, whether that can be from the same source or different application source.

客户端应用程序是指CMD，后端应用程序，应用程序服务，SQL Server Management Studio或任何其他允许访问数据库和操纵数据的工具。 单个客户端应用程序可以具有多个连接，并且来自单个客户端应用程序的多个连接或来自多个客户端应用程序的多个连接之间没有区别。 SQL Server将执行客户端请求并完成每个客户端连接，但是不幸的是，该连接可能彼此阻塞，无论是来自同一源还是不同应用程序源。

RDBMS database engine uses transaction lock-based connection concurrency as part of ACID. The database engine treats a number of concurrent requests; therefore, there can be a certain scenario with transaction locking collaboration. It happens when one of the transaction holds a lock on a particular resource of the database and another Transaction endeavors to obtain that lock which is conflicting on the same resource. As simple, blocking happens when one transaction puts a lock on resources then releases it so another transaction can use those resources. Blocking actually prevents conflicts from occurring. It occurs in little time allotments, and it is excessively snappy.

RDBMS数据库引擎使用基于事务锁定的连接并发作为ACID的一部分。 数据库引擎处理大量并发请求； 因此，在某些情况下可以使用事务锁定协作。 当事务之一在数据库的特定资源上持有锁，而另一事务试图获得在同一资源上发生冲突的锁时，就会发生这种情况。 简单来说，阻塞发生在一个事务对资源进行锁定然后释放它时，以便另一事务可以使用这些资源。 阻止实际上可以防止发生冲突。 它发生在很少的时间分配中，并且过于灵活。

Unfortunately, blocking can cause poor performance when the duration of locks is too long on the resource. If a resource lock lasts too long, then next SPID must wait in the transaction blocking chain. The total elapsed time taken by the SQL Server connection and number of query execution inside the transaction decides how long the lock would be placed on the object. In that sequence way, it affects other queries too. The execution time of the query is much dependent on Query Type, several SQL statements inside the single request, ISOLATION LEVEL, MAXDOP, Lock within the statement, and many more.

不幸的是，当资源的锁定时间太长时，阻塞会导致性能下降。 如果资源锁的持续时间太长，则下一个SPID必须在事务阻止链中等待。 SQL Server连接所花费的总时间以及事务内部查询执行的次数决定了将锁放置在对象上的时间。 以这种顺序方式，它也会影响其他查询。 查询的执行时间很大程度上取决于查询类型，单个请求内的多个SQL语句，ISOLATION LEVEL，MAXDOP，语句内的Lock等等。

For the queries being executed within a transaction, the lock duration is ruled by the query statement execution and TRANSACTION ISOLATION LEVEL used within the query. Damage to SQL Server performance is largely due to one of the following reasons:

对于在事务中执行的查询，锁定持续时间由查询语句执行和查询中使用的TRANSACTION ISOLATION LEVEL决定。 SQL Server性能的损坏很大程度上是由于以下原因之一：

• The procedure or SQL query has finished the execution; however, the transaction is not committed by the application due to some reason at the application level

  过程或SQL查询已完成执行； 但是，由于某种原因在应用程序级别，事务未由应用程序提交

  Ideally, an application request for a query would execute rapidly, and either get it committed or rolled back by the application. However, if there is something wrong with the application, the SQL Server Database Engine will stand by and wait for an application response. This blocks all subsequent transactions

  理想情况下，应用程序对查询的请求将快速执行，并由应用程序提交或回滚。 但是，如果应用程序出现问题，则SQL Server数据库引擎将待命并等待应用程序响应。 这会阻止所有后续交易

• At the point where the query execution took more time than expected, the resource lock won’t be released. This could be due to issues like memory, CPU, index, poor query logic, etc.

  在查询执行花费的时间比预期的多的时候，资源锁将不会释放。 这可能是由于内存，CPU，索引，查询逻辑不佳等问题引起的。

  Since a poorly-written statement can take more time than expected, insert, update, and delete statements should be written in a straightforward manner. During the execution, Query will hold the lock on the resources(pages) of the article(Tables), which are being utilized in Query, it tends to be row lock, page lock, table lock. Therefore, next blocked sessions need to hold up until the completion of the main transaction

  由于写得不好的语句可能比预期花费更多的时间，因此应该以简单的方式编写插入，更新和删除语句。 在执行过程中，Query将锁定在Query中正在使用的文章（表）的资源（页面）上，它倾向于是行锁，页面锁，表锁。 因此，下一个被阻止的会话需要保持到主事务完成为止

• Multiple queries executed in a single transaction could take longer execution across the databases or SQL Server instances (Using Linked Server)

  在单个事务中执行多个查询可能需要更长的时间跨数据库或SQL Server实例执行（使用链接服务器）

  A remote database query or remote method can be executed inside the SQL Server. If the remote server is in the same region, there should be fewer latency issues; however, with greater distances, latency can degrade your query performance

  可以在SQL Server内部执行远程数据库查询或远程方法。 如果远程服务器在同一区域中，则应减少等待时间问题； 但是，距离越远，延迟可能会降低查询性能

  Several SQL Query within the transaction can be executed across the database and SQL Server instance from the application end too. Any query of the bunch took more time than expected then lock holds on the table will continue, which are placed from the previous query within the transaction until transaction commit or rollback

  事务中的多个SQL查询也可以从应用程序端跨数据库和SQL Server实例执行。 串中的任何查询花费的时间都比预期的多，然后表上的锁保持将继续，这将从事务中的上一个查询放置，直到事务提交或回滚

In the SQL blocking chain, it can be difficult to recognize which query is causing trouble since there can be different SQL Statements and procedures in a single transaction. Using the T-SQL script, we can identify the SPID at the top of the SQL blocking chain with the SQL statement from the SQL Server Management Studio.

在SQL阻塞链中，由于单个事务中可能存在不同SQL语句和过程，因此很难识别哪个查询引起了问题。 使用T-SQL脚本，我们可以使用SQL Server Management Studio中SQL语句在SQL阻塞链的顶部标识SPID。

查询以列出SQL阻塞链中的阻塞请求或会话 (Query to List Blocked Requests or Sessions in SQL Blocking Chain)

SQL Server Dynamic Management Views (DMV) return internal engine state information. We can utilize certain DMVs and manipulate some metrics to identify a SQL blocking chain.

SQL Server动态管理视图（DMV）返回内部引擎状态信息。 我们可以利用某些DMV并操纵一些指标来识别SQL阻塞链。

The sys.dm_exec_requests table returns current executing requests with certain fundamental information, for example, Database name, ISOLATION LEVEL, request start time, CPU utilized time, elapsed time, wait type, Execution Plan(plan_handle), command, blocking_session_id, and more. To screen the blocking on the SQL Server, we can use the command shown below to see various threads which are blocked by other transaction or request.

sys.dm_exec_requests表返回具有某些基本信息的当前执行请求，例如，数据库名称，ISOLATION LEVEL，请求开始时间，CPU占用时间，经过时间，等待类型，执行计划（plan_handle），命令，blocking_session_id等。 要在SQL Server上屏蔽阻塞，我们可以使用下面显示的命令查看被其他事务或请求阻塞的各种线程。

For instance, an update statement has been executed with BEGIN TRANSACTION and before committing it, we have two SELECT and UPDATE statements. The below query can assist us with troubleshooting the issue:

例如，已使用BEGIN TRANSACTION执行了一条update语句，在提交该语句之前，我们有两个SELECT和UPDATE语句。 以下查询可以帮助我们解决问题：

SELECT session_id,blocking_session_id,start_time,status,command,DB_NAME(database_id) as [database],wait_type,wait_resource,wait_time,open_transaction_count, plan_handle
FROM SYS.DM_EXEC_REQUESTS
WHERE session_id > 49

The above command will return the fundamental details of the blocked request. However, we must look closely to see the parent blocking requests. Here, Session id (55) is getting blocked by SPID 59, and 59 is getting blocked by 57, yet 57 isn’t shown in the DMV(SYS.DM_EXEC_REQUESTS) result. Since execution is finished, yet not committed or rolled back. All SPID or threads in SQL blocking chain will be with the suspended wait type, excluding most parent SPID.

上面的命令将返回被阻止请求的基本细节。 但是，我们必须仔细查看以查看父级阻止请求。 此处，会话ID（55）被SPID 59阻塞，而59被57阻塞，但是DMV（ SYS.DM_EXEC_REQUESTS ）结果中未显示57。 执行完成后，尚未提交或回退。 SQL阻塞链中的所有SPID或线程都将具有暂停的等待类型，但不包括大多数父SPID。

使用DMV上的递归度量来识别和解析SQL阻塞链 (Identify and resolve the SQL Blocking Chain using Recursive Metrics on DMV)

With careful examination of the above DMV, we can determine the blocking problems that have occurred. How can we use this information to resolve common blocking scenarios, such as which blocking session is causing problems for others and why?

通过仔细检查上述DMV，我们可以确定已发生的阻塞问题。 我们如何使用这些信息来解决常见的阻塞情况，例如哪个阻塞会话给其他人造成了问题以及为什么？

Recursive CTE allows us to locate the most damaging parent blocking session or transaction, so we don’t have to analyze the complete blocking session chain when we are troubleshooting the SQL blocking issues:

递归CTE允许我们定位破坏性最大的父阻止会话或事务，因此在对SQL阻止问题进行故障排除时，我们不必分析完整的阻止会话链：

;WITH CTE
AS
(
SELECT session_id, blocking_session_id
FROM SYS.DM_EXEC_REQUESTS
WHERE session_id > 49 and blocking_session_id <> 0UNION ALLSELECT X.blocking_session_id AS session_id, ISNULL(Y.blocking_session_id, 0) AS blocking_session_id
FROM CTE X
OUTER APPLY [fn_get_blocking_session](X.blocking_session_id) Y
WHERE X.blocking_session_id <> 0
)SELECT DISTINCT sdes.session_id, host_name, program_name, sqltext.TEXT, dmv.wait_type, dmv.wait_resource
FROM CTE c
INNER JOIN SYS.dm_exec_sessions sdes ON c.session_id = sdes.session_id
LEFT JOIN sys.dm_exec_requests dmv ON c.session_id = dmv.session_id
OUTER APPLY sys.dm_exec_sql_text(dmv.sql_handle) AS sqltext
WHERE c.blocking_session_id = 0

If the execution of the session is finished, but not yet committed or rolled back, the above recursive query will assist us with getting that session request subtleties from SYS.dm_exec_sessions, which won’t exist in sys.dm_exec_requests table. In the above result set, execution of SESSION ID: 57 has finished, so we cannot have the query explanation of that session. Yet, DBCC INPUTBUFFER(session_id) gets more event data of current execution for the specific session id:

如果会话的执行已完成，但尚未提交或回滚，则上述递归查询将帮助我们从SYS.dm_exec_sessions中获取会话请求的细节，而sys.dm_exec_requests表中将不存在该请求。 在以上结果集中，SESSION ID：57的执行已完成，因此我们无法获得该会话的查询说明。 但是， DBCC INPUTBUFFER（session_id）会为特定的会话ID获取更多当前执行的事件数据：

DBCC INPUTBUFFER (57)

–57 is a parent Blocking Session ID in SQL Blocking chain.

–57是SQL阻止链中的父阻止会话ID。

wait_resource and wait_type are also significant in SQL Server blocking. If a remote procedure call is executing inside the primary parent blocker session, then wait_resource will help us to troubleshoot it with the remote server name and session id (at the remote server). So, we can distinguish and investigate the issue at the remote server end.

在SQL Server阻止中，wait_resource和wait_type也很重要。 如果在主父阻止程序会话中正在执行远程过程调用，则wait_resource将帮助我们使用远程服务器名称和会话ID（在远程服务器上）对它进行故障排除。 因此，我们可以在远程服务器端识别和调查问题。

In an eventful database, countless user transactions compete for instantaneous access to the same tables and indexes. As seen, usually SQL Server arbitrates access to these shared resources by using various types of locks. Blocking occurs when more than one session requests a lock on a resource, such as a row, page, or table, but SQL Server is not able to grant that lock due to another session already holding a non-compatible lock on that resource.

在一个多事的数据库中，无数的用户事务争夺对相同表和索引的即时访问。 可以看出，通常SQL Server通过使用各种类型的锁来仲裁对这些共享资源的访问。 当多个会话请求对资源（例如行，页或表）进行锁定时，会发生阻塞，但由于另一会话已对该资源持有了不兼容的锁定，因此SQL Server无法授予该锁定。

翻译自: https://www.sqlshack.com/resolve-and-troubleshoot-sql-blocking-chain-with-root-session/

阻塞会话