Oracle 11g RAC节点负载不均衡主因是Service级负载均衡未生效：需同时满足服务启用FAN、客户端支持FAN事件（如UCP或OJDBC配fanEnabled=true）、服务已注册到SCAN且LOAD字段可见，而tnsnames中LOAD_BALANCE=on仅实现地址随机选择，不感知真实负载。
oracle 11g rac 节点负载不均衡，不是因为“没开负载均衡”，而是因为默认 service 没配 load balancing goal 或配错了目标类型——service_time 和 throughput 必须显式指定，且只对启用了 fan 的客户端生效；纯 tns 连接压根不看这个。
Service 级别的 Load Balancing Goal 不生效的常见原因
你执行了 srvctl modify service -d db_unique_name -s mysvc -B SERVICE_TIME -j SHORT，但连接仍然全打到第一个节点。这不是命令错了，而是以下任一条件未满足：
-
SERVICE_TIME或THROUGHPUT目标只影响支持 FAN（Fast Application Notification）事件的客户端，比如 UCP 连接池、WebLogic 数据源、或设置了oracle.jdbc.fanEnabled=true的 OJDBC；tnsping、sqlplus、普通 JDBC URL 连接完全忽略该配置 - 服务没启动或没注册到 SCAN Listener：用
srvctl status service -d <db> -s <svc>确认状态，再用lsnrctl status LISTENER_SCAN1查看输出中是否有该服务名 +LOAD字段（如LOAD=0.82） - 数据库实例没开启 FAN 发布：检查
SELECT value FROM v$parameter WHERE name = 'enable_pluggable_database'不相关，真正要看的是SELECT * FROM v$services WHERE name = 'mysvc'中FAILOVER_METHOD和LOAD_BALANCE列是否为YES；若为NO，说明服务创建时没带-B参数，或修改后未重启服务 - 客户端仍在用老 TNSNAMES 配置直连 VIP，绕过了 SCAN 和 Service 路由逻辑——这种连接永远走不到 Server-Side LB
为什么 LOAD_BALANCE=on 在 tnsnames.ora 里不管用
这是最常被混淆的一点：LOAD_BALANCE=on 是客户端连接时的「地址随机选择」，和节点真实负载无关，只在多个 ADDRESS 条目间做 round-robin 式打散。它解决的是「连哪个监听器」的问题，不是「连哪个实例」的问题。
- 如果你的
tnsnames.ora只写了 SCAN 地址（如(HOST = scan.example.com)），那LOAD_BALANCE=on完全无效——只有一个地址可选 - 如果写了多个 VIP 地址但没配
LOAD_BALANCE=on，Oracle Net 默认按顺序尝试，第一个成功就停，结果就是大部分连接都落到第一个 VIP 对应的节点 - 即便配了
LOAD_BALANCE=on，它也不感知实例 CPU、会话数、GC 等真实指标，纯靠客户端本地随机，无法应对运行中节点突然过载的情况
调整 Service 权重的唯一有效方式：用 srvctl modify service + FAN 客户端
真要让连接按节点实时负载分发，必须组合使用：
- 服务端：用
srvctl modify service -d <db> -s <svc> -B SERVICE_TIME -j SHORT（短事务）或-j LONG（长事务），并确保服务已启动、实例已注册到 SCAN - 客户端：必须使用支持 FAN 的驱动，例如 OJDBC 12c+ 并在连接字符串加
;oracle.jdbc.fanEnabled=true，或用 UCP 配置connectionFactoryClassName=oracle.ucp.jdbc.PoolDataSourceFactory并启用 FAN - 验证方法：连接后查
V$SESSION的INST_ID，同时在另一会话里用SELECT inst_id, service_name, current_logons FROM gv$session_connect_info看各节点 logon 分布；别只看top或vmstat，那反映的是历史负载，不是连接路由依据
复杂点在于：FAN 事件依赖 UDP 广播，防火墙、多网卡、GNS 配置错误都会导致客户端收不到负载更新；而 LOAD_BALANCE=on 看似简单，却只能缓解连接建立阶段的倾斜，对已建立连接的长期负载毫无作用。这两层机制从来不是互斥选项，而是必须明确各自边界——想管连接入口，调客户端 TNS；想管连接去向，必须上 Service + FAN。
