案情描述：
11点20分，DBA接到CPU告警短信，业务数据库2节点CPU使用率达到100%；
11点22分，DBA登陆业务数据库进行核查，发现数据库两个节点CPU使用率达到100%，并且有library cache lock以及大量cursor: pin S wait on X异常等待事件,数据库执行查询缓慢并时常出现挂起的情况。应用人员反馈语句缓慢，事务有积压；
11点24分，DBA对业务数据库两个节点执行hang analyze信息收集。
注意，当我们遭遇到这种情况时，DBA 在处理中的通常过程就是：
首先通过 v$session 、v$session_wait、v$lock 去确定当前数据库的等待情况，锁信息等；
如果数据库能够响应，通过ASH报告，可以获取更直观的输出，看看阻塞的情况和情形，然后进行下一步的判断；
如果数据库失去响应，或者响应困难，则可以通过 Hang Analyze 进行信息采集，以便后续分析；
关于数据库挂起的诊断跟踪，参考我们之前的文章：DBA必备技能：数据库挂起时进行转储分析诊断案例。
案情继续：
11点30分，由于数据库严重挂起，进程积压严重，告知相关部门后，为了尽快恢复业务，重启数据库。
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都不应该草率执行。
原文发布时间为：2018-05-20
本文作者：墨墨
