Oracle RAC服务倾斜到单节点的根本原因是Service配置、客户端连接方式、FAN事件支持三者未对齐：需确保dba_services中load_balance与failover_method均为YES，gv$active_services中各节点LOAD字段非空，且客户端通过SCAN地址连接并启用FAN（如ojdbc配fanEnabled=true），缺一不可。
Oracle RAC服务倾斜到单节点，不是负载均衡没开，而是Service配置、客户端连接方式、FAN事件支持三者没对齐——只要其中一环断开，LOAD_BALANCE=on和srvctl modify service -B SERVICE_TIME就全失效。
查服务是否真启用了负载均衡目标
别只信srvctl config service输出，得进数据库看实时注册状态：
-
SELECT name, load_balance, failover_method, failover_type FROM dba_services WHERE name = 'your_service';——load_balance和failover_method必须都是YES，否则服务端LB根本没激活 -
SELECT service_name, load FROM gv$active_services WHERE service_name = 'your_service';—— 如果某节点LOAD字段为空或长期为0，说明该实例没向SCAN Listener正确上报负载，常见于未启用FAN或监听器未重载 - 用
lsnrctl status LISTENER_SCAN1确认输出里有该服务名，并带LOAD=xx字段；没有就说明服务没注册进SCAN，srvctl start service后需等30秒再查，或手动srvctl reload listener -l LISTENER_SCAN1
客户端连的到底是SCAN还是VIP？
tnsnames.ora里写的是SCAN地址还是直连VIP，决定负载逻辑走哪条路：
- 如果tnsnames里是
(HOST = scan.example.com)这种单地址，LOAD_BALANCE=on完全无效——没得选 - 如果写了多个VIP（如
(HOST = node1-vip)(HOST = node2-vip)），且配了LOAD_BALANCE=on，那只是客户端本地随机挑一个VIP，不感知CPU、会话数、GC等待等真实负载 - 真正起作用的路径是：客户端 → SCAN VIP → SCAN Listener → 根据
LOAD值路由到具体实例。这条路要求客户端必须用SCAN地址，且驱动支持FAN（如OJDBC 12c+ 配oracle.jdbc.fanEnabled=true）
为什么v$session里全是node1的会话？
先排除最隐蔽的陷阱：服务启动时没指定实例偏好，导致所有连接默认落到第一个启动的实例：
-
srvctl start service -d orcl -s mysvc -i orcl1这种指定-i的命令，会让服务只在orcl1上启动，其他节点压根不注册——检查srvctl status service -d orcl -s mysvc输出是否显示多节点 - 即使服务跨节点运行，若客户端用的是老版本JDBC（如ojdbc6）、没设
fanEnabled、或WebLogic数据源没勾选“Enable Fast Connection Failover”，那连接永远走tnsnames里的静态顺序，不会触发服务端LB - 用
SELECT inst_id, COUNT(*) FROM gv$session WHERE service_name = 'your_service' GROUP BY inst_id;确认是否真倾斜；如果只有inst_id=1有记录，说明服务根本没在其他节点上线
临时绕过但不治本的操作要小心
有些做法看似立竿见影，实则掩盖问题根源：
- 手动
srvctl relocate service把服务切到另一节点——这只是把压力从A节点转给B节点，没解决分配逻辑失效的问题 - 在tnsnames里硬写两个SCAN地址并加
LOAD_BALANCE=on——SCAN本身不支持多地址，Oracle Net会报错或只连第一个 - 改
remote_listener参数指向另一个SCAN——这会影响整个实例的FAN发布，可能让其他服务也失联
真正关键的是三件事同时成立：服务注册带LOAD、客户端用SCAN+支持FAN、实例级FAN已启用（SELECT value FROM v$parameter WHERE name = 'enable_pluggable_database'无关，要看v$services的FAILOVER_METHOD列）。漏掉任一环，服务就只能靠运气落点。
