循环使用带sysdate条件的游标触发ORA-01555错误排查

核心结论 #

• 循环使用的游标WHERE子句中写sysdate不会直接触发ORA-01555错误，网上流传的“逐行插入时sysdate动态变化导致快照过旧”属于错误认知。
• 你遇到的ORA-01555本质是Oracle读一致性机制下，长查询/长事务运行期间所需的UNDO回滚段数据被覆盖导致，和sysdate本身没有直接因果关系。

为什么游标里的sysdate不会动态改变结果集 #

Oracle显式游标在打开的瞬间，就会确定本次查询对应的SCN（系统变更号），后续所有Fetch取数操作，都严格基于这个开游标时刻的SCN做一致性读，不会因为执行过程中时间推移反复重算查询条件。
你写的add_months(trunc(sysdate)+0, 3)属于游标打开时就会完成计算的确定性值，筛选条件会在游标打开那一刻固定，不会在循环每取一条记录时重新读取sysdate更新筛选边界。
只有当你在循环内部反复打开、关闭游标重新执行查询时，sysdate才会每次取最新值，这种场景也不会触发ORA-01555，只是可能出现结果集变化的逻辑问题。

触发ORA-01555的真实根因 #

结合你贴的代码，问题出在以下几个点：

• 长周期逐行处理+内部提交导致UNDO被覆盖
  你循环调用的PACKAGE_POLICY_RENEWAL_REVIEW.INSERT_RENEW过程如果内部存在逐行COMMIT逻辑，会导致游标C_GET_DTL_POLIS读取POLICY_MAIN表依赖的旧版本UNDO数据被提前覆盖。游标需要全程基于打开时的快照读数据，一旦循环处理时间过长、中间频繁提交，UNDO段被其他事务复用覆盖需要的旧版本数据，就会抛出快照过旧错误。
  另外你游标定义里的and not exists子句是不完整的，缺少关联的子查询和关联条件，如果实际逻辑是关联renewal_review表做去重判断，缺失关联条件会导致判断逻辑变成低效的全表比对，进一步拉长游标执行时间，提升UNDO覆盖概率。
• 筛选条件对字段加函数导致全表扫描
  你写的筛选条件to_char(trunc(exp_date), 'yyyymm') = 目标值对exp_date字段做了函数转换，无法命中exp_date字段上的普通B树索引，会触发POLICY_MAIN全表扫描。表数据量越大，扫描时间越长，UNDO被覆盖的概率就越高。
• 代码语法错误放大异常概率
  你贴的代码存在多处语法问题：调用INSERT_RENEW过程时rec.end_no和p_status参数之间缺少逗号分隔、异常分支给P_ERROR_MESSAGE赋值后缺少分号，这些问题会导致过程执行异常，拉长事务运行时间。

修复方案 #

• 若要彻底消除sysdate计算时机的歧义，可以在存储过程声明段定义固定变量存储时间边界，游标直接引用变量即可，示例写法：

-- 声明段增加变量
V_TARGET_MONTH VARCHAR2(6);
--- BEGIN块开头固定赋值
V_TARGET_MONTH := to_char(add_months(trunc(sysdate), 3),'yyyymm');
-- 游标WHERE条件直接引用变量
where to_char(trunc(exp_date), 'yyyymm') = V_TARGET_MONTH

• 不要在循环调用的INSERT_RENEW过程中做逐行提交，等所有游标逻辑处理完成、日志表写入完成后再做统一提交，大幅缩短一致性读需要保留UNDO的时间窗口。
• 调整筛选条件写法，去掉字段上的函数使其可以命中索引，将to_char(trunc(exp_date), 'yyyymm') = 目标值改为范围查询：exp_date >= add_months(trunc(sysdate),3) and exp_date < add_months(trunc(sysdate),4)，这种写法可以直接用到exp_date字段上的普通索引，将大表查询时间从小时级压缩到秒级，从根源上避免长查询导致的UNDO覆盖问题。
• 补全游标中NOT EXISTS子句的关联逻辑，修复代码中缺失的逗号、分号等语法错误。

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