微信号:OraNews

介绍:分享数据库技术、新闻与信息,尤其是和Oracle数据库相关的内容,文章内容来自原创、专栏作者投稿或读者投稿.

实战课堂:一则CPU 100%的故障分析处理知识和警示

2018-05-20 23:59 墨墨

编辑手记:在现实的生产环境中,DBA可能遭遇到各种各样的异常,或简单、或复杂,但是无一不考验DBA的经验和能力,在『实战课堂』栏目中,我们将整理和分享来自云和恩墨一线的各种案例,以其帮助走在DBA道路上的朋友,积累经验,扩展知识。


案情描述:

  1. 11点20分,DBA接到CPU告警短信,业务数据库2节点CPU使用率达到100%;

  2. 11点22分,DBA登陆业务数据库进行核查,发现数据库两个节点CPU使用率达到100%,并且有library cache lock以及大量cursor: pin S wait on X异常等待事件,数据库执行查询缓慢并时常出现挂起的情况。应用人员反馈语句缓慢,事务有积压;

  3. 11点24分,DBA对业务数据库两个节点执行hang analyze信息收集。


注意,当我们遭遇到这种情况时,DBA 在处理中的通常过程就是:

首先通过 v$session 、v$session_wait、v$lock 去确定当前数据库的等待情况,锁信息等;

如果数据库能够响应,通过ASH报告,可以获取更直观的输出,看看阻塞的情况和情形,然后进行下一步的判断;

如果数据库失去响应,或者响应困难,则可以通过 Hang Analyze 进行信息采集,以便后续分析;


关于数据库挂起的诊断跟踪,参考我们之前的文章:DBA必备技能:数据库挂起时进行转储分析诊断案例


案情继续:

  1. 11点30分,由于数据库严重挂起,进程积压严重,告知相关部门后,为了尽快恢复业务,重启数据库。

  2. 11点35分,数据库重启完毕,CPU资源得到释放,应用恢复正常。


在实践中,有时候排查问题可能要遗留到事后,在当时为了尽快恢复业务,用户就采取了重启数据库的方式。


现在是DBA需要找出原因,防范后续问题的时间了。很多情况下,专业DBA是在这一阶段出场,需要找出Root Cause,并且给出防范解决方案。


首先通过ASH记录的信息,可以发现,从11月10日11点10分40秒左右,开始出现libaray cache lock以及cursor: pin S wait on X等待事件,这不一定意味着问题,正常解析也会出现

从11点10分46秒开始,等待cursor: pin S wait on X等待事件的会话越来越多:


这些等待cursor: pin S wait on X的会话都被三个会话阻塞(实例1上sid为7530的会话,实例1上sid 11124的会话,实例1上sid为3802的会话)。


而上述三个会话等待事件为libarary cache lock, 同时被实例1上sid为13906的会话阻塞。

而实例1上sid为13906的会话是从portal_sso2主机上以UNIRECHARGE用户登陆门户库,并在11点10分38秒的时候,开始执行alter  table的操作,但是语句一直没有执行完:

通过结合hang analzye收集到的信息分析:


该会话执行的alter table语句为:

alter table T_ZT_ORDER add history_record char(1) default ‘0’;


综合上述分析,造成数据库CPU高消耗的主要原因是由于开发人员,在生产高峰时段执行了DDL 语句:“Alter table T_ZT_ORDER add history_record char(1) default ‘0’”而引发的。


事实上,自从Oracle 11g开始,当我们在表上增加具有缺省值的新字段时,Oracle首先修改数据字典,并不会直接更新所有数据,以减少锁定。元数据的设置在 ecol$ 中:

insert into ecol$(tabobj#, colnum, binarydefval, guard_id)           values (:1, :2, :3, :4)

update ecol$ set binaryDefVal = :3 where tabobj# = :1 and           colnum = :2


关于这些内容,请参考以下文章:

空与非空 - 数据库中也有薛定谔的猫?

书接上文:薛定谔的猫是如何诞生的?


由于增加字段会导致表结构的变化,统计信息会被清除:

delete from tab_stats$ where obj#=:1

SQL 需要重新解析,就需要在表上获得 Library cache lock ,这个锁定无法获得,数据库产生阻塞。


在这个案例中,DDL操作在繁忙时段没有及时完成,阻塞了2139个会话,就导致了一次数据库事故。


那么如何防范问题呢?不以规矩,不成方圆,后续改进措施建议:

1). 建议开发人员按照操作规范,在进行DDL语句操作前进行相关备案,并且不要在繁忙时段在生产环境执行DDL操作;

2). 建议DBA加强对开发此类DDL操作进行监控。


这就是来自生产的一次故障处理和排查,通过这样的过程,我们能够看到,在生产环境中一次小的操作,就可能导致严重的生产故障,一个DDL都不应该草率执行。


多看多知,这就是实战课堂。



资源下载

关注公众号:数据和云(OraNews)回复关键字获取

2018DTCC , 数据库大会PPT

2017DTC,2017 DTC 大会 PPT

DBALIFE ,“DBA 的一天”海报

DBA04 ,DBA 手记4 电子书

122ARCH ,Oracle 12.2体系结构图

2017OOW ,Oracle OpenWorld 资料

PRELECTION ,大讲堂讲师课程资料


 
数据和云 更多文章 杨廷琨Oracle Code大会分享:如何编写高效SQL(含PPT) 数据科学:Oracle 并购 DataScience 公司提升机器学习能力 开源NewSQL – CockroachDB在百度内部的应用与实践 走向云端:Oracle SQL Developer Web 即将上线! 经典分享:一份高达555页的技术PPT会是什么样子?
猜您喜欢 【双色系】在产品设计的配色中,一白也能遮百丑! 我都懒得了解2018的设计趋势,因为老板肯定看不上? 3分钟看完Build2016 Day 1 Keynote SEO:为什么百度只收录网站首页不收录内页? 全新解读Twitter、Facebook和LinkedIn业务模型与架构