Oracle客户端LOAD_BALANCE=on必须置于DESCRIPTION层级，放错位置（如CONNECT_DATA内）将被忽略；实例需通过remote_listener注册并执行ALTER SYSTEM REGISTER才能向SCAN监听上报负载，DNS须返回3个独立A记录，且FAILOVER_MODE会干扰负载分发。
tnsnames.ora里LOAD_BALANCE=on放错位置了
oracle客户端根本不会识别放在connect_data里的load_balance=on，它只认description层级的配置。放错位置等于没配。
- 正确写法必须是：
(DESCRIPTION = (ADDRESS = ...)(LOAD_BALANCE = on)(CONNECT_DATA = ...)) - 如果用了
DESCRIPTION_LIST，每个DESCRIPTION都要单独加LOAD_BALANCE = on，否则只对第一个生效 - Java应用用UCP或OJDBC时，这个参数仍由TNS解析器读取，不是靠JDBC URL控制
实例没向SCAN监听注册负载信息
srvctl status scan_listener显示正常，不代表实例已上报负载。SCAN监听本身不管理实例，它依赖各节点的PMON进程主动广播当前连接数、CPU使用率等指标——这一步失败，服务端负载均衡就形同虚设。
- 查
remote_listener是否指向SCAN地址：SELECT value FROM v$parameter WHERE name = 'remote_listener';，应返回类似scan-rac.example.com:1521 - 执行
ALTER SYSTEM REGISTER;强制重注册（无需重启实例） - 检查
lsnrctl services LISTENER_SCAN1输出中是否有Service "ORCL" has 1 instance(s)且Handler(s)下带LOAD字段，没有说明负载未上报
FAILOVER_MODE干扰了负载分发逻辑
一旦启用FAILOVER=on或FAILOVER_MODE，客户端会优先尝试失败节点重试，而不是按负载选节点。尤其当某节点短暂不可达时，后续连接可能持续被“钉”在第一个可用节点上。
- 验证方式：连接时观察是否反复出现
ORA-12545或长延迟后才连到其他节点 - 真正需要负载均衡时，建议显式禁用故障转移干扰：
(FAILOVER = off)，或至少不与LOAD_BALANCE = on混用 - 如果业务确实需要故障转移，应改用服务端的
FAILOVER_METHOD = BASIC配合LOAD_BALANCE = YES在DBA_SERVICES中统一控制
DNS没返回3个独立A记录
SCAN依赖DNS轮询分发连接，但很多环境误配成CNAME或只返回1个IP，导致所有连接都打到同一个VIP，看起来像负载均衡失效。
- 必须用
dig scan-rac.example.com ANY确认返回3个独立A记录，不能是CNAME - 防火墙必须放行SCAN VIP所在网段的
1521端口，否则部分IP不可达，DNS轮询就退化为“伪随机” - 虚拟机环境下拔网线常不触发VIP漂移，因为OS收不到链路down通知，此时
ping target探测才是有效验证手段
ALTER SYSTEM REGISTER;这一步——修改remote_listener后不执行它，实例不会立刻向SCAN推送新负载数据，而日志里又几乎不报错。
