删除数百万条记录后，为什么我的 SQL Server 数据库的大小增加了三倍？

Question

我们有两个数据库表ErrorLog，Audit并且在过去几年中都变得相当大。所以为了减少数据库的大小，我必须编写一个脚本来清除这两个表中所有超过 6 个月的行。

这就是我想出的：

ALTER DATABASE StudioWebTest SET RECOVERY SIMPLE;

DELETE FROM [Audit] WHERE AuditDate < DATEADD(M, -6, GETDATE());
DELETE FROM [ErrorLog] WHERE ErrorDate < DATEADD(M, -6, GETDATE());

ALTER DATABASE StudioWebTest SET RECOVERY FULL;

在我的开发机器 (SQL Server 2008 R2) 上，无论是否更改恢复模式，数据库大小都会增长 2-3 倍。但是，如果我立即使用收缩命令进行跟踪，它会将数据库的大小减少到原始大小的一半（在删除记录之前）。

但是，如果我推迟几天进行收缩，收缩几乎没有那么有效，因为虽然数据库大小减少了，但它仍然几乎是原来大小的两倍（在删除记录之前）。不太了解 SQL Server 如何使用它分配的空间，我认为这与使用已释放的额外空间有关。

除了一件事，这一切都可以。当我们在使用 SQL Server 2005 的生产测试环境中运行它时，shrink 命令不会将数据库的大小减少到原始大小的一半。

作为替代方案，我也尝试使用TRUNCATE代替，DELETE但这似乎没有太大区别。语句完成后数据库仍然大量增长，我仍然必须缩小它以获得相同的结果。我们还没有在生产测试机器上尝试过这个，但是因为shrink 命令似乎没有削减它，所以这是否会产生任何改进似乎值得怀疑。

无论如何，我只是想知道是否有人可以解释为什么尽管更改了错误恢复设置，数据库还是增长了这么多？如何防止这种情况发生？或者，如果这不是解决此问题的最佳方法，则可能建议减少数据库大小的替代方法。

更新：

我只是使用TRUNCATE它进行了更多测试，现在似乎没有增加大小（也许是我想象的）。我仍然需要缩小数据库以查看整体大小的减少。我可能会在生产测试服务器上尝试这个。归根结底，只要规模缩小到一定程度，我的经理就会很高兴。

Answer 1

您正在执行两次巨大的删除，每一次都发生在隐含的事务中。被删除的每条记录首先写入事务日志。

因为您已将数据库更改为简单模式，事务日志将在检查点被截断，但您仍然会在每个删除语句期间导致它增长。

我建议你将删除分成块。在循环内，您可以一次删除一天，从最旧的数据开始，在 6 个月标记处停止。（确保您有支持您的删除标准的索引，如果需要，请创建它们，然后删除它们）。

这样，检查点将更频繁地出现，从而将事务日志的大小保持在最小。

截断表不会增大数据库。

此外，在发出删除语句之前，请确保查明该表上是否存在任何触发器。