ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Oracle 10g AWR Report 分析(转)

Oracle 10g AWR Report 分析(转)

原创 Linux操作系统 作者:逍遥三人 时间:2012-02-13 17:24:24 0 删除 编辑

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))的百分比。

本篇文章来源于 Linux公社网站(www.linuxidc.com) 原文链接:http://www.linuxidc.com/Linux/2011-11/48053p4.htm

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21584437/viewspace-716171/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-05-07

  • 博文量
    73
  • 访问量
    110101