AWR报告不直接暴露并行查询倾斜，因其Top 5 Timed Events和SQL Statistics仅汇总各实例数据、缺失time_waited字段，无法识别长尾等待；必须结合gv$active_session_history（跨实例、含精确time_waited）及PX相关等待事件分析定位真实倾斜。
AWR报告本身不直接暴露并行查询倾斜，必须结合gv$active_session_history和特定等待事件分析；单看AWR的Top 5 Timed Events或SQL Statistics，大概率漏掉根本原因。
为什么AWR里找不到PX倾斜信号
AWR的Top 5 Timed Events汇总了所有实例的等待，会把节点1上PX Deq: Execution Message等长尾等待“平均化”进总占比。比如节点2某slave卡住5秒，被采样1次，节点1其他slave各等0.1秒被采样50次——AWR里只显示“PX Deq: Execution Message”总计51次，但无法看出那1次是5秒长尾。真正反映倾斜的是time_waited（微秒级精确值），而AWR不存这个字段。
-
v$active_session_history每秒采样一次，记录time_waited，但RAC下只含本实例数据 -
gv$active_session_history才跨实例完整，且必须显式WHERE sample_time > SYSDATE - 1/24限定窗口，否则默认只查最近1小时（AWR快照间隔常为1小时，易错过短时倾斜） - AWR中
SQL ordered by Elapsed Time页面里的“Instance Detail”链接能跳转到各节点执行分布，但只显示executions/cpu_time，不包含time_waited或buffer_getsper slave
必须用gv$ASH查PX等待+time_waited
以下语句是定位倾斜的最小可行集，不能省略inst_id和time_waited：
SELECT sql_id, inst_id, event,
ROUND(AVG(time_waited)/1000, 2) avg_ms,
MAX(time_waited)/1000 max_ms,
COUNT(*) samples
FROM gv$active_session_history
WHERE sample_time > SYSDATE - 1/24
AND event IN ('PX Deq: Execution Message',
'PX Deq: Table Q Normal',
'PX qref latch')
GROUP BY sql_id, inst_id, event
HAVING MAX(time_waited) > 5000000
ORDER BY max_ms DESC;-
MAX(time_waited) > 5000000（5秒）是硬门槛：至少一个PX slave被阻塞超5秒，整个并行组被拖慢 - 若同一
sql_id在inst_id=1的max_ms=8200，而inst_id=2只有max_ms=12，说明任务分配严重不均 - 注意
samples只是采样次数，avg_ms低但max_ms极高，基本可断定是分区键倾斜或谓词未下推导致某slave扫描量爆炸
RAC下倾斜常被误判为CPU或IO瓶颈
当并行查询倾斜时，AWR里可能看到DB CPU飙升、db file scattered read占比高，但这只是表象。真实原因是：
- PX slave在节点2卡在
PX Deq: Execution Message，但协调进程（QC）在节点1持续轮询，消耗CPU——AWR里DB CPU全记在QC所在节点，实际是等待不是计算 - 倾斜导致某slave读取远超其他slave，触发大量物理IO——
db file scattered read占比升高，但根源不在磁盘慢，而在数据分布不均 - 检查
gv$sysmetric_history中DB CPU和GC CR BLOCKS RECEIVED是否同步飙升：若后者占比超15%，说明PX进程跨节点拉块，Cache Fusion开销已成瓶颈
分区设计不当会固化倾斜
RANGE分区按键值区间切分，不感知数据实际分布。例如订单表按order_date RANGE分区，但促销期间90%订单集中在最新分区，会导致：
- 并行查询时，所有PX slave都去扫同一个物理分区，I/O和锁争用集中 APPLY
- 用
SELECT partition_name, num_rows FROM dba_tab_partitions WHERE table_name = 'ORDERS'查各分区行数，若最大分区行数是平均值的5倍以上，就是RANGE分区键选择失误 - 补救措施：对热点分区启用
SUBPARTITION BY HASH，或改用LIST分区按业务线拆分，避免单一分区承载全部压力
DBMS_STATS.LOCK_TABLE_STATS后，统计信息仍显示“分区大小均衡”，掩盖真实倾斜真正难的不是查出哪条SQL倾斜，而是确认倾斜是来自数据分布、分区裁剪失效，还是RAC节点调度失当——这三者在gv$ASH里等待事件类型一致，但后续优化路径完全不同。
