我正在对 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
不,你无法检查它运行缓慢的原因,但我可以给你一些提示:
1) 在 SQL 2005 中,非聚集索引的管理从存储引擎(我的团队)更改为查询处理器。这有许多副作用,其中之一就是通过收缩移动堆数据页的速度。所有非聚集索引记录都包含指向它们正在索引的数据记录的反向链接 - 对于堆,这是指向特定数据页上的记录号的物理链接。当通过收缩移动堆数据页时,所有反向链接到该页面上的记录的非聚集索引记录都必须使用页面的新位置进行更新。在 2000 年,存储引擎本身非常高效地完成了这项工作。从 2005 年起,必须通过调用查询处理器来更新非聚集索引记录。这有时比 2000 年慢 100 倍。
2) 行外 LOB 值(实际 LOB 数据类型或行溢出数据)不包含指向其所属数据或索引记录的反向链接。当移动一页 LOB 记录时,必须扫描它们所属的整个表或索引,以确定哪个数据/索引记录指向它们,以便可以使用新位置更新它们。这也非常非常慢。
3) 可能有另一个进程正在使用数据库,导致收缩阻塞,等待移动页面所需的锁。
4) 您可能启用了快照隔离,并且 shrink 无法移动具有版本存储链接的页面,直到需要这些旧版本的事务完成为止。
5) 您的 I/O 子系统可能性能不足。磁盘队列长度高于低个位数意味着您的 I/O 子系统处于瓶颈。
其中任何一个或者全部都可能导致收缩运行时间变慢。
但一般来说,您不想运行 shrink。有关详细信息,请参阅此博客文章:为什么不应该缩小数据文件。
希望这可以帮助!
答案2
您可以运行此脚本来检查完成的百分比!
SELECT
percent_complete,
start_time,
status,
command,
estimated_completion_time,
cpu_time,
total_elapsed_time
--,*
FROM
sys.dm_exec_requests
WHERE
command = 'DbccFilesCompact'
答案3
我正在 SQL Server 2008 SP1 中收缩数据库,我可以通过执行 sp_lock spid 来了解收缩命令的进度,在大多数情况下,我可以看到它锁定了文件 1,然后完成后,它锁定了文件 ID 2,依此类推,这样我就可以知道它何时在处理最后一个文件 ID,这表明它几乎完成了。
谢谢,
亚历克斯·阿吉拉尔
答案4
我发现了问题所在(就我而言),并在此提供我使用的解决方案。
我没有使用数据库,master 是我会话中的默认数据库,我已经使用 sp_who2 验证了这一点。然后我右键单击数据库,选择“任务”,然后选择“收缩”,最后单击“确定”对话框。再次使用 sp_who2 检查,状态为“暂停”几分钟,之后因为“无法获得独占锁”而中止。您自己猜吧,但我确信对话框本身就是导致这种情况的原因。
因此我决定通过命令行使用:
DBCC SHRINKDATABASE(myDataBase)
(这在各处都有记载),然后心理医生只花了几秒钟的时间。