序列设计之enq SQ - contention处理一则

最新推荐文章于 2024-08-22 14:19:23 发布

24号信仰

最新推荐文章于 2024-08-22 14:19:23 发布

阅读量2.3k

点赞数 1

CC 4.0 BY-SA版权

分类专栏：【SQL TUNING】【对象设计】 24号信仰の优化专栏文章标签： enq SQ - contention 序列 cache 序列等待事件序列cache

本文链接：https://blog.youkuaiyun.com/Skybig1988/article/details/72867033

本文分析了enq: SQ – contention等待事件，指出该问题是由于序列缓存值过小导致的并发插入序列时的锁争用。通过收集AWR和ASH数据，定位到问题SQL，并提出解决方案，即增大序列的cache值以减少锁冲突。同时强调了数据库对象设计的重要性，推荐使用SQL_FILTER工具进行SQL和数据库对象设计的审核，预防潜在的性能问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

某系统负责人反应系统很慢，收集持续报警短信。
查看数据库当前活动回话等待事件为enq: SQ – contention，当前活动session 200+
enq: SQ – contention是sequence相关的锁，在内存上缓存(cache)范围内，调用sequence.nextval期间拥有此锁。
如果创建sequence时，cache值太小（默认是20（单位是“个”）），在调用sequence.nextval，内存事先cache值会很快耗尽。这时需要将数据字典信息物理修改，再次执行cache的工作。
在此期间。SQL会一直拥有SQ锁，许多会话同时为了获取SQ锁而发生争用。对应的等待事件就是enq: SQ – contention。随着session的增长等待时间也会一直持续

其实到这里我们基本上可以定位问题，当然解决问题还是需要按部就班

收集对应时间段的awr和ash如下：

ASH:

通过ASH可以定位到产生这个等待事件的SQL如下：

insert into  t_ttt_pppppppddddinfo valus
  (OPERDATE,
   OPERSERIALNO,
   CHANNELCODE,
   SUBCHANNELCODE,
   CHANNELDATE,
   CHANNELSERNO,
   AGENTDATE,
   AGENTSERIALNO,
   PROLEVEL,
   PRO