我们在 SQL 2005 服务器上有一个数据库，该数据库设置为简单事务模式。日志记录设置为 1 MB，并设置为在需要时增加 10%。
我们一直遇到事务日志已满而我们需要缩小它的问题。当事务日志设置为简单且允许无限制增长时，什么原因会导致事务日志已满？
答案1
即使在简单恢复模式下，也有一些因素会导致日志增大：
- 长时间运行的事务 - 直到事务提交或回滚后才能清除日志。您可以使用数据库连接开放传输协议向您显示最早的活动交易。
- 事务复制 - 直到日志读取器作业读取已提交的事务后，才能清除日志
SQL 2000 SP4 中也有一个错误，导致检查点无法正确清除日志 - 请参阅我的博客文章了解更多详细信息：为什么我的日志在简单恢复模式下不会清除？SQL 2000 错误或非常大的 VLF。
我猜你有一个长期运行的交易。
您不需要继续缩小日志 - 不断缩小和增加日志会导致 VLF 碎片化，这会影响性能。此外，每当日志增长时，它都必须进行零初始化，这会导致初始化时所有内容都等待。让日志达到稳定状态大小并离开
请参阅我为 TechNet 杂志撰写的关于理解日志以及它在各种恢复模型中的行为的长篇文章：了解 SQL Server 中的日志记录和恢复。
希望这可以帮助！
答案2
我知道这是一篇旧帖子，但我刚刚在尝试了解更多关于这个完全相同的问题时发现了它，这仍然是同类中最好的讨论。它对我帮助很大。
根据 Paul Randal 的说法，日志文件实际上是由每个 512KB 的虚拟日志文件组成的。另一方面，Robert 表示，5MB 的初始日志大小在 10% 的增量下可以正常工作。所以我做了一些简单的计算。
5MB = 5120KB。从 5120KB 增长 10% 正好是 512KB，或者 1 个 VLF 的大小！Will 的日志文件只有 1MB（我的情况是 2MB），增长 10% 会导致尝试增长 102.4KB（我的情况是 204.8KB），这甚至比 1 个虚拟日志文件还要小！我相信这就是日志无法增长的原因！Robert 的解决方案是增加日志的初始大小，这有助于启动增量。另一个解决方案（未经测试，但我相信会起作用）是让 Will 将增量增加到 50%，或者对我来说增加到 25%。当然，我不推荐这样做，因为即使这意味着第一次只增长 512KB，也可能导致以后出现巨大的增长。另一种选择是将增长设置为 1MB 增量。考虑到我们预计日志较小且增长缓慢，这可能是一个好的解决方案。当然，如果预期的增长幅度更大，那么如此小的增长就意味着日志文件需要过于频繁地增长，这将影响性能。无论如何，在具有大量可用硬盘空间的服务器上，这些解决方案中的任何一个都应该能够很好地避免无限制增长带来的 9001/9002 错误。
答案3
我在 SQL 2005 中遇到了同样的问题，日志文件设置为无限制增长，但它却没有增长，当它填满时，我收到 9001 错误。对我来说，解决方案是将初始日志大小设置为 5 mb，似乎已经解决了这个问题。