ORA-19960报错搞不定？内部错误修复和远程处理经验分享

ORA-19960这个错误，说实话，我第一次遇到的时候也懵了，它不像一些常见的错误会直接告诉你“表空间满了”或者“权限不足”，它的描述很笼统，通常是什么“internal error”或者“file size is too small”，但你去查文件大小，发现明明还有很大空间，这种感觉就像车坏了，仪表盘只亮了个红色的感叹号，具体哪儿坏了全靠猜，根据我在处理数据库维护和从一些技术社区像Oracle官方支持文档和墨天轮等平台看到的案例，这个错误很多时候跟RMAN备份恢复脱不开干系。

我记得最清楚的一次是,一个开发环境的数据库在做全量恢复时，卡住了然后报出ORA-19960，错误信息额外提了一句“datafile 5 needs more recovery”，当时的第一反应就是去检查数据文件5的状态和路径对不对，结果发现，路径是对的，文件也存在，这就很奇怪了，后来，我仔细对比了备份时记录的控制文件信息和当前环境，才发现问题所在：这个数据文件在备份之后，被同事在线移动过位置，但移动后没有及时对控制文件进行更新，也就是说，控制文件里记录的还是这个数据文件的老位置，RMAN在执行恢复时，它很死板，只会按照控制文件里写的路径去找文件，它找到了老位置的那个文件（可能是个旧文件或者根本不存在），然后试图应用归档日志进行恢复，但发现怎么都追不上当前的SCN号，最后就抛出了这个让人困惑的ORA-19960。

解决办法说起来也简单,就是告诉控制文件：“嘿，那个文件已经搬家了，新地址在这儿”，我们当时用的是RMAN的catalog命令，把新位置的数据文件重新登记到控制文件里，命令大概是这样的：CATALOG DATAFILECOPY '/新的路径/数据文件文件名.dbf'; 登记完之后，再重新执行恢复操作，过程就非常顺利了，这件事给我的教训是，任何对数据库物理结构的改动，比如移动数据文件，一定要确保所有相关的元数据（尤其是控制文件）都同步更新，不然备份恢复的时候一定会出幺蛾子。

还有一种常见情况,也容易引发ORA-19960，就是归档日志文件出了问题，你的数据库需要做基于时间点的不完全恢复，RMAN会需要一系列连续的归档日志，假如这一串日志里，突然少了一个，或者某个日志文件在拷贝过程中损坏了，RMAN在恢复进程中就卡住了，它找不到下一个需要的日志，也会抛出这个错误，这时候，你需要做的就是检查V$ARCHIVED_LOG视图，确认恢复所需的日志序列号是否完整，以及每个日志文件的状态是不是有效的（VALID），如果发现有缺失或无效的，那就只能从别的备份副本里把这个日志找回来，或者如果条件允许，可能就得考虑换个恢复时间点了。

根据一些资深DBA在论坛里的分享,有时候这个错误甚至和BUG有关，特别是当你使用的Oracle数据库版本比较老，或者打了某些不成熟的补丁时，可能在特定的备份恢复场景下，RMAN内部的处理逻辑会出问题，从而生成ORA-19960，这种情况下，靠自己琢磨是很难解决的，最有效的办法就是上Oracle官方支持网站去查一下，输入你的Oracle版本号和完整的错误代码，看看有没有对应的已知BUG和推荐的治疗补丁，如果公司有购买Oracle原厂支持服务，直接开个服务请求（SR）让工程师帮忙看看，往往是最高效的。

面对ORA-19960，别慌，它虽然提示是内部错误，但十有八九还是外部原因造成的，排查的思路应该像破案一样，从错误信息的附加提示入手，紧紧围绕着RMAN备份恢复的三个核心要素：控制文件记录的信息是否准确、数据文件本身是否可用且路径正确、归档日志链是否完整无损坏，一步一步地排除，总能找到那个捣乱的环节。