没有合适的资源？快使用搜索试试~ 我知道了~

文库首页数据库Oracleoracle AWR性能分析详解

oracle AWR性能分析详解

ORACLE

等待事件

需积分: 10 16 下载量 95 浏览量 2014-09-19 14:20:26 上传评论 3 收藏 2.33MB PDF 举报

温馨提示

试读

154页

awr往往是分析数据库性能得重要参照，这个是oracle的awr的分析总结，教你如何看awr分析数据库性能问题。

资源推荐

资源详情

资源评论

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 = cputime + 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

先说 ReportA,在 snapshot 间隔中，总共约 60 分钟，cpu 就共有 60*8=480 分钟，DBtime

为 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 和 DBTime 就能大概了解 db 的负载。

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

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

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

间段。

ReportSummary

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

Rollback per transaction %:

85.49

Rows per Sort:

########

显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的

负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝

大多数据并没有一个所谓“正确”的值，然而 Logons 大于每秒 1~2 个、Hardparses 大

于每秒 100、全部 parses 超过每秒 300 表明可能有争用问题。

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

重与否。Logical reads：每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的 block

数。Logical Reads= Consistent Gets + DBBlock Gets

Block changes：每秒/每事务修改的块数

Physical reads：每秒/每事务物理读的块数

Physical writes：每秒/每事务物理写的块数

User calls：每秒/每事务用户 call 次数

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

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

session_cursor_cache。在这里，fast parse 指的是直接在 PGA 中命中的情况（设置

了 session_cached_cursors=n）；soft parse 是指在 sharedpool 中命中的情形；hard

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

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

解析次数, 每秒超过 100 次，就可能说明你绑定使用的不好，也可能是共享池设置不

合理。这时候可以启用参数 cursor_sharing=similar|force，该参数默认值为 exact。

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

Sorts：每秒/每事务的排序次数

Logons：每秒/每事务登录的次数

Executes：每秒/每事务 SQL 执行次数

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

Blocks changed per Read：表示逻辑读用于修改数据块的比例.在每一次逻辑读中更

改的块的百分比。

Recursive Call：递归调用占所有操作的比率.递归调用的百分比，如果有很多PL/SQL，

那么这个值就会比较高。

Rollback pertransaction：每事务的回滚率.看回滚率是不是很高，因为回滚很耗资

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

剩余153页未读，继续阅读

评论收藏

内容反馈

资源评论

资源反馈

评论星级较低，若资源使用遇到问题可联系上传者，3个工作日内问题未解决可申请退款~

数仓大山哥

粉丝: 223
资源: 27

上传资源快速赚钱

我的内容管理展开

我的资源快来上传第一个资源

我的收益

登录查看自己的收益

我的积分登录查看自己的积分

我的C币登录后查看C币余额

我的收藏

我的下载

下载帮助

前往需求广场，查看用户热搜

oracle AWR性能分析详解

OracleAWR报告详细分析.pdf

Oracle AWR报告最详细分析

AWR报告详细分析

oracle awr报告分析

Oracle解读AWR报告(老白)

AWR报告分析利器 ---兼容10g,11g,12c,18c,19c-附件资源

ORACLE之AWR性能分析报告详解

ORACLE AWR数据性能分析

Oracle AWR性能分析报告

AWR分析报告，用于分析Oracle数据库整体性能

oracle awr分析报告详解

oracle awr报告详解

Oracle AWR运行日志分析工具详解.docx

AWR报告生成详解

ORACLE性能AWR报告的使用和分析

浅谈AWR工具在oracle性能优化和故障诊断中的应用.pdf

AWR报告生成和分析详解

oracle AWR报告分析案例

ORACLE性能AWR报告的使用和分析.pdf

Oracle 数据库 AWR 报告详解

AWR报告生成详解.doc

ORACLE AWR报告详解

Oracle+AWR报告解读+等待事件学习

awr_ash 详解

ORACLE性能AWR报告的使用和分析[归纳].pdf

oracle_AWR报告分析实例2009

oracle AWR性能监控报告生成方法

最新资源