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


    编辑手记:在现实的生产环境中,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 ,大讲堂讲师课程资料


  • 相关阅读:
    分布式事务slides
    为什么jdk中把String类设计成final
    Struts 体系结构与工作原理 图
    在指定路径或者是文件名查找指定的字符串
    Apache Avro 与 Thrift 比较
    SSL请求trustStore的两种注册方式
    java中的split使用的是正则表达式
    所有ghost操作系统大全
    Tomcat帮助文档翻译 未完成
    ORACLE基本配置
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13312368.html
Copyright © 2020-2023  润新知