AWR不记录并行度设置不当的直接原因，仅反映内存耗尽、进程创建失败、共享池争用等症状；需结合PGA使用率、process startup失败日志、latch: shared pool等待飙升三指标识别宕机风险。
awr本身不记录“并行度设置不当”这个原因，它只反映并行失控后的症状：内存耗尽、进程创建失败、共享池争用。真正要识别宕机风险，得盯住三个指标组合——pga memory使用率、process startup失败日志、latch: shared pool等待飙升。
为什么AWR里找不到“并行度太高”的直接证据
Oracle 19c不会在AWR中存“当前parallel_max_servers设为256”这类配置快照，也不会标记某条SQL因PX进程过多而拖垮系统。它只记录结果：ORA-27300报错出现在alert.log里，但AWR只间接体现为process startup failed事件激增、shared pool latch等待时间突升、PGA memory使用率长期>95%。
- 查不到“parallel_max_servers超限”，但能查到
v$sysstat中processes created速率异常高（比如每秒新建>5个进程） - 看不到“并行查询占满PGA”，但
PGA Aggr Target和PGA Used在Instance Efficiency Percentages里已显示100%或持续>98% - 执行计划里有
Q101不代表安全——如果V$PX_PROCESS里同时活跃着400+个ora_p00*进程，就已在悬崖边
从AWR报告里抓取并行失控的三类关键信号
别只扫Top 5 Timed Events，重点翻这三处：
-
Load Profile → Processes Created/sec：正常值应3，说明应用/ETL在高频启停并行会话，极可能触发
ORA-27300 - Top 5 Timed Events → latch: shared pool：该等待平均时间>5ms且占比>15%，大概率是大量并行子进程反复申请shared pool内存（如分配游标、临时表空间描述符）
- Memory Statistics → PGA Memory：看“PGA Aggr Target”和“PGA Used”两列。若Used长期等于Target，且“PGA Cache Hit %”
结合ASH验证并行是否真成“雪崩点”
AWR是静态快照，ASH才是动态录像。单靠AWR可能漏掉瞬时峰值，必须交叉验证：
- 执行
SELECT COUNT(*) FROM v$active_session_history WHERE event = 'latch: shared pool' AND sample_time > SYSDATE - 1/24;——若1小时内采样>500次，说明问题不是偶发，而是持续施压 - 查
SELECT sql_id, COUNT(*) FROM v$active_session_history WHERE program LIKE 'ora_p%' GROUP BY sql_id ORDER BY 2 DESC;——找出被最多并行从属进程执行的SQL，它就是真正的“压路机” - 注意
V$SESSION中MODULE为ora_p000_*、ACTION含slave的会话，它们的PGA_ALLOCATED列若普遍>200MB，说明单个并行进程已吃掉过大内存
容易被忽略的致命细节
最危险的情况，是DBA看到“PGA用了95%”却没往下挖——因为PGA_AGGREGATE_TARGET本身可能被设得过小，而_pga_max_size隐含参数又没调，导致单个并行进程上限卡死在200MB。更隐蔽的是，某些ETL脚本在ALTER SESSION SET PARALLEL_FORCE_LOCAL = FALSE;后，没配parallel_instance_group，结果所有并行进程全挤在一台RAC节点上，把那台的PGA瞬间打穿。这些细节AWR不说话，但ASH里的INST_ID分布一目了然。
