并行查询cpu消耗集中在coordinator和px server上，ash中session_state='on cpu'且sql_opname为select/insert/update、program含p00/p01的样本是关键；需结合v$px_session、v$px_process及parallel_servers_target等参数综合诊断。
查 v$active_session_history 里 ON CPU + 并行相关 sql_opname 和 program
并行查询的 CPU 消耗不会均匀摊到每个会话上，而是集中在 coordinator（协调进程）和多个 px server（如 ora_p000_*, ora_p001_*）上。ASH 中真正体现高 CPU 压力的，是那些 session_state = 'ON CPU'、且 sql_opname IN ('SELECT', 'INSERT', 'UPDATE') 的样本——尤其当 program 包含 p00、p01 等字样时，基本可断定是并行执行在吃 CPU。
实操建议：
- 别只盯着
username，program字段才是关键：比如ora_p004_ORCL或oracle@host (P000)就是典型的 px server -
sql_opname为SELECT但event为空或只有极短的direct path read，说明大部分时间真正在 CPU 上做 hash join / sort / bitmap conversion - 用
session_id和session_serial#关联v$px_session，确认该会话是否属于某个并行查询的 slave 组
过滤 sql_id 相同但 sql_child_number 不同的高采样样本
同一 sql_id 下，不同子游标（sql_child_number）可能启用完全不同的并行度（DEGREE）或执行计划。比如一个子游标走串行全表扫描，另一个却启用了 DEGREE=32，两者在 ASH 中都显示相同 sql_id，但 CPU 消耗天差地别。
实操建议：
- 查 ASH 时必须带上
sql_child_number：SELECT sql_id, sql_child_number, COUNT(*) FROM v$active_session_history WHERE session_state = 'ON CPU' AND sample_time > SYSDATE - 1/24 GROUP BY sql_id, sql_child_number ORDER BY 3 DESC - 对高采样组合，立刻查
v$sql：SELECT sql_id, child_number, plan_hash_value, degree, executions, cpu_time/executions/1000000 "cpu_per_exec_s" FROM v$sql WHERE sql_id = '<your_sql_id>' AND child_number = <n></n></your_sql_id> - 注意
degree列：若为 0 表示未启用并行；若为 1 但实际跑了 px server，说明是 auto DOP 触发的（需查parallel_degree_policy参数）
结合 v$px_process 和 v$px_session 确认并行资源占用真实规模
ASH 是采样数据，可能漏掉短时爆发的并行任务；而 v$px_process 显示当前活跃的 px server 进程数，v$px_session 则能还原 coordinator-slave 关系。这两张视图能告诉你“现在到底有多少个进程在并行跑”，比 ASH 更实时、更确定。
实操建议：
- 运行：
SELECT qcsid, qcserial#, server_name, status FROM v$px_session ORDER BY qcsid, qcserial#—— 查出所有 slave 及其 coordinator - 再查：
SELECT server_name, status, pid, spid FROM v$px_process WHERE status = 'IN USE'—— 看哪些 px server 真正在干活 - 如果
v$px_process中IN USE数量长期接近parallel_max_servers，说明并行资源已被打满，新并行请求会排队等待，表现为大量parallel query queue等待事件
警惕 parallel_degree_limit 和 parallel_servers_target 配置失衡
Oracle 并行不是开得越多越好。当 parallel_servers_target 设置过低（比如 32），但应用频繁提交 DEGREE=64 的语句，系统就会强行降级并行度，导致 coordinator 负担加重、slave 分配不均、CPU 利用率异常升高——这种“伪高并发”最容易被误判为 SQL 本身问题。
实操建议：
- 查当前配置：
SELECT name, value FROM v$parameter WHERE name IN ('parallel_max_servers', 'parallel_servers_target', 'parallel_degree_limit') - 若
parallel_degree_limit = 'CPU'且主机 CPU 核数少，但 SQL 强制指定/*+ PARALLEL(32) */，Oracle 会按 CPU 核数上限裁剪，但 coordinator 仍需调度 32 个逻辑 slave，徒增开销 - 临时缓解可设：
ALTER SYSTEM SET parallel_degree_limit=8 SCOPE=BOTH，避免单条语句抢占全部并行资源
并行查询的 CPU 爆满，往往不是某条 SQL 写得差，而是并行资源管理失控或 coordinator 调度逻辑被反复触发。ASH 能告诉你“谁在吃 CPU”，但必须立刻补查 v$px_session 和参数配置，否则容易在错误的方向上优化半天。
