row cache lock 引起的会话超标

背景：凌晨收到告警，数据库会话超标连接不上，其实对于压力比较大的数据库这是在正常不过的了，过几分钟就会恢复到正常值，可是半小时之后ogg复制进程告警，多个复制进程先后异常关闭，同事呗半夜“揪起来”处理故障，数据库是open状态，没有管数据库的会话超标，首先是先把ogg复制进程启动起来，dba同事真的很辛苦。。

第二天分析故障点，会话过多引起的数据库连接不上告警是出现在3：04，但其实上在这之前数据库已经连接不上了，告警滞后。

从db_time中不难发现，这个时间段平均等待时间是547.3，要知道数据库CPU是32核的，，这不合理，那么是什么原因导致avg_db_time 过大呢？

从TOP 5中不难发现，等待时间比较长了是row cache lock 、latch: row cache objects和一个游标，为了验证这一现象又收集了那一时间段的ash报告。发现同样的等待事件

那究竟是什么原因导致这么多锁等待呢？

我们又发现这个时间段内数据库出现了大量的物理读和逻辑读，--继续寻找信息

ash报告中发现

从 io stats 和SQL statistics可以发现有大量的DML语句对这个表空间的一些表进行操作，导致产生了大量的行级锁，引发事物等待，会话堆积导致会话过多数据库连接不上。那么又是什么原因导致产生那么多行级锁呢？单单是大量的DML操作不会造成那么严重的锁等待，insert完成之后会自动释放锁的啊！怎么会有某一条DML不释放锁呢？

从ash中又发现历史会话p1、p2、p3的值

通过dba_hist_active_sess_history数据字典也可发现等待事件是row cache lock，p1值是3，

通过p1值可发现是回滚段争用

SQL> select parameter,gets,getmisses,MODIFICATIONS from v$rowcache where cache#=3;

PARAMETER                              GETS  GETMISSES MODIFICATIONS
-------------------------------- ---------- ---------- -------------
dc_rollback_segments             1086012315       5929         23983

而事后有查看UNDO的使用率

TABLESPACE_NAME                Total_undo(M) USED_UNDO(M) used_PCT(%)
------------------------------ ------------- ------------ -----------------------------------------
UNDOTBS1                              112640   83201.4375 73.86%

不是很高，不需要对UNDO进行扩容。

 

未完。。。。。

 

如有错误之处请指正..！！