bisal的个人空间

厚积薄发,欢迎关注个人微信公众号:bisal的个人杂货铺

  • 博客访问: 2382496
  • 博文数量: 324
  • 用 户 组: 普通用户
  • 注册时间: 2013-07-26 09:29
个人简介

10g/11g OCP,11g OCM,YEP成员(Oracle Young Expert Program,Oracle用户组年轻专家项目),我不是DBA,但我的爱好是Oracle,微信公众号:bisal的个人杂货铺

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(324)

文章存档

2017年(66)

2016年(44)

2015年(41)

2014年(61)

2013年(112)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: Oracle

之前的几篇文章:
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执行计划异常变更的案例 - 外传之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空间写满后,会由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报告,
这里写图片描述
首先选择报告格式,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得出的,这方面罗大师、建荣等同仁有类似的经验分享,可以参考。

阅读(1630) | 评论(0) | 转发(2) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册