AWR报表分析

分析AWR报告

1 AWR报告头信息

         
          Elapsed:采样时间段

          DB Time:用户操作花费的时间

          DB Time远小于Elapsed Time说明数据库比较空闲

2 AWR负载概要信息

         
          Redo size:标志数据库的繁忙程度

          Parses:小于300则表示正常

          Hard parses:硬解析,小于100则表示正常

        从以上数据可以初步说明此数据库的吞吐量与负载正常


3 AWR实例效率

    
     Buffer Nowait%:内存获得数据的未等待比例

     Buffer Hit%:小于80%则要加内存

     Library Hit%:若低于90%,则需要调大share pool

     In-memory sort%:内存排序比例,过低排序会在临时表中进行,则需调大PGA

     Soft Parse%:确保大于99%,否则意味着share pool latch争用

     以上数据可以说明数据库实例命中率处于正常状态


4 AWR TOP等待事件

    
     在一个没有问题的数据库中,CPU time总是列在第一个位置

    DB file sequential read:此等待事件为多表连接的顺序存在问题,可能没有正确的使用基表或是不加选择的使用索引

     DB file scattered read:此等待事件比较显著说明存在大量的全表扫描或没有创建合适的索引

     ARCH wait on SENDERQ:远程传送archivelog的等待事件

      Oracle大致有100多个空闲等待事件与非空闲等待事件,
      Top 5 Timed Events是DB系统中影响比较大的前五个等待事件,
      CPU Time是空闲等待时间,它在排第一名说明DB比较空闲,
      Db file sequentail read与scattered read表明索引的选择不是很合理,


5 AWR TOP SQL Tuning
       

      对排名前几位的sql进行turning,Top sql的order by 对象有以下几种
      SQL ordered by Elapsed Time: 根据sql执行时间总和排序
      SQL ordered by CPU Time:     根据sql消耗CPU time总和排序
      SQL ordered by Gets:         根据sql消耗逻辑IO总和排序
      SQL ordered by Reads:        根据sql消耗物理IO总和排序
      SQL ordered by Executions:   根据sql执行次数排序
      SQL ordered by Parse Calls:  根据sql软解析次数

 

主要针对ordered by Elapsed time,orderedby CPU time,orderedby gets,orderedby read排名前三SQL进行观察并调优.

Oracle对SQL处理的步骤:

1.语法检查(检查SQL的拼写语法是否正确)

2.语义检查(检查SQL中的访问对象是否存在及是否具备相应权限)

3.进行解析(parse)(利用内部算法对SQL解析,生成解析树(parse tree)及执行计划(execution plan))à软硬解析发生在此过程中

4.执行SQL,返回结果

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

转载于:http://blog.itpub.net/28677145/viewspace-763949/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值