暂无图片
暂无图片
1
暂无图片
暂无图片
1
暂无图片

rman 恢复时候提示 ORA-01547、ORA-01194、ORA-01110

原创 伊伊相印 2023-10-21
962
在异机恢复数据库的时候,restore正常,recover的时候,很快就过去了。提示ORA-01547、ORA-01194、ORA-01110错误。从错误提示中看,归档日志不存在。

starting media recovery
 
Oracle Error: 
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '+DATA/abcd/datafile/system.502.1108624865'
 
released channel: c1
released channel: c2
released channel: c3
released channel: c4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/29/2022 18:22:55
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 2 with sequence 125966 and starting SCN of 6234223614488 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 125965 and starting SCN of 6234223488894 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 125964 and starting SCN of 6234218899569 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 125963 and starting SCN of 6234214130922 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 137219 and starting SCN of 6234221221375 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 137218 and starting SCN of 6234214130457 found to restore
 
Recovery Manager complete.

疑惑:

1 缺失的这些归档,都是最后的几个归档,按照道理,应该是先使用序号较小的归档做recover,最后才会发现没有这些缺失的归档,怎么一晃就结束了 。难道oracle检测到缺失归档,就不给恢复,没道理啊?

2 为什么会一晃而过?明明是有对归档做备份的,有备份集的。

3 是否为bug?mos上有案例,只说了解决方法,没有说是不是bug。

解决方法:参考MOS文档,做了不完全恢复。也就是找到那个scn开始,数据是一致的。最后做了不完全恢复。

参考文档:Open Database failed - DATAFILE NEEDS MORE RECOVERY TO BE CONSISTENT ORA-1194 ORA-1547 ORA-1110 (Doc ID 1528788.1)

在官网中,参考以下内容,做不一致恢复 (ABSSCN = Absolute SCN )

The following query will show you the SCN to which we must at least recover to, to get all datafiles consistent.

SQL> select  min(FHSCN) "LOW FILEHDR SCN"
           , max(FHSCN) "MAX FILEHDR SCN"
           , max(FHAFS) "Min PITR ABSSCN"
       from X$KCVFH ;

LOW FILEHDR SCN  MAX FILEHDR SCN  Min PITR ABSSCN
---------------- ---------------- ----------------
2446300          2472049          0


-- Example output explained:
--
-- "LOW FILEHDR SCN"  - this is the SCN at which recovery process starts
-- "MAX FILEHDR SCN"  - this is the SCN we must recover to to get all datafiles consistent
--
--   IF    "Min PITR ABSSCN"  != 0 AND  >  "MAX FILEHDR SCN"
--   THEN  "Min PITR ABSSCN"  is the SCN we must recover to to get all datafiles consistent
 

自己的环境中查询到的结果 

SYS@abcd>select  min(FHSCN) "LOW FILEHDR SCN"
  2             , max(FHSCN) "MAX FILEHDR SCN"
  3             , max(FHAFS) "Min PITR ABSSCN"
  4          from X$KCVFH ;
 
LOW FILEHDR SCN                  MAX FILEHDR SCN                  Min PITR ABSSCN
-------------------------------- -------------------------------- --------------------------------
6234167427056                    6234207627035                    6234213805895
 
SYS@abcd>

可以看到和官方的说法比较吻合。使用不完全恢复。
recover database until scn 6234213805895;	 -- 使用的是这个 

最后,open resetlogs 开库。
复制
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

星星之火
暂无图片
9月前
评论
暂无图片 0
世界上有两种人,最值得我们去珍惜。不富,却愿意为你倾其所有的人,很忙,却愿意为你有空的人。 世界上有两种人,最值得我们去珍惜。不富,却愿意为你倾其所有的人,很忙,却愿意为你有空的人。
9月前
暂无图片 点赞
评论