存档后缩小，这也很糟糕吗？

Question

我有一个增长到 20 GB 的数据库，在归档一些数据后，表的实际大小仅为 5GB。备份脚本会将备份副本保存到其他位置。移动 20GB 或 5Gb 确实有所不同，所以我想减小物理尺寸，但如果我不想影响性能，我读到的任何地方都不要缩小。

但是在这种（定期/每季度/每年）归档的情况下，是否仍然建议不要收缩？

Answer 1

您在网上看到的大多是复制的建议，人们实际上想说的是“请不要将缩小数据文件或日志文件作为日常操作”。如果情况如此糟糕，Microsoft 会删除它，但它仍然存在，即使是最有经验的 DBA 和开发人员也使用它，但他们知道后期影响，因此他们知道之后要做什么。只有缩小才能给你回自由空间

是的，当然您可以缩小数据和日志文件，因为您想要回收空间并且非常需要回收空间。如果你看到保罗的文章，他给出了一个方法，比如

我喜欢推荐的方法如下：

• 创建一个新的文件组

• 使用CREATE INDEX … WITH (DROP_EXISTING = ON) ON语法将所有受影响的表和索引移动到新文件组中，以同时移动表并从中删除碎片

• 删除您无论如何要缩小的旧文件组（如果它是主要文件组，则将其缩小）

如果它适合你，你可以使用它。由于您知道收缩是不好的活动，并且一年内收缩一次可能是两次，这实际上并不坏。收缩确实会导致逻辑碎片，所以不要忘记在收缩后重建索引。

备份脚本会将备份副本保存到其他位置。移动 20GB 或 5Gb 确实有所不同

备份仅包括数据和少量事务日志（如果需要），以在还原后使数据库恢复一致状态。所以再次备份将是大约 5 G 而不是 20G 但是是的，当你恢复它时它会占用 20 G 空间

PS：我不支持缩小数据库或数据库文件，但在极端情况下并且知道您可以这样做的影响。