db time与cpu time比值≥3且cpu占比＜60%时不宜并行；仅当cpu占比≥60%、db cpu/s≥900（16核）才具备硬件基础；top 5含direct path read或parallel query queue time为可行信号，而latch/shared pool类等待高则不可行；需满足parse to execute ratio＞0.95、buffer hit ratio＞0.9、library hit%＞99%，且sql需满足大结果集、全表扫描、物理读高且未走direct path等条件，并通过dbms_xplan确认历史真实执行过并行。
看 DB Time 与 CPU Time 的比值是否支持并行吞吐
DB Time 远高于 CPU Time（比如 DB Time 是 CPU Time 的 3 倍以上），说明系统存在大量等待，不是 CPU 密集型负载，强行开并行只会放大争用，让 latch: cache buffers chains 或 gc buffer busy acquire 更高。只有当 CPU Time 占 DB Time 比例稳定在 60% 以上、且 DB CPU 每秒值接近物理 CPU 核数 × 60（例如 16 核机器上 DB CPU(s) ≥ 900/s），才具备并行的硬件基础。
查 Top 5 Timed Foreground Events 里有没有并行敏感型等待
如果报告中 direct path read 或 parallel query queue time 出现在 Top 5，是并行可行的信号；但若 latch: shared pool、library cache lock 或 cursor: pin S wait on X 高居前列，说明共享池/库缓存已成瓶颈，开并行会加剧硬解析和游标争用。
-
direct path read占比 > 25% 且平均等待 -
log file sync平均等待 > 5 ms + 频次 > 5000/小时 → 并行 DML 可能引发提交风暴，先压事务粒度 -
gc cr block busy同步升高 → RAC 环境下并行跨实例分发需谨慎，优先绑定PARALLEL_INSTANCE_GROUP
核对 Instance Efficiency Percentages 中的硬解析与内存命中率
并行查询会显著放大 SQL 解析和执行计划缓存压力。必须确认：
-
Parse To Execute Ratio> 0.95：否则并行语句每轮都硬解析，shared_pool_size会迅速打满 -
Buffer Hit RatioPhysical reads /Logical reads> 0.15 → 并行全表扫描可能把 buffer cache 冲垮，触发大量free buffer waits -
Library Hit %cursor_sharing=force 在 12c+ 可临时缓解，但非根治
验证 SQL Statistics 中是否存在“伪高负载但适合并行”的语句
别只盯 SQL ordered by Elapsed Time 总耗时最高的那几条。真正适合并行的，往往是：
-
Elapsed Time per Exec在 5–60 秒之间、Executions≤ 10、Buffer Gets per Exec> 100000 的报表类 SQL -
Rows Processed per Exec> 100 万，且执行计划里已出现TABLE ACCESS FULL或HASH JOIN -
SQL ordered by Physical Reads排名靠前，但Physical Reads per Exec> 50000 且Direct Writes为 0 → 表明没走 direct path，手动加/*+ PARALLEL(4) */可能立竿见影
注意：AWR 不记录并行度（DOP）实际使用值，dbms_xplan.display_awr 查出的执行计划若含 PX COORDINATOR 或 PX SEND，才说明历史确实跑过并行；否则只是推测可行。
