sql-server - SQL Server 日志文件在简单恢复模式下填满

Question

我在 SQL Server 2008 R2 中有一个数据库，其中以 varbinary blob 的形式存储了数百万个文件。我上周设置了一个流程来执行以下操作:

1. 使用一些 Entity Framework 代码来获取具有 blob 的行(即实体)。
2. 将 blob 流复制到对象存储。
3. 使用商店中的新对象 ID 更新数据库中的实体。

我有 30 个线程不断地这样做，这个过程仍然需要几天时间。几天前，数据库日志文件已满，我确定它一定是由这个过程引起的。我决定时间点备份对该数据库并不重要，并将数据库设置为使用简单恢复模型。然后昨天我再次从我的过程中得到错误，说日志文件已满!这在简单模式下怎么可能？!知道我能做些什么来阻止这种情况发生吗？当我监视日志文件时，SQL Server 让它达到 7%，然后将其截断为零，所以我非常困惑。当完整备份开始时，日志文件似乎开始不受控制地增长......

Answer 1

即使在简单恢复模式下，SQL Server 也会填充日志文件以保持 ACID 合规性并允许回滚(或在某些灾难恢复场景中“前滚”)。因此，您需要在那里有足够的空间来至少处理一次可能收到的交易，否则它会自动增长或出现错误。

现在，作为一个实际问题，您有几个选择。最简单的就是给它足够的空间来处理交易。另一种方法是将其分解为更少的事务，因为在简单恢复中，一旦事务完全提交并完成，它将允许重新使用该空间。

为清楚起见而编辑并回应评论:SQL Server 会将几乎所有操作(有一些异常(exception)，但它们在这里并不重要)放在隐式事务中，即使显式事务不是叫。因此，如果您说执行一个插入一百万行的命令，它将对该插入有一个隐式事务，即使在简单恢复模式下，所有这些百万行也会影响事务日志，直到事务完全提交并完成。如果您希望它更快地释放空间，请重写您的代码，而不是一个语句插入一百万行，您有十个语句，每个语句插入十万行。

从您的问题中不清楚它仅在完整备份期间增长，但是是的，备份过程确实会影响其在发生时释放日志空间的能力。这是因为完整备份还包括日志文件中的数据，因此服务器需要确保该信息在备份过程中可用。 In Recovery 有相关讨论.

我通常非常不愿意推迟计划的备份，但在这种特殊情况下它可能会有所帮助。这听起来也像是将您的交易分成更小的部分最终可能是可行的方法。