在 1.5 TB 的数据库上，收缩数据库没有像预期的那样收缩。

Question

我在一个企业系统中工作，它有一个 1.5 TB 的数据库，它位于单个文件组上，日志处于简单恢复模式。由于我们有许多团队并行处理不同的项目，因此我们在不同环境中拥有该数据库的大约 20 个副本，以及主要的 DEV、QA、Staging 和 Production 副本。

对于 DEV、QA 和其他环境，我们不需要完整的数据库，因此我们开发了一个脚本来从前 20 个表中删除旧数据。这将回收大约 1 TB 的可用空间。在所有环境中，我们将在 SAN 上节省至少 15 TB 的磁盘空间。我知道这个缩小过程会导致索引碎片 - 但不要介意在数据库缩小后重建所有索引。

Shrink 数据库有两个问题：

1. 它似乎需要永远；超过 48 小时。

2. 它不会像预期的那样收缩数据库。收缩过程没有错误地完成，但在数据库中留下了 100 MB 的可用空间。

我试过了：

DBCC SHRINKFILE ( 'XXXX_Data', NOTRUNCATE ) 
GO
DBCC SHRINKFILE ( 'XXXX_Data', TRUNCATEONLY )
GO 
DBCC SHRINKFILE ( 'XXXX_Log' ) GO

我还尝试创建一个新的文件组并将数据移动到其中 - 没有结果。

有没有人在类似大小的数据库上做过这种类型的事情？关于如何最好地做到这一点的任何建议？或者有人知道为什么数据库收缩不起作用？

Answer 1

数据库中总会有一些可用空间，存储在对于其他数据来说太满的页面中。缩小数据库是一项极其密集的操作，并且会花费大量时间，因为它将几乎所有记录都移动到新的地方。1 TB 是大量数据。有趣的是，通过应用压缩（例如 Red Gate 的 Hyperbac 东西），您可能会更幸运地创造空间。这可以帮助删除可用空间并压缩其余空间，但可能会在此过程中执行更少的写入操作（当然不必执行大量日志活动）。不过，您的情况可能会有所不同 - 在不了解您的数据的情况下，我不想尝试权威地谈论 Hyperbac 数据压缩的工作原理。希望这会有所帮助...