并行管道函数必须显式声明PARALLEL_ENABLE，否则Oracle绝不并行执行；声明方式包括PARALLEL_ENABLE、BY ANY或BY HASH分区；严禁会话状态，DML需自治事务，实际并行度受系统参数和资源管理器限制。
并行管道函数必须显式声明 PARALLEL_ENABLE
没加 parallel_enable 的管道函数，哪怕加了 hint 或开了并行参数，oracle 也绝不会真正并行执行。它只会串行跑完所有数据，再返回结果集。
声明方式有两种常见写法：
-
PARALLEL_ENABLE：表示函数支持并行，但不指定数据如何分区 -
PARALLEL_ENABLE(PARTITION l_cursor BY ANY)：告诉优化器“按输入游标任意切分”，适合无序、可乱序处理的场景 -
PARALLEL_ENABLE(PARTITION l_cursor BY HASH(column_name))：需要保证相同 key 走同一并行进程时用，比如做 group by 前预聚合
注意：PARTITION 子句只接受游标变量（sys_refcursor 类型），不能对字符串或集合类型参数分区。
管道函数体内严禁使用会话绑定状态
一旦开启并行，多个 slave 进程会同时调用同一个函数实例，如果用了包变量、DBMS_SESSION.SET_IDENTIFIER、会话级临时表（ON COMMIT PRESERVE ROWS），不同线程的数据就会互相覆盖或污染。
典型错误现象：
- 返回结果行数忽多忽少，甚至重复或丢失
- 日志表里出现多个 session 写入同一
session_id -
ORA-04068: existing state of packages has been discarded频发
正确做法是：所有状态必须局部化——用函数内声明的变量（如 l_session_id NUMBER）、BULK COLLECT 的局部集合，或通过自治事务写日志。
想在管道里写日志或控制表？必须加 PRAGMA AUTONOMOUS_TRANSACTION
直接在管道函数里执行 INSERT INTO log_table 会触发 ORA-14551: cannot perform a DML operation inside a query。因为管道函数本质是 SQL 执行计划的一部分，不允许修改数据。
解决方法只有这一种：
- 把 DML 封装进独立过程，并在其声明头加上
PRAGMA AUTONOMOUS_TRANSACTION - 过程末尾必须显式
COMMIT，否则事务挂起，阻塞后续管道输出 - 避免高频写日志——每 pipe 一行就 commit 一次，IO 和锁开销极大，建议按批次聚合后写
示例片段：
CREATE OR REPLACE PROCEDURE write_log(p_msg VARCHAR2) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN INSERT INTO pipeline_log VALUES (SYSDATE, p_msg); COMMIT; -- 必须 END;
真实并行度受资源管理器和系统参数压制
即使函数加了 PARALLEL_ENABLE，SQL 加了 /*+ PARALLEL(8) */ hint，实际启动的并行进程数仍可能远低于预期。
关键压制点：
-
PARALLEL_THREADS_PER_CPU：默认值常为 2，若 CPU=16，理论最大并行度为 32；设成 1 就直接砍半 - 资源管理器（Resource Manager）计划中对 consumer group 的
PARALLEL_DEGREE_LIMIT_P1限制 - 目标表的
DEGREE属性为 1（ALTER TABLE t2 PARALLEL 1）会强制降级整个执行计划
验证是否真并行：查 v$pq_slave 或看 t2.session_id 是否出现多个不同值——这是最直接的证据。别只信执行计划里的 “PX” 字样。
复杂点在于，并行管道和底层表统计信息强耦合。用 DBMS_STATS.SET_TABLE_STATS “骗”优化器认为表很大，是触发并行的常见手段，但这不是万能解——如果统计信息失真严重，可能导致其他 SQL 性能雪崩。
