如何在SQL Server中监控大批量DELETE的执行进度-SQL-PHP中文网

sql server delete无法监控行级进度，只能判断执行状态与阻塞原因；应结合sys.dm_exec_requests查运行状态、dbcc opentran看事务起点、sys.dm_tran_locks定位锁冲突，并用sp_whoisactive替代sp_who2获取完整上下文。

如何在sql server中监控大批量delete的执行进度

SQL Server 的 DELETE 本身不暴露行级进度，percent_complete 对它永远是 0；你真正能监控的，是“它卡在哪”“是不是真在跑”，而不是“还剩多少行没删”。

查 `sys.dm_exec_requests` 看 DELETE 是否活着、卡在哪

这是第一反应该查的视图。它告诉你当前这个 DELETE 请求的状态，不是“删了多少”，而是“它现在算不算正常工作”。

command = 'DELETE' 且 status = 'running'：说明它正在执行（但不等于快——可能正扫全表）
status = 'suspended' 且 wait_type 非空（比如 LCK_M_U、PAGEIOLATCH_SH）：它被锁或 I/O 卡住了，不是慢，是堵
last_wait_type 和 start_time 结合看：如果同一 wait_type 持续十几分钟，基本可判定阻塞未解
session_id 是后续所有排查的起点，必须记牢

用 `DBCC OPENTRAN` 判断事务起点是否异常

它不告诉你进度，但能帮你区分“刚启动就被堵”和“真删了 40 分钟还没完”。关键看事务 BEGIN 时间。

必须在目标数据库上下文里执行：USE [YourDB]; DBCC OPENTRAN;
输出中 Oldest active transaction 行的 SPID 应与 sys.dm_exec_requests.session_id 匹配
如果 DBCC OPENTRAN 显示事务始于 2 分钟前，但你看到它“跑了 45 分钟”，那它大概率从第 2 分钟起就 suspended 了
若返回 No active open transactions，说明事务已结束（提交或回滚），你看到的可能是残留连接或未释放会话

查 `sys.dm_tran_locks` 定位锁冲突源头

90% 的“长 DELETE”不动，根源是锁。这里能看出它锁了什么、等谁放、甚至谁在锁它。

先过滤：WHERE request_session_id = @your_session_id
重点看 resource_type：'KEY' 多说明走索引逐行删；'OBJECT' 或 'PAGE' 多可能已锁升级或扫描范围过大
找 request_status = 'WAIT' 的记录，再根据 resource_description（常含页号或键值）往上翻，找相同描述且 request_status = 'GRANT' 的行——那就是持锁者
若发现大量 KEY 锁但 resource_description 分散（如不同 hobt_id），说明没走覆盖索引，排序/定位开销大

别用 `sp_who2`，装个 `sp_WhoIsActive`

sp_who2 输出太简陋，缺 SQL 文本、缺等待资源细节、默认混入系统进程，容易漏掉关键线索。

sp_WhoIsActive 默认输出包含：sql_text（能看到实际删的条件）、blocking_session_id（谁在堵它）、wait_info（带超时时间的完整等待链）
安装只需运行作者官网提供的脚本，无副作用
常用调用：EXEC sp_WhoIsActive @filter = @session_id, @filter_type = 'session';
它还能导出为 XML 或存表分析，适合持续盯梢

真正难的不是“怎么查”，而是把 sys.dm_exec_requests、DBCC OPENTRAN、sys.dm_tran_locks 三者的输出串起来读——比如看到 suspended + LCK_M_U，立刻去锁视图里找谁占着那个 KEY，再顺藤摸到持锁者的 SQL。这个闭环判断，比任何单点指标都管用。