oracle rac环境下序列跳号主因是nextval在pl/sql中预取、循环调用或异常分支重复调用，叠加rac节点缓存机制导致号段空缺；应将nextval仅用于最终dml语句内联调用，禁用变量赋值、批量预取及业务序列复用于日志，并调小cache、保持noorder。
oracle存储过程在rac环境下出现序列跳号，不是代码写错了，而是nextval调用方式撞上了rac的缓存机制——只要在pl/sql里提前取值、循环预取、或异常分支里又调了一次，跳号就几乎必然发生。
为什么存储过程里调NEXTVAL会跳号
存储过程本身不导致跳号，但常见写法会让序列值“被浪费”：事务回滚后已取的值不回收；循环中每次NEXTVAL都消耗一个号；异常处理块里再查一次NEXTVAL用于日志，主流程失败后这个号也丢了。RAC下更危险：不同节点各自缓存号段（比如A缓1–20、B缓21–40），若过程在节点A执行一半失败，切换到B重试，就可能从21开始，中间号段永远空缺。
- 在
FORALL前用SELECT seq.NEXTVAL BULK COLLECT INTO预生成ID数组：数组长度为100，哪怕只成功插入10条，也已消耗100个号 - 把
seq.NEXTVAL赋给变量后再插入：l_id := seq.NEXTVAL;→ 若后续INSERT失败回滚，l_id已不可逆地消耗 - 在
EXCEPTION块里写INSERT INTO log_table VALUES (seq.NEXTVAL, 'err');：主事务失败+日志记录再跳一个
怎么改存储过程才能减少跳号
核心原则：让NEXTVAL只出现在最终生效的DML语句中，不落地为变量，不跨事务使用。
- 直接在
INSERT语句里内联调用：INSERT INTO t(id, name) VALUES (seq.NEXTVAL, 'x');，避免先赋值再插入 - 批量插入时，用
INSERT ... SELECT seq.NEXTVAL FROM ...构造源数据，而不是先BULK COLLECT再循环INSERT - 日志记录改用
CURRVAL（如果当前会话已取过）或单独序列（如log_seq.NEXTVAL），绝不复用业务序列 - 禁用所有“测试性”调用：删掉存储过程开头或调试段里的
SELECT seq.NEXTVAL FROM DUAL;
RAC下必须检查的序列属性
即使存储过程写对了，底层序列配置不当也会放大跳号影响。重点看三处：
-
CACHE值是否过大：查DBA_SEQUENCES.cache_size，若设为100且RAC节点频繁重启，单次丢失就是百位跳号；建议压到20或10（非关键序列） - 是否误启
ORDER：RAC中ORDER强制全局串行，高并发下enq: SQ - contention飙升，反而引发超时和重试跳号；99%场景应保持默认NOORDER - 是否被
FLUSH SHARED_POOL波及：查V$ROWCACHE中parameter = 'dc_sequences'的getmisses陡增，说明序列对象正被频繁淘汰
跳号已发生，存储过程还要继续跑吗
要。跳号不影响主键唯一性、不破坏约束、不导致数据错乱——它只是数字不连续。真正危险的是应用层把“ID连续”当逻辑前提（比如用ID差值算批次大小、或前端靠ID递增做排序）。这类依赖必须剥离：用ROW_NUMBER() OVER (ORDER BY create_time)生成展示序号，物理ID只做索引和关联用。监控上盯住DBA_SEQUENCES.last_number与实际表最大ID的差值，若差值稳定在CACHE值附近，说明机制正常；若突增数百，立刻查RAC节点状态和共享池刷新记录。
