srvctl config service 显示备节点缺失是服务切换失败最常见原因，因Available instances为空导致无故障转移路径；需用srvctl modify service -a补配并重启服务才生效。
srvctl config service 显示备节点缺失
服务切换失败最常见原因是根本没配备节点，srvctl config service 输出里只列 Preferred instances，而 Available instances 为空。这不是故障，是配置缺位。
- 执行
srvctl config service -d <db_name> -s <service_name>确认输出结构 - 若
Available instances行缺失或为空，说明服务未定义故障转移路径 - 补上备节点：
srvctl modify service -d <db_name> -s <service_name> -a <standby_inst>（注意是-a不是-n） - 修改后必须用
srvctl stop service+srvctl start service重启服务才生效，仅 reload 不触发新配置
srvctl stop instance 时服务不自动 failover
12c 及以后版本中，srvctl stop instance 默认不触发服务迁移，这是设计行为，不是 bug。报错 PRCD-1315、PRCR-1065 是预期结果。
- 要强制迁移，必须加
-f参数：srvctl stop instance -d <db_name> -i <inst_name> -f - 不加
-f时，服务仍留在被停实例上，状态变为STOPPED，但不会自动跳转 - 验证是否生效：停实例后立刻查
srvctl status service，确认服务已 running on 其他节点 - 注意：11g 用
-f，12c+ 也用-f，别信“新版自动迁移”的误传
tnsnames.ora 中 FAILOVER_MODE 位置写错
TAF（Transparent Application Failover）失效往往无声无息——连接正常、查询正常，但实例一挂就断连，日志里还找不到报错。根源常是 FAILOVER_MODE 放错了层级。
- 必须嵌套在
CONNECT_DATA下，且是其直接子项；不能放在DESCRIPTION或ADDRESS_LIST里 - 正确结构示例：
(CONNECT_DATA = (SERVICE_NAME = mypdb) (FAILOVER_MODE = (TYPE = SESSION) (METHOD = BASIC)))
- 错误结构如
(DESCRIPTION = (FAILOVER_MODE = ...) (ADDRESS_LIST = ...))，Oracle Net 完全忽略该参数 - Java 应用必须用 tnsnames 别名连接（
@RACDB），不能用 Easy Connect 格式（@//host:port/sid），否则 TAF 根本不加载
srvctl add service 用了 grid 用户而非 oracle 用户
用 grid 用户执行 srvctl add service 后，服务看似创建成功，但后续启停、failover 全部失败，报错类似 PRCR-1079 或权限拒绝。
- Oracle 官方明确要求：数据库服务（非 ASM、OCR 类资源）必须由
oracle用户操作 -
grid用户拥有集群栈控制权，但无权管理数据库层 service 的启动/停止逻辑 - 已错建的服务需先删再重建：
srvctl remove service -d <db_name> -s <service_name>，然后切到oracle用户重跑add - 检查当前服务属主：
crsctl stat res -w "TYPE = ora.service.type" -p | grep ACL，ACL 字段应含oracle:而非grid:
srvctl status service 显示 running），但实际没注册到监听、没启用 TAF、或底层权限链断裂——得一层层剥开看，而不是盯着一个报错反复 retry。 
