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

之前的几篇文章：

《一个执行计划异常变更的案例 - 前传》

《一个执行计划异常变更的案例 - 外传之绑定变量窥探》

《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》

《一个执行计划异常变更的案例 - 外传之rolling invalidation》

《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》

《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》

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

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

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

11g下默认ASH存储空间是2MB，



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

如下一些和ASH相关的视图，



实验：

1.创建ASH报告，



首先选择报告格式，HTML或文本文件。

2.若是RAC，可以选择具体实例的序号，



3.选择采集开始时间，默认是15分钟之前，

选择持续时间，默认是使用SYSDATE-begin_time，



4.提示信息，





5.输入生成的报告名称，默认是“实例序号_MMDD_HH24MM.html”，



6.生成ASH报告，





7.打开ASH报告，





可以看出和AWR报告相比，ASH少了一些系统负载信息，更多还是

TOP SQL、TOP EVENTS这些信息。

总结：

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