我有一笔大规模的交易，涉及超过200万条记录，产生超过400万条记录。出于回滚失败的目的，我对将其拆分为多个事务犹豫不决。但是，在测试此交易时，我遇到了一个＆＃39; log_backup＆＃39;错误。
在做了一些研究之后，这似乎与使用“全部”相关。恢复模式，我可以将其设置为“SIMPLE＆＃39;用一个简单的命令。我在交易开始时放置了以下消息：
ALTER DATABASE <Name> SET RECOVERY SIMPLE;
在交易结束时，我将其改为：
ALTER DATABASE <Name> SET RECOVERY FULL;
几个问题：
答案 0 :(得分：2)
恢复的两项措施之一是恢复点目标（RPO）†。从本质上讲，数据所有者有义务说“如果我们必须从备份中恢复，我们可以丢失多少数据？”。完全恢复模式允许在计划外恢复的情况下通过使用日志备份尽可能减少数据丢失，从而尽可能接近导致恢复的事件。
通过将数据库置于简单恢复中，您将删除该安全网。如果在您的操作过程中发生了某些事情，您唯一的办法就是在更改恢复模型之前从备份中恢复。
我的建议是将您的操作分解为更小的批次，并确保您可以进行逻辑回滚。我的意思是，例如，如果您要更新数据，请在单独的表中跟踪主键和预更新值。这样，如果需要，您可以使用该单独的表将数据恢复到其原始状态。类似的插入（跟踪主键值，以便您可以删除）和删除（移动整行）。
†另一个是恢复时间目标（RTO），它衡量您实际恢复所需的时间。
答案 1 :(得分：1)
在Full和Simple之间切换本身并没有害处，但它具有破坏性。
从完全切换到简单将基本上使事务日志无效并清除，因此自上次事务日志备份以来所做的任何事务都将不再可恢复。如果你必须这样做，那么我会在更改为Simple之前进行事务日志备份和数据库备份，并在更改回Full之后立即进行数据库备份。
这种情况恰恰是Bulk Logged recovery mode的用途。您可以切换到批量记录模式，运行satisfy the bulk logged requirements语句并利用最少日志记录，然后切换回完全恢复而不会破坏事务日志备份链（尽管您确实丢失了一些时间点恢复当然，对于最少日志记录的操作）。如果您可以满足批量日志记录的要求，这可能是最好的解决方案，但通常是不可能的。
如果您不能这样做但仍想使用简单恢复，那么还有其他一些注意事项要做。
如果您运行的单个语句涉及200万条记录并创建了400万条记录，那么就您将消耗的磁盘空间而言，根本无法切换到简单恢复。在简单恢复模式下运行语句将在事务持续期间消耗相等数量的事务日志空间。简单恢复下的事务仍然完全记录，因为整个事务可能会回滚。只是一旦提交了事务并且发生了检查点，日志页面就会被标记为空。如果您不关心临时使用的磁盘空间，并且不希望事务显示在事务日志备份中，那么这不是主要问题。
如果您正在运行存储过程或一组语句而不是将整个事务包装在单个事务中，那么您可以从简单恢复模式中受益，但您可能希望定期发出CHECKPOINT statement控制使用的日志量。默认情况下，在简单恢复模式下，系统应该在日志已满70％时发出自动检查点，但根据我的经验，这并不总是在服务器负载过重时立即发生。如果您只是尽快运行所有内容，服务器可能不会停下来花时间清除日志以便重用，因此它将只使用整个Simple文件，展开它并继续使用它。与完全恢复完全相同的问题。