oracle rac客户端负载均衡需同时配置客户端tnsnames.ora中description级load_balance=on及服务端remote_listener并执行alter system register，缺一不可；failover_mode会干扰负载分发，应避免混用。
client load balancing 配置错，tnsnames.ora 里少这行就白搭
oracle rac 客户端负载均衡不是默认打开的，得靠客户端配置显式启用。很多人改完服务端 remote_listener 就以为完事了，结果连接全打到第一个节点——问题出在客户端没告诉 oracle “我想被分摊”。
关键就在 TNSNAMES.ORA 的服务名定义里加 LOAD_BALANCE=on：
MYDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = scan.example.com)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = mydb)))
→ 这样不行，没负载均衡。
正确写法（注意括号层级和位置）：
MYDB =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = scan.example.com)(PORT = 1521))
(LOAD_BALANCE = on) ← 必须放在这里，且是 DESCRIPTION 级别
(CONNECT_DATA = (SERVICE_NAME = mydb))
)
)
-
LOAD_BALANCE=on必须放在DESCRIPTION下，不是CONNECT_DATA里，放错位置无效 - 如果用了多个
ADDRESS（比如直连单个 VIP），每个DESCRIPTION都要单独配，否则只对第一个生效 - Java 应用用 UCP 或 OJDBC 时，这个参数仍由 TNS 解析驱动读取，不是 JDBC URL 控制
Server 端没开 REMOTE_LISTENER，srvctl 查不到监听就等于没调度
Client 端发来的连接请求，最终能不能被数据库实例“主动推”给其他节点，取决于实例是否向 SCAN Listener 注册了负载信息。这个注册动作靠 REMOTE_LISTENER 参数驱动。
检查方法很简单：
$ srvctl config listener $ lsnrctl status LISTENER_SCAN1 # 看输出里有没有各实例的 service 和 instance load 信息
常见错误现象：lsnrctl status 显示服务名在线，但 service_handler 全是 DEDICATED，没有 LOAD 字段 —— 说明实例没上报负载。
- 确认每个实例的
REMOTE_LISTENER指向正确的 SCAN 地址，例如：ALTER SYSTEM SET REMOTE_LISTENER='scan.example.com:1521' SCOPE=BOTH; - 修改后必须执行
ALTER SYSTEM REGISTER;，否则不会立刻推送新负载数据 - 如果用了 GNS，
REMOTE_LISTENER要指向 GNS VIP，不是 SCAN；否则注册失败且无报错
连接时看到 ORA-12545 或反复重试，其实是 FAILOVER_MODE 干扰了负载逻辑
很多人把 LOAD_BALANCE=on 和 FAILOVER_MODE 混在一起配，结果发现连接总往一个节点扎，或者一断就连不上——因为 Failover 机制会覆盖 Load Balance 的初始选择逻辑。
典型错误配置：
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = scan.example.com)(PORT = 1521)) (LOAD_BALANCE = on) (FAILOVER_MODE = (TYPE = SELECT)(METHOD = BASIC)(RETRIES = 3)(DELAY = 5)) (CONNECT_DATA = (SERVICE_NAME = mydb)) )
问题：Oracle 在启用 FAILOVER_MODE 后，首次连接会优先选“最近可用”的节点（按 TNS 解析顺序），而不是随机轮询。
- 纯负载均衡场景，直接删掉整个
FAILOVER_MODE块，它和LOAD_BALANCE是互斥策略 - 真要兼顾故障转移，改用
FAILOVER_TYPE=SESSION+RETRY_COUNT=0，避免干扰初始分发 - 应用层做连接池（如 HikariCP）时，更建议关掉 TNS 层 Failover，由池子自己管理健康检查
短连接压测看不出效果，sqlnet.ora 的 SQLNET.EXPIRE_TIME 会悄悄拖慢重平衡
负载均衡不是实时动态调整的，它只在新建连接时起作用。如果你用的是长连接、连接池复用率高，那从监控上看不出节点间流量差异——不是没生效，是没机会触发。
另一个隐形干扰项是 SQLNET.EXPIRE_TIME。设得太小（比如 1 分钟），会导致空闲连接频繁被探测中断，连接池不断重建连接，反而让负载集中在刚重启的节点上。
- 压测验证负载均衡，必须用大量短生命周期连接（比如脚本循环
sqlplus /@MYDB执行简单查询） -
SQLNET.EXPIRE_TIME建议设为 0（禁用）或 ≥ 1800（30 分钟），避免干扰连接分布 - 查实际连接分布，别看
v$session，用SELECT inst_id, COUNT(*) FROM gv$session GROUP BY inst_id;实时观察
真正难调的不是参数开关，而是 client 端连接行为和 server 端注册节奏之间的时机差。SCAN Listener 每 10 秒收一次负载更新，而客户端解析 TNS 可能缓存数分钟——这两边不同步，就容易误判配置失败。
