4月25日正好碰到类似问题需要诊断故将此文转到自己博客，转自Oracle Blog：

背景在很多情况下当数据库发生性能问题的时候，我们并没有机会来收集足够的诊断信息比如system state dump或者hang analyze，甚至问题发生的时候DBA根本不在场这给我们诊断问题带来很大的困难。那么在这种情况下我们是否能在事后收集一些信息来分析问题嘚原因呢？在Oracle 10G或者更高版本上***是肯定的。本文我们将介绍一种通过dba_hist_active_sess_history的数据来分析问题的一种方法

适用于Oracle 10G或更高版本，本文适用于任何平台

holder。下面通过一个例子来详细说明

1. Dump出问题期间的ASH数据：为了不影响生产系统，我们可以将问题大概期间的ASH数据export出来在测试机上汾析

2. 验证导出的ASH时间范围:为了加快速度，我们采用了并行查询另外建议采用Oracle SQL Developer来查询以防止输出结果折行不便于观察。

从以上输出可知該数据库共2个节点采样时间共2小时，节点1的采样比节点2要多很多问题可能发生在节点1上。

3. 确认问题发生的精确时间范围:参考如下脚本：

注意观察以上输出的每个采样点的active session的数量数量突然变多往往意味着问题发生了。从以上输出可以确定问题发生的精确时间在 22:03:21 ~ 22:04:42问题持續了大约1.5分钟。

注意: 观察以上的输出有无断档比如某些时间没有采样。

event并且注掉了采样时间以观察所有采样点的情况如果数据量较多，您也可以通过开启sample_time的注释来观察某个时间段的情况注意最后一列session_count指的是该采样点上的等待该event的session数量。

1) 再次确认以上输出有无断档是否有某些时间没有采样。
2) 注意那些session_state为ON CPU的输出比较ON CPU的进程个数与您的OS物理CPU的个数，如果接近或者超过物理CPU个数那么您还需要检查OS当时的CPU資源状况，比如OSWatcher/NMON等工具高的CPU Run Queue可能引发该问题，当然也可能是问题的结果需要结合OSWatcher和ASH的时间顺序来验证。

5. 观察每个采样点的等待链:

在RAC环境中每个节点的ASH采样的时间很多情况下并不是一致的，因此您可以通过将本SQL的第二段注释的sample_time稍作修改让不同节点相差1秒的采样时间可以仳较(注意最好也将partition by中的sample_time做相应修改)该输出中isleaf=1的都是最终holder，而iscycle=1的代表死锁了(也就是在同一个采样点中a等bb等c，而c又等a这种情况如果持续發生，那么尤其值得关注)采用如下查询能观察到阻塞链。

其他关于ASH的应用除了通过ASH数据来找holder以外我们还能用它来获取很多信息(基于数據库版本有所不同)：