今天一个客户问我，有个异机恢复的问题，原库是生产，还在运行，需要将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，然后即可。