AWR之初体验-AWR报告分析（一）

最新推荐文章于 2024-04-25 15:59:02 发布

iceCache

最新推荐文章于 2024-04-25 15:59:02 发布

阅读量1.1k

点赞数

分类专栏：数据库文章标签： Oracle dba 文档

本文链接：https://blog.csdn.net/mensuo1111/article/details/8905325

版权

数据库专栏收录该内容

42 篇文章 0 订阅

订阅专栏

AWR:AutomaticWorkload Repository,自动负载信息库，是oracle 10g 版本推出的新特性。AWR通过对比两次快照收集到的统计信息来生成报表数据。

db time= cpu time + wait time（不包含空闲等待）（非后台进程）

DB Time：服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间，小于Elapsed表示数据库比较空闲。

Elapsed：表示过去了多长时间，这里指两个快照之间的时间。

数据表示在168分钟内生成了四次快照（27-30），数据库耗时不到一分钟。

Buffer Cache:SGA的组成部分之一，用于保存从数据文件中读取的数据块的副本信息。

Std Block Size: oracle 标准块大小；

Share pool size：SGA中最关键的内存片段，主要由库缓存(共享SQL区和PL/SQL区)和数据字典缓存组成；

LogBuffer：日志缓冲区。

Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。

Redo size每秒产生的日志大小(单位字节)可标志数据变更频率,数据库任务的繁重与否。Logicalreads每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的block数。

Logical Reads= Consistent Gets + DB Block Gets

Block changes每秒/每事务修改的块数

Physical reads每秒/每事务物理读的块数

Physical writes每秒/每事务物理写的块数

User calls每秒/每事务用户call次数

ParsesSQL解析的次数.每秒解析次数包括fastparsesoft parse和hard parse三种数量的综合。软解析每秒超过300次意味着你的"应用程序"效率不高调整session_cursor_cache。在这里fastparse指的是直接在PGA中命中的情况设置了session_cached_cursors=nsoftparse是指在shared pool中命中的情形hard parse则是指都不命中的情况；

Hard parses其中硬解析的次数硬解析太多说明SQL重用率不高。每秒产生的硬解析次数,每秒超过100次就可能说明你绑定使用的不好也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force该参数默认值为exact。但该参数设置为similar时存在bug可能导致执行计划的不优。

Sorts每秒/每事务的排序次数

Logons每秒/每事务登录的次数

Executes每秒/每事务SQL执行次数

Transactions每秒事务数.每秒产生的事务数反映数据库任务繁重与否

Blocks changed per Read表示逻辑读用于修改数据块的比例.在每一次逻辑读中更改的块的百分比。

Recursive Call递归调用占所有操作的比率.递归调用的百分比如果有很多PL/SQL那么这个值就会比较高；

Rollbackper transaction每事务的回滚率.看回滚率是不是很高因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来UndoBlock的竞争该参数计算公式如下:Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% ；Rows per Sort每次排序的行数

Buffer Nowait：表示在内存获得数据的未等待比例。在缓冲区中获取Buffer的未等待比率。BufferNowait的这个值一般需要大于99%。否则可能存在争用可以在后面的等待事件中进一步确认。

buffer hit：表示进程从内存中找到数据块的比率监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统如果此值低于80%应该给数据库分配更多的内存。

Redo NoWait：表示在LOG缓冲区获得BUFFER的未等待比例。如果太低可参考90%阀值考虑增加LOG BUFFER。

library hit：表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率当应用程序调用SQL或存储过程时Oracle检查LibraryCache确定是否存在解析过的版本如果存在Oracle立即执行语句如果不存在Oracle解析此语句并在LibraryCache中为它分配共享SQL区。低的library hit ratio会导致过多的解析增加CPU消耗降低性能；如果libraryhit ratio低于90%可能需要调大shared pool区。STATEMENT在共享区的命中率通常应该保持在95%以上否则需要要考虑加大共享池使用绑定变量修改cursor_sharing等参数。

Latch Hit：Latch是一种保护内存结构的锁可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%否则意味着Shared Pool latch争用可能由于未共享的SQL或者LibraryCache太小可使用绑定变更或调大Shared Pool解决。要确保>99%否则存在严重的性能问题。当该值出现问题的时候我们可以借助后面的等待时间和latch分析来查找解决问题。

Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)越高越好。计算公式为ParseCPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%意味着CPU等待时间为0没有任何等待；