Oracle Data Guard脑裂是Failover后原主库未强制下线导致并发写入的必然结果；必须立即SHUTDOWN ABORT、网络隔离、禁用监听与进程，并在重建前严禁启动至MOUNT状态。
Oracle Data Guard脑裂不是配置失误的结果，而是主库未被强制下线时仍处于OPEN或MOUNT状态，与新主库并发写入共享数据的必然后果。
Failover后原主库必须物理级隔离
Failover命令只改变备库角色，对原主库完全无影响。它仍监听1521端口、接受DML、写redo——此时新主库也在提供服务，块级冲突无法避免。
- 立即在原主库执行
SHUTDOWN ABORT：不能用SHUTDOWN IMMEDIATE，后者可能等待事务提交，留下数秒写入窗口 - 拔掉业务网卡或在交换机侧禁用其业务端口，确保应用层彻底断连
- 检查
lsnrctl status无监听器运行，ps -ef | grep pmon无Oracle进程残留 - 确认
/etc/hosts和tnsnames.ora中无其他节点仍能解析到该实例
重建前严禁启动原主库到MOUNT状态
只要原主库进入MOUNT，CSSD或Clusterware就可能尝试挂载OCR/Voting Disk，尤其当它仍连着共享存储时，极易引发IO Fencing失败或仲裁盘写冲突。
- 保持原主库完全关机（
shutdown -h now比仅SHUTDOWN ABORT更稳妥） - 仅在RMAN恢复阶段才启动到
NOMOUNT，且必须指定DB_NAME与新主库一致 - 执行
ALTER DATABASE CONVERT TO PHYSICAL STANDBY前，务必确认新主库已启用指向该节点的LOG_ARCHIVE_DEST_n
跨中心场景下需切断底层存储访问
同城双活架构中，若原主库仅网络隔离但未断电，其CSSD进程仍可能反复尝试访问远端第三投票盘（如NFS上的+ASM/voting_disk）。当网络延迟在14–27秒间震荡，CSSD会持续重试写入，造成心跳抖动和误判。
- 停掉多路径服务：
systemctl stop multipathd - 卸载ASM磁盘组：
asmcmd umount <diskgroup_name> - 验证
lsblk和df -h中已无对应ASM设备挂载
最容易被忽略的是：脑裂风险不来自“没做Failover”，而来自“做完Failover却忘了关原主库”。所有自动化脚本都应把SHUTDOWN ABORT和网络端口禁用作为Failover流程的最后一步，且不可跳过。
