我们有SQL Server 2008中的一个数据库，其中Recovery model设置为Simple 。
我们定期在一张大桌子上进行一个大更新（需要更新1500万行）。 为了实现这个目标，我们运行一个需要2个小时以上运行的存储过程。 当存储过程完成运行时，日志文件增长到37GB，这是奇怪的，因为恢复模型是简单的， 我们甚至不明确开始在存储过程中的事务（我们做了数据库的完整备份在安全更新之前）
另外，当我们收缩日志文件时，它会回到1MB
是否有可能只是防止日志文件长大37GB ？
谢谢
我有一个类似的问题。 我需要删除几百万条旧logging。 大约30分钟后删除失败，因为日志文件的可用空间太小。 我们通过修改delete语句来解决它，一次只能删除50万条logging。 这解决了这个问题。
将这些知识应用于您的案例。 你可以运行一些较小的更新，而不是一个大的？ 这可以通过在存储过程中明确添加“begin transaction”和“commit”语句来完成。 除了在存储过程的开始和结束处的语句之外，还可以在一百万行之后发出一个提交，并开始一个新的事务。 每次更新后我都不会做任何提交，因为这会大大降低性能。 另一个select是将存储过程限制到一定的数量，并多次调用它，或创build在数据的不同部分上工作的类似的存储过程。
由于您没有明确使用事务边界，因此您可能会将事务隔离级别设置为未提交的读取。 看到这里。 我认为这可能会加快处理速度，但我不认为它会对事务日志产生重大影响。 请注意，通过将隔离级别设置为未提交的读取来启用脏读。
我也build议试图打破运作，以尽量减less日志增长。 除非启用了auto_shrink，否则SQL Server不会自动收缩日志，这可能会导致严重的性能问题。
AFAIK，autoshrink每30分钟只运行一次。 存储过程完成后多长时间您正在查看日志文件？ 另外，该服务器上有多less个数据库？ Autoshrink以循环方式工作，可能需要一段时间才能到达这个特定的数据库。