为什么我们在 SQL Server 中有 SHRINKDATABASE 命令

Question

我在互联网上读过最好的开发人员说应该避免收缩数据库，因为它会导致碎片增加和性能下降。

我想知道你们是否曾经使用过收缩数据库命令，如果是，那么我们应该在哪些实际场景中使用它们。

Answer 1

首先，让我们区分一下对 SHRINK 的需求和众所周知的意外副作用：可能会增加碎片。后者是实现的副作用。事实上，完全有可能以显着更长的运行时间为代价来设计一个收缩来减少碎片（即具有​​与重组相同的效果）。

收缩的需求是完全有效的：减少因任何原因而增长的数据库的大小。是否在大量一次性数据删除后减小大小，逆转导致意外大小增长（例如错误导入）的一次性操作的影响，迁移到大大改进（和小得多）的数据模型，清理以前一些糟糕的 DBA 管理的后果，它们都是缩小数据库的完全正当理由。当然，必须考虑收缩的成本（增加的碎片）。但是考虑一个设计糟糕的 200Gb 的 DB 被减少到只有 20GB 的数据的情况。将其缩小到 50Gb 大小并重建索引非常有意义。换句话说，需要收缩数据库的能力。

不赞成的是滥用收缩：

• 定期预定收缩
• 出于毫无根据的原因手动收缩（'我需要为......释放一些磁盘空间'），通常数据库实际上需要该大小并且会在一夜之间增长
• 收缩小产量（例如，将 200Gb 减少 5Gb）

至于 LOG 收缩，问题更加直接：即使在维护良好的系统上，LOG 也可以增长。明显的例子：事务复制或数据库镜像部署遇到分发数据库或镜像伙伴的问题。在问题解决之前，日志必须由发布者（对于 TX）或主（对于 DBM）保留。当问题最终得到解决并清除固定日志时，您最终会得到一个不必要的大日志。这可以而且应该缩小到运营规模。缩小日志以某种方式被视为 VooDoo（“我尝试过，但没有做任何事情！”，“嗯，我尝试了它，现在它起作用了”）但是一旦你明白了为了缩小日志的尾部日志必须是免费的 这意味着，与直觉相反，在压缩文件之前必须生成（和释放）更多日志。在如何使用 DBCC SHRINKFILE 语句收缩 SQL Server 2005 中的事务日志文件中都有说明

Answer 2

几乎从不。

有效的用例？一些例子：

• 修复臃肿的日志文件
  假设恢复模型已满且未完成日志备份。
• 节省空间的开发机器：这些机器不会产生生产负荷
• 只读数据库

但你的调查是正确的：任何类型的心理咨询都不应该是例行的、有计划的操作

当你确实需要收缩时，你可以使用更有针对性的 SHRINKFILE