oracle rac节点cpu负载不均的根源是service未按业务逻辑切分，导致报表与oltp混跑、cache fusion引发跨节点块传输；需拆分service、设clb_goal=service_time、验证remote_listener生效、监控gc/enq等待事件。
Oracle RAC节点CPU负载不均不是配置没生效，而是负载均衡策略与业务访问模式不匹配导致的——单纯开LOAD_BALANCE=ON或设REMOTE_LISTENER，解决不了Service级业务倾斜问题。
客户端随机连接导致负载毛刺
tnsnames.ora里配了LOAD_BALANCE=ON，但客户端每次连接都从地址列表里随机挑一个节点，完全不看当前CPU使用率。结果就是：节点1刚处理完一批大查询，CPU回落中；节点2正被OLTP压着跑，新连接还继续往它上面打。
- 现象：用
v$osstat查NUM_CPUS和BUSY_TIME，发现各节点CPU利用率方差>30% - 本质：这是连接层负载均衡，不是请求执行层调度，无法感知SQL实际开销
- 临时缓解：在客户端TNS中加
FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=2)(DELAY=1)，避免单点长时阻塞
服务端负载均衡没真正启用
很多人以为设了REMOTE_LISTENER就万事大吉，但PMON要能把负载信息同步过去，得满足三个条件同时成立：监听器正常、CLB_GOAL参数正确、节点间网络通。
- 检查
lsnrctl status输出里是否显示多个INSTANCE_NAME（如rac1、rac2），没有说明REMOTE_LISTENER未生效 -
CLB_GOAL必须设为SERVICE_TIME（按响应时间）或THROUGHPUT（按吞吐量），设成NONE等于关掉服务端均衡 - 确认各节点
listener.ora里有PREFER_LEAST_LOADED_NODE=ON（默认是ON，但显式写出来更稳妥） - 如果用了SCAN IP，确保
remote_listener指向的是SCAN别名，而不是单个VIP
Service没按业务逻辑切分
这才是CPU不均的根因。比如报表作业和交易服务混在一个Service里，负载自然全堆到同一节点上——Cache Fusion会把跨节点块传输变成CPU密集型操作。
- 查当前Service分布：
SELECT service_name, instance_name, goal FROM gv$active_services; - 用
srvctl modify service把高CPU业务单独拆成Service，并绑定到指定实例：srvctl modify service -d racdb -s report_svc -i rac1 -f - 客户端连接串必须明确指定Service名，不能只用
SERVICE_NAME=racdb这种泛化写法 - 对关键Service启用
CLB_GOAL=SERVICE_TIME，并配合GOAL=SERVICE_TIME参数让PMON按实际响应时间反馈
监控盲区掩盖真实瓶颈
只看v$sysmetric里的CPU%容易误判。RAC里真正拖慢节点的，常是内存融合等待（gc buffer busy acquire）或全局队列争用（enq: TX - row lock contention），这些都会让CPU空转却不出结果。
- 运行
SELECT inst_id, event, COUNT(*) FROM gv$session_wait WHERE event LIKE 'gc%' OR event LIKE 'enq:%' GROUP BY inst_id, event; - 若某节点
gc cr block busy远高于其他节点，说明该节点承担了过多跨实例块请求，需调整Service亲和性 - 用
AWR报告对比各节点Top 5 Timed Events，不要只信OS级CPU指标
真正有效的优化，从来不是调一个参数就完事。它需要把Service拆分、CLB_GOAL设对、监听器状态验实、等待事件盯住——四件事缺一不可。最容易被跳过的，是验证gv$active_services里每个Service是否真按预期绑定了实例。
