背景:凌晨收到告警,数据库会话超标连接不上,其实对于压力比较大的数据库这是在正常不过的了,过几分钟就会恢复到正常值,可是半小时之后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进行扩容。
未完。。。。。
如有错误之处请指正..!!