Pro*C程序中子进程CLOSE CURSOR操作不生效的原因是什么？

1. 前置背景：fork对Oracle数据库连接的影响 #

你在父进程中执行EXEC SQL CONNECT后，Oracle客户端OCI层会和数据库服务端建立一个独占的有状态会话，会话的所有状态（包括游标句柄、事务上下文、网络连接信息）同时存储在客户端OCI进程内存、服务端会话内存两块区域。
调用fork()生成子进程时，子进程仅会复制父进程的用户态内存（拿到的是客户端OCI状态的副本），但父子进程共享同一个服务端会话ID、同一个网络连接，服务端始终认为只有一个客户端在和当前会话交互。

2. 为什么DECLARE/OPEN/FETCH可以正常执行 #

这三个操作都是单次的网络RPC请求：子进程复制得到的OCI内存中保留了完整的会话标识、网络端点信息，请求发往服务端后可以正常匹配到对应会话，服务端会按逻辑执行操作并返回结果，所以这几步不会报错。此时你OPEN的游标已经被标记为打开状态，存在于服务端的会话内存中。

3. 为什么CLOSE操作不生效，最终触发ORA-01000 #

核心是父子共享会话导致的状态不同步、资源无法正常回收：

• 父子进程共享同一网络连接，并发操作会导致请求冲突：你子进程发出的CLOSE游标请求可能因为和父进程的操作冲突，没有被服务端正确接收处理，服务端会话里的游标始终处于打开状态。
• 子进程退出不会触发服务端会话资源清理：子进程执行exit(0)只会释放自己进程的内存空间，服务端感知不到子进程退出，只会认为会话的所有者（父进程）还在运行，因此不会主动回收该会话下所有未关闭的游标资源。
• 你代码中存在额外的状态破坏逻辑：子进程中执行的EXEC SQL COMMIT WORK RELEASE会直接断开整个数据库连接，父进程持有的连接实际已经失效，后续fork出的子进程拿着失效的连接状态操作，会进一步导致服务端产生孤立会话、游标资源持续泄漏，累计超过数据库open_cursors参数阈值后就会触发ORA-01000错误。

Oracle官方也明确要求：fork生成的子进程不能直接复用父进程的OCI数据库连接，必须由子进程单独创建新连接，否则会出现各类不可预期的状态异常。 #

内容的提问来源于stack exchange，提问作者hyejoon jung