标签: blocking

我正在使用扩展事件收集阻塞的进程报告，并且由于某些原因，在某些报告中该blocking-process节点为空。这是完整的xml：

<blocked-process-report monitorLoop="383674">
 <blocked-process>
  <process id="processa7bd5b868" taskpriority="0" logused="106108620" waitresource="KEY: 6:72057613454278656 (8a2f7bc2cd41)" waittime="25343" ownerId="1051989016" transactionname="user_transaction" lasttranstarted="2017-03-20T09:30:38.657" XDES="0x21f382d9c8" lockMode="X" schedulerid="7" kpid="15316" status="suspended" spid="252" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2017-03-20T09:39:15.853" lastbatchcompleted="2017-03-20T09:39:15.850" lastattention="1900-01-01T00:00:00.850" clientapp="Microsoft Dynamics AX" hostname="***" hostpid="1348" loginname="***" isolationlevel="read committed (2)" xactid="1051989016" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
   <executionStack>
    <frame line="1" stmtstart="40" sqlhandle="0x02000000f7def225b0edaecd8744b453ce09bdcff9b291f50000000000000000000000000000000000000000" />
    <frame line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" />
   </executionStack>
   <inputbuf>
(@P1 bigint,@P2 int)DELETE FROM DIMENSIONFOCUSUNPROCESSEDTRANSACTIONS WHERE ((PARTITION=5637144576) AND ((FOCUSDIMENSIONHIERARCHY=@P1) AND (STATE=@P2)))   </inputbuf>
  </process>
 </blocked-process>
 <blocking-process>
  <process />
 </blocking-process>
</blocked-process-report>

此 hobt_id 所属索引的索引定义是

CREATE UNIQUE …

我们的生产环境今天早上在更改表时冻结*了一段时间，实际上是添加了一列。

违规 SQL：ALTER TABLE cliente ADD COLUMN topicos character varying(20)[];

* 登录到我们的系统需要从同一张表中进行选择，因此在更改表期间没有人可以登录。我们实际上不得不终止进程以让系统恢复正常运行。

表结构：

CREATE TABLE cliente
(
  rut character varying(30) NOT NULL,
  nombre character varying(150) NOT NULL,
  razon_social character varying(150) NOT NULL,
  direccion character varying(200) NOT NULL,
  comuna character varying(100) NOT NULL,
  ciudad character varying(100) NOT NULL,
  codigo_pais character varying(3) NOT NULL,
  activo boolean DEFAULT true,
  id serial NOT NULL,
  stock boolean DEFAULT false,
  vigente boolean DEFAULT true,
  clase integer DEFAULT 1,
  plan integer DEFAULT 1,
  plantilla character varying(15) …

我们正在尝试更新/删除数十亿行表中的大量记录。由于这是一张受欢迎的桌子，因此这张桌子的不同部分有很多活动。任何大型更新/删除活动都被长时间阻塞（因为它正在等待获得所有行的锁或页锁或表锁），从而导致超时或需要多天才能完成任务。

因此，我们正在更改一次删除小批量行的方法。但是我们想检查选定的（比如 100、1000 或 2000 行）当前是否被不同的进程锁定。

• 如果没有，则继续删除/更新。
• 如果它们被锁定，则移至下一组记录。
• 最后，回到开头并尝试更新/删除遗漏的。

这是可行的吗？

谢谢，ToC

查询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 的输入缓冲区中）很少是持有锁的那个。

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

这个问题在 MSDN 上再次出现：Blocked-process-report: what is this waitresource "OBJECT: 32767:124607697:0 [COMPILE]"

我在 Profiler 中发现了这些语句。它们的持续时间都超过 3 秒。一些超过 10+。阻止活动与来自MSDN的链接相同。

调用都使用 3 部分命名。都指定了一个不同的过程，它们看起来像下面这样：

exec [db1].[sys].sp_procedure_params_90_rowset N'proc1', 1, NULL, NULL
exec [db2].[sys].sp_procedure_params_90_rowset N'proc2', 1, NULL, NULL
exec [db3].[sys].sp_procedure_params_90_rowset N'proc3', 1, NULL, NULL
exec [db4].[sys].sp_procedure_params_90_rowset N'proc4', 1, NULL, NULL

我可以做些什么来减少这种级别的阻塞？

（编辑）我现在看到同样的事情：

exec [db1].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db2].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db3].[sys].sp_primary_keys_rowset N'view1', N'dbo'
exec [db4].[sys].sp_primary_keys_rowset N'view1', N'dbo'

有系统性的事情正在发生，但我不知道还能做什么。调用者是通过 ADO 的 VB6。是 ADO 进行这些调用。

下面是一个被阻止的进程报告示例

 <blocked-process-report>
    <blocked-process>
        <process
            id="process5bc1288"
            taskpriority="0"
            logused="0"
            waitresource="OBJECT: 32767:124607697:0 [COMPILE]" …

我在 SQL SERVER 中有一个锁定整个表的选择。

这是设置脚本（确保您没有覆盖任何内容）

USE [master]
GO

IF EXISTS(SELECT 1 FROM sys.databases d WHERE d.name = 'LockingTestDB')
DROP DATABASE LockingTestDB
GO

CREATE DATABASE LockingTestDB
GO

USE [LockingTestDB]
GO
IF EXISTS(SELECT 1 FROM sys.tables t WHERE t.name = 'LockingTestTable')
  DROP TABLE LockingTestTable
GO

CREATE TABLE LockingTestTable (
  Id int IDENTITY(1, 1),
  Name varchar(100),
  PRIMARY KEY CLUSTERED (Id)
)
GO

INSERT INTO LockingTestTable(Name) VALUES ('1')
INSERT INTO LockingTestTable(Name) VALUES ('2')
GO

打开一个新的查询窗口并运行以下事务（其中有一个等待）：

USE [LockingTestDB]
GO

BEGIN TRANSACTION
  SELECT * FROM LockingTestTable …

此处找到的 SQL Server 中的隔离级别列表指出，在事务中获取的写锁将保留到事务结束。但是，它没有提及有关何时获取这些锁的任何信息。

默认情况下，锁是在事务开始时获取还是在需要时获取？如果后者为真，那么在大型事务中尽可能晚地执行写操作以最小化持有 X 锁的时间是否有利？

我遇到过一种情况，用户在我们的一个运行存储过程的应用程序中运行了某些内容。存储过程执行一些日志记录（INSERT记录到日志表），然后以以下格式执行简单的删除

DELETE FROM MyTable WHERE Id = 1

从具有数百万行的表中删除DELETE数万条记录（存储过程对多个表执行此操作）并生成并行执行计划。Id 列是复合主键中的第二列，但该表没有任何以该列开头的索引。

删除计划可在此处获取

表的匿名 DDL 如下

CREATE TABLE [dbo].MyTable
(
    [Column15] [varchar](50) NULL,
    [Column16] [int] NULL,
    [Column2] [datetime] NULL,
    [Column3] [datetime] NULL,
    [Column4] [varchar](50) NOT NULL,
    [Column5] [datetime] NULL,
    [Column17] [varchar](8) NULL,
    [Column18] [varchar](50) NULL,
    [Column6] [int] NULL,
    [Column7] [int] NULL,
    [Column9] [int] NULL,
    [Column8] [int] NULL,
    [Column19] [varchar](50) NULL,
    [Column20] [varchar](50) NULL,
    [Column21] [varchar](50) NULL,
    [Column22] [varchar](50) NULL,
    [Column23] [varchar](50) NULL,
    [Column24] [varchar](50) NULL,
    [Column25] [varchar](50) …

我正在尝试诊断一个间歇性需要很长时间的查询。我怀疑它可能在尝试获取锁时被阻止。我无权在遇到问题的环境中使用探查器。

有什么方法可以让我在不使用外部分析器的情况下获取有关此单个查询被阻止多长时间的统计信息？

我最近将我们的 2016 SQL Server 更新到 SP2 和 2018 年 8 月发布的最新 CU (KB4458621)。就在最后一天左右，我注意到我有一些阻塞。我无法杀死 SPID b/c，它不是用户进程。根据 SP_WHO2，命令是“Query Store ASYN”。我尝试通过脚本和 UI 清除数据并禁用查询存储。似乎没有任何效果，它只是旋转，然后开始造成更多阻塞。还有其他人有这个问题吗？谁能帮我弄清楚如何成功禁用查询存储？SP_WhoIsActive @show_System_SPIDS = 1 个结果如下（仅查询存储结果）

更新 - 这现在导致 TempDB 驱动器填满。几个小时后尝试重新启动，看看是否能解决问题。将及时向大家发布。

谢谢，内特