我正在600G数据文件上运行SHRINK文件。
目前，状态报告为“挂起”，而对于DbccFilesCompact命令， sys.dm_exec_requests.percent_complete报告它正在运行（但速度非常慢）
有没有办法来检查为什么它被暂停，以及如何使其运行更平滑？
FYI – 用于检查状态的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中，非聚簇索引的pipe理从存储引擎（我的团队）更改为查询处理器。 这有很多副作用，其中之一就是堆数据页可以通过缩小来移动的速度。 所有非聚簇索引logging都包含一个到它们索引的数据logging的反向链接 – 在堆的情况下，这是到特定数据页上的logging号的物理链接。 当通过收缩来移动堆数据页时，反向链接到该页上的logging的所有非聚集索引logging必须用页面的新位置来更新。 在2000年，这是由存储引擎本身非常有效地完成的。 在2005年以后，这必须通过调用查询处理器来更新非聚集索引logging来完成。 这有时比2000年慢100倍。
2）行外LOB值（实际的LOB数据types或行溢出数据）不包含它们所包含的数据或索引logging的反向链接。 当移动LOBlogging页面时，必须扫描它们所包含的整个表格或索引，以确定哪些数据/索引logging指向了这些logging，因此可以使用新的位置进行更新。 这也非常非常缓慢。
3）可能会有另一个使用数据库的进程，导致收缩阻塞等待其移动页面所需的locking。
4）您可能已启用快照隔离function，并且收缩不能使用版本存储链接移动页面，直到需要旧版本的事务完成。
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，而且对于大多数情况，我可以看到它将文件1locking，然后在完成时放置locking文件ID 2，等等，这样我可以告诉它什么时候在最后一个文件ID上工作，这是我的迹象，几乎完成。
谢谢，
Alex Aguilar
我发现了什么问题（在我的情况），我在这里提供了我使用的解决scheme。
我什么都没有使用数据库，并且master是我的会话的默认数据库，我已经validation，使用sp_who2。 然后我右键单击数据库，select“任务”，然后“缩小”和“确定”对话框。 再次用sp_who2进行检查，状态将被“暂停”几分钟，之后终止，因为“不能获得排他locking”。 猜猜你自己，但我确信对话本身就是导致这种情况的原因之一。
所以我决定通过命令行使用：
DBCC SHRINKDATABASE（myDataBase）
（女巫无处不在），然后缩短了几秒钟。