静态归档数据库: Server无法缩小它并留下400克未分配的空间

Question

我们的数据库有问题。下面是发生的事情：

所有的数据库都有大约50%的未分配空间，DBCC SHRINKDATABASE/SHRINKFILE不会收回空间。这些都是最近清理过的归档数据库，应该是只读的，因此性能不是问题(是的，我完全了解收缩和聚集索引的碎片，我对此毫不在意)。这里的主要目标是减少所有数据文件，以节省存储空间中的$$。再说一遍，我不在乎性能，这些数据文件必须不惜一切代价减少！我指的是800 at、1,5TB和2,1TB的数据库。所以没有什么普通的或小的。

所以：

• 收缩数据库显示约50%的浪费空间
• 具有强制页面重组(NOTRUNCATE)和强制1%空闲空间的收缩后数据库将继续显示50%的未分配空间。
• 因此，一个800 GB的数据库在sp_spaceused中显示为拥有大约410 GB的未分配空间，即使在收缩之后也是如此。
• 一个收缩文件承认数据库只有1%的空闲空间。
• 当我们开始使用SELECT INTO将表迁移到另一个数据库时，我们开始注意到原始表占用了几十万页，但是在迁移之后，它们只占用了几百页。
• DBCC还显示原始数据库(在SELECT之前)使用了大量的区段。

我对此的分析如下：

• 收缩没有释放未分配的空间。
• 选择是的会腾出很多空间

我想得到一些帮助：

• 为什么心理医生不能工作
• 为什么选择进入作品
• 为什么原始数据库有那么多浪费空间(是的，在成为存档之前，它已经启用了很长时间的自动增长)。

我们已经在研究填充因子、页面和范围的使用情况，但是我们想要的至少是对这么多丢失空间的解释，以及如何在没有选择的情况下收回它--进入所有to的数据。任何帮助都将不胜感激。

Answer 1

事实证明，这确实是指数重建的一个案例。

在创建了一个简单的维护计划来重新构建整个数据库中的所有内容之后，忽略了它们的碎片级别或页面数(字面上是所有的内容)，之后，甚至SSMS也开始“看到”数据文件中的新可用的空闲空间。收缩文件刚刚将800 GB的数据文件减少到80 GB (严重地)。显然，在收缩过程中，索引是支离破碎的，因此我在收缩之后执行了另一次重建，数据文件从80 GB增长到100 GB，与其初始大小相比仍然相当不错。

注意:如果您想知道为什么要大幅度减少，这是一个存档数据库，过去X年的生产数据已经被devs大量删除，但是它仍然显示与生产数据库相同的总大小(该数据库拥有100%的数据)。

Microsoft的文档确认了重建和页面分配之间的关系：

https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver15

我从未想过，维护不善的索引在磁盘空间分配方面会产生如此巨大的影响。

现在我们来看看填充因子以及它对数据文件大小的影响程度。

谢谢大家！

Answer 2

这里有两个潜在的东西在起作用。收缩的algo取最后一页并将其移动到第一个空点，这会产生大量的碎片，还可能创建转发记录。更好的方法是使用已经定义好的预数据填充的聚集索引在不同的文件组上重新构建数据库。

另一个项目可能是在2008年左右的鬼清理bug。我不知道您正在运行哪个版本，但如果是2008年，请确保您的补丁程序是最新的。

https://codingsight.com/moving-existing-table-from-primary-filegroup-to-different-filegroup/

Answer 3

你有两种方法..。1)检查数据库文件，看看是否有空空间要释放。如果你有它，你可以运行收缩文件来释放空间(我建议你收缩1MB) 2)你可以运行一个报告，显示你在数据库上的表的磁盘使用情况。如果您看到有一个很大的未使用的空间，那么您需要查看每个索引的填充因子，或者如果它们是堆。如果是这样的话，那么首先需要重建这些索引/堆，然后释放空间。

希望这能帮上忙！