参数一致却导致ORA-01105: mount is incompatible with mounts by other instances

昨日，RAC数据库2节点因私网心跳超时导致CRS重启，异常的是，数据库实例并没有如愿启动，而是在CRS自动带起数据库实例时，NOMOUNT到MOUNT过程中抛出了如下报错：

ORA-01105: mount is incompatible with mounts by other instances 
ORA-19808: recovery destination parameter mismatch

此错误为RAC数据库各实例同一参数生效值存在differ的情况，但是针对本次案例，经过分析与测试，此问题定性为软件Bug，故障现象还原模拟如下：

与生产系统现象一致，3节点RAC中，db_recovery_file_dest 参数为空，db_recovery_file_dest_size为300gb，

我们在节点2上设置db_recovery_file_dest参数，设置为+DG_DATA

我完全还原生产环境中故障的现象，生产环境中，在时间节点1时,集群2节点设置了db_recovery_file_dest参数，并且该参数在1个月后左右，人为将节点1上这个参数设置成了空，并且两次参数范围生效均为scope=both sid=’*’

故障现象出现，节点2宕机，并且无法启动抛出了预期的错误，生成create pfile from memory与create pfile from spfile后进行对比，但是这个参数各个节点均为格式一致的空，理论上不存在参数不一致且冲突的设置。

 

 

是否这个参数的设置方式不规范导致了此问题的发生，询问了Oracle业界大神ACED杨廷琨老师，杨老师建议用reset方式再次进行测试，但是测试结果一致，只用alter system reset方式进行参数的重置，仍然会导致此问题的发生。

严谨的杨老师继续给予我第二个测试内容，

（1）是否只是设置为空会引发这个问题，如果修改为其他目录是不是在任意一个节点都可以？

（2）另外，如果置空需要在当时set的节点运行，那么如果当前崩溃尝试启动的恰好是这个节点呢？其他节点的reset都无法使当前节点的实例启动吗？

测试点（1）是否只是设置为空会引发这个问题，如果修改为其他目录是不是在任意一个节点都可以？

 

 这时，模拟2节点宕机并重启后，没有发生ORA-01105与ORA-19808的错误，说明本节点设置值A，另外节点设置非空值B是OK的

测试点（2）如果置空需要在当时set的节点运行，那么如果当前崩溃尝试启动的恰好是这个节点呢？其他节点的reset都无法使当前节点的实例启动吗？

 

测试结论：因为这个参数设置导致的“冲突”，从而引发了实例重启的故障，但是，通过上述对生产环境的模拟发现，这个参数各个节点实际上内存生效值与实例SPFILE中的参数数值并不存在差异（包括格式），显然，这是Oracle软件的Bug行为，

1.节点set value，节点set null必须在同一节点上运行，如果不同，则会影响set value 节点重启，解决方案为在set null节点再次执行set null命令，其他节点设置其他VALUE是无影响的（只要别设置为空）

2.如果set null节点已宕机的情况下，之后set value节点也无法启动了，需要其他存活节点上再次执行set null命令后，set value，set null的异常节点均可成功启动

3.如果set null节点存活，则必须在set null节点 再次执行set null命令，若在其他存活节点上执行set null命令，set value节点同样无法启动。