如何修复log_reuse_wait_desc=LOG_BACKUP？日志备份不可能

Question

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

在进行了一些搜索之后，有人建议将数据库模式从完全更改为简单，然后返回到完整，以重置内容。完成此操作后，我仍然无法获得日志备份以成功运行。

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

谢谢

Answer 1

更新:我想出来了！

因为脚本检查日志传送角色，如果它在以下任何一个中找到当前db，则跳过日志备份

msdb.dbo.log_shipping_primary_databases

或

msdb.dbo.log_shipping_secondary_databases

而且，因为我最近与数据库进行斗争的数据库确实有一些旧的日志传送条目没有被彻底清除掉，所以这个脚本无法创建日志备份。既然这些都被清理干净了，我们似乎可以走了。

非常感谢所有花时间插话的人！-Josh

Answer 2

现在，您已经将数据库上的恢复模型从full更改为simple，然后再次更改为full，数据库以“伪简单”模式运行。在日志备份完成任何有意义的工作之前，现在需要进行数据库备份。有关更多细节，请参见这里。概括地说：

• 为了使日志备份对还原有用，需要有数据库备份和日志备份，这些备份涵盖了数据库备份后的所有LSNs。
• 将恢复模型更改为simple时，Server会破坏日志备份链。然后，当您将其更改为full时，数据库将继续处于简单模式，直到有人通过数据库备份创建一个新的日志备份链。这就是所谓的伪简单模式.以这种方式实现这种方法的原因是为了防止有人进行永远无法用于恢复的日志备份，因为它们不是以数据库备份开始的日志备份链的一部分。
• 数据库备份完成后，新的日志备份链开始，数据库开始在完全恢复模型中工作。此时，您的日志备份应该可以工作，或者至少由于另一个原因，您的日志备份会出现更多的描述性错误。

这至少是您的日志备份现在无法工作的一个原因。