解读awr报告
2012-05-29 22:52
351 查看
第一次看到awr报告,里面包含很多东西,完全不知道从哪里看起也不知道各项指标都是什么含义,从头到尾看了一遍,啥也没有看到,看了后面忘了前面的,花费一天的时间去熟悉它,在网上查资料对着报告一项项的熟悉了一遍
DB Name
:数据库名字 DBid:
数据库id
DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间,说明数据库比较空闲。在31分钟里,数据库耗时0.1分钟,数据中显示系统有2个CPU
Load Profile
Load Profile
Per Second Per Transaction
这两部分是数据库资源负载的一个明细列表,分割成每秒钟的资源负载和每个事务的资源负载情况,性能指标的含义如下:
redo size: 每秒/每个事务 产生的redo量 (单位字节)
logical reads:
每秒/每个事务 产生的逻辑读的块数
block changes:
每秒/每个事务 改变的数据块数
physical reads:
每秒/每个事务 产生的物理读
physical writes:
每秒/每个事务 产生的物理写的块数
user calls: 每秒/每个事务 用户的调用次数
parses: 每秒/每个事务 分析次数
hard parses: 每秒/每个事务 硬分析次数
sorts: 每秒/每个事务 排序次数
logons: 每秒/每个事务 登录数据库次数
executes: 每秒/每个事务 SQL的执行次数
rollbacks: 每秒/每个事物回滚次数
transactions: 每秒的事务数
Instance Efficiency Percentages (Target 100%)
Buffer Nowait:表示在内存获得数据的未等待比例。
buffer hit:表示进程从内存中找到数据块的比率,内存数据块命中率
Redo NoWait:表示在LOG缓冲区获得BUFFER的未等待比例。
library hit:表示共享池中SQL解析的命中率
Latch Hit:Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。
Parse CPU to ParseElapsd:解析总时间中消耗总CPU的时间百分比
Non-Parse CPU :SQL实际运行时间/(SQL实际运行时间+SQL解析时间),太低表示解析消耗时间过多。
Execute to Parse:是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
In-memory Sort:在内存中排序的比率,如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。
Soft Parse:软解析的百分比(softs/softs+hards),近似当作sql在共享区的命中率,太低则需要调整应用使用绑定变量。
Shared Pool Statistics
Memory Usage %:对于一个已经运行一段时间的数据库来说,共享池内存使用率,应该稳定在75%-90%间,如果太小,说明Shared
Pool有浪费,而如果高于90,说明共享池中有争用,内存不足。
SQL with executions>1:执行次数大于1的sql比率,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多SQL解析。
Memory for SQL w/exec>1:执行次数大于1的SQL消耗内存的占比。
Top 5 Timed Foreground Events
这是报告概要的最后一节,显示了系统中最严重的5个等待,按所占等待时间的比例倒序列示。当我们调优时,总希望观察到最显著的效果,因此应当从这里入手确定我们下一步做什么。
通常,在没有问题的数据库中,CPUtime总是列在第一个
SQL Statistics
SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by User I/O Wait Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Physical Reads (UnOptimized)
SQL ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable Memory
SQL ordered by Version Count
Complete List of SQL Text
二、解析报告
1.SQL ordered by Elapsed Time:
记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和,而不是单次SQL执行时间
Elapsed Time = CPU Time + Wait Time)
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。
DB Name | DB Id | Instance | Inst num | Startup Time | Release | RAC |
Db10 | 663168021 | Db10 | 1 | 28-5月 -12 22:05 | 11.2.0.1.0 | NO |
Host Name | Platform | CPUs | Cores | Sockets | Memory (GB) |
PC-200910080511 | Microsoft Windows IA (32-bit) | 2 | 2 | 1 | .75 |
Snap Id | Snap Time | Sessions | Cursors/Session | |
Begin Snap: | 73 | 28-5月 -12 22:28:57 | 23 | 1.5 |
End Snap: | 74 | 28-5月 -12 23:00:43 | 23 | 1.5 |
Elapsed: | 31.76 (mins) | |||
DB Time: | 0.10 (mins) |
:数据库名字 DBid:
数据库id
DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间,说明数据库比较空闲。在31分钟里,数据库耗时0.1分钟,数据中显示系统有2个CPU
Load Profile
Per Second | Per Transaction | Per Exec | Per Call | |
DB Time(s): | 0.0 | 0.0 | 0.00 | 0.02 |
DB CPU(s): | 0.0 | 0.0 | 0.00 | 0.02 |
Redo size: | 5,896.4 | 59,450.5 | ||
Logical reads: | 71.9 | 724.7 | ||
Block changes: | 41.1 | 414.7 | ||
Physical reads: | 2.2 | 21.9 | ||
Physical writes: | 0.9 | 9.2 | ||
User calls: | 0.2 | 1.8 | ||
Parses: | 3.7 | 37.6 | ||
Hard parses: | 0.3 | 2.5 | ||
W/A MB processed: | 0.0 | 0.2 | ||
Logons: | 0.1 | 0.6 | ||
Executes: | 8.1 | 81.7 | ||
Rollbacks: | 0.0 | 0.0 | ||
Transactions: | 0.1 |
Per Second Per Transaction
这两部分是数据库资源负载的一个明细列表,分割成每秒钟的资源负载和每个事务的资源负载情况,性能指标的含义如下:
redo size: 每秒/每个事务 产生的redo量 (单位字节)
logical reads:
每秒/每个事务 产生的逻辑读的块数
block changes:
每秒/每个事务 改变的数据块数
physical reads:
每秒/每个事务 产生的物理读
physical writes:
每秒/每个事务 产生的物理写的块数
user calls: 每秒/每个事务 用户的调用次数
parses: 每秒/每个事务 分析次数
hard parses: 每秒/每个事务 硬分析次数
sorts: 每秒/每个事务 排序次数
logons: 每秒/每个事务 登录数据库次数
executes: 每秒/每个事务 SQL的执行次数
rollbacks: 每秒/每个事物回滚次数
transactions: 每秒的事务数
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: | 100.00 | Redo NoWait %: | 100.00 |
Buffer Hit %: | 96.98 | In-memory Sort %: | 100.00 |
Library Hit %: | 90.91 | Soft Parse %: | 93.27 |
Execute to Parse %: | 53.96 | Latch Hit %: | 99.99 |
Parse CPU to Parse Elapsd %: | 64.26 | % Non-Parse CPU: | 67.81 |
buffer hit:表示进程从内存中找到数据块的比率,内存数据块命中率
Redo NoWait:表示在LOG缓冲区获得BUFFER的未等待比例。
library hit:表示共享池中SQL解析的命中率
Latch Hit:Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。
Parse CPU to ParseElapsd:解析总时间中消耗总CPU的时间百分比
Non-Parse CPU :SQL实际运行时间/(SQL实际运行时间+SQL解析时间),太低表示解析消耗时间过多。
Execute to Parse:是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
In-memory Sort:在内存中排序的比率,如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。
Soft Parse:软解析的百分比(softs/softs+hards),近似当作sql在共享区的命中率,太低则需要调整应用使用绑定变量。
Shared Pool Statistics
Begin | End | |
Memory Usage %: | 84.18 | 83.00 |
% SQL with executions>1: | 74.54 | 76.34 |
% Memory for SQL w/exec>1: | 78.06 | 73.38 |
Pool有浪费,而如果高于90,说明共享池中有争用,内存不足。
SQL with executions>1:执行次数大于1的sql比率,如果此值太小,说明需要在应用中更多使用绑定变量,避免过多SQL解析。
Memory for SQL w/exec>1:执行次数大于1的SQL消耗内存的占比。
Top 5 Timed Foreground Events
Event | Waits | Time(s) | Avg wait (ms) | % DB time | Wait Class |
DB CPU | 5 | 87.64 | |||
db file sequential read | 258 | 1 | 5 | 22.30 | User I/O |
library cache load lock | 1 | 0 | 87 | 1.45 | Concurrency |
db file scattered read | 17 | 0 | 3 | 0.85 | User I/O |
log file sync | 35 | 0 | 1 | 0.77 | Commit |
通常,在没有问题的数据库中,CPUtime总是列在第一个
SQL Statistics
SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by User I/O Wait Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Physical Reads (UnOptimized)
SQL ordered by Executions
SQL ordered by Parse Calls
SQL ordered by Sharable Memory
SQL ordered by Version Count
Complete List of SQL Text
二、解析报告
1.SQL ordered by Elapsed Time:
记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和,而不是单次SQL执行时间
Elapsed Time = CPU Time + Wait Time)
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。
相关文章推荐
- oracle11g-----AWR报告介绍
- 【机器学习】【智能制造】报告6大权威解读机器学习革新智能制造10大趋势
- ORACLE 10g AWR报告设置总结
- oracle 11g的awr报告生成
- 一次AWR报告引发的自我反省 推荐
- AWR 报告 查看 数据库 负载
- Oracle AWR 报告中 No data exists for this section of the report 说明
- AWR报告导出
- 【ORACLE】AWR报告的生成和简单分析方法
- 常见性能报告收集方法(AWR,ASH)
- 转: Oracle AWR 报告 每天自动生成并发送邮箱
- 安全测试报告解读
- 解读《第二十四次互联网报告》
- 企鹅智酷“2015年互联网终极报告——解读九大行业红利”
- 深入浅出网站分析(五)——Google Analytics报告解读
- 常见问题:如何使用AWR报告来诊断数据库性能问题 (文档 ID 1523048.1)
- 【性能优化】 之AWR 报告分析
- AI 新技术革命将如何重塑就业和全球化格局?深度解读 UN 报告 (下篇)
- 借助AWR报告分析解决oracleCPU过高的问题(转)
- 手工生成awr报告