dbms_pipe 不适用于高速数据流传输，因其默认8kb缓冲区、无持久性、无ack机制、单次单消息且仅支持标量值；适合传递短控制信号如'stop'或'refresh_cache'。
dbms_pipe 不能用于传递“高速数据流”。它根本不是为这个设计的——缓冲区默认仅 8kb，消息不持久、无 ack、单次只传一个打包单元，且同一消息只能被一个会话消费。想靠它做实时流式传输，相当于用邮筒送快递。
为什么 DBMS_PIPE.SEND_MESSAGE 一发大数据就卡住或报 ORA-06502
常见现象是 SEND_MESSAGE 阻塞几秒后抛出 ORA-06502: PL/SQL: numeric or value error，实际原因往往是管道满或类型错位，而非数值越界。
- 管道缓冲区默认大小为 8192 字节（可设上限至 2GB），但
SEND_MESSAGE是原子操作：整个打包缓冲区必须一次性写入，超限就直接失败 -
PACK_MESSAGE每次只接受一个标量值（VARCHAR2、NUMBER、DATE等），不能传集合、游标或 CLOB；拼接多次PACK_MESSAGE后调用SEND_MESSAGE，接收端必须严格按相同次数和顺序调用UNPACK_MESSAGE，否则解包错位 - 若发送端未显式调用
CREATE_PIPE('name', size, FALSE)就直接SEND_MESSAGE，Oracle 会隐式创建一个公有管道——但隐式管道在空闲时自动销毁，接收端可能根本等不到
接收端 DBMS_PIPE.RECEIVE_MESSAGE 总是返回 0 或立即报错
默认超时是 0 秒（非阻塞），RECEIVE_MESSAGE('p', 0) 没消息就立刻返回 0，不是“没收到”，而是“压根没等”。很多人误以为这是成功信号，结果跳过 UNPACK_MESSAGE 导致后续逻辑错乱。
- 要阻塞等待，必须显式传
-1：RECEIVE_MESSAGE('p', -1)；但前提是发送端已启动且管道存在、名字完全一致（区分大小写、无空格） - 私有管道（
CREATE_PIPE(..., TRUE)）其他会话无法访问，接收端会静默失败——查v$db_pipes可确认：private = 'TRUE'的管道owner列非空，且仅创建者能读 - 接收前漏掉
DBMS_PIPE.RESET_BUFFER，可能导致上次异常中断遗留的缓冲区脏状态，使UNPACK_MESSAGE解包失败
替代方案：真要传结构化/高频/大体积数据，别硬扛 DBMS_PIPE
它适合发「控制信号」，比如 'STOP'、'PAUSE'、'REFRESH_CACHE' 这类短指令。一旦涉及批量数据、进度反馈或广播通知，立刻换技术栈。
- 传中等体积结构化数据（如参数列表、任务描述）：用全局临时表（
ON COMMIT DELETE ROWS）+DBMS_ALERT做轻量通知，比拼管道安全得多 - 需要可靠、有序、可重放的消息流：上 Oracle Advanced Queue（AQ），支持持久化、多消费者、延迟投递
- 跨会话共享状态或进度：用包级变量 +
DBMS_PIPE辅助触发刷新，而不是传原始数据；或者直接查V$SESSION_LONGOPS获取运行时指标 - 前端需实时进度条：让后台过程定期更新一张状态表（含
session_id、progress_pct、status），前端轮询该表，比管道更稳
最易被忽略的细节：权限与实例边界
DBMS_PIPE 不是跨实例机制。即使连的是 RAC 集群的同一个 service_name，若两个会话落在不同 instance 上，管道通信必然失败——因为管道内存驻留在 UGA/SGA 中，不跨节点同步。
- 执行
DBMS_PIPE需要EXECUTE权限，普通用户需显式授权：GRANT EXECUTE ON SYS.DBMS_PIPE TO user_x; -
CREATE_PIPE返回非 0 值不一定是失败：返回 1 表示管道已存在（不报错），但你得自己判断是否要继续；返回 -1 才是真错误 - 管道名长度上限 30 字符，且受 Oracle 标识符规则约束（不能以数字开头、不能含特殊字符），别用
'my_pipe_2024_v2!'这种命名
