2
如何找到仍持有锁的查询?
查询sys.dm_tran_locksDMV将向我们显示哪些会话(SPID)持有对表,页面和行等资源的锁定。 对于获得的每个锁,是否有任何方法可以确定哪个SQL语句(删除,插入,更新或选择)导致了该锁? 我知道,most_recent_query_handle在列sys.dm_exec_connectionsDMV给了我们执行的最后一个查询的文本,而是多次其他查询同一个会话(SPID)在跑前和仍持有锁。 我已经使用了该sp_whoisactive过程(来自Adam Machanic),它仅显示了当前在输入缓冲区上的查询(认为DBCC INPUTBUFFER @spid),但并非总是(在我的情况下通常是)获取锁定的查询。 例如: 公开交易/会话 exec一条语句(持有资源锁) 在同一会话上执行另一条语句 打开另一个事务/会话,然后尝试修改在步骤2锁定的资源。 该sp_whoisactive过程将在第3步指出该语句,它不是锁的责任,因此无用。 这个问题来自使用“ 阻塞的流程报告”功能进行分析,以查找生产中阻塞方案的根本原因。每个事务都运行几个查询,大多数情况下,最后一个查询(显示在BPR的输入缓冲区上)很少是持有锁的查询。 我有一个后续问题:有效识别阻塞查询的框架