Oracle AWR 报告详解.pdf

辉柏嘉910

970

74页

4次

2021-02-17

70墨值下载

Oracle AWR 报告详解

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

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 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 的负载。

可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期

不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所

得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代

表性能问题的时间段。

Report Summary

Cache Sizes

Begin

End

Buffer Cache:

3,344M

Std Block Size:

Shared Pool Size:

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

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

of 74

70墨值下载

database

关注

评论