提取的数据远远大于删除行留下的赤字

Question

由于磁盘限制，我最近进行了一项练习，以释放生产数据库 (SQL Server 2008 R2) 中的一些空间。特别是一张表就占据了 98% 的数据库。不需要的记录被识别出来，占数据的 1/3（大约 160GB 或 450GB）。

所以我在不同的磁盘上创建了一个数据库，创建了一个具有相同架构的表，唯一的区别是创建了一个 ID 列，而不是IDENTITY. 我将其称为存档，将原始称为源。根据 SSMS，Original 有 PK 索引和另外两个小索引，总计 19MB。存档只有 PK 索引，因为它不会被查询。

我一次将数据分批传出 1000 行，以尽量减少对生产的影响。几个小时后，存档上的磁盘空间也用完了，所以当数据库达到 145GB 时我停止了传输，这代表了 800,000 行。

然后我开始删除源表，确保只删除存档的内容。这运行了一夜，并在交易开始前停止，最终从原始表中删除了 550,000 行。

根据存档，这应该是大约 (145GB / 800000) * 550000 ~= 100GB。但是源数据库中的可用空间只有45GB！

我已经做了明显的谷歌搜索和检查 DMV，但我找不到任何有用的东西，然后我承担了比较所有数据的数据长度以查看问题是否出在那里的任务。当我们使用 XML 列时，我的想法是删除的列由于其内容而代表较小比例的存档数据。这变得更加混乱，以下是结果：

• 在存档和源中，（存档图）= 69.24362996 GB
• 在存档和源中，（源图）= 69.24362996 GB
• 在存档中但不在源中（从源中删除）61.09401641 GB
• 存档总数 130.3376464 = GB

所以这证明存档的数据大小与源（前两名）匹配，更重要的是我怀疑删除的 550000 行代表磁盘空间的一部分比剩余的 250000 更小。

但是删除的记录加起来比数据库中释放的 45GB 多出 16GB。而且存档被计算为具有 130GB，尽管大小为 145GB，因此再次出现 15GB 的赤字。

这是我正在努力弄清楚的。我目前的理论，虽然我不知道如何证明，但删除的数据（哪个日期分布在表格中）已从页面中删除，留下一些不符合标准的数据，所以如果这些页面已满 8kb，我们删除了一些代表其中 2kb 的数据，这就是数字不匹配的原因，仅释放了 45GB 的页面，其余 16GB 被捆绑在与其他不匹配的行共享的页面中标准。

对不起，这篇大量的帖子，我已经用尽了我目前对 SQL Server 如何存储事物的复杂性的知识。

如果您知道为什么存档行大小加起来比总数据库大小少 15GB（顺便说一句，它是数据库中唯一的表）。
或者
最重要的是，当相同的数据在存档中占用 61GB 时，为什么在源中只释放了 45GB 的空间。

补充说明：

• 删除后，所有索引都被重建，所以数字是重建后的。
• 有问题的表确实有一个聚集索引（在 PK 上）——它不是一个堆。
• 两个表的 FillFactor 均为 80%，源页面的页面填充度为 76%，存档页面的填充度为 78%。
• 我将存档的填充因子（通过重建索引）更改为 99%，以查看它是否会释放任何空间并且没有任何影响。
• 我在带有 Compact 大对象数据的 Source 上运行了 reorg，它对可用空间的影响也为 0。
• 每页的行数因 xml 列而异，可以是 1 到 18 之间的任何位置。
• 存档中的填充因子为 80%，因为架构脚本用它生成了填充因子。它只是一个临时保存空间，我们很快就会建立一个适当的档案或数据仓库。不管它似乎不是索引问题，因为改变重建和重组没有影响存档或源数据库。
• 分配信息

-LOB_DATA USED: 47740971 DATA:0 TOTAL:49987517 很明显，lob 数据页被保留而不被使用。当我获得批准时，我将尝试使用在 MSDN 上找到的这个命令 DBCC CLEANTABLE 虽然这是用于删除的列，但我的选项用完了。

-DBCC CLEANTABLE 没有用，不可否认，这是一个很长的镜头。回到绘图板，唯一可行的其他建议是我迁移到新表中，但考虑到 400GB+，我无法拥有维护窗口或足够的磁盘空间来尝试。很高兴听到其他理论。

Answer 1

首先，我要控制两个索引的FillFactor（你说你的表上定义了 PK，所以我假设这些表是聚集的）。

它可以在第一个表中设置为 50% 或类似的值，即使我认为将 FF 设置为与标识列索引的 100 不同的值没有多大意义。

在这种情况下，当您重建第一个表时，即使它应该压缩该表，它也可以根据 FF 定义留下可用空间。

......................

第二个选项是你XML没有释放空间的。

重建表后，所有索引页和具有行内或行溢出数据的数据页再次满（当然，如果 FF 没有更改为比之前更低的值）

但 LOB 页并未通过重建进行压缩。在这种情况下，您可以尝试ALTER INDEX..REORGANIZE压缩您的XML