love wife & love life —Roger 的Oracle技术博客

Phone:18180207355 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务

Restore Database with ORA-01861

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客

本文链接地址: Restore Database with ORA-01861

今天一个客户问我,有个异机恢复的问题,原库是生产,还在运行,需要将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挑出来,单独执行,发现果然有问题。如下是我的测试结果:

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

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

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

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

    分享到:
18180207355
加Q咨询