记一次活动会话暴涨事件

一、事件背景

某天下午上班时，产品突然问某个shema中午是否有异常，？？？这个大概是我当时脸上的表情，哪个数据库？中午是什么时间？什么是异常？在我的观念中，schema有什么异常难道不应该是产品的事情么，DBA的职责难道不是保障数据库正常稳定运行么，继续沟通一番，终于明确了产品的需求，应用中午有3台机器web线程池满了，想找我来看看在数据库层面有没有执行锁表、或者执行sql很慢等。

二、初步分析

第一直觉看数据库在中午有没有什么告警出来，然后再看实例保障，获取数据库中午的cpu、活动会话数等信息，发现在产品给的时间段里，数据库确实存在异常，活动会话突然之间冲到八九百，随后回落。查看两个节点的alert日志，对应时间段正常无报错。

三、继续分析

查询给定时间段活动会话信息：

SELECT snap_id,
       sample_time,
       Count (sample_time) cnt
FROM   dba_hist_active_sess_history
WHERE  sample_time BETWEEN To_date ('2019-06-14 11:55', 'yyyy-mm-dd hh24:mi') AND To_date ('2019-06-14 12:10', 'yyyy-mm-dd hh24:mi')
GROUP  BY snap_id,
          sample_time
HAVING Count(sample_time) > 300
ORDER  BY sample_time;

由查询结果可以获取到活动会话数随时间增长的具体信息，找出活动会话数最大的时刻进行分析，查看该时刻活动会话等待事件及sql信息：

SELECT event,
       sql_id,
       Count(event) cnt
FROM   DBA_HIST_ACTIVE_SESS_HISTORY
WHERE  sample_time = To_timestamp('2019-06-14 12:00:09.776', 'yyyy-mm-dd hh24:mi:ss.ff')
GROUP  BY event,
          sql_id
ORDER  BY cnt DESC;

至此，对问题原因有了个大概的了解，发现是因为用户在短时间内提交了大量的查询请求(50s提交了179条)导致数据库产生严重的GC，进一步导致活动会话数暴涨。