我们有一个SQL 2005服务器上的数据库设置为简单事务模式。 日志logging设置为1 MB，并在需要时设置为增长10％。
我们继续讨论事务日志填满的问题，我们需要缩小它。 什么可能导致事务日志填满时，其设置为简单和无限制的增长是允许的？
有几件事情可能会导致日志必须增长，即使在SIMPLE恢复模式中：
SQL 2000 SP4中也有一个错误，它阻止了检查点正确地清除日志 – 请参阅我的博客文章以获取更多详细信息： 为什么我的日志不能在SIMPLE恢复模式下清除？ SQL 2000错误或非常大的VLF 。
我的猜测是你有一个长期运行的交易。
你不需要不断缩小日志 – 不断缩小和增长日志会导致一个叫做VLF碎片的事情，这会影响性能。 而且，无论何时日志增长，它都必须被初始化为零，这样在初始化发生的时候，所有的东西都会等待。 让日志达到一个稳定的大小，离开
查看我为TechNet杂志撰写的长篇文章，了解日志以及它在各种恢复模式中的行为： 了解SQL Server中的日志logging和恢复 。
希望这可以帮助！
我意识到这是一个旧的post，但是我试图找出更多关于这个完全相同的问题，但这只是一个最好的讨论。 这对我非常有帮助
根据Paul Randal的说法，日志文件实际上由每个512KB的虚拟日志文件组成。 另一方面，罗伯特说，一个5MB的初始日志大小工作正常，以10％的增量。 所以这让我做了一些简单的math。
5MB = 5120KB。 从5120KB增长10％正好是512KB，或者1个VLF的大小！ Will的日志文件只有1MB（在我的情况下是2MB），10％的增长导致尝试增长102.4KB（或204.8KB），这个数字甚至比1个虚拟日志文件还要小。 我相信这是日志不能成长的原因！ 罗伯特的解决scheme，以增加他的日志的初始大小帮助启动增量。 另一个解决scheme（未经testing，但我敢打赌会工作）将为威尔增加到50％，或增加到25％。 当然，我不会推荐这个，因为即使这意味着第一次只有512KB的增长，以后可能会有一些巨大的增长。 另一种select是将增长设置为1MB的增量。 鉴于我们预计小型原木增长缓慢，这可能是一个很好的解决scheme。 当然，如果预期的增长要大得多，这么小的增长意味着日志文件需要经常增长，这会影响性能。 无论哪种方式，这些解决scheme中的任何一个都可以很好地工作，避免9001/9002无限制增长的错误，而这些错误在有大量免费硬盘空间的服务器上。
我在SQL 2005中有同样的问题，日志文件设置为无限制的增长，但它不会增长，当它填满我得到一个9001错误。 对我来说，解决scheme是将初始日志大小设置为5 MB，似乎已经解决了这个问题。