AWR不直接记录并行度降级，但可通过Parallel Executions=0、高物理读/逻辑读、低执行次数、Top 5含parallel query queue time、Parse To Execute Ratio
AWR本身不直接记录“并行度降级”这个动作，但能通过多个指标交叉印证某条SQL本该并行却退化为串行执行——关键不是找“降级日志”，而是发现“预期并行但实际没走并行”的证据链。
查SQL Statistics里Parallel Executions = 0但有高物理读
在AWR报告的SQL ordered by Physical Reads或SQL ordered by Elapsed Time部分，筛选满足以下条件的语句：
-
Physical Reads per Exec> 50,000 且Buffer Gets per Exec> 100,000 -
Executions≤ 10（说明不是高频小查询） -
Parallel Executions列显示为0（这是最直接的降级信号） - 同时确认该SQL历史执行计划中曾出现过
PX COORDINATOR或PX SEND操作（需用DBMS_XPLAN.DISPLAY_CURSOR查真实历史计划）
这类SQL通常具备并行潜力（大表扫描、高物理读），但当前快照周期内完全没触发并行，大概率被系统自动降级了。
看Top 5 Timed Events是否含parallel query queue time
如果parallel query queue time出现在Top 5，说明系统确实在排队等并行资源；但它单独出现不等于降级——要结合其他现象判断：
- 若该事件等待时间长 +
Parallel Executions = 0→ 很可能因资源不足（如PARALLEL_MAX_SERVERS耗尽）被拒绝调度 - 若该事件排第1但
Parallel Executions > 0→ 是正常排队，非降级 - 若该事件未出现，但
latch: parallel query alloc buffer或enq: PQ - slave reservation等待突出 → 说明并行内存/进程分配失败，SQL被迫串行
核对Instance Efficiency Percentages中的硬解析与并行参数
并行SQL对共享池压力极大，硬解析失败会直接导致降级。重点检查：
-
Parse To Execute RatioPARALLEL hint 或对象级并行属性可能被忽略 -
Library Hit %cursor: pin S wait on X高时，优化器可能跳过并行计划生成 - 确认
PARALLEL_DEGREE_POLICY不是MANUAL：设为AUTO或LIMITED才能触发自动降级逻辑；MANUAL下要么全并行要么全串行，无“降级”概念
另外注意：PARALLEL_MIN_PERCENT若设为非0值（如50），当可用并行服务器不足时，SQL会报错ORA-12827: insufficient parallel query slaves available而非静默降级——此时AWR里看不到该SQL，因为它根本没执行。
从Load Profile和DB CPU/s反推并行能力是否被抑制
并行执行需要CPU资源支撑。若系统已不具备并行基础，SQL即使写了hint也会被降级：
-
DB CPU每秒值远低于物理核数 × 60（例如16核机器上DB CPU(s) -
DB Time / DB CPU比值 ≥ 3 → 系统大量时间花在等待上（如I/O、锁），此时开启并行只会加剧latch: cache buffers chains等争用，Oracle会主动抑制并行 -
Physical reads每秒很高但direct path read占比
真正难排查的是“隐式降级”：SQL写了/*+ PARALLEL(t,4) */，但因为统计信息陈旧导致优化器估算行数远小于阈值，最终选择串行索引范围扫描——这时AWR里Parallel Executions是0，但你得去SQL Plan部分看实际执行路径才能确认。
