我有几个数据库，都在Simple恢复模式。 以前有关于日志文件大小的担心，我已经使用Management Studio的Shrink任务缩小了这些大小。 我还将日志自动增长的设置设置为最大1024 MB的大小。 我期待日志文件继续增长，直到它是1024 MB。 在这一点上我有两个问题：
应该指出，还有一个备份维护计划每天执行2次，日志应该自动截断（而不是缩小）。
如果您的日志文件在事务中达到其大小限制并且无法自动增长，那么事务将无法提交，并且您将在SQL中看到错误。 日志文件需要有足够的大小来处理CHECKPOINT操作之间的事务。 设置下限会增加由于大量事务（取决于工作负载）而遇到麻烦的可能性。
你的日志文件会自然增长到需要的大小，假设已经设定了自动增长的参数（注意TomTombuild议最好从一个合理的大小开始，而不是等到autogrowth把你带到那里，与此同时）。 通常情况下，缩短简单模式日志文件的唯一时间是，如果您最近执行了某种批量事务，导致日志文件增长到比通常所需的大得多的大小，并且您需要回收该空间使用。
如果您发现自己需要经常收缩日志文件，则需要为系统增加更多空间，或者将需要该空间的任何其他服务移动到其他服务器。
达到此限制后，日志文件会发生什么情况？
你有麻烦了。 事务失败，这可能是一个系统没有准备好处理负载的1gb回滚 – 将花费你假定的时间的字面上的年龄。
设置一个较小的最大限制（比如100 MB而不是1024 MB）会有什么影响吗？
你先前用完了空间。 如果出现某些操作可能会失败。
注意确定你的数据库有多小，但是我
这里没有简单的工作，但是我有一个每15分钟运行500MB的数据库（我们每隔50分钟备份一次），偶尔的ETL工作的tx日志是400GB。 与增长文件的麻烦和性能损失相比，这确实花了我几分钱（以及相关的内部碎片）。 自动增长只适用于“低端小型数据库”。
应该指出，还有一个备份维护计划每天执行2次，日志应该自动截断（而不是缩小）。
简单的恢复模式，他们几乎每个检查点被截断。 阅读你已经configuration。