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

我正在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

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

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

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

3）使用数据库的其他进程可能导致收缩阻塞，以等待其移动页面所需的锁。

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

5）您的I / O子系统电源可能不足。磁盘队列长度大于低个位数意味着您的I / O子系统处于瓶颈。

这些中的任何一个或全部都可能导致收缩的运行时间变慢。

通常，您不希望收缩。有关详细信息，请参见此博客文章：为什么不应该收缩数据文件。

希望这可以帮助！

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

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

我正在收缩SQL Server 2008 SP1中的数据库，一种可以告诉Shrink命令进度的方法是执行sp_lock spid，大部分情况下，我可以看到它对文件1进行了锁定，然后将其放置在文件1上。锁定文件ID 2，依此类推，这样我就可以知道何时它正在处理最后一个文件ID，这是我的指示，它即将完成。

谢谢，

亚历克斯·阿吉拉尔

我发现了问题所在（就我而言），并在此提供了我使用的解决方案。

我没有使用该数据库的任何信息，而master是会话中的默认数据库，我已经使用sp_who2进行了验证。然后，我右键单击数据库，选择“任务”，然后选择“缩小”，然后单击“确定”对话框。再次使用sp_who2进行检查，状态将“暂停”几分钟，然后终止，原因是“无法获得排他锁”。猜猜你自己，但是我确信对话框本身就是导致这种情况的原因。

所以我决定使用以下命令通过命令行：

DBCC SHRINKDATABASE（myDataBase）

（女巫到处都有记录），然后收缩只用了几秒钟。