• AWR报告分析解读


    http://blog.csdn.net/weiwangsisoftstone/article/details/7614430

    1、AWR报告头信息

    Oracle AWR 报告分析(转) - 666 - 666

    • DB Name :数据库名字 DBid: 数据库id
    • Elapsed:采样时间段
    • DB Time:用户操作花费的时间,不包括Oracle后台进程消耗的时间
    • DB Time远小于Elapsed Time说明数据库比较空闲

     

    2、AWR负载概要信息

    Oracle AWR 报告分析(转) - 666 - 666

    • Per Second 和Per Transaction:这两部分是数据库资源负载的一个明细列表,分割成每秒钟的资源负载和每个事务的资源负载情况
    • Redo size:每秒/每个事务 产生的redo量 (单位字节) 标志数据库的繁忙程度
    • logical reads:每秒/每个事务 产生的逻辑读的块数
    • block changes:每秒/每个事务 改变的数据块数
    • physical reads:每秒/每个事务 产生的物理读
    • physical writes:每秒/每个事务 产生的物理写的块数
    • user calls:每秒/每个事务 用户的调用次数
    • parses:每秒/每个事务 分析次数 小于300则表示正常
    • hard parses: 每秒/每个事务 硬分析次数 小于100则表示正常
    • sorts: 每秒/每个事务 排序次数
    • logons: 每秒/每个事务 登录数据库次数
    • executes: 每秒/每个事务 SQL的执行次数
    • rollbacks: 每秒/每个事物回滚次数
    • transactions: 每秒的事务数

    3、AWR实例效率

    Oracle AWR 报告分析(转) - 666 - 666

    • Buffer Nowait%:表示在内存获得数据的未等待比例
    • Buffer Hit%:表示进程从内存中找到数据块的比率,内存数据块命中率。小于80%则要加大data buffer pool
    • Library Hit%:表示共享池中SQL解析的命中率。若低于90%,则需要调大share pool
    • Execute to Parse:是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
    • Parse CPU to Parse Elapsd:解析总时间中消耗总CPU的时间百分比
    • Redo NoWait:表示在LOG缓冲区获得BUFFER的未等待比例。
    • In-memory sort%:在内存中排序的比率,如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。
    • Soft Parse%:软解析的百分比(softs/softs+hards),近似当作sql在共享区的命中率,太低则需要调整应用使用绑定变量。
    • Latch Hit:Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。
    • Non-Parse CPU :SQL实际运行时间/(SQL实际运行时间+SQL解析时间),太低表示解析消耗时间过多。

    4、共享池概要

    image

    • Memory Usage %:对于一个已经运行一段时间的数据库来说,共享池内存使用率,应该稳定在75%-90%间,如果太小,说明Shared Pool有浪费,而如果高于90,说明共享池中有争用,内存不足。
    • SQL with executions>1:执行次数大于1的sql比率,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多SQL解析。
    • Memory for SQL w/exec>1:执行次数大于1的SQL消耗内存的占比。

    5、AWR TOP等待事件

    Oracle AWR 报告分析(转) - 666 - 666 
    显示了系统中最严重的5个等待,按所占等待时间的比例倒序列示。当我们调优时,总希望观察到最显著的效果,因此应当从这里入手确定我们下一步做什么。

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

    6、AWR TOP SQL Tuning

    Oracle AWR 报告分析(转) - 666 - 666

    1)SQL ordered by Elapsed Time:记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和,而不是单次SQL执行时间)

    • Elapsed Time(S): SQL语句执行用总时长,此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间,而是监控范围内SQL执行次数的总和时间。单位时间为秒 
      Elapsed Time = CPU Time + Wait Time
    • CPU Time(s): 为SQL语句执行时CPU占用时间总时长,此时间会小于等于Elapsed Time时间。单位时间为秒。
    • Executions: SQL语句在监控范围内的执行次数总计。
    • Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。
    • % Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。
    • SQL ID: SQL语句的ID编号,点击之后就能导航到下边的SQL详细列表中,点击IE的返回可以回到当前SQL ID的地方。
    • SQL Module: 显示该SQL是用什么方式连接到数据库执行的,如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。
    • SQL Text: 简单的sql提示,详细的需要点击SQL ID。

    2)SQL ordered by CPU Time: 记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和,而不是单次SQL执行时间)。

    3)SQL ordered by Gets: 记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和,而不是单次SQL执行所占的Gets).

    4)SQL ordered by Reads: 记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和,而不是单次SQL执行所占的磁盘物理读)。

    5)SQL ordered by Executions: 记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

    6)SQL ordered by Parse Calls: 记录了SQL的软解析次数的TOP SQL。

    7)SQL ordered by Sharable Memory: 记录了SQL占用library cache的大小的TOP SQL。
    Sharable Mem (b):占用library cache的大小。单位是byte。

    8)SQL ordered by Version Count: 记录了SQL的打开子游标的TOP 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,返回结果
  • 相关阅读:
    Array.prototype.slice.call(arguments)
    change,propertychange,input事件小议
    H5项目常见问题汇总及解决方案
    director.js:客户端的路由---简明中文教程
    Web APP开发技巧总结
    Flex 布局教程:语法篇
    解决iPhone中overflow:scroll;滑动速度慢或者卡的问题
    flexbox布局的兼容性
    移动前端知识总结
    使用React重构百度新闻webapp前端
  • 原文地址:https://www.cnblogs.com/hhandbibi/p/6721654.html
Copyright © 2020-2023  润新知