减轻收缩的负面影响

Question

与几周前的这个问题密切相关，但答案没有讨论如何做肮脏的行为。这是情况：

我们现在数据库中有 15 GB 的数据，但应用程序中的日志记录错误异常猖獗，并运行了高达 80 GB 的数据，为我们提供了大约 130 GB 的 DB 文件。我们已经修复了这个错误，清除了受影响的表，我想找回一些空间，也许可以将数据库降低到 40GB 左右。

我想这样做的最大原因是我们可以更轻松地将备份恢复到虚拟测试实例上的较小驱动器。

我明白了：收缩是邪恶的，它会将索引和磁盘文件分成碎片。我被卖了。这是一次性事件。

那么如何才能最大程度地减轻痛苦呢？好像我应该：

1. 使用DBCC SHRINKFILE (DataFile1, 40000);瞄准40 GB。
2. 立即使用一些智能重新索引来重新组织和重建索引
3. 对物理磁盘进行碎片整理

这会适当减轻收缩的副作用吗？或者这只会在我申请邪恶联盟的时候结束？

Answer 1

这是我缩小文件的有点手动的方法。十多年来，这对我来说效果很好。

缩小文件不一定是坏事，但这并不意味着它总是最好的做法。

首先，想想你为什么缩小。大多数数据库只会变得更大。如果您希望在可预见的未来需要空间，您可能不想缩小。

缩小的最佳原因是您正试图从某些错误中恢复，其中数据文件的大小已远远超过不久的将来所需的任何大小。

另一个很好的理由是您需要将受影响的数据库恢复到开发或测试服务器上，这些服务器根本没有存储容量来处理额外的、未使用的空间。

缩小的最糟糕的原因是您正试图将另一个数据库塞入已经快满的存储中。您将耗尽空间，接受它是第一步。下一步是制定更多存储（或更少数据库）的计划，而不是通过掠夺 Peter 来支付 Paul。

收缩tempdb几乎总是痛苦的。不重启实例很难得到及时收缩，重启实例是一个坏习惯。

其次，确保在MDF和NDF文件中留出额外的空间。重新索引需要一些工作空间。多少？这取决于。找到最大桌子的尺寸并将其用作指导。在数据文件中留下那么多空间，我从来没有出错。如果您的文件中没有足够的空间，它们将尝试自动增长。如果 SQL Server 文件中缺少连续空间，您可能会在重新索引大表时遇到问题；在重新索引例程运行后，它们似乎永远不会进行属性碎片整理。

不要使用自动收缩。它旨在用于在用户工作站上运行的数据库，而不是在专用生产服务器上运行，并且很久以前就被考虑到，无论出于何种原因使用它在这一点上都不是一个好主意。

使用dbcc shrinkfile，不是dbcc shrinkdatabase。如果您需要收缩具有多个 * MDF * 的数据库，请以循环方式进行，注意每个文件所属的文件组。为了有效地分散 I/O，SQL Server 需要文件组中大小相同的文件。

通常，shrinkfile 不会给服务器带来太多负载，但是当我收缩文件时，我可以避开高峰需求期，而且我喜欢用性能监视器比平时更密切地观察。

不要试图一次性缩小所有空间。如果您尝试一次性缩小大量空间，则 dbcc 命令通常看起来会变得紧张。磁盘 I/O 将下降，但命令不会完成。

运行 dbcc shrinkfile 后，您将需要重新索引以将数据放回原位。根据您的表，您可能能够进行在线重新索引，这已被广泛记录。

如果您将文件缩小得太远，文件将尝试自动增长。你不想那样，所以要小心不要把东西缩小太多。如有疑问，请留出额外的 GB。

文件级碎片往往发生在具有大量经常增长的数据文件的卷上。频繁删除/重新创建数据库可能会加剧问题。如果您正在缩小文件，它们应该会变小并且碎片应该更少。没有特别的理由认为碎片整理会使事情变得更糟，尽管它会给您的服务器带来 I/O 负载，如果存储已经负载过重，这可能会受到伤害。一些管理员对第三方碎片整理工具发誓，但我只在服务器上使用过微软的工具。同样，我不会在需求高峰时期这样做。