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列)。漏掉任一环,服务就只能靠运气落点。











