不能直接 kill -9 PMON 进行RAC故障转移测试，因为CRS监控资源而非进程，仅杀PMON会导致实例“半死不活”，无法触发故障转移，反而引发集群不稳定。
为什么不能直接 kill -9 PMON 进行 RAC 故障转移测试
pmon 是 oracle 实例的关键后台进程，负责清理异常会话和释放资源。但在 rac 环境中，直接 kill -9 pmon 并不会触发预期的实例故障转移（failover），反而大概率导致该节点 crs 资源进入 unknown 或 offline 状态，甚至引发 ocr/ voting disk 访问异常，使集群整体不稳定。
根本原因是：CRS 层监控的是 ora.<sid>.asm</sid>、ora.<sid>.srv</sid> 等资源状态，而非单个 OS 进程；PMON 挂掉后，Oracle 实例可能仍被 CRS 认为“活着”（因为其他进程如 crsd、ocssd 仍在运行），从而跳过故障检测逻辑。
- 真实生产环境里，实例宕机通常表现为整个
oracle用户下的所有 Oracle 后台进程全部消失，或 CRS 主动停止该实例资源 - 仅杀
pmon属于“半死不活”状态，既不满足 CRS 的 failure threshold，也不符合 Oracle 的 instance death 判定条件 - 部分版本（如 11.2.0.4）在 PMON 被 kill 后，实例可能持续数分钟处于
STARTED状态，但无法接受新连接，造成假性可用
正确模拟 RAC 实例宕机的两种可靠方式
必须让 CRS 明确感知到该实例资源已不可用，并触发 relocation 或 restart 行为。以下方法经 11gR2 / 12cR1 / 19c 验证有效：
- 使用
crsctl stop resource ora.<db_name>.db -n <node_name>：这是最干净的方式，等价于正常关闭实例并释放所有资源，会触发连接重定向（TAF）、服务迁移和服务重启流程 - 强制终止整个数据库资源栈：
crsctl stop cluster -n <node_name>（慎用）：适用于测试节点级故障，但会影响该节点上所有数据库和服务，且需确保另一节点能承载全部负载 - 避免用
sqlplus / as sysdba执行shutdown abort：它虽能杀死实例，但 CRS 可能因未收到通知而将资源标记为FAILED，后续需手动crsctl start resource，偏离真实故障场景
验证故障转移是否生效的关键检查点
不是看到“实例起来了”就完事。RAC 故障转移的核心是业务连续性，重点看客户端连接、服务状态和服务透明度是否按预期工作：
- 检查
srvctl status service -d <db_name>输出，确认原故障节点上的 service 已自动迁移到存活节点（running on nodes: node2） - 用
tnsping <service_name>和实际应用连接测试，观察是否发生 TAF 切换（如 SELECT 查询中断后自动重连，非 DML 场景下应无报错） - 查
v$active_services和v$session，确认新连接确实落在目标节点，且failover_type、failover_method字段与 service 创建时设置一致 - 留意 alert.log 中是否有
ORA-03113、ORA-03137等会话中断记录——少量可接受，大量出现说明客户端未配置 TAF 或 JDBC 连接串缺少failover=true
最容易被忽略的配置陷阱
即使操作步骤全对，没配好这些，故障转移也会“静默失败”：客户端连得上，但其实没切走，或者切走了却卡在中间状态。
-
remote_listener必须指向 SCAN 地址，且所有节点的local_listener指向本机 VIP，否则 service 无法跨节点发布监听信息 - service 创建时未指定
-r（preferred）和-a（available）节点，会导致 CRS 默认只在单节点启动 service，不支持自动 relocation - JDBC 连接串漏了
LoadBalance=true&Failover=true，或 .NET 的Data Source=xxx;Failover Partner=xxx;未启用，应用层根本不会尝试重连 - tnsnames.ora 中 service 的
FAILOVER_MODE块缺失或TYPE=SELECT写成type=select（大小写敏感），TAF 不生效
真正难的从来不是“怎么杀”，而是“杀完之后，系统是否按你设想的路径反应”。每一步配置偏差，都会让故障转移变成一次黑盒行为。
