AWR报告详解 - 墨天轮文档

AWR报告详解

雷

1781

69页

33次

2019-08-19

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

10.2.0.3.0

YES

HPGICCI1

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

2678

25-Dec-08 14:04:50

1.5

End Snap:

2680

25-Dec-08 15:23:37

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

Std Blo ck Size:

Shared Pool Size:

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

Sorts:

0.61

0.51

Logons:

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

：

每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任

务的繁重与否。

Logical reads

：

每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的 block 数。

Logical Reads= Consistent Gets + DB Block Gets

Block changes

：

每秒/每事务修改的块数

Physical reads

：

每秒/每事务物理读的块数

Phy sical writes

：

每秒/每事务物理写的块数

User calls

：

每秒/每事务用户 call 次数

Parses

：

SQL 解析的次数.每秒解析次数，包括 fast parse，soft parse 和 hard

parse 三种数量的综合。软解析每秒超过 300 次意味着你的"应用程序"效率不

高，调整 session_cursor_cache。在这里，fast parse 指的是直接在 PGA 中命

中的情况（设置了 session_cached_cursors=n）；soft parse 是指在 shared pool

中命中的情形；hard parse 则是指都不命中的情况。

Hard parses

：

其中硬解析的次数，硬解析太多，说明 SQL 重用率不高。每秒

产生的硬解析次数, 每秒超过 100 次，就可能说明你绑定使用的不好，也可能是

共享池设置不合理。这时候可以启用参数 cursor_sharing=similar|force，该参数

默认值为 exact。但该参数设置为 similar 时，存在 bug，可能导致执行计划的不

优。

Sorts

：

每秒/每事务的排序次数

Logons

：

每秒/每事务登录的次数

Executes

：

每秒/每事务 SQL 执行次数

Transactions

：

每秒事务数.每秒产生的事务数，反映数据库任务繁重与否。

Blocks chan ged p er R ead

：

表示逻辑读用于修改数据块的比例.在每一次逻辑

读中更改的块的百分比。

Recursive Call

：

递归调用占所有操作的比率.递归调用的百分比，如果有很多

PL/SQL，那么这个值就会比较高。

Rollback p er tran sactio n

：

每事务的回滚率.看回滚率是不是很高，因为回滚很

耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的

回滚可能还会带来 Undo Block 的竞争该参数计算公式如下:

Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。

Rows per Sort

：

每次排序的行数

注:

Oracle 的硬解析和软解析

提到软解析(soft prase)和硬解析(hard prase)，就不能不说一下 Oracle 对

sql 的处理过程。当你发出一条 sql 语句交付 Oracle，在执行和获取结果前，Oracle

对此 sql 将进行几个步骤的处理过程：

1、语法检查(syntax check)

检查此 sql 的拼写是否语法。

2、语义检查(semantic check)

诸如检查 sql 语句中的访问对象是否存在及该用户是否具备相应的权限。

3、对 sql 语句进行解析(prase)

利用内部算法对 sql 进行解析，生成解析树(parse tree)及执行计划

(execution plan)。

4、执行 sql，返回结果(execute and return)

其中，软、硬解析就发生在第三个过程里。

of 69

5墨值下载

oracle 日常运维特别推荐

相关文档

评论