\_PARALLEL\_MAX\_SERVERS仅限制实例级并行进程总数，不控制会话或SQL级并行度；需配合资源管理器（启用PLAN、设置PARALLEL\_DEGREE\_LIMIT\_P1或PARALLEL\_SERVER\_LIMIT、正确配置consumer group）才能真正限制并行。
为什么设置 _PARALLEL_MAX_SERVERS 后并行还是没限制住
因为这个隐含参数只控制单个实例能启动的最大并行服务进程数，不参与会话级或sql级的资源仲裁。它像水龙头总阀，但每个应用可以自己开多个水龙头——只要没配资源管理计划（resource manager plan），oracle 就不会主动掐断超限的并行请求。
常见错误现象：ORA-12827: insufficient parallel query slaves available 没出现，但 V$PX_PROCESS 显示实际并发远超预期，V$RSRC_CONSUMER_GROUP 里各组 CPU/IO 消耗严重失衡。
- 必须启用资源管理器：执行
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'YOUR_PLAN_NAME'; -
_PARALLEL_MAX_SERVERS建议设为物理CPU核心数 × 2 左右，过高会导致内存争用；过低会让资源计划“有计划无执行” - 该参数修改后需重启实例才生效（非动态），别在RAC里只改一个节点
怎么让资源管理计划真正管住并行度
关键不是加个 plan 就完事，得在 consumer group 里显式配置 PARALLEL_DEGREE_LIMIT_P1 或 PARALLEL_SERVER_LIMIT。前者按 SQL 级别限制 DOP（Degree of Parallelism），后者按会话级限制并行服务进程总数。
使用场景：ETL 批处理组不能抢走报表组的并行资源；开发账号执行全表扫描时，DOP 必须 ≤ 2。
-
PARALLEL_DEGREE_LIMIT_P1值为整数（如 4），表示该组内任一 SQL 最大允许 DOP；设为 0 则继承系统默认（通常是CPU_COUNT × PARALLEL_THREADS_PER_CPU） -
PARALLEL_SERVER_LIMIT是硬上限，单位是并行服务进程数（如 20），超了直接报ORA-12827 - 别漏掉
ACTIVE_SESS_POOL_P1配合使用，否则高并发小SQL可能挤占大并行任务的 slot
DBMS_RESOURCE_MANAGER 创建 plan 时最容易错的三处
不是语法报错才叫错——很多 plan 看似创建成功，但根本不起作用，因为底层逻辑被忽略。
- 没给 consumer group 分配
CPU_P1或UTILIZATION_LIMIT：资源管理器默认所有组共享 100% CPU，不设限额等于没设 plan - 把
PARALLEL_DEGREE_LIMIT_P1设在 plan directive 里，却忘了在DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP时指定MGMT_MTH为'EMPHASIS'（11g+ 默认值，但老脚本常漏） - 用
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA()过了，但没执行DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA()—— pending area 里的配置永远不落地
验证并行是否真被限制住了
别只看 V$SESSION 的 DEGREE 和 REQ_DEGREE，这两个字段反映的是优化器预估，不是运行时实际分配。真实情况藏在 V$PX_SESSION 和 V$RSRC_SESSION_INFO 里。
性能影响提示：过度限制 DOP 可能让原本 30 秒跑完的 SQL 拖到 3 分钟；但放任不管，可能让一个 SQL 吃光所有 PX server，导致其他会话卡在排队状态。
- 查实时并行占用：
SELECT qc_session_id, server_set, degree FROM V$PX_SESSION WHERE qc_session_id IS NOT NULL; - 查资源组实际执行限额：
SELECT name, active_sessions, queue_length, cpu_wait_time FROM V$RSRC_SESSION_INFO; - 确认 plan 生效：
SELECT name, is_top_plan, status FROM V$RSRC_PLAN WHERE is_top_plan = 'TRUE';返回空？说明 plan 没真正激活
