直接kill smon不能触发RAC故障切换，因smon非实例存活性关键进程，Oracle会尝试重启它，实例仍保持OPEN状态，CRS不判定宕机；需通过srvctl stop instance、shutdown abort或kill pmon等使实例不可恢复终止才能触发接管。
直接 kill smon 不能触发 RAC 故障切换
oracle rac 的故障切换（failover）依赖于集群心跳、css 检测和实例死亡确认机制，不是进程级信号能绕过的。手动 kill -9 一个 smon 进程，数据库实例通常不会立即终止——smon 是后台恢复进程，oracle 会尝试重启它；即使它持续异常，实例本身仍可能保持 open 状态，crs 不会判定为“宕机”，自然不会触发接管。
真正有效的手动模拟实例宕机方式
要让 CRS 主动发起故障切换，必须让实例进入不可恢复的终止状态，且被 CSS 正确识别。以下方法才可靠：
-
srvctl stop instance -d <db_name> -i <inst_name></inst_name></db_name>：标准、安全、可审计，推荐用于测试 -
sqlplus / as sysdba→ 执行shutdown abort：强制关闭实例，触发 CRS 心跳超时后接管（需确保crsctl check crs正常） -
kill -9所有 Oracle 后台进程（如pmon、crsd对应的ora_pmon_<inst></inst>），而非只杀smon：仅当pmon被杀且无法重启时，实例才真正“死亡”
注意：shutdown abort 后需等待约 60–90 秒（取决于 misscount 和 disktimeout 配置），CRS 才完成检测并启动接管流程。
为什么 smon 不是关键故障点
smon 负责实例恢复、空间管理等后台任务，但它挂掉不等于实例崩溃。Oracle 实例的存活性由 pmon（进程监控）守护——pmon 检测到其他后台进程异常会尝试重启，只有它自身失效或整个实例地址空间不可达，才会导致 CRS 判定失败。
- 常见误判现象：kill
smon后查v$process看不到该进程，但select status from v$instance仍是OPEN - 真实故障信号：CRS 日志中出现
ora.<db>.<inst>.violation</inst></db>或ORA-00474: SMON process terminated with error并不触发 failover，除非伴随ORA-00470: LGWR process terminated with error或pmon异常 - 性能影响：反复 kill
smon可能导致未提交事务回滚延迟、临时段清理卡顿，但不会加速故障转移
验证接管是否成功的必要检查项
别只看服务是否“起来”，RAC 故障切换是否生效，得交叉验证多个层面：
- 在 surviving 节点执行
crsctl stat res -t | grep -A2 <db_name></db_name>，确认资源状态为ONLINE且托管节点已变更 - 连接数据库后查
select instance_name, host_name, status from gv$instance，确认原故障实例已消失，剩余实例数正确 - 检查 alert.log 中是否有
Starting background process LMS、Reconfiguration started等集群重配日志，以及Instance shutdown complete是否来自被杀节点 - 应用端重连后执行
select sys_context('USERENV','INSTANCE')，确认会话确实落在接管节点上（避免连接串未启用 TAF 或 SCAN 解析异常）
最容易被忽略的是：没关掉客户端连接池的长连接缓存，导致看起来“服务通了”，其实流量还在往宕机节点发包，直到超时才切走——这不是 RAC 的问题，是应用层配置缺陷。
