在异机恢复数据库的时候,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进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




