我有几个数据库，全部处于Simple恢复模式。之前一直担心日志文件大小，我使用 Management Studio 的Shrink任务将它们全部缩小。我还将日志自动增长设置为最大 1024 MB。我预计日志文件会根据需要继续增长，直到达到 1024 MB。此时我有两个问题：
- 一旦达到此限制，日志文件会发生什么情况？
- 设置较小的最大限制（例如 100 MB 而不是 1024 MB）会产生什么影响吗？
值得注意的是，还有一个备份维护计划，每天要执行2次，并且日志应该自动截断（而不是缩小）。
答案1
如果您的日志文件在事务期间达到其大小限制并且无法自动增长，则事务将无法提交，您将看到 SQL 错误。日志文件需要足够大才能处理CHECKPOINT操作之间的事务。设置较低的限制会增加您因大型事务（取决于工作负载）而遇到麻烦的可能性。
假设设置了合理的自动增长参数，您的日志文件将自然增长到所需的大小（请注意，正如 TomTom 所建议的，最好从合理的大小开始，而不是等待自动增长将您带到那里，同时会降低您的性能）。通常，只有在您最近执行了某种批量事务导致日志文件增长到比正常需要的大得多的大小时，并且您需要回收该空间用于其他用途，您才应该缩小简单模式日志文件。
如果您发现自己需要频繁缩小日志文件，则需要为系统添加更多空间或将需要该空间的其他服务移至另一台服务器。
答案2
一旦达到此限制，日志文件会发生什么情况？
您有麻烦了。交易失败。这是一个 1gb 的回滚，系统可能还没有准备好处理负载 - 这会花费您预计的很长时间。
设置较小的最大限制（例如 100 MB 而不是 1024 MB）会产生什么影响吗？
您之前已用尽空间。这意味着某些操作可能会失败。
请注意你使用的数据库有多小，但我
- 始终预先分配最大大小，并且
- 确保他们有喘息的空间。
这里不是使用 simple，但我有一个数据库，每 15 分钟运行 500mb（我们每 50 分钟备份一次），并且偶尔的 ETL 作业的 tx 日志为 400gb。与文件增长带来的麻烦和性能损失（以及您造成的相关内部碎片）相比，它确实花费了我几分钱。自动增长仅适用于“低端小型数据库”。
值得注意的是，还有一个备份维护计划，每天要执行2次，并且日志应该自动截断（而不是缩小）。
使用简单的恢复模式，它们几乎在每个检查点都会被截断。阅读您已配置的内容。