验证taf是否启用需三步：先查v$session中failover_type、failover_method、failed_over字段；再用srvctl config service确认服务级failover type为select；最后模拟节点宕机观察客户端是否无感切换。
查 v$session 看当前会话是否启用 TAF
连接数据库后，直接查 v$session 是最快速的验证起点。关键字段是 failover_type、failover_method 和 failed_over：
-
failover_type = 'SELECT'或'SESSION'表示 TAF 已生效；NULL或'NONE'说明未配置或配置未生效 -
failover_method = 'BASIC'表示客户端侧 TAF；'PRECONNECT'表示服务端已预连备用实例（资源开销更大，但切换更快） -
failed_over = 'YES'是故障发生后的真实切换证据，不是配置状态
执行语句：SELECT failover_type, failover_method, failed_over FROM v$session WHERE username = 'YOUR_USER';
用 srvctl 检查服务是否启用 FAILOVER_TYPE=SELECT
RAC 的 TAF 行为由服务（service）级别控制，不是实例或数据库级。即使 tnnsnames.ora 配了 failover_mode，如果底层服务没开 TAF，客户端照样拿不到 SELECT 级别切换。
- 运行
srvctl config service -d <db_name> -s <service_name></service_name></db_name>，确认输出中含Failover type: SELECT - 若显示
Failover type: NONE，需用srvctl modify service -d <db> -s <svc> -e SELECT</svc></db>显式开启 - 注意：修改后必须
srvctl stop service+srvctl start service才生效，仅 reload 不行
模拟节点宕机时观察客户端行为是否“无感”
真实验证必须触发一次故障。不能只看配置，要测行为：
- 用该服务连接后，执行一个长查询（如
SELECT * FROM big_table WHERE rownum ），在返回部分结果后，立刻在对应节点上执行 <code>crsctl stop crs或srvctl stop instance -i <inst_name></inst_name> - 若查询继续返回剩余结果（且不报
ORA-03113或ORA-01034），说明type=SELECT生效 - 若查询中断并报错，或需手动重执行，说明实际走的是
type=SESSION或 TAF 根本未启用 - 特别注意：应用必须使用支持 TAF 的驱动（如 Oracle JDBC 12c+ 的
oracle.jdbc.replay默认关闭，需显式启用）
tnsnames.ora 中的 method=preconnect 容易被忽略
method=preconnect 不是可选优化项，而是 type=SELECT 正常工作的前提条件之一。它要求客户端在初始连接时，就同时连上所有 RAC 节点——否则切换时无法“续查”。
- 缺它会导致
type=SELECT退化为type=SESSION，即使配置写了 SELECT，实际也做不到无缝续查 - 检查 tnnsnames.ora 中对应条目是否含
(method = preconnect)，且(retries)和(delay)值合理（如retries=5,delay=1） - Preconnect 会多占 1~2 个连接槽位，生产环境需评估连接池容量是否足够
真正起作用的从来不是“配了什么”，而是“连上去之后查 v$session 是什么”和“杀掉节点那一刻应用有没有断”。配置写得再全，只要服务没开 SELECT、客户端没 preconnect、驱动不支持 replay，切换就只是纸上谈兵。
