LOAD_BALANCE=ON必须置于ADDRESS_LIST内层而非DESCRIPTION顶层，否则无效；客户端据此随机选择ADDRESS建立连接，仅影响新建连接，不适用于已建立的长连接。
LOAD_BALANCE=ON 必须放在 ADDRESS_LIST 内层，不是 DESCRIPTION 顶层
很多人配了多个 address 却发现连接始终打到第一个节点，根本原因是把 load_balance=on 错误地写在了 (description=...) 外层或同级位置。oracle 客户端只认嵌套在 address_list 下的该参数，其他位置一律忽略。
常见错误写法：(DESCRIPTION=(LOAD_BALANCE=ON)(ADDRESS=...)(ADDRESS=...))
这是无效的——LOAD_BALANCE 不在 ADDRESS_LIST 节点下。
- 正确结构必须是：
(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=...)(ADDRESS=...)) - 一个
DESCRIPTION可含多个ADDRESS_LIST，但负载均衡只在单个ADDRESS_LIST内部生效，跨 list 不轮询 - 客户端每次新建连接时随机选一个
ADDRESS，不是连接中动态切换；所以短连接（如 Web 应用）效果明显，长连接（如 SQL*Plus 会话）看不出变化
FAILOVER=ON 单独配置没用，必须搭配 CONNECT_TIMEOUT
开了 FAILOVER=ON 后，连接失败仍卡住 20–30 秒？这不是故障转移没起作用，而是 Oracle 默认依赖 TCP 层超时，不主动中断连接尝试。
关键补救措施是：为每个 ADDRESS 显式设置 CONNECT_TIMEOUT=10（单位秒），否则客户端会在第一个不可达地址上干等到底。
-
CONNECT_TIMEOUT必须写在每个ADDRESS括号内，例如：(ADDRESS=(PROTOCOL=TCP)(HOST=db1)(PORT=1521)(CONNECT_TIMEOUT=10)) -
RETRY_COUNT和RETRY_DELAY只控制重试次数与间隔，不能替代CONNECT_TIMEOUT -
FAILOVER_MODE（如(TYPE=SESSION)）用于已建立连接后的会话级故障转移，对连接建立阶段完全无效
JDBC URL 中 load_balance 值必须小写 on
Java 应用通过 JDBC 连接时，如果 tnsnames.ora 配置正确但负载均衡仍不生效，大概率是 JDBC URL 里传参写成了大写 ON 或布尔值 true。
Oracle JDBC 驱动对这个参数严格区分大小写，且只接受字符串 on，其他形式（包括 ON、On、1）均被忽略。
- 正确 JDBC URL 片段：
?TNS_ADMIN=/path/to/network/admin&load_balance=on - 错误示例：
&load_balance=ON、&load_balance=true、&load_balance=1 - 该参数仅影响客户端解析 tnsnames.ora 的行为，不改变服务端监听逻辑
多监听器 ≠ 自动负载均衡，得靠客户端配置驱动
在 RAC 或多实例部署中，有人以为只要数据库端起了多个监听器（比如每个节点一个），客户端就能自动分摊流量。其实不然——服务端监听器本身不参与客户端连接分发决策，它只负责接收和转发请求。
真正的负载分发逻辑由客户端解析 tnsnames.ora 时的行为决定，服务端无感知。也就是说，即使你有 5 个监听器，只要客户端 tns 配置没启用 LOAD_BALANCE=ON，所有连接仍会扎堆到第一个地址。
- 验证是否生效：用
tnsping MYDB多次执行，观察输出中 “Attempting to contact” 行指向的 host 是否变化 - 生产环境建议配合连接池（如 UCP）使用，避免依赖客户端随机算法；UCP 可基于响应时间做更智能的路由
- 不要试图用多个
ADDRESS_LIST实现“主备+轮询”混合逻辑——Oracle 不支持这种嵌套语义，容易导致行为不可控
