parallel提示未生效的根本原因是会话级并行未启用或被隐式禁用，需确认三点：已执行alter session enable parallel dml、目标表统计信息完整且未被nologging等机制绕过、语句中未混用no_parallel提示或表级parallel 1设置。
存储过程里加 /*+ PARALLEL */ 提示为什么没生效？
常见现象是：明明写了 /*+ PARALLEL(t, 8) */，但执行计划里看不到 PQ 或 PCWP，V$PQ_TQSTAT 为空，实际还是串行跑。根本原因不是提示写错了，而是会话级并行未启用或被隐式禁用。
必须确认以下三点：
- 当前会话已执行
ALTER SESSION ENABLE PARALLEL DML（即使只查不改，某些版本或策略下也需显式启用） - 目标表
t的统计信息完整，且未被NOLOGGING、INMEMORY或临时表等机制绕过并行路径 - 没有在语句中混用
/*+ NO_PARALLEL */，也没有在表上设ALTER TABLE t PARALLEL 1—— 这类设置会直接压制提示
分区表 + PARTITION 提示能提升并行效率吗？
不能直接提升，但能显著改善数据分布和调度质量。Oracle 对分区表的并行扫描天然倾向按分区切分任务单元，比非分区表更易做到负载均衡。
关键操作建议：
- 确保分区键与查询条件匹配（如按
dt分区，WHERE 中有dt >= DATE '2025-01-01'），否则优化器可能放弃分区裁剪，退化为全表扫描+低效并行 - 避免在 SQL 中额外加
/*+ PARTITION(t) */—— 这个提示不存在；正确做法是让优化器自动识别分区，或用/*+ PARALLEL(t, 8) */配合分区裁剪 - 若分区数量远少于请求 DOP（比如只有 4 个分区但设了
DOP=16），Oracle 会把每个分区再拆成多个块，但容易引发gc cr block 2-way等 RAC 跨节点争用
PARALLEL_INSTANCE_GROUP 参数怎么影响存储过程中的并行调度？
这个参数决定并行进程能否跨 RAC 实例分配。如果存储过程部署在 RAC 环境，而 PARALLEL_INSTANCE_GROUP 被设为单实例名（如 'inst1'），哪怕你写了 /*+ PARALLEL(t, 24) */，所有并行进程也只会挤在 inst1 上，无法利用其他节点资源。
检查与修复步骤：
- 查当前值：
SHOW PARAMETER parallel_instance_group，若返回非空字符串且只含一个实例名，就是瓶颈 - 修改方式（需有权限）：
ALTER SYSTEM SET parallel_instance_group='' SCOPE=BOTH（清空即允许全部实例） - 更稳妥的做法是配合服务（Service）使用：创建绑定多实例的服务，并让存储过程连接该服务，比改系统参数更可控
存储过程中动态拼 SQL 时如何安全传入 DOP？
不能直接把变量拼进 /*+ PARALLEL(t, &dop) */ —— 提示必须在硬解析阶段可见，动态拼接会导致提示被忽略，甚至报错 ORA-30584。
可行方案只有两个：
- 用
EXECUTE IMMEDIATE配合固定 DOP 值的模板，例如：EXECUTE IMMEDIATE 'SELECT /*+ PARALLEL(t, 8) */ COUNT(*) FROM t WHERE ...' INTO v_cnt; - 改用会话级强制并行：
EXECUTE IMMEDIATE 'ALTER SESSION FORCE PARALLEL QUERY PARALLEL 8';，后续所有 SELECT 自动走并行（注意作用域仅限当前会话） - 绝对不要尝试
EXECUTE IMMEDIATE 'SELECT /*+ PARALLEL(t, ' || dop_var || ') */ ...'—— 这种写法提示失效，且易引入 SQL 注入风险
真正难处理的是“DOP 需随数据量动态调整”的场景：这时得在存储过程里先查 NUM_ROWS，再分支调用不同硬编码 DOP 的语句，而不是试图在提示里做计算。
