dbccrinklebase是否真的需要2天以上的时间(并且还在增加中..) [英] Should dbcc shrinkdatabase really take 2+ days (and counting..)

问题描述

由于索引大小的限制，我有几个索引无法建立，并且注意到我的数据库数据存储分配已跃升至已使用的509GB，已分配936GB，最大1TB.我按照此处的建议在 文档，并做了一个dbcc收缩数据库.

I had a few indexes fail to build (due to log size constraints) and noticed that my database data storage allocation had leapt to 509GB used, 936GB allocated, 1TB max size.  I followed the advice here in the docs and did a dbcc shrinkdatabase.

2天零4个小时后，它仍以50％CPU，<2％数据IO〜60/65％日志IO的速度运行-在整个期间都相当稳定.

2 days and 4 hours later its still running at 50% CPU,<2% Data IO ~60/65% Log IO - fairly consistently for the whole period.

我的配置是关键业务，第5代，2个vCore，1TB存储

My config is a Business Critical, Gen 5, 2 vCores, 1TB storage

基本上，这使我离线了2天，因为服务器当然无法使用.

Its basically taken me offline for 2 days as the server is of course otherwise unusable.

我认为这是不正常的吗?我应该把它当做票...

Am I right in thinking this isn't normal and I should really be raising this as a ticket...

推荐答案

你好，

我会先对现有索引进行碎片整理，而宁愿回收空间比执行数据库收缩更容易.

通常，当数据库具有LOB数据或varchar(max)数据时，DBCC SHRINKDATABASE将运行缓慢.

请运行以下查询以验证收缩过程没有被阻止，这可能是因为它花费了很多时间的原因.

I would have defragmented existing indexes first to reclaim space rather than executing a database shrink.

Usually when the database has LOB data or varchar(max) data the DBCC SHRINKDATABASE will run slowly.

Please run the following query to verify the shrink process is not blocked, that may be the reason is taking so much time.

SELECT session_id, blocking_session_id,

percent_complete ,estimated_completion_time

FROM sys.dm_exec_requests

You can kill the session if you want using KILL. The statement does not rollback and the progress obtained will be retained.

Hope this helps.

Alberto Morillo
SQLCoffee.com

这篇关于dbccrinklebase是否真的需要2天以上的时间(并且还在增加中..)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！