为什么“DbccFilesCompact”状态为“暂停”？

Question

我在 600G 数据文件上运行 SHRINK 文件。

目前，状态报告为“暂停”，并sys.dm_exec_requests.percent_complete为DbccFilesCompact命令会报告它正在运行（但很慢）

有没有办法检查它为什么被暂停以及如何使它运行更顺畅？

仅供参考- 检查状态的 SQL 查询

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

Answer 1

不，你无法检查它为什么运行缓慢，但我可以给你一些提示：

1) 在 SQL 2005 中，非聚集索引的管理从存储引擎（我的团队）更改为查询处理器。这有许多副作用，其中之一是收缩可以提高堆数据页的移动速度。所有非聚集索引记录都包含指向它们正在建立索引的数据记录的反向链接 - 在堆的情况下，这是指向特定数据页上的记录编号的物理链接。当一个堆数据页面被收缩移动时，所有反向链接到该页面上的记录的非聚集索引记录必须更新为该页面的新位置。在 2000 年，存储引擎本身非常有效地完成了这项工作。从 2005 年开始，这必须通过调用查询处理器来更新非聚集索引记录来完成。这有时比 2000 年慢 100 倍。

2) 行外 LOB 值（实际 LOB 数据类型或行溢出数据）不包含指向它们所属的数据或索引记录的反向链接。当移动一页 LOB 记录时，必须扫描它们所属的整个表或索引，以确定哪些数据/索引记录指向它们，以便使用新位置更新它们。这也非常非常缓慢。

3) 可能有另一个进程使用数据库导致收缩阻塞等待移动页面所需的锁。

4) 您可能启用了快照隔离，并且在需要那些旧版本的事务完成之前，收缩无法移动带有版本存储链接的页面。

5) 您的 I/O 子系统可能功率不足。磁盘队列长度高于低个位数意味着您的 I/O 子系统处于瓶颈。

任何或所有这些都可能导致收缩运行时间变慢。

但一般来说，您不想运行收缩。有关详细信息，请参阅此博客文章：为什么不应缩小数据文件。

希望这可以帮助！

Answer 2

您可以运行此脚本来检查完成的百分比！

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'