sequence 跳号 或许你也遇到过

业务系统反馈系统 序列sequence  不连续 ，第二天就会出现sequence 跳号 sequence设置如下

 

由于sequence 是实例级业务中设置了order，人为操作 如（异常关库，获取序列时回滚、中断事务、刷新共享池均会到时cache 清空）

逐步排查sequence 使用情况 及数据库重启时间 

业务中除主键使用外，无其他用法

数据库启动时间外 也存在跳号问题，范围逐步缩小到系统收集统计信息

通过对exec dbms_stats.gather_database_stats_job_proc; 做10046跟踪

发现关键步骤 （对seq$表做更新操作）

PARSING IN CURSOR #650744768 len=102 dep=2 uid=0 oct=3 lid=0 tim=402539565368 hv=3967354608 ad='7ff8ac5ed278' sqlid='axmdf8vq7k1rh'
select increment$,minvalue,maxvalue,cycle#,order$,cache,highwater,audit$,flags from seq$ where obj#=:1
END OF STMT
PARSE #650744768:c=0,e=384,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=4,plh=0,tim=402539565367
BINDS #650744768:
 Bind#0
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=00 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=26ea0910  bln=22  avl=03  flg=05
  value=291
EXEC #650744768:c=0,e=981,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=4,plh=2203911306,tim=402539566429
FETCH #650744768:c=0,e=18,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,plh=2203911306,tim=402539566466
STAT #650744768 id=1 cnt=1 pid=0 pos=1 obj=74 op='TABLE ACCESS BY INDEX ROWID SEQ$ (cr=3 pr=0 pw=0 time=19 us cost=2 size=72 card=1)'
STAT #650744768 id=2 cnt=1 pid=1 pos=1 obj=79 op='INDEX UNIQUE SCAN I_SEQ1 (cr=2 pr=0 pw=0 time=10 us cost=1 size=0 card=1)'
CLOSE #650744768:c=0,e=2,dep=2,type=3,tim=402539566550
=====================
PARSING IN CURSOR #654115448 len=37 dep=1 uid=0 oct=3 lid=0 tim=402539567020 hv=2907401737 ad='7ff8ab75aae8' sqlid='1dubbbfqnqvh9'
SELECT ORA_TQ_BASE$.NEXTVAL FROM DUAL
END OF STMT
PARSE #654115448:c=0,e=2759,p=0,cr=7,cu=0,mis=1,r=0,dep=1,og=1,plh=1161457970,tim=402539567019
EXEC #654115448:c=0,e=35,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=1161457970,tim=402539567112
BINDS #650744768:
 Bind#0
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=00 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=232936f8  bln=22  avl=03  flg=05
  value=291
EXEC #650744768:c=0,e=67,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,plh=2203911306,tim=402539567244
FETCH #650744768:c=0,e=15,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,plh=2203911306,tim=402539567273
CLOSE #650744768:c=0,e=1,dep=2,type=3,tim=402539567305
=====================
PARSING IN CURSOR #589902568 len=129 dep=2 uid=0 oct=6 lid=0 tim=402539567781 hv=2635489469 ad='7ff8ac219918' sqlid='4m7m0t6fjcs5x'
update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:1
END OF STMT
PARSE #589902568:c=0,e=441,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=4,plh=0,tim=402539567780
BINDS #589902568:
 Bind#0
  oacdty=02 mxl=22(02) mxlc=00 mal=00 scl=00 pre=00
  oacflg=10 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=a6565a28  bln=22  avl=02  flg=09
  value=1
 Bind#1
  oacdty=02 mxl=22(02) mxlc=00 mal=00 scl=00 pre=00
  oacflg=10 fl2=0001 frm=00 csi=00 siz=24 off=0

 

我们知道 sequence 增长 是对seq$做 更改保存，统计信息中存在对seq$的操作导致序列异常

解决方案 

 1 手工对必要对象收集统计信息，避免全库收集

 2 设置nocache 避免cache存储丢失 ，业务频繁会导致 行锁等待 （不建议）

 

....................如有更好方案再做更新