主页 / dba / 问题 / 93473
Accepted
NedOtter
Asked: 2015-02-22 10:42:34 +0800 CST

无法恢复（错误 3456）

  • 772

我有一个不容易弄清楚的情况，我想我会在这个论坛上询问其他人是否有建议。

我在 Windows Server 2008R2 Enterprise 上运行 SQL Server 2008 R2 Standard SP3。

数据库需要一些维护，事后我需要在另一台服务器上恢复。我有一个完整的数据库备份，使用 COPY_ONLY 加上一组 4 个 tlog 备份。

  1. 在开始之前，创建 tlogbackup1
  2. 从FULL恢复BULK_LOGGED模式转变
  3. 添加新文件组
  4. 将文件添加到新文件组
  5. 将 newfilegroup 设置为默认值
  6. 选择表（在新文件组上）
  7. 删除原始表
  8. 删除原始文件
  9. 删除原始文件组
  10. 更改新表的名称以匹配原始表
  11. 更改新文件组的文件名以匹配原始文件组
  12. 更改目录中的文件名以匹配原始文件名
  13. 在操作系统级别更改文件名以匹配原始文件名
  14. 将默认文件组设置为原始文件组
  15. 使数据库联机
  16. 从BULK_LOGGED恢复FULL模式转变
  17. 完成所有步骤后，创建 tlogbackup2

由于还原服务器上的驱动器号更改，所有备份的还原都必须使用 WITH MOVE。

恢复步骤：

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

最终的 tlog 恢复达到 100%，然后失败并出现错误 3456：

为数据库“SomeDB”、文件 1 上的文件“SystemData”处理了 368 页。

为数据库“SomeDB”、文件 1 上的文件“SystemDataPDS”处理了 7656520 页。

为数据库“SomeDB”处理了 172430 页，文件 1 上的文件“SystemData_log”。

消息 3456，级别 16，状态 1，第 1 行
无法重做日志记录 (210388:123648:232)，事务 ID (0:1016710921)，页面 (4:8088)，数据库“SomeDB”（数据库 ID 6） . 页面：LSN = (0:0:1)，类型 = 11。日志：操作码 = 4，上下文 11，PrevPageLSN：(210388:122007:1)。从数据库的备份中恢复，或修复数据库。Msg 3013, Level 16, State 1, Line 1 RESTORE LOG 异常终止。

只是为了验证完整的 db 备份是否正常，我将其还原为 run CHECKDB，并且没有错误。

欢迎所有反馈。

提前致谢，

内德·奥特

sql-server sql-server-2008-r2

1 个回答

  1. Best Answer

    为了理解为什么会抛出错误 3456，我们需要退后一步，了解 SQL Server 如何处理这个恢复角落。

    当 SQL Server 正在重做一个操作并且该重做是页面修改时，它会进行快速检查。在页眉中最终会有一个PageLSN，它表示最后修改该页的 LSN，由该页记录。像这样想，页面会跟踪对它进行修改的最后一个 LSN。这是PageLSN.

    每次记录页面修改操作时，该日志记录都会包含一些 LSN。即，日志记录的 LSN（想想......当前 LSN），然后它有所谓的上一页 LSN（PrevPageLSN向前）。因此，当我们修改页面时，放入日志记录中的一条数据就是该页面指示的最后一个 LSN，即您修改该页面之前的最后一个 LSN 。

    像这样想......你的车需要完成它的工作。机械师约翰在你的车上工作，在发动机舱里它有一个小标签，机械师约翰写道“约翰最后在这辆车上工作”。然后，下次您将汽车开到另一家商店时，机械师马克查看发动机舱并看到机械师约翰最后在这辆车上工作。在他的数据表上，他写下了这些信息。与 SQL Server 相同的想法。

    这可能有点令人困惑，因此请看下面的这张图片，了解顺序页面修改，以及PageLSN和的PrevPageLSN关系：

    在此处输入图像描述

    让我们回过头来，因为当您需要重做页面上的操作（恢复、恢复、HA 等）时，这一切都会发挥作用。当 SQL Server 需要重做页面操作时，它会进行完整性检查以查看PageLSN页面上的PrevPageLSN是否与日志记录包含的匹配。如果不相等，那么您将看到错误 3456 被抛出。

    PageLSN是否等于PrevPageLSN？不？？？停止并引发错误 3456...

    让我们分析您的错误消息，其中包括如何：

    无法重做日志记录 (210388:123648:232)，事务 ID (0:1016710921)，页面 (4:8088)，数据库“SomeDB”（数据库 ID 6）。页面：LSN = (0:0:1)，类型 = 11。日志：操作码 = 4，上下文 11，PrevPageLSN: (210388:122007:1)。从数据库的备份中恢复，或修复数据库。Msg 3013, Level 16, State 1, Line 1 RESTORE LOG 异常终止。

    我加粗了两条不等式导致错误的数据。您可以看到我们的PageLSN为0:0:1（在页面标题中找到），我们的PrevPageLSN为210388:122007:1（在尝试重做的日志记录的数据中找到）。这些显然不相等，因此 err3456。

    所以要找出这个事件的原因，就是找出为什么这里会出现差异。我们确实需要跟踪页面 4:8088 的生命周期，并查看断开连接的位置。不幸的是，没有更多信息或动手故障排除，除了向您提供此恢复操作的背景以及导致错误的原因之外，我无能为力。

    • 9

相关问题