如何修复 log_reuse_wait_desc=LOG_BACKUP？无法进行日志备份

Question

我检查了 sys.databases 以找出哪些数据库需要 LOG 备份。令我惊讶的是，我有很多log_reuse_wait_desc=LOG_BACKUP意思，我为在这些数据库上运行 LOG 备份而设置的作业实际上并没有创建 LOG 备份文件。

在做了一些搜索之后，有人建议将数据库模式从 FULL 更改为 SIMPLE，然后返回到 FULL 以重置内容。执行此操作后，我仍然无法获得 LOG 备份以成功运行。

我正在使用 SQL Server 2005，并使用在http://ola.hallengren.com/sql-server-backup.html 中找到的 ola hallengren 备份方法。

谢谢

Answer 1

既然您已将数据库的恢复模式从完整更改为简单，然后又更改为完整，则数据库以“伪简单”模式运行。在日志备份执行任何有意义的工作之前，现在需要进行数据库备份。有关更多详细信息，请参见此处。总结一下：

• 为了使日志备份对恢复有用，需要有一个数据库备份以及涵盖自该数据库备份以来所有 LSN 的日志备份。

• 当您将恢复模型更改为简单时，SQL Server 会中断日志备份链。然后，当您将其更改回完整模式时，数据库将继续像在简单模式下一样运行，直到有人通过进行数据库备份来创建新的日志备份链。这被称为伪简单模式。以这种方式实施的原因是为了防止某人进行永远不会用于恢复的日志备份，因为它们不是以数据库备份开始的日志备份链的一部分。

• 进行数据库备份后，新的日志备份链开始，数据库开始在完整恢复模型中运行。此时，您的日志备份应该可以工作，或者至少由于其他原因而失败，并出现更具描述性的错误。

这至少是您的日志备份现在无法运行的原因之一。

Answer 2

更新：我想通了！

因为 ola Hallengren 脚本会检查日志传送角色，如果在任一位置找到当前数据库，则会跳过日志备份

msdb.dbo.log_shipping_primary_databases

或者

msdb.dbo.log_shipping_secondary_databases

而且因为我最近一直在处理的数据库确实有未正确清除的旧日志传送条目，所以该脚本无法创建日志备份。现在一切都已清理完毕，我们似乎可以开始了。

非常感谢所有花时间参与进来的人！-乔什