Pro*C 报 ORA-01001 invalid cursor？用伪代码拆解无效游标排查路径

1. Pro*C 里 ORA-01001 invalid cursor 到底在报什么先说结论ORA-01001: invalid cursor不是数据库连不上也不是 SQL 写错了而是你手里的游标句柄在“用的时候已经失效了”。在 Pro*C 嵌入式 SQL 里这个错误几乎都指向同一类问题——游标生命周期错位该 OPEN 的时候没 OPEN该 PREPARE 的时候被 COMMIT 顺手关掉了或者 CLOSE 之后又拿去 FETCH。我先把概念对齐一下方便后面看伪代码。Pro*C 里的“游标”分两种一种是显式游标你写EXEC SQL DECLARE ... CURSOR FOR ...然后OPEN / FETCH / CLOSE另一种是隐式语句游标你写EXEC SQL EXECUTE S或EXEC SQL PREPARE S FROM :dynstmt时预编译器在背后帮你维护一个 statement cursor。ORA-01001 在两种游标上都会出现但触发路径不太一样。为什么它难查因为报错行号经常指向EXEC SQL EXECUTE或EXEC SQL FETCH但真正的原因在几行之前的COMMIT、ROLLBACK或者编译选项CLOSE_ON_COMMIT、RELEASE_CURSOR、HOLD_CURSOR的组合。你盯着报错那行改怎么改都不对因为游标是在别处被“悄悄回收”的。这篇适合谁看正在做 Pro*C 老代码重构、把写死的 SQL 改成预编译动态语句、遇到批量提交后游标失效、或者被CLOSE_ON_COMMIT默认值坑过的同学。我会用可复制的伪代码把四种典型触发场景拆开每条都给出验证动作和修复方式最后说下怎么用统一的 Key/API 通道把报错上下文整理清楚方便排查和归档。核心检索词先记住Pro*C、ORA-01001、invalid cursor、游标生命周期、伪代码排查。下面所有例子都围绕这几个词展开你可以直接对着自己的.pc文件比对。2. 用伪代码复现四种游标失效路径这一节是重点我把 excerpt 里提到的四种编译选项组合用最小伪代码重写一遍每条都能单独编译验证。你不需要完整业务代码只要一个dual表就能跑通。先给一个公共骨架后面四种情况只改编译选项和循环结构/* demo.pc 公共骨架 */ #include stdio.h #include string.h EXEC SQL INCLUDE sqlca; int main() { char dynstmt[256]; int i; EXEC SQL BEGIN DECLARE SECTION; char *dn orcl; EXEC SQL END DECLARE SECTION; EXEC SQL CONNECT :uid IDENTIFIED BY :pwd AT :dn; sprintf(dynstmt, select test from dual); EXEC SQL AT :dn DECLARE S STATEMENT; EXEC SQL AT :dn PREPARE S FROM :dynstmt; for (i 0; i 2; i) { EXEC SQL AT :dn EXECUTE S; printf(execute %d sqlcode%d\n, i, sqlca.sqlcode); } EXEC SQL AT :dn COMMIT WORK; EXEC SQL AT :dn EXECUTE S; /* 关键观察点 */ printf(after commit sqlcode%d\n, sqlca.sqlcode); return 0; }2.1 场景一CLOSE_ON_COMMITYES 批量提交后复用编译命令proc demo.pc close_on_commityes release_cursorno现象第一次循环两次EXECUTE都成功COMMIT WORK之后第三次EXECUTE报sqlcode-1001也就是 ORA-01001。原因很直接CLOSE_ON_COMMITYES时COMMIT 会关闭所有游标包括 statement cursor。你后面再EXECUTE S这个 S 已经不存在了。修复方式有两种。第一种是在 COMMIT 之后重新 PREPAREEXEC SQL AT :dn COMMIT WORK; EXEC SQL AT :dn PREPARE S FROM :dynstmt; /* 重新绑定 */ EXEC SQL AT :dn EXECUTE S;第二种是把 PREPARE 放进循环每次执行前都重新准备。这也是 excerpt 里提到的“懒惰但有效”的做法。2.2 场景二RELEASE_CURSORYES 单条执行即释放编译命令proc demo.pc close_on_commitno release_cursoryes现象循环里第一次EXECUTE成功第二次就报 ORA-01001。因为RELEASE_CURSORYES会在语句执行后立即释放游标连 COMMIT 都不用等。你循环里复用同一个 S第二次自然找不到。修复每次执行前重新 PREPARE或者把RELEASE_CURSOR改回 NO。如果业务是高频单条执行建议保留 RELEASE_CURSORNO用 HOLD_CURSOR 控制缓存。2.3 场景三HOLD_CURSORNO 游标缓存被重用编译命令proc demo.pc close_on_commitno release_cursorno hold_cursorno现象这个组合下语句执行且游标关闭后预编译器会把游标缓存实体标记为“可重用”。如果中间有别的 SQL 语句抢占了这块缓存你原来的 S 就指向了别人的私有 SQL 区再执行就报 ORA-01001。单独跑上面的骨架可能不报错因为没别的语句来抢但真实业务里穿插了其他 SQL问题就出来了。验证动作在两次EXECUTE S之间插一条无关的EXEC SQL SELECT ... FROM dual观察是否触发。修复方式是给频繁复用的语句设HOLD_CURSORYES或者每次执行前重新 PREPARE。2.4 场景四HOLD_CURSORYES 维持连接编译命令proc demo.pc close_on_commitno release_cursorno hold_cursoryes现象游标连接被维持预编译器不重用频繁执行时不需要重新解析速度最快也不会报 ORA-01001。代价是每个维持的游标都占一个私有 SQL 区MAXOPENCURSORS要相应调大否则会撞上OPEN_CURSORS上限。这四种情况对照下来规律很清楚只要游标在“你还想用”的时候被关闭或回收就会 ORA-01001。排查时先确认编译选项再看代码里 COMMIT/ROLLBACK 的位置最后看是否有其他语句抢占缓存。3. 可复制的编译配置与 settings 片段这一节给你可以直接抄的配置。Pro*C 的选项有三个来源命令行、用户配置文件pcscfg.cfg、代码内联EXEC ORACLE OPTION。优先级是内联 命令行 配置文件排查时一定要确认最终生效值。先看命令行方式适合临时验证# 场景一提交即关游标 proc demo.pc close_on_commityes release_cursorno hold_cursorno # 场景二执行即释放 proc demo.pc close_on_commitno release_cursoryes # 场景三缓存可重用默认 proc demo.pc close_on_commitno release_cursorno hold_cursorno # 场景四维持游标高频复用 proc demo.pc close_on_commitno release_cursorno hold_cursoryes maxopencursors50再看用户配置文件pcscfg.cfg路径通常在$ORACLE_HOME/precomp/admin/pcscfg.cfg内容形如sys_include($ORACLE_HOME/precomp/public,/usr/include) include$ORACLE_HOME/precomp/public close_on_commitno release_cursorno hold_cursoryes maxopencursors50 modeoracle注意MODE和CLOSE_ON_COMMIT的联动如果你在配置文件里写MODEANSI且CLOSE_ON_COMMITNOCOMMIT 后游标不关如果配置文件写MODEORACLE而命令行加CLOSE_ON_COMMITYES游标会关。这个组合最容易踩坑因为两个文件各写一半看代码根本看不出来。代码内联方式适合局部覆盖比如只在某个函数里改EXEC SQL EXECUTE BEGIN EXEC ORACLE OPTION (RELEASE_CURSORyes); END; END-EXEC;不过内联选项作用域有限且容易和全局配置打架建议只在明确知道影响范围时用。日常排查我更推荐把最终生效的选项打印出来或者用proc的-v之类参数确认。关于MAXOPENCURSORS默认值是 10它决定预编译器尝试缓存的并发打开游标数。经验公式是MAXOPENCURSORS 6 OPEN_CURSORS那 6 个是 Oracle 数据字典处理语句要用的开销游标。如果你把HOLD_CURSORYES且业务并发高MAXOPENCURSORS设 45 到 50 不罕见但每个游标都要占用户进程内存里的私有 SQL 区别盲目调大。如果你在整理这些配置和报错上下文时想找个统一入口可以用 TaoToken 的 API 通道把日志和配置片段归到一起方便对照。接入地址是https://taotoken.net/apiKey 在控制台生成模型 ID 按你实际用的填。这样排查时不用在多个终端之间来回切。4. 验证请求与成功结果对照配置改完必须验证不然你不知道是修好了还是碰巧没触发。这一节给你一套可复制的验证动作每条都对应一个明确的成功标志。第一步确认编译选项真的生效。在代码里加一行打印或者用proc的选项回显。最直接的办法是在EXEC SQL CONNECT之后立刻执行一条探测语句看sqlca.sqlcodeEXEC SQL AT :dn PREPARE S FROM :dynstmt; EXEC SQL AT :dn EXECUTE S; printf(probe sqlcode%d\n, sqlca.sqlcode); /* 期望 0 */第二步构造“提交后复用”的验证。把 COMMIT 放在两次 EXECUTE 中间观察第三次的 sqlcodeEXEC SQL AT :dn EXECUTE S; EXEC SQL AT :dn COMMIT WORK; EXEC SQL AT :dn PREPARE S FROM :dynstmt; /* 修复动作 */ EXEC SQL AT :dn EXECUTE S; printf(after fix sqlcode%d\n, sqlca.sqlcode); /* 期望 0 */如果修复前是 -1001修复后是 0说明 PREPARE 补位生效。如果还是 -1001检查是不是RELEASE_CURSORYES在作怪因为它在每次执行后都释放光在 COMMIT 后补 PREPARE 不够。第三步验证 HOLD_CURSOR 的效果。用同一个 S 连续执行 100 次统计耗时和 sqlcodefor (i 0; i 100; i) { EXEC SQL AT :dn EXECUTE S; if (sqlca.sqlcode ! 0) { printf(fail at %d code%d\n, i, sqlca.sqlcode); break; } } printf(loop done, last code%d\n, sqlca.sqlcode);HOLD_CURSORYES时应该 100 次全 0且耗时明显低于每次重新 PREPARE。HOLD_CURSORNO时如果中间没有其他语句抢占也可能全 0所以这个验证要配合“插入干扰语句”才有区分度。第四步检查OPEN_CURSORS是否够用。在数据库侧执行show parameter open_cursors;然后对照你的MAXOPENCURSORS确保MAXOPENCURSORS 6 OPEN_CURSORS。如果业务里还有 PL/SQL 父游标、子游标余量要留更大。成功结果的判断标准很简单所有EXECUTE和FETCH的sqlcode都是 0循环跑完不中断COMMIT 后复用不报 -1001。如果某一步 sqlcode 非 0先看是不是 -1001再看是不是 -1403no data found这个不是游标失效别混为一谈。5. 本篇常见报错排查对照这一节把真实会撞到的报错列出来对照着查。每条都给出触发条件和处理动作。ORA-01001: invalid cursorsqlcode-1001。最常见触发条件就是本文讲的四种游标失效路径。处理动作先确认编译选项再确认 COMMIT/ROLLBACK 位置最后确认是否有其他语句抢占缓存。如果代码里用了EXEC SQL CLOSE检查是不是 CLOSE 之后又 FETCH 或 EXECUTE。ORA-01002: fetch out of sequencesqlcode-1002。这个和 -1001 容易混。它通常出现在FOR UPDATE游标上COMMIT 之后继续 FETCH。处理动作COMMIT 后重新 OPEN 游标或者改用CLOSE_ON_COMMITNO且避免 FOR UPDATE 跨提交。ORA-01403: no data foundsqlcode-1403。这不是游标失效是查询没返回行。别把它当 -1001 修方向完全错了。处理动作检查 WHERE 条件或者用EXEC SQL WHENEVER NOT FOUND处理。local proxy failed这类报错通常出现在你通过某个中间层连数据库时和 Pro*C 本身无关。处理动作确认连接串、网络、认证信息别在游标代码里找原因。401 Unauthorized出现在你用 API 通道整理日志时。处理动作检查 Key 是否过期、Base URL 是否写对、Model ID 是否存在。这三件套缺一不可Base URL、Key、Model ID 要同时正确。reading choices类报错一般出现在解析模型返回时。处理动作确认返回格式别把非 JSON 当 JSON 解析。OAuth相关报错出现在用 OAuth 方式接入时。处理动作确认 token 有效期和 scope必要时重新授权。排查顺序建议先看 sqlcode 数值-1001 走本文路径-1002 走 FOR UPDATE 路径-1403 走数据路径。再看编译选项最后看代码结构。别一上来就改 SQL方向错了白费功夫。如果你用 Claude Code 或类似工具辅助排查记得把 Base URL、Key、Model ID 三件套配全缺一个都会报认证类错误。配置片段参考{ base_url: https://taotoken.net/api, api_key: 你的Key, model_id: 你实际使用的模型ID }6. 把游标生命周期管起来游标问题的根子不在 SQL在生命周期。我自己的做法是给每个 statement cursor 画一条时间线DECLARE、PREPARE、EXECUTE/FETCH、COMMIT/ROLLBACK、CLOSE每个节点标注谁会动它。COMMIT 和 ROLLBACK 是最容易被忽略的“游标杀手”尤其是CLOSE_ON_COMMITYES的时候。一个实用技巧把 PREPARE 封装成函数每次执行前调用虽然多一次解析开销但能彻底避免 -1001。高频语句再用HOLD_CURSORYES优化低频语句直接每次 PREPARE代码简单不易错。另一个技巧在 COMMIT 之后统一加一个“游标重建”步骤把所有活跃的 statement cursor 重新 PREPARE 一遍。这样即使编译选项变了代码逻辑也不受影响。最后把编译选项写进版本管理别让它散落在命令行和配置文件里。pcscfg.cfg和构建脚本一起提交排查时一眼能看到最终生效值。报错上下文用统一通道归档下次遇到同类问题直接搜关键词不用从头查。游标生命周期管住了ORA-01001 基本就绝迹了。剩下的就是 OPEN_CURSORS 容量和性能调优那是另一个话题。