小编tan*_*lle的帖子

查询sys.dm_tran_locksDMV 会向我们显示哪些会话 (SPID) 持有表、页和行等资源的锁。

对于获取的每个锁，是否有任何方法可以确定导致该锁的 SQL 语句（删除、插入、更新或选择）？

我知道，most_recent_query_handle在列sys.dm_exec_connectionsDMV给了我们执行的最后一个查询的文本，而是多次其他查询同一个会话（SPID）在跑前和仍持有锁。

我已经使用了这个sp_whoisactive过程（来自 Adam Machanic），它只显示了此时输入缓冲区上的查询（想想DBCC INPUTBUFFER @spid），这并不总是（在我的情况下通常永远不会）是获取锁的查询。

例如：

1. 打开交易/会话
2. exec 语句（持有资源锁）
3. 在同一个会话中执行另一个语句
4. 打开另一个事务/会话并尝试修改在步骤 2 中锁定的资源。

该sp_whoisactive过程将指出第 3 步中的语句，该语句不是锁的负责人，因此没有用。

这个问题来自使用Blocked Process Reports功能进行分析，以找出生产中阻塞场景的根本原因。每个事务运行多个查询，并且大多数时候最后一个（显示在 BPR 的输入缓冲区中）很少是持有锁的那个。

我有一个后续问题：有效识别阻塞查询的框架

我发现以下查询显示设置了多少会话上下文变量：

SELECT cache_address
      ,name
      ,pages_kb
      ,pages_in_use_kb
      ,entries_count
      ,entries_in_use_count
FROM   sys.dm_os_memory_cache_counters
WHERE  TYPE = 'CACHESTORE_SESSION_CONTEXT';

但现在我想知道设置了哪些键值对SESSION_CONTEXT()——如果有的话。

在对微软网站进行广泛研究后，我没有发现任何相关内容。

提前致谢。

我需要一个例程来有效识别哪些查询导致阻塞。这与我之前的问题如何找到仍然持有锁的查询有关？.

我知道网上有很多关于这方面的资料，但所有这些资料都是基于活动会话上的最后一条 SQL 语句很可能是获取锁的那个（因此产生了阻塞），这并不总是真的（在我的情况下，从来没有）。

我已将 设置blocking-process-threshold为 30 秒并开始分析阻塞进程报告 (BPR)。
当达到阈值时，每次发生阻塞时都会触发这些报告。
它包含有关阻塞 spid 和阻塞 spid 的信息。

通常，阻塞 spid 会在获取并持有资源（表、页或行）锁的语句之后运行几个语句：因此，不管报告内容如何，​​我仍然不知道究竟是哪个查询导致了该阻塞。

通常 SQL Server DMV 只显示每个 的最后一个 SQL 文本session_id，与活动锁（例如sys.dm_tran_locks）相关的 DMV也没有解决这个问题。

调整阻塞的查询在这里不是最好的方法：我们的应用程序全部基于嵌入在客户端代码中的动态 SQL，我们不使用存储过程，并且基于我目前看到的阻塞，所有阻塞的查询都被正确索引并写成。

我认为解决这个问题的一个选项是收集候选查询，这可能会产生阻塞，然后使用在 BPR 上收集的时间戳和 spid 查找此信息。你同意？如果是这样，您能否指出一种使用 xEvents 以尽可能少的开销来做到这一点的方法？