srvctl relocate service仅迁移服务资源，不触发会话级故障转移；它改变服务注册位置和监听器绑定，但不中断或重路由已有TCP连接，需配合TAF配置、lsnrctl reload、local_listener调整及应用层连接池清理才能实现无缝切换。
srvctl relocate service 不触发会话级故障转移
Oracle RAC 的 srvctl relocate service 命令只迁移服务资源（即让服务在目标节点 online），不强制断开现有连接、也不重建客户端会话。这是设计行为，不是 bug。
常见错误现象：执行 srvctl relocate service -d orcl -s app_svc -i orcl1 -t orcl2 后，srvctl status service 显示服务已迁到 orcl2，但旧连接仍连在 orcl1 上，且新连接才打到 orcl2。
- 服务重定位 ≠ 会话重路由：它只改变服务注册位置和监听器服务名绑定，不干预已建立的 TCP 连接
- 客户端连接池（如 HikariCP、Tomcat JDBC Pool）默认复用连接，不会因服务迁移主动 close/reconnect
- Oracle Net 层无“会话漂移”机制；TAF（Transparent Application Failover）需显式配置且仅对故障生效，不响应人工 relocate
FAILOVER_MODE 不生效的典型配置陷阱
TAF 要在服务重定位后自动重建会话，必须满足三个硬性条件，缺一不可——多数失败源于其中某条未达标。
-
FAILOVER_MODE必须作为CONNECT_DATA的直接子项，不能嵌套在ADDRESS或提级到DESCRIPTION顶层；否则 Oracle Net 静默忽略 - 客户端必须使用 tnsnames.ora 别名连接（如
jdbc:oracle:thin:@APPDB），不能用 Easy Connect 格式（如@//vip:1521/app）——后者根本不解析 FAILOVER_MODE - JVM 必须能读到 tnsnames.ora，即启动时设置
TNS_ADMIN环境变量指向该文件所在目录；Spring Boot 中仅配spring.datasource.url不够
监听器未重载导致新节点服务不可见
服务迁到新节点后，若监听器没重新加载注册信息，客户端即使连对 VIP，也会报 ORA-12514: TNS:listener does not currently know of service requested。
- 执行
srvctl relocate service后，必须在目标节点手动运行lsnrctl reload，否则监听器仍只注册旧节点的服务名 - 确认
local_listener参数已指向本节点 VIP+端口（如'(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.102)(PORT=1521))'），否则动态注册失败 - 避免在
listener.ora中硬编码SID_LIST——RAC 环境下优先依赖动态注册；静态注册仅作兜底，且SID_NAME必须与数据库实际服务名一致
应用层缓存连接未清理
即使 VIP、监听器、TAF 全部正确，Java/.NET 应用仍可能持续复用旧连接，本质是连接池未感知底层变化。
- 连接池需配置
validationQuery（如SELECT 1 FROM DUAL）+testOnBorrow=true，才能在借连接时发现失效并丢弃 - 部分池（如 Druid）支持
removeAbandonedOnBorrow=true，可强制回收长时间空闲连接，间接缓解问题 - 最彻底方案：切换前通知应用侧执行连接池 soft reset（如调用
HikariDataSource.close()再重建），但需业务配合停写窗口
真正难处理的从来不是命令怎么敲，而是客户端连接池是否真把旧连接扔了——这一步没人帮你做，得自己盯着日志查 v$session 的 machine 和 inst_id 字段确认流向。
