RAC节点性能倾斜需通过v$active_session_history的instance_number分布和gc类等待事件精准定位，而非依赖应用日志；ASH实时分析、跨实例ASH报告（ashrpti.sql）及历史表dba_hist_active_sess_history联合使用可揭示真实瓶颈。
直接看 v$active_session_history 的 instance_number 分布
RAC节点性能倾斜不是靠猜的，是数据偏斜。ASH每秒采样活动会话，v$active_session_history 里带 instance_number 字段，它就是真实执行节点的标识。别信应用日志里“查得慢”，先确认是不是真在节点1上跑得多。
- 执行
SELECT instance_number, COUNT(<em>) FROM v$active_session_history WHERE sample_time > SYSDATE - INTERVAL '5' MINUTE GROUP BY instance_number ORDER BY COUNT(</em>) DESC - 如果节点1的采样数是节点2的3倍以上，说明负载已严重不均
- 注意：这个查询必须在有足够ASH内存保留的前提下执行（默认只存1小时，高负载下可能被覆盖）
查 gc cr multi block request 等跨节点等待事件
RAC里“慢”往往不是SQL本身慢，而是节点间协调开销大。gc cr multi block request 是典型信号——节点1在反复向节点2要一致性读块，说明热点数据或事务分散在不同节点。
- 运行
SELECT event, instance_number, COUNT(<em>) FROM v$active_session_history WHERE event LIKE 'gc%' AND sample_time > SYSDATE - INTERVAL '5' MINUTE GROUP BY event, instance_number ORDER BY COUNT(</em>) DESC - 若
gc cr multi block request在节点1占比显著高于节点2，基本可锁定是RAC内部数据融合拖慢 - 这类等待不会出现在单实例，也不反映在SQL执行计划里，只在ASH/ASHRPT中暴露
生成跨实例ASH报告用 @?/rdbms/admin/ashrpti.sql
单节点ashrpt.sql只能看本实例，RAC必须用带i的脚本——ashrpti.sql，它支持指定实例号、时间范围和输出格式。
- 连接任意节点后执行
@?/rdbms/admin/ashrpti.sql，按提示输入：-
report_type：选text或html -
begin_time和duration：建议覆盖问题时段前后各10分钟 -
instance_number：分别对节点1、节点2各跑一次，再对比“Top Events by DB Time”和“Top SQL with Top Events”两节
-
- 报告里若节点1的“%DB time”中
gc类事件占比超30%，而节点2不足5%，这就是倾斜根源
别忽略 dba_hist_active_sess_history 的历史回溯能力
实时v$视图只存1小时，但真正的问题常发生在凌晨批量任务期间。这时得查持久化的历史表：dba_hist_active_sess_history。
- 查询语句示例：
SELECT instance_number, event, COUNT(*) cnt FROM dba_hist_active_sess_history WHERE sample_time BETWEEN TIMESTAMP '2026-07-20 02:00:00' AND TIMESTAMP '2026-07-20 03:00:00' AND event LIKE 'gc%' GROUP BY instance_number, event ORDER BY cnt DESC - 注意：该表依赖AWR快照触发归档，如果
dba_hist_wr_control里retention设得太短（比如仅1天），旧数据会被清理，查不到就不是没发生，是被删了
RAC节点性能倾斜最麻烦的地方在于：它不报错，不阻塞，只让SQL变慢；而慢的原因藏在节点间通信里，不是SQL写法或索引问题。盯住instance_number和gc类事件，比调优单条SQL更关键。
