我在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中,非聚簇索引的管理从存储引擎(我的团队)更改为查询处理器.这有许多副作用,其中一个是通过收缩移动堆数据页的速度.所有非聚簇索引记录都包含指向它们正在编制索引的数据记录的反向链接 – 在堆的情况下,这是指向特定数据页上的记录号的物理链接.通过shrink移动堆数据页时,必须使用页面的新位置更新反向链接到该页上记录的所有非聚簇索引记录.在2000年,存储引擎本身非常有效地完成了这项工作.在2005年以后,必须通过调用查询处理器来更新非聚集索引记录来完成此操作.这有时比2000年慢100倍.
2)行外LOB值(实际LOB数据类型或行溢出数据)不包含它们所属的数据或索引记录的反向链接.移动一页LOB记录时,必须扫描它们所属的整个表或索引,以确定哪些数据/索引记录指向它们,以便可以使用新位置更新它们.这也非常非常慢.
3)可能有另一个使用数据库的进程导致收缩阻塞等待移动页面所需的锁.
4)您可能启用了快照隔离,并且缩小无法移动带有版本存储链接的页面,直到需要这些旧版本的事务完成为止.
5)您的I / O子系统可能功能不足.磁盘队列长度高于低个位数意味着您的I / O子系统处于瓶颈状态.
任何或所有这些都可能导致缩短运行时间.
但一般情况下,您不希望运行收缩.有关详细信息,请参阅此博客文章：Why you should not shrink your data files.
希望这可以帮助！
