COMMIT 会关闭所有未显式声明为 FOR UPDATE 的显式游标；Oracle 提交事务时丢弃一致性读 SCN，导致后续 FETCH 报 ORA-01001，而 FOR UPDATE 游标仅释放锁、保持打开，REF CURSOR 不受影响但结果集可能失效。
COMMIT 会关闭所有未显式声明为 FOR UPDATE 的显式游标
Oracle 在执行 COMMIT 时，会隐式关闭当前事务中所有已打开但未加 FOR UPDATE 的显式游标。这不是 bug，而是 Oracle 的事务语义设计：事务提交后，结果集快照失效，游标持有的查询上下文（包括一致性读 SCN）被丢弃。
典型错误现象是：游标 OPEN 后执行了 COMMIT，再执行 FETCH 就报 ORA-01001: invalid cursor。
- 隐式游标（如
SELECT ... INTO）不受影响，因为它们生命周期只有一条语句 - 显式游标若带
FOR UPDATE，COMMIT后游标仍保持打开，但锁被释放，后续FETCH可继续（只是数据可能已变） -
REF CURSOR是指针类型，COMMIT不影响其有效性，但底层结果集是否还能取取决于它是否基于已提交的查询
子过程里误写 COMMIT 是最隐蔽的触发点
主存储过程调用子过程，子过程内部写了 COMMIT，而主过程还在用游标遍历数据——这时游标已在子过程提交时被关闭，主过程后续 FETCH 必然失败。
这种问题难定位，因为错误堆栈通常只显示在主过程的 FETCH 行，但根源在子过程中。
- 检查所有被调用的子过程、函数，确认没有
COMMIT或ROLLBACK - 避免在业务逻辑层做提交，把事务控制权收归顶层过程（即“一个入口，一次提交”）
- 若子过程必须独立提交（如日志记录），改用
PRAGMA AUTONOMOUS_TRANSACTION隔离事务上下文
批量处理中边循环边 COMMIT 加剧游标失效风险
常见反模式：FOR i IN 1..1000 LOOP SELECT ... BULK COLLECT INTO ...; COMMIT; END LOOP;。每次 COMMIT 都会关闭上一轮打开的游标，下一轮重新 OPEN 虽能绕过报错，但带来严重副作用：
- 重复解析 SQL，消耗大量
shared pool和 CPU - 每轮都触发 redo 写入和日志切换，I/O 压力陡增
- 无法对整个批次做原子性回滚：第 500 次出错，前 499 次已提交，数据不一致
- 若游标定义含
ORDER BY且未加FOR UPDATE，两次OPEN可能因并发 DML 导致结果集错位
如何安全地在游标处理中做分批提交
真正需要分批提交（防锁表、控内存、限事务时长）时，应避免在游标循环体内 COMMIT，改用基于结果集切片的显式分页 + 外层事务控制。
例如：用 ROW_NUMBER() 分页更新，每批在一个事务内完成，游标仅用于驱动分页逻辑，不承载 DML 数据流：
DECLARE
v_offset INTEGER := 0;
v_batch_size CONSTANT INTEGER := 1000;
BEGIN
LOOP
UPDATE /*+ INDEX(t idx_status) */ your_table t
SET status = 'processed'
WHERE id IN (
SELECT id FROM (
SELECT id, ROW_NUMBER() OVER (ORDER BY id) rn
FROM your_table WHERE status = 'pending'
) WHERE rn BETWEEN v_offset + 1 AND v_offset + v_batch_size
);
EXIT WHEN SQL%ROWCOUNT = 0;
COMMIT;
v_offset := v_offset + v_batch_size;
END LOOP;
END;
关键点：这里没用游标取数据，而是用子查询分页驱动更新；COMMIT 发生在每批更新之后，不干扰任何游标生命周期。
真正难缠的，是那些把游标当“数据管道”又在中途塞 COMMIT 的老代码——它不会立刻报错，但会在高并发或数据倾斜时突然崩出 ORA-01001，而且很难从调用链里一眼揪出那个偷偷提交的子过程。
