问题描述
20231127上午客户反馈绩效系统20231125、20231126出现2次YAS-02020 snapshot too old的问题，测试也有类似问题。
该过程是客户新增的存储过程，目的是通过PRO_RUN_JOB作为主控，调度其他存储过程，后续不用其他调度引擎。
原因分析
错误信息收集分析
分析存储过程报错日志，核查UNDO_RETENTION、undo表空间
看了相应的优化建议，可以增大参数UNDO_RETENTION的值，或者使用更大的undo表空间。
客户环境目前UNDO_RETENTION配置了600，该参数单位是秒。临时修改客户测试环境的配置为3000，试图规避问题。
正常理解，MVCC用于高并发的情形，会出现该错误，而该存储过程执行是串行的，不符合预期！需要继续分析。
UNDO、MVCC机制分析
了解背后机制，snapshot too old是由于db需要做多版本控制（mvcc），在数据commit之后，仍然会保留undo一段时间，在超过这段时间之后undo的空间会被复用，如果需要还原的数据超过了这个时间，则还原不了，触发该错误。
崖山db快照隔离级别的核心就是MVCC（Multi-Version Concurrency Control）,多版本并发控制
快照本质上就是一个时间点。记录版本的时间点为事务提交的时间点。
可见性可分为2类情况：
1、事务内的语句可见性
2、事务间的可见性
由于老版本保留时间的限制，我们可能无法读取到某些很老的版本，这时就会有snapshot too old错误。
事务功能梳理 - YashanDB
可以确认：
不同事务间，特别是长查询，容易出现该问题；
另一个是专门的快照读，如Oracle的快照读select count(*) from tableA as of timestamp to_timestamp('2013-10-16 08:46:57','yyyy-mm-dd hh24:mi:ss');
疑点一
分析测试环境出现过类似的问题，看到报错的时间点：
2023/11/23 13:21:52执行的是PRO_DAILY_DPSIT
2023/11/23 12:04:00执行的是PRO_SYS_USER_POST_REL
有个共同点：
PRO_SYS_USER_POST_REL用的是merge，同时读和写同个表
PRO_DAILY_DPSIT用的是insert into select，insert 和select的表有相同的
开始怀疑这里有并发机制，读写自同个表，但是作为同个事务内的，undo不应该被释放掉，不符合预期！
确认问题
剩下的就是长查询的可能。只有在查询的时候才会报这个错误，update的时候是不会报这个错误的。
继续分析游标loop的结果，如果在游标读取的时候报错，则remark也是：更新跑数任务明细表：单个任务成功结束的相关信息
fetch在一开始就拿到scn（SCN即系统改变号（System Change Number）），每次fetch都用的open时的scn，由于loop过程中还是update RUN_JOB_DETA表更新了db存储的某一个block，commit之后undo的数据会保留undo_retention的时间，当超过这个时间undo的空间会别其他任务复用。
而一个block不止一条数据，在后续loop的过程，如果继续读取到这个block的数据，需要对这个block还原到scn对应的状态再读取，由于undo已经被复用，就会报snapshot too old的错误。
undo机制、MVCC机制，在Oracle、DB2中都是有的，该问题也会存在。崖山的数据块不会存2个表的数据，可以使用下面方法规避：
PRO_RUN_JOB这个存储过程使用游标读取RUN_JOB_DETA表做为配置表，loop过程中需要更新的结果数据放到历史表（主要更新任务状态，开始、结束时间，耗时），配置表和历史结果分开存储，彻底解决问题。
经验教训
Undo机制中，undo_retention是一个不容易理解的参数项。设置之后，Oracle会根据自动undo管理的原则进行调节，进行空间拓展，来适应实现用户的期间要求。而崖山db需要根据实际的业务频繁度和数量量、以及undo表空间设置情况进行综合评估。
存储过程存在游标遍历，需要注意更新目标表不是fetch的表，否则存在类似问题。
