开发者社区> 余二五> 正文

Oracle 10g AWR Report 分析

简介:
+关注继续查看

Oracle 10g 提供了一个新的性能采集和分析工具awr(automaticworkload repository)。

Awr存在于sysaux表空间,是sysaux的主要占用者之一。

快照,在特定时间捕获的一组性能统计信息,用于计算统计信息的更改率。每个快照由snap_id进行标识。

默认快照每60分钟生成一次。保留7天。

 


Awr快照集,一种用于标记和保留重要时段快照集数据的机制。一个快照集定义一对快照(两个快照)。快照集用于保留快照数据。在删除快照集之前,属于快照集的快照会一直存在。

一般情况下,可以将具有代表性的时段设置为快照集,以便用于与当前系统行为进行比较。

 

Awr compare periods 用于比较awr中两个时段。Awr显示两个快照(两个时间点)之间的awr数据,而awr compare periods 显示两个时段即两个awr report(相当于四个快照)之间的差异。根据两个时段之间报告的更改,可准确诊断性能降低的原因。

 

生成awr report,可运行$ORACLE_HOME/rdbms/admin/awrrpt.sql。

Awr快照设置,使用dbms_workload_repository.modify_snapshot_settings()。

生成awr快照集,可使用dbms_workload_repository.create_baseline ()。

生成awr compare periods,可运行$ORACLE_HOME/rdbms/admin/awrddrpt.sql。

Awr report 分析-CPU繁忙程度与CPU使用率


Sessons:采集时实例连接的会话数。

Cursors/Session:每个会话平均打开的游标数。

Elapsed:采样时间。

DB Time:代表了实例的工作负载,在时间模型统计中非常重要。

DB Time表示用户操作花费的时间,包括cpu时间(非后台进程花费时间(比如PMON))和等待时间(非空闲等待时间)。

如果DB Time接近于Elapsed Time*cpu数,表明数据库比较忙,cpu负载也许比较大。这时很有可能是因为资源争用导致等待事件的结果,可以去top 5等待事件分析原因。

可以在Time Model Statistics部分获取DB Time的值与DB CPU的值。DB CPU 指用户操作的总的CPU时间,同样不包括后台进程花费的CPU时间(比如PMON)。那么DB Time去除掉DB CPU是不是就应该是等待时间?应该是,于是公式DB Time=DB CPU + 等待时间。


V$SESS_TIME_MODEL

http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2087.htm#REFRN30340

 

看一下系统统计部分:


从这部分信息可以看出我们系统的CPU情况与内存等信息。

SYS_TIME与USER_TIME之和 1776 +4834 = 6610 正好等于BUSY_TIME,再者(6610 + 719387)/100/60/2 = 60.49975 ,这不是我们的采样时间吗?2代表两个cpu(NUM_CPUS)。上面提到DB CPU不包括后台进程花费的时间(比如PMON),而在Time Model Statistics中显示出了后台进程CPU时间(backgroundcpu time)。所以数据库的整体 cpu 使用情况可以这样计算吧,cpu使用率 = ( DB CPU + background cpu time ) / (Elapsed *NUM_CPUS) * 100% = ( 19.45 + 7.08 ) / ( 60.45mins * 2 )* 100% = 0.00366 % 。看来我们的系统很闲呀,我应该在系统稍微忙点的时候取一份report来分析。

V$OSSTAT

http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2010.htm#REFRN30321

 

Awr report 分析-IO stats

 

性能指标说明:

Reads: 发生了多少次物理读。

Av Reads/s : 每秒钟物理读的次数。


Av Rd(ms): 平均一次物理读的时间(毫秒),有一种说法是如果这个值大于7说明系统有严重的I/O问题,也有人说这个值不应该超过30,否则IO也可能有问题。硬件不同对IO瓶颈的判断也会相应的改变。

Av Blks/Rd:每次读多少个数据块。

Writes:发生了多少次写。

Av writes/s:每秒写的次数。

Buffer Waits:获取内存数据块等待的次数。

Av Buf Wt(ms):获取内存数据块平均等待时间。

V$FILESTAT

http://docs.oracle.com/cd/B19306_01/server.102/b14237/dynviews_1107.htm#REFRN30087


IOPS (Input/Output Operations Per Second),即每秒进行读写(I/O)操作的次数。

MBPS也就是带宽,每秒传输的比特(数据量),一个字节8比特(bit)。比如:4Mbps=每秒钟传输4M比特。

 

IOPS计算:

IOPS = Av Reads/s + Av Writes/s

MBPS计算:

MBPS=(Physical reads +Physical writes)* block_size =(0.12 + 0.28 )*块大小

MBPS的的指标在 Load Profile 或 Instance ActivityStatistics 部分分别对应Physical reads 与Physical writes 或 physical writes 与 physicalreads。


相关描述说明:

Statistics Descriptions

http://docs.oracle.com/cd/B19306_01/server.102/b14237/stats002.htm#i375475

 


同样一个系统,我们可以设置一个基线作为依据,也可以判断出IO性能是否出现了问题,比如,在系统运行性能良好的时候做一个基线,当系统IO性能很差时,我们可以取一份report,然后对比两个report的性能指标,这样就可以准确诊断当前IO对性能的影响。

Awr report 分析-oracle 内存组件大小


在awr report中显示了oracle对各个内存组件大小的性能估算,包括Buffer Pool Advisory,PGA Memory Advisory,Shared Pool Advisory,SGATarget Advisory。

先看一下Report Summary里这方面的信息:

指标说明:

Memory Usage %:表示共享池内存使用率,应保持在75到90之间,如果太小说明分配的共享池过大,如果>90说明共享池中有争用,共享池内存不足。

% SQL with executions>1:执行次数大于1的SQL语句的比率,太小的话要结合Parse,看看是不是有硬编码现象,避免过多的sql硬解析。

% Memory for SQL w/exec>1:执行次数大于1的SQL语句所消耗的内存,占所有SQL语句消耗内存的比率。


指标说明:

Size for Est (M):oracle 估算buffer pool的大小。

Size Factor:估算值与实际值的一个比例,比如0.9,代表估算值是实际值大小的90%,1.0代表buffer pool的实际大小。

Buffers for Estimate:估算的buffer pool的大小(数量)。

Est Phys Read Factor:估算的物理读的影响因子,是估算物理读和实际物理读的一个比例,1.0代表实际的物理读。

Estimated Physical Reads:估算的物理读的次数。

 

可以看出系统的实际bufferpool的大小是380M(Size Factor=1.0)。我们应该找到SizeFactor的改变对物理读影响最大的点,即Size Factor=0.66的点。从Size Factor=0.57的物理读次数391999降到Size Factor=0.66的物理读次数414222,以后物理读的变化很小,或基本没有变化。即buffer pool为252M时,效率是最高的。

指标说明:

PGA Target Est (MB):估算PGA 的大小。

Size Factr:影响因子。

W/A MB Processed:oracle为了产生估算处理的数据量。

Estd Extra W/A MB Read/ Written to Disk:处理数据中需要物理读写的数据量。

Estd PGA Cache Hit %:估算的PAG命中率。

Estd PGA Overalloc Count:需要在估算的PGA大小下额外分配内存的次数。

 

这份数据没有任何代表性!这里需要掌握两个点:1)oracle估算的PGA大小不会导致额外分配内存的点。2)物理读写值(Estd Extra W/A MB Read/ Written to Disk)不再增加的点。不过还要考虑当前内存是否充足。

指标说明:

Shared Pool Size(M):估算的共享池大小。

SP Size Factr:影响因子。

Est LC Size (M) :估算的库高速缓存占用的大小。

Est LC Mem Obj:高速缓存中的对象数。

Est LC Time Saved (s) :需要额外将对象读入共享池的时间。

Est LC Time Saved Factr:额外将对象读入共享池的时间影响因子。

Est LC Load Time (s) :分析所花费的时间。

Est LC Load Time Factr:分析花费事件的影响因子。

Est LC Mem Obj Hits:内存中对象被发现的次数。

 

这里主要看Est LC Time Saved Factr这一列,它表示将对象读入共享池的影响情况,当这个值变化很小或不变的时候,增加shared pool的值就没有太大意义了。这样看来,这里应该将shared pool 设置为80M。共享池设置大了,这正好验证了Shared Pool Statistics中Memory Usage %列说明。


指标说明:

SGA Target Size (M):估算的SGA大小。

SGA Size Factor:影响因子。

Est DB Time (s):估算的SGA大小计算出的DB TIME。

Est Physical Reads:估算的物理读次数。

 

同样找到影响最大的点,即Size Factor=0.75的点。

Awr report 分析-其它

OLTP系统中必须关注的两个性能指标是LibraryHit与Buffer Hit。Library Hit指共享池中sql解析的命中率; Buffer Hit指内存数据块命中率。

关于这两项性能指标可以查看:

oracle SharedPool优化思路 http://www.linuxidc.com/Linux/2011-07/38912.htm


oracle Buffer Cache优化思路 http://www.linuxidc.com/Linux/2011-11/48052.htm

 

SQL ordered by Elapsed Time

image


这部分以sql消耗时间降序排列。

指标说明:

Elapsed Time (s):该条sql消耗的总时间。

CPU Time (s):该条sql花费的总cpu时间。

Executions:该条sql执行次数。

Elap per Exec (s):该条sql执行一次消耗的平均时间。

% Total DB Time:该条sql消耗总时间(ElapsedTime)占数据库时间(DB Time)的百分比。

 

SQL ordered by CPU Time

% Total DB Time is the Elapsed Time of theSQL statement divided into the Total Database Time multiplied by 100

这部分以sql消耗的cpu时间降序排列。

指标说明:略

 

SQL ordered by Gets

image


这部分以sql获取内存数据块的数量降序排列。

指标说明:

Buffer Gets:sql获取内存数据块总数量。

Executions:sql执行次数。

Gets per Exec:sql执行一次获取内存数据块数量。

%Total:占内存数据块的百分比。

CPU Time (s) :sql花费的总cpu时间。

Elapsed Time (s):sql消耗的总时间。

 

SQL ordered by Reads

这部分以sql物理读降序排列。

 

SQL ordered by Executions

这部分列出sql执行次数信息。

指标说明:

Rows Processed:sql处理的总记录数。

Rows per Exec CPU per Exec (s):sql每次执行处理的记录数。

OLTP可以关注,OLAP无须关注(因为sql重复执行的频率很低)。

 

SQL ordered by Parse Calls

这部分列出sql被分析次数(不区分硬分析与软分析)的信息。

指标说明:

Parse Calls:sql分析的次数。

% Total Parses:占总分析次数的百分比。

 

SQL ordered by Sharable Memory

这部分列出sql占用library cache大小的信息。

指标说明:

Sharable Mem (b):占用librarycache的大小。

 

SQL ordered by Version Count

这部分列出sql版本数信息。

指标说明:

Version Count:sql版本数。

OLTP可以关注。

 

SQL ordered by Cluster Wait Time

这部分列出集群等待时间信息。

指标说明:

Cluster Wait Time(s):集群等待时长。

CWT% of Elapsd Time:集群操作等待时长占总时长(ElapsdTime(s))的百分比。





本文转自 vfast_chenxy 51CTO博客,原文链接:http://blog.51cto.com/chenxy/892837,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器ECS登录用户名是什么?系统不同默认账号也不同
阿里云服务器Windows系统默认用户名administrator,Linux镜像服务器用户名root
15906 0
如何设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云安全组设置详细图文教程(收藏起来) 阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程。阿里云会要求客户设置安全组,如果不设置,阿里云会指定默认的安全组。那么,这个安全组是什么呢?顾名思义,就是为了服务器安全设置的。安全组其实就是一个虚拟的防火墙,可以让用户从端口、IP的维度来筛选对应服务器的访问者,从而形成一个云上的安全域。
19214 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
28477 0
阿里云服务器安全组设置内网互通的方法
虽然0.0.0.0/0使用非常方便,但是发现很多同学使用它来做内网互通,这是有安全风险的,实例有可能会在经典网络被内网IP访问到。下面介绍一下四种安全的内网互联设置方法。 购买前请先:领取阿里云幸运券,有很多优惠,可到下文中领取。
22256 0
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
20890 0
+关注
20378
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载