如何实现RAC的会话负载均衡_Client Load Balancing与Server端调度

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 可能缓存数分钟——这两边不同步，就容易误判配置失败。