完全恢复模型和事务日志

Question

由于新的业务需求，我将将5TB数据库从简单的恢复模式更改为完全恢复模式。自5年以来，该数据库一直采用简单的恢复模式。

我的问题是，一旦我改变恢复模式，将采取完全备份。但是，如何确保数据库的日志不会增长。因为估计备份完成时间约为5小时。我正在考虑创建一个作业并安排它，以便日志备份在5个小时后开始。这方法好吗？请给我建议。我想确保在刚刚更改为完全恢复模型的数据库的完整备份完成之前，日志不应该增长。

谢谢

Answer 1

当数据库处于完全恢复模型中时，事务日志将继续填充，并且一旦事务日志文件已满，事务日志就会增长，前提是磁盘上有可供该文件增长的可用空间。如果文件没有任何增长空间，那么当您尝试运行事务性查询(不管它是隐式的还是显式的事务性查询)时，您将收到SQL实例中的错误，这将是大多数查询。

当您进行事务日志备份时，Server将事务日志文件的消耗空间标记为可重用。这将允许覆盖日志文件的字节，而不是不断地附加到日志文件中，并将有助于最小化日志文件的增长。

这是独立于您的完整备份和何时完成。现在，您将看到在运行事务备份直到第一次完全备份完成之前，Server事件日志或作业历史记录日志中的错误。这是因为，如果没有前面的完整备份，并且是同一备份链的一部分，就无法还原这些事务日志备份。但是，一旦完整备份完成，任何后续的事务日志备份都将是可用的，并且该错误将自动消失。

鉴于以上所述，大多数人将事务日志备份安排在一个频率上，以满足他们所需的时间点恢复粒度级别。大多数时候，这是在每1分钟或每1小时之间的任何地方。我个人每5分钟运行一次，因为它给了我更好的时间恢复(数据丢失的可能性更小)，并导致更小的备份文件，因此他们完成备份过程更快(通常在一秒钟内)。它还会更快地释放日志文件，以便覆盖这些日志，帮助维护日志文件，而不会使它失控。

长话短说，我的建议是安排您的事务日志备份在您需要的时间点恢复的粒度频率上运行。您可以安排它们运行的频率越高，日志文件失控的可能性就越小。

但请注意，没有完美的解决方案。即使是非常大的显式事务也会导致日志文件增长，不管备份的频率如何。这通常不是正常情况，如果是的话，那么日志文件增长到的大小应该保持在适当的大小。

Answer 2

我将在尽可能少的事务处理期间进行此修改(如果您考虑在空闲时间执行此操作，则请小心，如果您的维护任务也在此期间运行)。索引rebuid可以生成大量日志)。

完成完整日志备份后，应该定期进行日志备份(取决于活动和RPO (可能丢失的数据量)，日志备份的频率可能从每分钟到每小时不等)。

最后，我将确保日志磁盘上有大量空闲空间(并且可能有另一个磁盘可访问以以防万一)，并确保对日志文件启用了自动增长。

Answer 3

一旦将日志设置为满，日志将只被截断，直到您进行日志备份。在简单模式下，Server将自己截断日志文件。在完全恢复模式下，它不依赖于完整备份所需的时间，也不取决于是否使用完整备份。日志在进行日志备份时被截断(释放)。在繁忙的数据库(您的数据库似乎是这样)上等待五个小时可能会导致一个大日志。如果您的日志没有被设置为自动增长，或者它在您的存储设备上耗尽空间，DB将停止，您可能会收到9002错误。