Failover后原主库未隔离是脑裂主因，必须强制关闭并网络隔离原主库，禁止其进入MOUNT状态，跨中心场景下还需停多路径服务并卸载ASM磁盘组。
Failover后原主库未隔离是脑裂主因
failover不是单向切换动作，而是双端状态重置过程。原主库若未被强制下线或网络隔离，它仍会以“primary”身份继续接受写入——此时新主库也在提供服务，共享数据被两套独立事务同时修改，必然导致块级冲突和逻辑损坏。这不是配置问题，是角色状态未同步的必然结果。
必须执行原主库的强制关闭与网络隔离
Failover命令（如ALTER DATABASE FAILOVER TO standby）只作用于备库端，原主库仍处于OPEN状态且监听正常。必须人工干预：
- 立即在原主库执行
SHUTDOWN ABORT，不能用SHUTDOWN IMMEDIATE——后者可能等待事务提交，留出写入窗口 - 拔掉原主库的业务网卡或在交换机侧禁用其业务端口，切断所有应用连接路径
- 确认
lsnrctl status已无监听器运行，ps -ef | grep pmon无Oracle进程残留 - 检查
/etc/hosts和tnsnames.ora，确保没有其他节点仍能解析到该实例
重建前严禁启动原主库到MOUNT或OPEN状态
很多DBA在重建时习惯先STARTUP MOUNT再RMAN恢复，这是高危操作。只要原主库进入MOUNT状态，CSSD或Clusterware就可能尝试挂载OCR/Voting Disk，触发集群资源争抢——尤其当它仍连着共享存储时，极易引发IO Fencing失败或仲裁盘写冲突。
正确做法是：
- 保持原主库完全关机（物理断电或
shutdown -h now更稳妥） - 仅在RMAN恢复阶段才启动到NOMOUNT，且必须指定
DB_NAME与新主库一致 - 恢复完成后，执行
ALTER DATABASE CONVERT TO PHYSICAL STANDBY前，务必确认新主库已启用LOG_ARCHIVE_DEST_n指向该节点
跨中心场景下第三投票盘延迟会放大风险
同城双活架构中，若原主库所在站点未彻底断电，而只是网络隔离，它的CSSD进程仍可能尝试访问远端第三投票盘（如NFS上的+ASM/voting_disk）。当网络延迟超过27秒（短磁盘超时），该节点会被驱逐；但若延迟在14–27秒之间震荡，CSSD可能反复重试写入，造成心跳状态抖动，增加误判概率。
这种情况下，仅靠crsctl stop crs不够，必须同步停掉底层存储多路径服务（如systemctl stop multipathd）并卸载ASM磁盘组，彻底切断对共享存储的任何访问能力。
