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