EXTPROC 是 Oracle 专用于代理外部过程调用的独立进程，通过 IPC 将 PL/SQL 请求转发给它执行 C/DLL/SO；需在 listener.ora 和 tnsnames.ora 中正确配置 PLSExtProc 条目，否则报 ORA-28575；SELinux/AppArmor 及 Oracle 12c+ 默认禁用进一步限制其使用，且存在输出捕获难、审计黑盒等缺陷，现已弃用。
EXTPROC 是 Oracle 启动外部进程的“守门人”
Oracle 存储过程本身运行在数据库服务器进程（如 ora_p000_*）内，完全受数据库内存和权限模型约束。它不能直接调用 fork() 或 execve() 创建子进程——这不是语法限制，而是内核级安全隔离。EXTPROC 就是那个被数据库“特批”出来、专门干这件事的独立代理进程。当 PL/SQL 调用 EXTERNAL 声明的函数时，数据库不是自己去执行 C 代码，而是通过 IPC（通常是 KEY = EXTPROC0 的共享内存段）把调用请求转发给正在监听的 extproc 进程，再由它加载你的 DLL / SO 并执行。
listener.ora 中 PLSExtProc 条目不配就根本连不上
EXTPROC 不是随数据库自动拉起的服务，它依赖监听器（tnslsnr）按需启动。如果你删了 listener.ora 里这段：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /u01/product/oracle)
(PROGRAM = extproc)
)
)
或者没配对应的 tnsnames.ora 条目（如 EXTPROC_CONNECTION_DATA），PL/SQL 一调用外部函数就会卡在连接阶段，报 ORA-28575: unable to open RPC connection to external procedure agent。这个错误不是你的 C 函数写错了，是数据库压根找不到能代劳的 extproc 进程。
SELinux/AppArmor 和 Oracle 12c+ 默认禁用才是真拦路虎
- 即使
listener.ora配对了，Linux 上 SELinux 默认策略会拦截extproc加载任意第三方 so 文件，日志里可能只显示模糊的ORA-28576；AppArmor 在 Ubuntu/Debian 环境下也有同样效果 - Oracle 12c 起把 EXTPROC 标记为
deprecated for security reasons，安装后默认不启用，DBA 必须手动修改extproc.ora并重启监听器 -
extproc.ora里必须显式声明允许加载的库路径，比如SET EXTPROC_DLLS=ONLY:/u01/app/oracle/ext_libs，写成ANY等于开后门
为什么现在几乎没人用 EXTPROC 了
它本质是给 90 年代 C 扩展留的接口，今天的问题都更复杂：要捕获命令输出？EXTPROC 只能靠临时文件中转，高并发下极易冲突；要调 Python/Shell？得先编译成 C wrapper；要审计调用链？RPC 连接是黑盒，日志只记“调了”，不记参数值。真正落地时，大家宁可改用 DBMS_CLOUD_FUNCTION 调 OCI 云函数，或在应用层用 C# / Java 做中间调度——把“外部”这件事从数据库内移出去，反而更可控、更可观测。
