0
AWR报告详解
982
69页
29次
墨值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 Time
Sessions
Cursors/Session
Begin Snap:
25-Dec-08 14:04:50
24
1.5
End Snap:
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 个逻辑 CPU4 个物理 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 cachelibrar y cache 用来存储
最近解析(或编译)后 SQLPL/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
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文档的来源(墨天轮),文档链接,文档作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

关注
最新上传
暂无内容,敬请期待...
下载排行榜
Top250 周榜 月榜
近期活动
全部
暂无活动,敬请期待...
相关课程
全部