转载

一个执行计划异常变更的案例 - 外传之ASH

之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执行计划异常变更的案例 - 外传之rolling invalidation》
《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》
《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》
《一个执行计划异常变更的案例 - 外传之AWR》

上篇文章介绍了AWR，他的默认采集周期是一小时，这一小时内对系统负载或性能产生持续性影响的会话、SQL、等待事件等的信息，AWR可以提供一个完整的镜像说明，但有时往往产生资源高消耗的就是一个或某几个会话，对于AWR，除非手工收集AWR，否则会有一小时的延迟，另外，如果我现在就需要查看系统中的负载，或查找性能最差的一条SQL，此时就需要另一种工具的支持，ASH，即Active Session History，顾名思义，他是基于session级别的统计信息收集工具，比AWR粒度更细。

ASH的信息以v$session为基础，每秒采集一次，较新的信息保存在v$active_session_history视图，历史数据保存在dba_hist_active_sess_history视图，只记录活动会话等待的事件，不活动的会话不采样，采样工作由后台进程MMNL完成(AWR信息采集由MMON进程完成)。

11g下默认ASH存储空间是2MB，
一个执行计划异常变更的案例 - 外传之ASH

ASH空间写满后，会由MMNL进程写入AWR负载中，而且也不是所有ASH信息全部写入，一般只写入10%的数据，内存中的信息可以使用v$active_session_history查询，已写入AWR的ASH信息可以使用wrh$_active_session_history/dba_hist_active_sess_history视图查询，可以说ASH是AWR的子集，但AWR中的信息不仅只有ASH，还会收集其他一些统计信息。

如下一些和ASH相关的视图，
(1) v$session：保存当前正在发生的session信息；
(2) v$session_wait：当前处于等待的session信息会被复制一份；
(3) v$session_wait_history：会话最近的10次等待事件；
(4) v$active_session_history：内存中的ASH采集信息，理论为1小时；
(5) wrh$active_session_history：写入AWR库中的ASH信息，理论为1小时以上；
(6) dba_hist_active_sesshistory：根据wrh$_active_session_history生成的视图；

实验：
1.创建ASH报告，
一个执行计划异常变更的案例 - 外传之ASH
首先选择报告格式，HTML或文本文件。

2.若是RAC，可以选择具体实例的序号，
一个执行计划异常变更的案例 - 外传之ASH

3.选择采集开始时间，默认是15分钟之前，
选择持续时间，默认是使用SYSDATE-begin_time，
一个执行计划异常变更的案例 - 外传之ASH

4.提示信息，
一个执行计划异常变更的案例 - 外传之ASH

一个执行计划异常变更的案例 - 外传之ASH

5.输入生成的报告名称，默认是“实例序号_MMDD_HH24MM.html”，
一个执行计划异常变更的案例 - 外传之ASH

6.生成ASH报告，
一个执行计划异常变更的案例 - 外传之ASH

一个执行计划异常变更的案例 - 外传之ASH

7.打开ASH报告，
一个执行计划异常变更的案例 - 外传之ASH

一个执行计划异常变更的案例 - 外传之ASH
可以看出和AWR报告相比，ASH少了一些系统负载信息，更多还是TOP SQL、TOP EVENTS这些信息。

总结：
相比AWR默认跨度一小时的间隔，ASH基于v$session提供更多session级别的统计信息，每秒会采集一次，其存储于SGA分配的空间，写满会写入AWR中，虽然少一些AWR中包含的系统负载信息，但对于一些查找当前性能最差的SQL、session负载等的场景，可能比较适合，当然使用一些数据字典视图SQL可以做相同的工作，毕竟这些报告后台就是执行相应的脚本、视图SQL得出的，这方面罗大师、建荣等同仁有类似的经验分享，可以参考。

正文到此结束