即使在简单的恢复中，Server 2008日志文件也会变得异常庞大。

Question

Server 2008中有一个数据库，其中Recovery model设置为Simple。

定期，我们在一个大表上运行一个大更新(需要更新的1500万行)。为了实现这一点，我们运行一个存储过程，它需要2 hours+才能运行。当存储过程结束运行时，日志文件增长到37 DB，这有点奇怪，因为恢复模型很简单，而且我们甚至没有在存储过程中显式地开始一个事务(为了安全起见，我们在更新之前对DB进行了完全备份)。

另外，当我们收缩日志文件时，它会返回到1MB。

是否有可能阻止日志文件增长到37 it？

谢谢

Answer 1

我也有过类似的问题。我需要删除几百万张旧唱片。删除大约30分钟后失败，因为日志文件的可用空间太小。我们通过修改delete语句来解决这个问题，一次只删除50万条记录。这解决了问题。

把这些知识应用到你的案子上。你能不能运行一些更小的更新，而不是一个大的更新？这可以通过在存储过程中显式添加‘’和'commit‘语句来实现。除了在存储过程开始和结束时的语句之外，您还可以在百万行之后发出commit，并启动一个新的事务。每次更新后我都不会提交，因为这会大大降低性能。另一种选择是将存储过程限制在一定数量之内，并多次调用它，或者创建类似的存储过程，这些存储过程工作在数据的不同部分。

由于您没有显式地使用事务边界，您可能会很幸运地将事务隔离级别设置为未提交的读取。请参阅这里。 --我认为它可能会加快处理速度，但我并不认为它会对事务日志产生重大影响。请注意，通过将隔离级别设置为未提交的读，可以启用脏读。

Answer 2

我还建议尝试打破这些操作，以最小化日志增长。除非启用了auto_shrink，否则Server不会自动收缩日志，这会导致严重的性能问题。

Answer 3

AFAIK，自动收缩只运行30分钟一次。存储过程完成后多长时间您正在查看日志文件？而且，这个服务器上有多少个数据库？自动收缩在循环的基础上工作，可能需要一段时间才能找到这个特定的数据库。