看AWR中PARALLEL_EXECUTIONS是否大于0且执行计划含px操作符；DOP由对象degree、hint、会话级设置、系统参数按优先级决定；瓶颈关注Parallel Operations接近parallel_max_servers、gc cr block busy等指标。
AWR里怎么看并行度是否被真正用上？
直接查 dba_hist_sqlstat 和 dba_hist_sql_plan，别只盯着 sql 文本。重点看 parallel_executions（在 dba_hist_sqlstat 中）是否大于 0，再结合执行计划里是否有 px 开头的操作符（比如 px send qc、px receive）。如果 parallel_executions = 0，哪怕 sql 写了 /*+ parallel(t,4) */，也大概率没生效——常见原因是对象本身未启用并行（degree 为 1 或 default），或会话级被 alter session disable parallel dml; 干扰。
并行度（DOP）到底由谁决定？优先级怎么排？
Oracle 的 DOP 是动态协商结果，不是写死的 hint 就一定生效。优先级从高到低是：
• 表/索引/物化视图上的 degree 属性（select degree from dba_tables where table_name='T';）
• SQL 中的 parallel hint（如 /*+ parallel(t,8) */）
• 会话级设置：alter session set parallel_degree_policy = 'AUTO'; + parallel_degree_limit
• 系统级参数：parallel_threads_per_cpu × cpu_count × parallel_servers_target（影响后台进程池是否够用）
特别注意：parallel_degree_policy = 'MANUAL' 时，hint 和对象 degree 才起作用；设为 AUTO 后，优化器可能降级 DOP（比如数据量小就改用串行），这时 parallel_min_time_threshold（默认 10 秒）才是关键开关。
AWR 报告里哪些指标暴露并行瓶颈？
翻 AWR 的 “SQL Statistics” 部分，重点关注三组值：
• Parallel Operations：实际启动的并行操作数，持续接近 parallel_max_servers 值，说明资源吃紧
• Parallel Servers Highwater：历史最高并发 server 数，若远高于常用 SQL 的 DOP，说明存在短时尖峰或配置冗余
• 在 “Instance Activity Stats” 里查 queries parallelized 和 DML statements parallelized，两者比值异常低（比如 DML 并行极少），大概率是没开 alter session enable parallel dml;
另外，gc cr block busy 或 enq: PS - contention 高，往往意味着跨节点数据分发（PX SEND）成为瓶颈，不是加 DOP 能解决的。
调 DOP 时最容易被忽略的两个硬约束
一是 PGA 内存：每个并行服务器进程独占一份 PGA（受 pga_aggregate_target 分配），DOP 从 4 升到 16，PGA 消耗可能翻 4 倍，触发频繁 sort/mem → sort/disk 切换，反而更慢。
二是 I/O 调度能力：如果底层存储是单盘 SAS 或 NFS 共享卷，盲目提高 DOP 只会让随机 I/O 队列更长，cell flash cache read hits 下降、average wait time 上升就是信号。
实操建议：先用 alter session set events '10046 trace name context forever, level 8'; 抓单条 SQL 的 10046 trace，看 PX 进程实际分配数和等待事件，再决定是调 DOP、改分布策略（parallel_distribution hint），还是干脆关并行。
