查gv$servicemetric是验证Oracle RAC连接负载均衡是否生效的第一手依据，必须用gv$（非v$）并指定service_name，重点关注load_percent（LBA建议权重）、service_time_per_call等字段，每15秒刷新；需结合gv$session连接分布和FAN事件交叉验证，避免因客户端未启用LOAD_BALANCE=on或CLB_GOAL配置错配导致假均衡。
查 gv$servicemetric 看实时负载建议值
load balancing advisory（lba）不直接记录连接去了哪，而是通过 gv$servicemetric 暴露每个实例对某 service 的“建议权重”。这个值每 15 秒刷新一次，是判断分发是否按预期工作的第一手依据。
常见错误现象：只查 v$servicemetric，结果只看到当前实例的数据，误以为负载均衡正常——其实其他节点的指标全被漏掉了。
- 必须用
gv$servicemetric，且显式加WHERE service_name = 'xxx' - 重点关注
service_name、inst_id、goal、service_time_per_call、global_service_time_per_call和load_percent -
load_percent是核心：它代表该实例“被建议承担的服务请求比例”，不是 CPU 或会话数，而是基于CLB_GOAL（SHORT/LONG）动态算出的归一化值 - 如果两个节点的
load_percent长期是 95 / 5，说明 LBA 认为其中一节点明显过载或响应迟缓，得立刻查它上面的service_time_per_call是否异常高
比对 gv$session 和 service_name 分布是否匹配 LBA 建议
LBA 只提建议，客户端最终连到哪个节点，取决于 tnsping 路由、JDBC 连接池配置、以及服务端是否真把负载信息注册给了 SCAN Listener。所以必须交叉验证实际连接分布。
实操建议：
- 执行
SELECT inst_id, service_name, COUNT(*) FROM gv$session WHERE type = 'USER' GROUP BY inst_id, service_name ORDER BY inst_id; - 把结果里的
COUNT(*)换算成百分比，和上一步查出的load_percent对比：如果 A 节点 LBA 建议 40%，但实际连接占了 75%，说明客户端没听建议——大概率是 tnspnames.ora 没配LOAD_BALANCE=on，或应用用了硬编码 VIP 直连 - 注意过滤
service_name，别混进SYS$BACKGROUND或默认orcl服务；真实业务 service 必须显式创建并启用 LBA（ALTER SERVICE ... CLB_GOAL = SHORT）
抓 FAN event 确认 LBA 是否真正触发
LBA 生效的底层信号是 FAN（Fast Application Notification）事件。如果没收到 FAN load balancing event，客户端驱动根本不会调整连接策略，哪怕 gv$servicemetric 数值再合理也没用。
怎么确认？
- 在客户端机器上开启 Oracle Net trace（
sqlnet.ora加TRACE_LEVEL_CLIENT = 16），连一次后搜日志里有没有FAN_EVENT=LOAD - 或者在数据库端查
SELECT * FROM gv$fan_event WHERE event_type = 'LOAD' AND service_name = 'xxx' ORDER BY timestamp DESC;（需已启用 FAN） - 常见坑：服务没开
AQ_HA_NOTIFICATIONS=ON，或监听没收到实例注册——检查lsnrctl status LISTENER_SCAN1输出中对应 service 下是否有LOAD字段
避开 CLB_GOAL 和连接模式错配导致的假均衡
CLB_GOAL 不是万能开关，它和应用连接模式强耦合。配错了，LBA 就会给出反直觉的建议值，甚至让负载更倾斜。
关键区别：
-
CLB_GOAL = SHORT：适用于短连接（如 Web 请求、脚本批量连接），依赖service_time_per_call。如果应用实际用长连接池，这个目标会让 LBA 误判“某节点响应快就该多分”，结果连接全堆过去，PGA 爆掉 -
CLB_GOAL = LONG（默认）：适用于连接池、报表工具，看的是各节点当前session_count。但如果连接池设了最大连接数上限，LBA 就会持续建议往空闲节点导流，而那些节点可能 IO 或 CPU 已饱和 - Java 应用用 UCP 时，必须同时配
connectionPool.setLoadBalancingEnabled(true)，否则 JDBC 驱动忽略 FAN LOAD event
最易被忽略的一点：LBA 的 service_time_per_call 统计包含网络延迟。如果某个节点离应用服务器物理距离远、或中间有防火墙抖动，它的指标就会虚高，LBA 自动把它“拉黑”——这时要查的是网络层，不是数据库参数。
