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