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