AWR报告详解(一)
上一篇 / 下一篇 2016-04-16 22:54:51 / 个人分类:数据库
AWR是Oracle 10g版本推出的新特性,全称叫Automatic Workload Repository-自动负载信息库, AWR是通过对比两次快照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分
WORKLOAD REPOSITORY report for
DB Name | DB Id | Instance | Inst num | Release | RAC | Host |
ICCI | 1314098396 | ICCI1 | 1 | 10.2.0.3.0 | YES | HPGICCI1 |
| Snap Id | Snap Time | Sessions | Cursors/Session |
Begin Snap: | 2678 | 25-Dec-08 14:04:50 | 24 | 1.5 |
End Snap: | 2680 | 25-Dec-08 15:23:37 | 26 | 1.5 |
Elapsed: |
| 78.79 (mins) |
|
|
DB Time: |
| 11.05 (mins) |
|
|
DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间,说明数据库比较空闲。
db time= cpu time + wait time(不包含空闲等待)(非后台进程)说白了就是db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间DB time = cpu time + all of nonidle wait event time
在79分钟里(其间收集了3次快照数据),数据库耗时11分钟,RDA数据中显示系统有8个逻辑CPU(4个物理CPU),平均每个CPU耗时1.4分钟,CPU利用率只有大约2%(1.4/79)。说明系统压力非常小。
列出下面这两个来做解释:
Report A:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1
End Snap: 4612 24-Jul-08 23:00:25 17 1.7
Elapsed: 59.51 (mins)
DB Time: 466.37 (mins)
Report B:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6
End Snap: 3102 13-Nov-07 22:00:15 40 16.4
Elapsed: 59.63 (mins)
DB Time: 19.49 (mins)
服务器是AIX的系统,4个双核cpu,共8个核:
/sbin> bindprocessor -q
The available processors are: 0 1 2 3 4 5 6 7
先说Report A,在snapshot间隔中,总共约60分钟,cpu就共有60*8=480分钟,DB time为466.37分钟,则:
cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)
也就是说cpu有466.37/480*100%花费在处理Oracle的操作上,这还不包括后台进程
看Report B,总共约60分钟,cpu有19.49/480*100%花费在处理Oracle的操作上
很显然,2中服务器的平均负载很低。
从awr report的Elapsed time和DB Time就能大概了解db的负载。
可是对于批量系统,数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。
ReportSummary
Cache Sizes
| Begin | End |
|
|
Buffer Cache: | 3,344M | 3,344M | Std Block Size: | 8K |
Shared Pool Size: | 704M | 704M | Log Buffer: | 14,352K |
显示SGA中每个区域的大小(在AMM改变它们之后),可用来与初始参数值比较。
shared pool主要包括library cache和dictionary cache。library cache用来存储最近解析(或编译)后SQL、PL/SQL和Java classes等。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。
Load Profile
| Per Second | Per Transaction | |||||||||||||||||||||||||||||||||||||||||||||||||
Redo size: | 918,805.72 | 775,912.72 | |||||||||||||||||||||||||||||||||||||||||||||||||
Logical reads: | 3,521.77 | 2,974.06 | |||||||||||||||||||||||||||||||||||||||||||||||||
Block changes: | 1,817.95 | 1,535.22 | |||||||||||||||||||||||||||||||||||||||||||||||||
Physical reads: | 68.26 | 57.64 | |||||||||||||||||||||||||||||||||||||||||||||||||
Physical writes: | 362.59 | 306.20 | |||||||||||||||||||||||||||||||||||||||||||||||||
User calls: | 326.69 | 275.88 | |||||||||||||||||||||||||||||||||||||||||||||||||
Parses: | 38.66 | 32.65 | |||||||||||||||||||||||||||||||||||||||||||||||||
Hard parses: | 0.03 | 0.03 | |||||||||||||||||||||||||||||||||||||||||||||||||
Sorts: | 0.61 | 0.51 | |||||||||||||||||||||||||||||||||||||||||||||||||
Logons: | 0.01 | 0.01 | |||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
1 | 2 | 3 | 4 | ||||||
5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
26 | 27 | 28 | 29 | 30 | 31 |
我的存档
数据统计
- 访问量: 148093
- 日志数: 83
- 文件数: 1
- 建立时间: 2008-08-20
- 更新时间: 2018-03-05
清空Cookie - 联系我们 - 51Testing软件测试网 - 交流论坛 - 空间列表 - 站点存档 - 升级自己的空间
Powered by 51Testing
© 2003-2021
沪ICP备05003035号