数据库版本:11.2.0.4 RAC
(1)问题现象
从EM里面可以看到,在23号早上8:45~8:55时,数据库等待会话暴增,大约到了80个会话。通过查看EM的sql信息,发现等待产生于sql语句
select TIMEKEYID.nextval from dual@H_403_13@
(二)问题追踪
获取AWR报告观察,在TOP事件中,排名第二的enq:SV-contention
再去查看AWR报告,发现该语句执行频率非常的高,在8:00~9:00期间执行了51万多次。
从执行的语句可以看出,使用到的数据库对象是一个sequence,查询可看到该sequence的语法:
(1)定位哪些程序执行该sql
(2)定位该语句的执行频率
(3)再把时间扩长一些,查看最近4天的该sql捕获记录,发现其它时间段该sequence的使用并不是如此频繁,真正出问题是在大约23日8:49
至此可以得出结论:
程序BidmMES在早上8:49产生了大量的“select TIMEKEYID.nextval from dual”语句,导致缓存的100个sequcence快速使用完,缓存使用完后,数据库实例会为其分配新的缓存,异常就发生在分配缓存的时候,Oracle会更新sequence的字典信息,频繁的数据字典更新会导致要使用该sequence的session产生enq:SV-contention等待。
(三)解决方案
如果确认业务没问题,那么需要修改序列的最大值为9999和cache值为1000
另外,需要考虑,业务上是采用3位的sequence来与其它字符做连接,如果需要保持业务一致,需要截取数字。
(四)案例重现
(1)创建sequence
(2)创建一个plsql来消耗seq_test
(4)通过修改cache来查看等待
alter sequence b7dba.seq_test cache {cache数量};
(4.1)no cacahe