AWR中「SQL ordered by Parallel Operations」仅统计实际触发并行的SQL，若该页为空或数值极低，说明并行未生效；需结合执行计划、V$PQ_SLAVE、V$PX_PROCESS、ASH及OS线程等多维度验证真实并行状态。
看AWR里SQL Statistics中Parallel Operations是否真被调度
加了PARTIAL hint 或设了表级 DEGREE，不代表并行就真的跑起来了。AWR 的「SQL ordered by Parallel Operations」页只统计实际触发并行的 SQL，不是按 hint 或参数算的。如果这页为空或数值极低，说明并行根本没生效，后续所有分析都失去意义。
常见错误现象：执行计划里只有 Q000（协调器），没有 Q101/Q201 等从属进程；IN-OUT 列显示 P->S 而非 P->P；V$PQ_SLAVE 中活跃进程数长期为 0。
- 先确认表真实并行能力：
SELECT degree, instances FROM dba_tables WHERE table_name = 'YOUR_TABLE'—— 若degree = 1或instances = 1，则跨实例并行不会启动 - 检查会话级开关：
SHOW PARAMETER parallel_force_local—— 返回TRUE会强制串行，必须用ALTER SESSION SET parallel_force_local = FALSE - 统计信息过期会导致优化器低估数据量，直接降级为串行；执行
DBMS_STATS.GATHER_TABLE_STATS后再验证
查Top Events里是否有并行相关等待事件堆积
合理并行应摊薄单个 SQL 的等待，而不是制造新瓶颈。如果 parallel query queue time、px qref latch、px msg pool latch 进了 Top 5，说明并行度远超资源承载能力，不是“不够并行”，而是“并行太猛”。
典型信号：parallel query queue time 平均等待 > 100 ms，且总等待时间占比突增；latch: px msg pool 频次比平时高 3 倍以上；DB CPU 占比未升但 Elapsed Time per Exec 反而变长。
-
parallel_max_servers设得过大（比如 256），但物理 CPU 核心仅 32，大量并行进程争抢 CPU 调度，反而拖慢整体吞吐 -
parallel_threads_per_cpu> 2 时需警惕——Oracle 默认是 2，翻倍后若 I/O 子系统跟不上，direct path read等待会飙升 - RAC 环境下，
gc cr block busy配合高并行度出现，大概率是跨节点数据块争用，不是并行本身的问题
对比SQL Statistics中Elapsed Time与Parallel Operations的比值
并行的目标是缩短单次执行耗时，不是单纯增加操作次数。如果某条 SQL 的 Parallel Operations 很高，但 Elapsed Time per Exec 也同步升高，甚至超过串行版本，说明并行引入了严重开销（如数据重分布、全局排序、内存争用），当前设置不合理。
关键阈值参考：Elapsed Time per Exec > 1 秒 且 Parallel Operations > 0 是合理起点；若 Parallel Operations / Executions > 8 但 Elapsed Time per Exec > 5 秒，基本可判定过度并行化。
- 注意排除
ORDER BY或GROUP BY引发的全局排序——这类操作即使并行，也会在 coordinator 层串行归并，Elapsed Time不降反升 - 查
Physical Reads Per Exec：若并行后该值翻倍，说明多个并行进程重复读同一块（常见于未分区大表），需补加分区或调整PARALLEL_DEGREE_POLICY - 对比两份快照：业务高峰期开启并行 vs 非高峰期关闭并行，看
DB Time是否下降 —— 如果 DB Time 没变甚至上升，说明并行没带来净收益
结合ASH确认并行任务是否真正分散到多核
AWR 是小时级聚合，看不出并行进程是否真在多核上跑。比如 parallel_max_servers = 64，但所有并行进程都挤在 2 个 CPU 上，其余核心空闲，这种“伪并行”在 AWR 里完全无法识别。
实操方法：用 SELECT sql_id, session_id, pga_allocated, cpu_time FROM v$active_session_history WHERE sql_id = 'xxx' AND sample_time > SYSDATE - 1/24 ORDER BY sample_time，观察不同 session_id 的 cpu_time 分布是否离散。
- 若 8 个并行进程的
cpu_time都集中在同一session_id（即 coordinator），说明实际是 coordinator 在模拟并行，没走真正的 PQ 路径 - 查
V$PX_PROCESS的server_name字段：正常应看到P001~P008等多个进程，若只有P000，说明并行 slave 没拉起来 - Linux 下用
ps -T -p <PMON_PID>查线程数，再比对V$PX_PROCESS数量 —— 两者不一致，说明 OS 层资源限制（如 ulimit -u）卡住了并行进程创建
并行度是否合理，最终要看它有没有把工作真正分出去，而不是把等待和争用一起放大。很多 DBA 把 DEGREE=8 当成万能解药，却忽略了底层 CPU、内存、I/O 的实际承载边界。最危险的是：AWR 里数字看起来“很并行”，但业务响应时间没变，甚至更差——那说明并行正在悄悄吃掉本可用于其他请求的资源。
