我们在 SQL Server 2008 中有一个数据库，其Recovery model设置为Simple。
我们定期对一个大表（需要更新 1500 万行）进行大更新。为此，我们运行一个存储过程，该过程需要 2 小时以上才能运行。当存储过程完成运行时，日志文件增长到 37GB，这有点奇怪，因为恢复模型很简单，而且我们没有甚至在存储过程中明确开始事务（为了安全起见，我们在更新之前对数据库进行了完整备份）
此外，当我们缩小日志文件时，它会回到 1MB
有可能吗防止日志文件增大到 37GB？
谢谢
答案1
我遇到了类似的问题。我需要删除几百万条旧记录。删除在大约 30 分钟后失败，因为日志文件的可用空间太小。我们通过修改删除语句以一次仅删除 500,000 条记录来解决这个问题。这解决了问题。
将这些知识应用到您的案例中。您可以运行一些较小的更新而不是一个大的更新吗？这可以通过在存储过程中明确添加“开始事务”和“提交”语句来实现。除了存储过程开头和结尾的语句之外，您还可以在一百万行之后发出提交并启动新事务。我不会在每次更新后都提交，因为这会大大降低性能。另一种选择是将存储过程限制为一定数量并多次调用它，或者创建对数据的不同部分起作用的类似存储过程。
由于您没有明确使用事务边界，因此您可能能够将事务隔离级别设置为未提交的读取。请参阅这里。我认为它可能会加快处理速度，但我不认为它会对事务日志产生重大影响。请注意，通过将隔离级别设置为未提交读取来启用脏读。
答案2
我还建议尝试拆分操作以尽量减少日志增长。除非您启用了 auto_shrink，否则 SQL Server 不会自动收缩日志，这可能会导致严重的性能问题。
答案3
据我所知，自动收缩每 30 分钟才运行一次。存储过程完成后多久您才会查看日志文件？此外，此服务器上有多少个数据库？自动收缩以循环方式工作，可能需要一段时间才能到达这个特定的数据库。