load_balance=on必须置于description层级内，若放在connect_data或address_list子项中则被忽略；正确结构为(description=(address=...)(load_balance=on)(connect_data=...))，多address时需配合address_list且每个description单独配置。
LOAD_BALANCE=on 在 tnsnames.ora 里没生效
这不是参数写错了，而是放错位置导致 Oracle Net 完全忽略它。客户端只认 DESCRIPTION 层级的 LOAD_BALANCE = on，如果塞进 CONNECT_DATA 或 DESCRIPTION_LIST 的子项里，就等于没配。
- 正确写法必须是：
(DESCRIPTION = (ADDRESS = ...)(LOAD_BALANCE = on)(CONNECT_DATA = ...)) - 若用了
DESCRIPTION_LIST，每个DESCRIPTION都得单独加LOAD_BALANCE = on，否则只对第一个地址生效 - 只写 SCAN 地址（如
(HOST = rac-scan.example.com)）时，LOAD_BALANCE = on无效——只有一个地址可选，随机无意义 - 写了多个 VIP 却没配该参数，Oracle Net 默认顺序尝试，90% 连接都会落到第一个节点
Service 级负载均衡目标未触发
SERVICE_TIME 或 THROUGHPUT 这类目标根本不会影响 sqlplus、tnsping、普通 JDBC 连接——它们只对支持 FAN（Fast Application Notification）的客户端生效，比如 UCP 连接池、WebLogic 数据源，或 OJDBC 显式启用 oracle.jdbc.fanEnabled=true。
- 执行
srvctl modify service -d db -s svc -B SERVICE_TIME -j SHORT后仍不均衡？先确认服务是否已启动：srvctl status service -d db -s svc - 再查 SCAN 监听是否注册了负载指标：
lsnrctl status LISTENER_SCAN1输出中必须有该服务名 +LOAD=xx字段 - 检查服务是否真正启用了负载均衡：
SELECT load_balance, failover_method FROM dba_services WHERE name = 'svc'，值必须为YES - 客户端直连 VIP 或老 TNS 配置绕过 SCAN，就彻底走不到服务端 LB 逻辑
REMOTE_LISTENER 没配对或未强制注册
实例不向 SCAN 监听上报负载，服务端 LB 就是摆设。常见原因是 remote_listener 参数指向的 TNS 别名在 $ORACLE_HOME/network/admin/tnsnames.ora 中根本不存在，或只存在于单个节点。
- 用
tnsping LISTENERS_RAC（把你实际的别名代入）验证：返回TNS-03505: Failed to resolve name就确认失败 -
remote_listener值不能是裸 IP+端口字符串，必须是 tnsnames.ora 中定义的完整别名 - 改完参数后必须立刻执行：
ALTER SYSTEM SET REMOTE_LISTENER='LISTENERS_RAC' SCOPE=BOTH;，再跟一句ALTER SYSTEM REGISTER; - 等 30 秒后查
lsnrctl services LISTENER_SCAN1，确认对应 service 下出现多个 instance 名（如rac1,rac2）
DNS 或 SCAN 监听本身不可用
SCAN 依赖 DNS 返回 3 个独立 A 记录，不是 CNAME，也不是只返回一个 IP。防火墙若拦截 SCAN VIP 网段的 1521 端口，部分地址不可达，DNS 轮询就退化成“伪随机”。
- 用
dig rac-scan.example.com ANY查真实返回，必须看到 3 行独立 A 记录 -
crsctl stat res -t | grep lsnr必须显示ora.scan1.vip等资源为 ONLINE -
lsnrctl status LISTENER_SCAN1若报错或超时，说明 SCAN 监听没起来或端口不通 - 虚拟机环境拔网线常不触发 VIP 漂移，要用
ping+nc -zv实测 SCAN VIP 是否可达
