ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle性能awr报告

oracle性能awr报告

原创 Linux操作系统 作者:物理狂人 时间:2012-03-02 11:20:49 0 删除 编辑

首先说一下什么是awr报告,它能给我们带来什么。 

    * 定义:awr报告是oracle 10g下提供的一种性能收集和分析工具,它能提供一个时间段内整个系统资源使用情况的报告,通过这个报告,我们就可以了解一个系统的整个运行情况,这就像一个人全面的体检报告。 

如何分析: 

    * 在看awr报告的时候,我们并不需要知道所有性能指标的含义,就可以判断出问题的所在,这些性能指标其实代表了oracle内部实现,对oracle理解的越深,在看awr报告的时候,对数据库性能的判断也会越准确 

    * 在看性能指标的时候,心里先要明白,数据库出现性能问题,一般都在三个地方,io,内存,cpu,这三个又是息息相关的(ps:我们先假设这个三个地方都没有物理上的故障),当io负载增大时,肯定需要更多的内存来存放,同时也需要cpu花费更多的时间来过滤这些数据,相反,cpu时间花费多的话,有可能是解析sql语句,也可能是过滤太多的数据,到不一定是和io或内存有关系了 

    * 当我们把一条sql送到数据库去执行的时候,我们要知道,什么时候用到cpu,什么时候用到内存,什么时候用到io 

   1. cpu:解析sql语句,尝试多个执行计划,最后生成一个数据库认为是比较好的执行计划,不一定是最优的,因为关联表太多的时候,数据库并不会穷举所有的执行计划,这会消耗太多的时间,oracle怎么就知道这条数据时你要,另一个就不是你要的呢,这是需要cpu来过滤的 
   2. 内存:sql语句和执行计划都需要在内存保留一段时间,还有取到的数据,根据lru算法也会尽量在内存中保留,在执行sql语句过程中,各种表之间的连接,排序等操作也要占用内存 
   3. io:如果需要的数据在内存中没有,则需要到磁盘中去取,就会用到物理io了,还有表之间的连接数据太多,以及排序等操作内存放不下的时候,也需要用到临时表空间,也就用到物理io了 

这里有一点说明的是,虽然oracle占用了8G的内存,但pga一般只占8G的20%,对于专用服务器模式,每次执行sql语句,表数据的运算等操作,都在pga中进行的,也就是说只能用1.6G左右的内存,如果多个用户都执行 
多表关联,而且表数据又多,再加上关联不当的话,内存就成为瓶颈了,所有优化sql很重要的一点就是,减少逻辑读和物理读


如何生成awr报告: 

    * 1:登陆对应的数据库服务器 
2:找到oracle磁盘空间(d:oracle\product\10.2.0\db_1\RDBMS\Admin) 
3:执行cmd-cd d:回车 
4: cd  d:oracle\product\10.2.0\db_1\RDBMS\Admin 回车 
5:sqlplus 用户名/密码@服务连接名(例:sqlplus carmot_esz_1/carmot@igrp) 
6:执行@awrrpt.sql 回车 

第一步输入类型: html 
第二步输入天数: 天数自定义(如1,代表当天,如果2,代表今天和昨天。。。) 
第三步输入开始值与结束值:(你可以看到上面列出的数据,snap值) 
      这个值输入开始,与结束 
第四步输入导出表的名称:名称自定义 回车 
第五步,由程序自动导完。 

第六:到d:oracle\product\10.2.0\db_1\RDBMS\Admin 目录下。找到刚才生成的文件。 XXXX.LST文件 

具体分析过程: 

    * 在分析awr报告之前,首先要确定我们的系统是属于oltp,还是olap(数据库在安装的时候,选择的时候,会有一个选项,是选择oltp,还是olap) 
      对于不同的系统,性能指标的侧重点是不一样的,比如,library hit和buffer hit,在olap系统中几乎可以忽略这俩个性能指标,而在oltp系统中,这俩个指标就非常关键了 

    * 首先要看俩个时间 
      Elapsed: 240.00 (mins) 表明采样时间是240分钟,任何数据都要通过这个时间来衡量,离开了这个采样时间,任何数据都毫无疑义 
      DB Time: 92,537.95 (mins) 表明用户操作花费的时候,包括cpu时间喝等待时间,也许有人会觉得奇怪,为什么在采样的240分钟过程中,用户操作时间竟然有92537分钟呢,远远超过了 
      采样时间,原因是awr报告是一个数据的集合,比如在一分钟之内,一个用户等待了30秒,那么10个用户就等待了300秒,对于cpu的话,一个cpu处理了30秒,16个cpu就是4800秒,这些时间都是以累积的方式记录在awr报告中的。 

          再看sessions,可以看出连接数非常多 

    * 为了对数据库有个整体的认识,先看下面的性能指标

 
   

 
   1. Buffer Nowait 说明 在从内存取数据的时候,没有经历等待的比例,期望值是100% 
   2. Buffer Hit 说明从内存取数据的时候,buffer的命中率的比例,期望值是100%,但100%并不代表性能就好,因为这只是一个比例而已,举个例子,执行一条 sql语句,# 执行计划是需要取10000个数据块,结果内存中还真有这10000个数据块,那么比例是100%,表面上看是性能最高的,还有一个执行计划是需要500 个数据块,内存中有250个,另外250个需要在物理磁盘中取, 
      这种情况下,buffer hit是50%,结果呢,第二个执行计划性能才是最高的,所以说100%并不代表性能最好 
   3. Library Hit 说明sql在Shared Pool的命中率,期望值是100% 
   4. Execute to Parse 说明解析sql和执行sql之间的比例,越高越好,说明一次解析,到处执行,如果parse多,execute少的话,还会出现负数,因为计算公式是100*(1-parse/execute) 
   5. Parse CPU to Parse Elapsd 说明在解析sql语句过程中,cpu占整个的解析时间比例,,期望值是100%,说明没有产生等待,需要说明的是,即使有硬解析,只要cpu没有出现性能问题,也是可以容忍的,比较硬解析也有它的好处的 
   6. Redo NoWait 说明在产生日志的时候,没有产生等待,期望值是100% 
   7. Soft Parse 说明软解析的比例,期望值是100%,有一点要说明的是,不要单方面的追求软解析的高比例,而去绑定变量,要看性能的瓶颈在哪里 
   8. Latch Hit 说明latch的命中率,期望值是100%,latch类似锁,是一种内存锁,但只会产生等待,不会产生阻塞,和lock还是有区别的,latch是在并发的情况下产生的 
   9. Non-Parse CPU 说明非解析cpu的比例,越高越好,用100减去这个比例,可以看出解析sql所花费的cpu,100-99.30=0.7,说明花费在解析sql上的cpu很少 

    * 结合Time Model Statistics



 

         可以看出,在整个sql执行时间(sql execute elapsed time)时间为5552019秒中,解析时间(parse time elapsed)用了36秒,硬解析时间(hard parse elapsed time)用了34秒虽然硬解析时间占了整个解析时间的绝大部分,但解析时间是花的很少的,所以可以判断出,sql的解析没有成为性能的瓶 颈,进一步推测,sql在获取数据的过程中遇到了瓶            颈 

    * 继续看Top 5 Timed Events,从这里可以看出等待时间在前五位的是什么事件,基本上就可以判断出性能瓶颈在什么地方




 
   1. buffer busy waits 说明在获取数据的过程中,频繁的产生等待事件,很有可能产生了热点块,也就是说,很多会话都去读取同样的数据块,这一事件等待了5627394次,总共等待了5322924秒,平均等待时间为946毫秒,而且频率也是最高的,有95.9%,等待类别是并发 
      这里有一个概念:oracle操作的最小单位是块,当一个会话要修改这个块中的一条记录,会读取整个块,如果另一个会话要修改的数据也正好在这个块中,虽然这俩个 
   2. 会话修改的记录不一样,也会产生等待direct path write temp和direct path read temp 说明用到了临时表空间,那我们再看一下Tablespace IO Stats 


 
          各项指标都是非常高的,再根据上面的In-memory Sort是100%,没有产生磁盘排序,也就在排序的时候没有用到临时表空间,进一步推测,多个session,每个session执行的sql语句中多表关联,产生了很多中间数据,pga内存中放不下, 
          用到了临时表空间,也有可能是用到了lob字段,在用lob字段的时候,也会用到临时表 

    * 继续看SQL Statistics 
      根据buffer busy waits等待次数,时间,频率都是最高的,我们重点看逻辑读,物理读,和执行时间最长的sql,把排在前几位的拿出来优化 
      优化的原则为降低物理读,逻辑读,sql语句中的子操作执行次数尽量少,在看oracle估计出来的执行计划是看不出子操作的执行次数的,要看运行时的执行计划 

    * 有兴趣的话还可以看一下Segment Statistics 
      列出了用到的索引和表的使用情况,从这里也能看出索引和表的使用频率 

    * 也可以看一下Load Profile 
      里面列出了每秒,每个事务所产生的日志,逻辑读和物理读等指标

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24104518/viewspace-717502/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-06-16

  • 博文量
    80
  • 访问量
    142091