故障诊断：ASM莫名出现GC等待事件、ADG的MRP进程HANG住

我们的文章会在微信公众号Oracle恢复实录和博客网站同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

ASM环境中有GC的等待事件的案例很少，今天就为大家分享一个老的案例，分享这个案例的本质不是想看最后的解决方案和定位的BUG，而是想分享一下ASM实例中的异常等待事件的分析方法其实跟普通数据库里时一样的，仍然可以通过hanganalyze和systemstate来分析，接下来我们就一起看看这个案例
1，环境介绍

这里大概的描述一下版本，有点老，11.2.0.4.2的版本，现在很少能看见这样的版本了。

1. Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
2. With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
3. Data Mining and Real Application Testing options
4. ORACLE_HOME = /u01/oracle/product/11.2.0
5. System name:        AIX

复制代码

2，对ASM实例做HANGANALYZE与SYSTEMSTATE

这里对ASM实例做下面的操作不会生成很多的TRACE文件。

1. oradebug setmypid
2. oradebug unlimit
3. oradebug hanganalyze 3
4. oradebug dump systemstate 266

复制代码

3，KILL MRP进程

ASM环境中还运行着数据库备库，此时通过recover managed standby database cancel想取消日志前滚，但是不能正常取消，唯有手动KILL MRP进程。KILL后再执行RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT；日志前滚又恢复正常。
4，分析HANGANALYZE与SYSTEMSTATE日志

4.1  查看hanganalyze部分

[code]*** -03-31 20:09:59.453===============================================================================HANG ANALYSIS:  instances (db_name.oracle_sid): cdhtz_p780.cdhtz1  oradebug_node_dump_level: 3  os thread scheduling delay history: (sampling every 1.000000 secs)    0.000000 secs at [ 20:09:58 ]      NOTE: scheduling delay has not been sampled for 0.818740 secs    0.000000 secs from [ 20:09:54 - 20:09:59 ], 5 sec avg    0.000000 secs from [ 20:09:00 - 20:09:59 ], 1 min avg    0.000000 secs from [ 20:05:00 - 20:09:59 ], 5 min avg  vktm time drift history=============================================================================== Chains most likely to have caused the hang: [a] Chain 1 Signature: 'gc buffer busy release'