DBCC SHRINKFILE性能

Question

我有一个生产Server 2008，8 TB分布在几个数据库中。我已经删除了每个数据库中大约85%的数据，并且必须恢复磁盘空间。所有USED_SPACE的最后总和为1.2TB。

此SHRINKFILE流程必须适合每个数据库7小时的维护窗口。

然而，在每一个上都要花费许多小时才能运行。例如，将一个800 GB的数据库缩小到120 GB需要超过15个小时。

不幸的是，这超出了我的维护窗口，我不得不终止进程，希望数据库不会损坏(随后的DBCC显示它们正常)。

我可以看到没有充分利用可用的磁盘I/O或CPU资源。

例如，只需几个小时就可以将完整大小的数据库文件从一个磁盘复制到另一个磁盘，但是SHRINKFILE进程所需时间要长得多。

注意:数据库都设置为简单恢复模式，AUTO_SHRINK关闭。

是的，我看到很多人说永远不要这样做，因为它破坏了索引-我确实计划在SHRINKFILE完成时重建这些索引。

是否有任何方法提高SHRINKFILE命令的优先级或任何替代解决方案？以下是我正在考虑的一些选择：

• 在运行DEADLOCK_PRIORITY之前，在同一会话中将SHRINKFILE.设置得很高(但我怀疑这会有帮助)。
• 创建一个新数据库并逐个表复制所有数据表。

Answer 1

解决办法是留出更多的空间。

当缩小MDF文件时，如果我留下一些未使用的空间(不要删除所有未使用的空间)，那么它完成的速度要快得多。

例如:如果一个3TB数据库仅使用了200 to，那么将其缩小到200 to将需要很长的时间。但是，如果我将其缩小到300 is，则收缩过程要快得多。

我猜SQL必须将数据整理到极致，以便删除所有未使用的空间。然而，通过留出额外的空间，它只能重新组织更大的数据部分，或者调整文件指针以适应。