AWR报告详解
5墨值下载
AWR 是 Oracle 10g 版本 推出的新特性， 全称叫
Automatic Workload Repository-自动负载信息库, AWR 是通过对比两次快照
(snapshot)收集到的统计信息，来生成报表数据，生成的报表包括多个部分
WORKLOAD REP OS I TORY 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 Sna p Ti m e Sessions Cur s/ Sess
--------- ------------------- -------- ---------
Begin Sna p: 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 Sna p Ti m e Sessions Cur s/ Sess
--------- ------------------- -------- ---------
Begin Sna p: 3098 13-Nov-07 21:00:37 39 13.6
End Snap: 3102 13-Nov-07 22:00:15 4 0 16. 4
Elapsed: 59. 63 (mins)
DB Time: 19. 49 (mins)
服务器是 AIX 的系统，4 个双核 cpu,共 8 个核:
/sbin> bindprocessor -q
The availa ble pr oc essors 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 t i m e 和 DB Time 就能大概了解 db 的负载。
可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期
不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所
得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代
表性能问题的时间段。
Report Summary
Cache Si z es
Begin
End
Buffer Cache:
3,344M
3,344M
Std Blo ck Size:
8K
Shared Pool Size:
704M
704M
Log Buffer:
14,352K
显示 SGA 中每个区域的大小（在 AMM 改变它们之后），可用来与初始参数值
比较。
shared pool 主要包括 libr ary cac he 和 diction ary cache。librar y cache 用来存储
最近解析（或编译）后 SQL、PL/SQL 和 Java classes 等。library cache 用来
存储最近引用的数据字典。发生在 library cache 或 dictionary cache 的 cache
miss 代价要比发生在 buffer cac he 的代价高得多。因此 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
Executes:
354.34
299.23
Transactions:
1.18
% Blocks changed per Read:
51.62
Recursive Call %:
51.72
Rollback per transaction %:
85.49
Rows per Sort:
########
显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事
务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载
情况，绝大多数据并没有一个所谓“正确”的值，然而 Logons 大于每秒 1~2 个、
Hard parses 大于每秒 100、全部 parses 超过每秒 300 表明可能有争用问题。
Redo size
：
每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任
务的繁重与否。
of 69
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论