没有合适的资源?快使用搜索试试~ 我知道了~
首页ORACLE AWR报告详解
ORACLE AWR报告详解
3星 · 超过75%的资源 需积分: 16 15 下载量 171 浏览量
更新于2023-06-18
收藏 2.06MB DOC 举报
AWR 是 Oracle 10g 版本 推出的新特性, 全称叫Automatic Workload Repository-自动负载信息库, AWR 是通过对比两次快照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分
资源详情
资源推荐
AWR 是 Oracle 10g 版本 推出的新特性, 全称叫
AutomaticWorkloadRepository-自动负载信息库, AWR 是通过对比两次快照
(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分
WORKLOAD REPOSITORY 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 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 3,344M Std Block Size: 8K
Shared Pool Size: 704M 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 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:每秒产生的日志大小(单位字节),可标志数据变更频率, 数据库任
务的繁重与否。
Logical reads:每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的 block 数。
Logical Reads= Consistent Gets + DB Block Gets
Block changes:每秒/每事务修改的块数
Physical reads:每秒/每事务物理读的块数
Physical 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 changed per Read:表示逻辑读用于修改数据块的比例.在每一次逻辑
读中更改的块的百分比。
Recursive Call:递归调用占所有操作的比率.递归调用的百分比,如果有很多
PL/SQL,那么这个值就会比较高。
Rollback per transaction:每事务的回滚率.看回滚率是不是很高,因为回滚
很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的
回滚可能还会带来 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)
其中,软、硬解析就发生在第三个过程里。
Oracle 利用内部的 hash 算法来取得该 sql 的 hash 值,然后在 library
cache 里查找是否存在该 hash 值;
假设存在,则将此 sql 与 cache 中的进行比较;
假设“相同”,就将利用已有的解析树与执行计划,而省略了优化器的相关
工作。这也就是软解析的过程。
诚然,如果上面的 2 个假设中任有一个不成立,那么优化器都将进行创建
解析树、生成执行计划的动作。这个过程就叫硬解析。
创建解析树、生成执行计划对于 sql 的执行来说是开销昂贵的动作,所以,
应当极力避免硬解析,尽量使用软解析。
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 98.72 In-memory Sort %: 99.86
Library Hit %: 99.97 Soft Parse %: 99.92
Execute to Parse %: 89.09 Latch Hit %: 99.99
Parse CPU to Parse Elapsd %: 7.99 % Non-Parse CPU: 99.95
本节包含了 Oracle 关键指标的内存命中率及其它数据库实例操作的效率。其
中 Buffer Hit Ratio 也称 Cache Hit Ratio,Library Hit ratio 也称 Library Cache
Hit ratio。同 Load Profile 一节相同,这一节也没有所谓“正确”的值,而只能根
据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的 DSS 环境,
20%的 Buffer Hit Ratio 是可以接受的,而这个值对于一个 OLTP 系统是完全不
能接受的。根据 Oracle 的经验,对于 OLTPT 系统,Buffer Hit Ratio 理想应该
在 90%以上。
Buffer Nowait 表示在内存获得数据的未等待比例。在缓冲区中获取 Buffer
的未等待比率。Buffer Nowait 的这个值一般需要大于 99%。否则可能存在争用,
可以在后面的等待事件中进一步确认。
buffer hit 表示进程从内存中找到数据块的比率,监视这个值是否发生重大变
化比这个值本身更重要。对于一般的 OLTP 系统,如果此值低于 80%,应该给
数据库分配更多的内存。数据块在数据缓冲区中的命中率,通常应在 95%以上。
否则,小于 95%,需要调整重要的参数,小于 90%可能是要加
db_cache_size。一个高的命中率,不一定代表这个系统的性能是最优的,比
如大量的非选择性的索引被频繁访问,就会造成命中率很高的假相(大量的 db
file sequential read),但是一个比较低的命中率,一般就会对这个系统的性能
产生影响,需要调整。命中率的突变,往往是一个不好的信息。如果命中率突
然增大,可以检查 top buffer get SQL,查看导致大量逻辑读的语句和索引,如
果命中率突然减小,可以检查 top physical reads SQL,检查产生大量物理读的
语句,主要是那些没有使用索引或者索引被删除的。
Redo NoWait 表示在 LOG 缓冲区获得 BUFFER 的未等待比例。如果太低
(可参考 90%阀值),考虑增加 LOG BUFFER。当 redo buffer 达到 1M 时,
就需要写到 redo log 文件,所以一般当 redo buffer 设置超过 1M,不太可能存
在等待 buffer 空间分配的情况。当前,一般设置为 2M 的 redo buffer,对于内
存总量来说,应该不是一个太大的值。
library hit 表示 Oracle 从 Library Cache 中检索到一个解析过的 SQL
或 PL/SQL 语句的比率,当应用程序调用 SQL 或存储过程时,Oracle 检查
Library Cache 确定是否存在解析过的版本,如果存在,Oracle 立即执行语句;
如果不存在,Oracle 解析此语句,并在 Library Cache 中为它分配共享 SQL 区。
低的 library hit ratio 会导致过多的解析,增加 CPU 消耗,降低性能。如果
library hit ratio 低于 90%,可能需要调大 shared pool 区。STATEMENT 在共享
区的命中率,通常应该保持在 95%以上,否则需要要考虑:加大共享池;使用
绑定变量;修改 cursor_sharing 等参数。
Latch Hit:Latch 是一种保护内存结构的锁,可以认为是 SERVER 进程获取
访问内存数据结构的许可。要确保 Latch Hit>99%,否则意味着 Shared Pool
latch 争用,可能由于未共享的 SQL,或者 Library Cache 太小,可使用绑定变
更或调大 Shared Pool 解决。要确保>99%,否则存在严重的性能问题。当该值
出现问题的时候,我们可以借助后面的等待时间和 latch 分析来查找解决问题。
Parse CPU to Parse Elapsd:解析实际运行时间/(解析实际运行时间+解析
中等待资源时间),越高越好。计算公式为:Parse CPU to Parse Elapsd %=
100*(parse time cpu / parse time elapsed)。即:解析实际运行时间/(解析实际
运行时间+解析中等待资源时间)。如果该比率为 100%,意味着 CPU 等待时间
为 0,没有任何等待。
Non-Parse CPU :SQL 实际运行时间/(SQL 实际运行时间+SQL 解析时间),
太低表示解析消耗时间过多。计算公式为:% Non-Parse CPU =round(100*1-
PARSE_CPU/TOT_CPU),2)。如果这个值比较小,表示解析消耗的 CPU 时间
过多。与 PARSE_CPU 相比,如果 TOT_CPU 很高,这个比值将接近 100%,
这是很好的,说明计算机执行的大部分工作是执行查询的工作,而不是分析查
询的工作。
Execute to Parse:是语句执行与分析的比例,如果要 SQL 重用率高,则这
个比例会很高。该值越高表示一次解析后被重复执行的次数越多。计算公式为:
Execute to Parse =100 * (1 - Parses/Executions)。本例中,差不多每
execution 5 次需要一次 parse。所以如果系统 Parses > Executions,就可能出
现该比率小于 0 的情况。该值<0 通常说明 shared pool 设置或者语句效率存在
问题,造成反复解析,reparse 可能较严重,或者是可能同 snapshot 有关,通常
说明数据库性能存在问题。
In-memory Sort:在内存中排序的比率,如果过低说明有大量的排序在临时
表空间中进行。考虑调大 PGA(10g)。如果低于 95%,可以通过适当调大初始
化参数 PGA_AGGREGATE_TARGET 或者 SORT_AREA_SIZE 来解决,注意
这两个参数设置作用的范围时不同的,SORT_AREA_SIZE 是针对每个
session 设置的,PGA_AGGREGATE_TARGET 则时针对所有的 sesion 的。
Soft Parse:软解析的百分比(softs/softs+hards),近似当作 sql 在共享区
的命中率,太低则需要调整应用使用绑定变量。 sql 在共享区的命中率,小于
<95%,需要考虑绑定,如果低于 80%,那么就可以认为 sql 基本没有被重用
剩余63页未读,继续阅读
ys_ping
- 粉丝: 0
- 资源: 8
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- 利用迪杰斯特拉算法的全国交通咨询系统设计与实现
- 全国交通咨询系统C++实现源码解析
- DFT与FFT应用:信号频谱分析实验
- MATLAB图论算法实现:最小费用最大流
- MATLAB常用命令完全指南
- 共创智慧灯杆数据运营公司——抢占5G市场
- 中山农情统计分析系统项目实施与管理策略
- XX省中小学智慧校园建设实施方案
- 中山农情统计分析系统项目实施方案
- MATLAB函数详解:从Text到Size的实用指南
- 考虑速度与加速度限制的工业机器人轨迹规划与实时补偿算法
- Matlab进行统计回归分析:从单因素到双因素方差分析
- 智慧灯杆数据运营公司策划书:抢占5G市场,打造智慧城市新载体
- Photoshop基础与色彩知识:信息时代的PS认证考试全攻略
- Photoshop技能测试:核心概念与操作
- Photoshop试题与答案详解
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功