RMAN-06054: 介质恢复正在请求未知的线程 1 序列 105776 的归档日志以及起始 SCN 62897768726

最新推荐文章于 2024-09-19 18:09:24 发布

原创最新推荐文章于 2024-09-19 18:09:24 发布 · 6.4k 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#oracle

笔记同时被 2 个专栏收录

164 篇文章

订阅专栏

Oracle

129 篇文章

订阅专栏

本文详述了在RAC到单实例数据库迁移过程中，遇到RMAN-06054错误的解决办法。主要介绍了如何处理因归档日志缺失导致的恢复问题，包括日志记录的添加及不完全恢复的步骤。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

问题描述

在做异机恢复（RAC->单实例）的时候，recover database时遇到如下报错：
RMAN-03002: recover 命令 (在 09/30/2019 08:36:48 上) 失败
RMAN-06054: 介质恢复正在请求未知的线程 1 序列 105776 的归档日志以及起始 SCN 62897768726

在11g官方文档error messages中对错误描述如下：
RMAN-06054: media recovery requesting unknown archived log for thread string with sequence string and starting SCN of string
Cause: Media recovery is requesting a log whose existence is not recorded in the recovery catalog or target database control file.
Action: If a copy of the log is available, then add it to the recovery catalog and/or control file via a CATALOG command and then retry the RECOVER command. If not, then a point-in-time recovery up to the missing log is the only alternative and database can be opened using ALTER DATABASE OPEN RESETLOGS command.

可见，出先此错误的原因是恢复需要的日志记录在控制文件或恢复目录中找不到。

解决方法

解决方法分两种情况：
1.如果相关的日志存在且可用的话，就将此日志记录添加到控制文件或恢复目录中。
2.如果相关的日志已经被删除了或不可用了，那么就按照错误的提示scn将数据库恢复到此scn。也就是说此时数据库只能进行不完全恢复了，在打开数据库时得使用resetlogs打开。
例：(另一套环境，单实例->单实例)

unable to find archived log
archived log thread=2 sequence=21316
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/29/2019 14:52:06
RMAN-06054: media recovery requesting unknown archived log for thread 2 with sequence 21316 and starting SCN of 2674576144
解决：直接恢复到SCN点2674576144
RMAN> recover database until scn 2674576144;
Starting recover at 2019-05-29 14:55:09
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
starting media recovery
media recovery complete, elapsed time: 00:00:04
Finished recover at 2019-05-29 14:55:16
RMAN> exit
Recovery Manager complete.
[oracle@rac1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Wed May 29 14:55:28 2019
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> alter database open resetlogs;
Database altered.

但是也有另一种情况。迁移数据库的时候，在新库恢复数据时，控制文件记录的current sequence要比实际备份片里的sequence号大。

目标库的sequence：
在这里插入图片描述

RMAN> list archivelog all;
db_unique_name 为 RACDB 的数据库的归档日志副本列表
=====================================================================
关键字     线程序列     S 时间下限  
------- ---- ------- - ----------
2315726 1    105774  A 29-9月 -19
        名称: +FRA/racdb/archivelog/2019_09_29/thread_1_seq_105774.620.1020211243
2315728 1    105775  A 29-9月 -19
        名称: +FRA/racdb/archivelog/2019_09_29/thread_1_seq_105775.1141.1020211261

因为旧库是通过rman热备的，所以在备份的时候，数据库是打开的状态，比如说从10点开始备，备分完成后可能已经11点了，那么最后完成备份的文件和第一个备份的文件在时间上是有区别的。所以恢复的时候肯定会找归档，需要通过归档日志把先备完的追到最后的时间点。
1.如果想恢复到全备的时刻，需要通过查看数据文件的scn号，指定恢复到那个时刻；如果不写，那么就是默认归档到current log的那个时刻。
2.如果要恢复到最近的位置，需要RMAN> list backup of archivelog all;
找到最后一个能找到的归档日志，恢复到这个日志所对应的的scn号。不然rman会找到current的scn，因为这个日志还没有备，所以就会发生这个错误。
最后将源库全备完成后的归档备份片cp到目标库，重新recover后，恢复成功。