什么时候可以收缩数据库？

我知道收缩是魔鬼：它会颠倒页面顺序，并导致皮肤癌，数据碎片和全球变暖。清单还在继续……也就是说，我有一个100 GB的数据库，我删除了50 GB的数据-不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖了90％的数据。表-这是否构成缩小数据库的合适用例？

如果不是，那么从数据库中删除如此高的数据百分比后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计信息。还有什么？

绝对不建议进行重组和收缩。

如果您可以使数据库正在离线处理的应用程序脱机，则可以通过在收缩之前删除所有索引和主键/外键约束来加快此过程并减少索引碎片（这意味着要移动的数据较少，因为只有数据页将被改组，而不是现在不存在的索引页被改组，从而加快了处理速度），然后重新创建所有索引和键。

在收缩后重新创建索引意味着不应将它们显着分散，而在收缩过程中将其移走则意味着对其进行重建不会在文件分配的页面分配中留下很多小的“漏洞”，而这些孔可能会在以后引起碎片。

如果可以使应用程序脱机，另一种选择是将所有数据迁移到具有相同结构的新数据库中。如果您的构建过程是可靠的，那么您应该能够快速构建该空白数据库，如果不从当前数据库创建一个空白数据库（还原当前数据库的备份，则截断/删除表中的所有内容并执行完全收缩）。

您可能仍然希望将所有索引放到目标中，然后再重新创建它们，因为在更改许多索引数据（在这种情况下为100％）时，这样做可以提高效率。为了加快复制过程，请将目标数据库的数据文件放在不同的物理驱动器上，再到源（除非您使用的是SSD，在这种情况下您无需担心减少磁头移动），可以移动它们完成后转到源位置。

另外，如果将目的地创建为新目的地（而不是通过清空源副本），请使用初始大小创建目的地，该初始大小将包含所有当前数据以及数月的增长额-这将使数据复制速度再快一点它不会在整个过程中一次又一次地分配新空间。

这可能比使用收缩更好，因为将数据迁移到新数据库将复制收缩操作的预期操作，但可能会产生更少的碎片（这是重组和收缩的意外结果）。收缩只是从文件末尾获取块，然后将它们放在靠近起始处的第一个空间中，而不用努力将相关数据保持在一起。

我怀疑结果的空间效率也会更高，因为事后使用的页面可能会更少。收缩只会移动部分使用的页面，移动数据更有可能导致整页，特别是如果您按照表的集群键/索引（表有一个）的顺序插入目标并创建其他索引数据全部迁移之后。

当然，如果您根本无法使应用程序脱机，则仅执行收缩操作是您唯一的选择，因此，如果您确实需要回收空间，那么请执行此操作。根据您的数据，访问模式，通用工作集大小，服务器具有多少RAM等，最终，额外的内部碎片可能并不那么重要。

对于复制操作，无论是SSIS还是基本的T-SQL都可以正常工作（SSIS选项的效率可能较低，但以后可能更易于维护）。如果您在末尾创建FK关系以及索引，则无论哪种情况，都可以执行简单的“对于每个表复制”。当然，一次性完成收缩+重组也可能很好，但我只是想吓people人们不要考虑定期收缩！（我知道人们每天都安排它们）。

数据库会再次增长吗？如果是这样，那么您将要花在收缩操作上的工作将是浪费，因为当您减小文件大小然后添加更多数据时，文件将不得不再次增大，并且交易必须等待这种增长发生。如果您的自动增长设置不理想和/或驱动器速度较慢，则这种增长活动将非常痛苦。

如果您确实收缩数据库，那么您将使用释放的磁盘空间做什么？再说一次，如果您要保留该空间以防万一该数据库再次增长，那么您就在旋转轮子。

现在，您已经在文件中拥有了所有这些可用空间，您可能会考虑执行以下操作：重新构建索引，以便对其进行更好的优化（如果您有足够的可用空间，那么这样做的痛苦将大大减轻-考虑尝试在小衣柜和大卧室里换一件毛衣）。

因此，除非这是一个主要的清理操作，并且您真的不会再次提升到相同的数据级别，否则我将仅保留它，并专注于其他优化领域。

如果空间不足，并且您的数据不应该那么大然后收缩，但是请在使用适当的填充因子（允许典型增长）之后重建索引。

如果最终目标实际上是减少备份大小，请确保实施全面的备份策略以清除事务日志，并且在备份数据库时，请使用compress选项。

• 创建完整的数据库备份（SQL Server）
• 事务日志备份（SQL Server）

我不建议自动增长5GB，除非您通常希望经常增长5GB。否则，您可能会遇到间歇性的性能问题。首先，应将数据大小设置为您认为一年所需的大小，然后将“自动增长”设置为已测试的大小，这不会影响操作性能。请参见不要触摸SQL Server中的缩小数据库按钮！由Mike Walsh撰写。

在缩小之前重建索引会导致索引布局不正确。重建然后收缩是不好的。缩小会导致索引被破坏以恢复空间-因此事先重建然后缩小是没有意义的。请参阅何时使用 Thomas LaRock的“ 自动收缩”。

我不知道这是否比收缩后重新建立索引更好，但是另一个选择是创建一个适当大小的新数据文件并将所有数据移到该文件。在这种情况下，我将首先进行重新索引，以便您知道实际的数据大小。有一个问题是，如果这是主数据文件中的第一个文件，我认为您不能将其清空。您应该能够缩小它，然后再将数据移回去，这样可以避免页面反转。但是，如果您要转向固态，那么无论如何都不会有太大的不同。

晚点回到这条路。尽管如此，我们也一直在思考和测试在我们的测试环境中使用收缩方法。按照这个话题，还有的时候，收缩是一个可行的选择。但是，知道何时以及如何应用它对于长期和短期的正确执行至关重要。

在我们的方案中，我们最近对大型数据库进行了许多更改，包括压缩，分区，归档和冗余数据的旧删除。结果，我们的主数据文件的已使用部分已减少到不到以前的一半。但是，随身携带所有行李的目的是什么？特别是由于与网络上的某些文章相反，数据文件的大小与备份/恢复时间直接相关。这是因为与许多文章所假定的不同，现实生活中的场景在任何给定页面上加载的数据都不仅仅是您已删除的内容。

更重要的是，这为缩小提供了一个很好的方案：

1. 创建一个脚本，该脚本将在数据库中找到所有对象及其文件组（大量在线示例），使用该脚本创建drop子句以及为每个索引和约束创建定义。
2. 创建一个新的文件和文件组，并将其设置为默认值。
3. 删除所有非聚集索引（请注意，某些索引可能是约束）。
4. 在DROP_EXISTING = ON的情况下，在新文件组上创建聚簇索引（顺便说一句，与许多替代方法相比，这是一个非常快速，最少记录的操作）。
5. 重新创建您的非聚集索引。
6. 最后，收缩您的旧数据文件（通常是PRIMARY）。

这样，剩下的唯一数据将是数据库的系统对象，统计信息，过程以及诸如此类的东西。收缩应该很大，而且速度要快得多，并且不需要对主数据对象进行任何进一步的索引维护，这些索引将被整齐地创建，从而将将来的碎片风险降至最低。