解读awr报告
来源:互联网 发布:mac卸载google chrome 编辑:程序博客网 时间:2024/05/18 15:54
第一次看到awr报告,里面包含很多东西,完全不知道从哪里看起也不知道各项指标都是什么含义,从头到尾看了一遍,啥也没有看到,看了后面忘了前面的,花费一天的时间去熟悉它,在网上查资料对着报告一项项的熟悉了一遍
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)
DB Name:数据库名字 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
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 %:
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 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
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
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
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
这是报告概要的最后一节,显示了系统中最严重的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。
- 解读awr报告
- oracle11g解读awr报告
- 解读awr报告
- AWR解读
- 【深度长文】循序渐进解读Oracle AWR性能分析报告
- AWR报告
- awr报告
- AWR报告
- AWR报表解读
- oracle11g-----AWR报告介绍
- 生成AWR性能报告!
- AWR性能报告分析!
- Oracle性能awr报告
- AWR/ADDM/ASH 报告
- oracle的AWR报告
- 批量生成awr报告
- 怎样找到AWR报告
- AWR 报告分析
- iOS通过http post上传图片
- 走进cassandra之四:副本机制
- 数据包接收系列 — IP协议处理流程(一)
- GetMessage(), PeekMessage(), PostMessage(), SendMessage()
- Uva 11752 The Super Powers 解题报告(数学)
- 解读awr报告
- Camera显示之Hal层的适配(一)
- Object-c消息之运行时动态绑定
- 马航一客机因故障降落香港 271名乘客平安无事
- 走进cassandra之五:存储机制
- SSH框架-HIbernate简介
- 走进cassandra之六:数据读写删
- Zookeeper常用命令
- JSch_SFTP授权机制