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

【数据恢复】Restore Database with ORA-01861

李真旭 2017-05-08
802

今天一个客户问我,有个异机恢复的问题,原库是生产,还在运行,需要将NBU中的备份恢复到另外一个主机上,数据文件均为raw。首先我们来看一下错误:



大家不难看出,rman执行报错了。从上述错误来看,感觉像是nls_date_format设置的问题。的确,如果我们在rman命令行中使用了until time操作,那么建议设置nls_date_Format参数,可以设置os环境变量也可以在rman中执行sql执行。但是这里其实并不是这种情况。实际上我无论是在os设置还是rman命令行中设置,均不会起作用。


针对该问题,Oracle mos有一篇文档RMAN Recovery Session Fails with ORA-1861 (文档 ID 852723.1) 记录十分详细,里面提到了一些解决方案,其中也提到了一些检测判断是否为文章中提到的bug的方式。


不幸的是,我参考文章的的方式,执行了如下脚本发现根本不返回记录,也就说明不是文档中描述的这个问题。


于是我进一步使用rman target debug trace=/tmp/rman.trc进行跟踪,检查发现rman在执行脚本的时候,在运行如下的SQL时报错:



从上面的内容来看,上述的select fhscn语句是报错的关键。将该SQL挑出来,单独执行,发现果然有问题。如下是我的测试结果:



执行以上SQL


从测试结果来看,我们可以断定第252号文件在控制文件中的信息可能有点问题。这个问题我也是第一次遇到。不过我将controlfile 的内容dump出来之后,过滤定位到file=252的内容,发现似乎并没有异常的地方:



不难看出,上述的内容似乎没有什么问题。从整体现象来看与Oracle mos文档中提到的bug确实很像,几乎完全一样。但是通过mos文档中提到的脚本检查缺没有问题,这让我感觉很奇怪。

不过这里有点不确认的是,我是在生产库进行检测的,同时执行select语句也没有任何问题。说明原生产库的controlfile本身就是ok的。按理说应该在新环境中进行检测。

简而言之,这个问题确实有些怪异。不过还好的是,要解决或者绕过这个问题并不难,比如可以restore tablespace  xx,xxx  skip datafile 252即可。最后单独备份这个252文件进行restore,然后即可。


文章转载自李真旭,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论