问将恢复设置为简单，然后恢复到完全是有害的吗？

EN

在完全和简单之间切换本身并不有害，但它是破坏性的。

从完全切换到简单将基本上使事务日志失效并清除事务日志，因此自上一次事务日志备份后所做的任何事务都将不再可恢复。如果您必须这样做，那么在更改为Simple之前，我将立即进行事务日志备份和数据库备份，并在更改为Full之后立即进行数据库备份。

这种情况正是大容量日志恢复模式的作用所在。您可以切换到大容量日志记录模式，运行满足批量日志记录的要求语句并利用最小日志记录，然后切换回完全恢复，而不破坏事务日志备份链(当然，对于最小日志记录的操作，您确实丢失了一些时间恢复)。如果您能够满足批量日志的要求，这可能是最好的解决方案，但这通常是不可能的。

如果您不能这样做，并且仍然希望使用简单的恢复，那么还有其他需要考虑的事项。

如果您正在运行一条涉及200万条记录并创建400万条记录的语句，那么就您所消耗的磁盘空间而言，切换到简单恢复基本上没有任何好处。在简单恢复模式下运行语句将在事务持续时间内占用同等数量的事务日志空间。简单恢复下的事务仍然完全记录在案，因为整个事务可能回滚。只是一旦事务被提交并且出现了检查点，日志页就会被标记为空。如果您不关心暂时使用的磁盘空间，只是不希望事务出现在事务日志备份中，那么这不是一个主要问题。

如果您正在运行一个存储过程或一组语句，而不是将整个事件包装在一个事务中，那么您可能会从简单的恢复模式中受益，但是您可能希望定期发出一个检查点语句来控制使用了多少日志。默认情况下，在简单恢复模式下，当日志已满70%时，系统应该发出一个自动检查点，但根据我的经验，这并不总是在服务器负载过重时立即发生。如果您只是尽可能快地运行所有内容，服务器可能不会停下来清除日志以供重用，因此它将只使用整个简单文件，展开它，并继续使用它。和完全恢复问题完全一样。

恢复的两个措施之一是恢复点目标(†)。实质上，这是对数据所有者的一种义务，即“如果我们必须从备份中恢复，我们会损失多少数据？”完全恢复模型允许在意外恢复的情况下很少丢失数据，方法是使用日志备份使您尽可能接近导致恢复必要的事件。

通过将数据库放入简单的恢复中，您将删除该安全网。如果在您的操作过程中发生了一些事情，那么您唯一的方法就是在更改恢复模型之前从备份中恢复。

我的建议是将您的操作分解成较小的批，并确保您可以进行逻辑回滚。我的意思是，例如，如果您正在更新数据，跟踪主键和在一个单独的表中的预更新值。这样，如果有必要的话，可以使用这个单独的表将数据恢复到原来的状态。类似地，对于插入(跟踪主键值以便您可以删除)和删除(移动整行)。

†，另一个是恢复时间目标(RTO)，它是衡量您实际执行恢复所需的时间。