AWR报告解读近年原文.pdf

AWR报告解读

0初步结论

①数据库CPU资源不够，CPU使⽤率较⾼，造成CPU等待时较长，可适当提升CPU资源；

②数据库I/O资源消耗不太⼤，不存在IO瓶颈；

③可适当调⼤SGA空（增加10G左右），PGA暂不需要调整；

④sql_id=16dhat4ta7xs9，aw9ttz9acxbc3，d4ujh5yqt1fph三条SQL可以尝试进⾏优化存储过程。

⑤调整CPU资源后，再观察⼀下logfilesync等待事件是否还会很⾼，如果还⾼的话需要进⼀步跟进处理。

1概览

1.1数据库和实例的信息

分析结果如下：

版本：11.2.04

RAC：YES

平台：Linux

CPU：2*20cores

内存：252.17GB

1.2Sessions和Cursors/Session

Sessions：实例连接的会话数-并发⽤户数量-数据库类型

Cussors/Session：每个会话打开的cursor数量-执⾏SQL的情况

分析结果：当前会话量不是特别多

1.3Elapsed和DBTime

系统负载和等待事件

DBTime:累积⽅式记录，如1个CPU处理23.48，那么40个就是939.2分钟。（CPU时+等待事件）

负载情况：DBTime/(CPUs*Elapsed)=1387.55/(40*23.48)=1397.55/939.2=148.8%

分析结果：说明当前数据负载较⾼

2LoadProfile

2.1指标

Redosize：每秒（每个事务）产⽣的redo量

Logicalreads：每秒（每个事务）产⽣的逻辑读（对应于物理读）

Blockchanges：每秒（每个事务）改变的数据块数

Physicalreads：每秒（每个事务）产⽣的物理读

Physicalwrites：每秒（每个事务）产⽣的物理写

Usercalls：每秒（每个事务）⽤户的调⽤次数

Parses：每秒（每个事务）分析次数

Hardparses：每秒（每个事务）硬分析次数(软=总-硬)

Sorts：每秒（每个事务）排序次数

Logons：每秒（每个事务）登录数据库次数

Executes：每秒（每个事务）SQL的执⾏次数

Transactions：每秒的事务数

2.2IO

分析结果1：IO吞吐和IOPS都不是很⼤，对于⼀体机IO来说可以轻松应对

Physicalread*8K/1024=ReadIO

Physicalwrite*8K/1024=WriteIO

RedoSize=0/1024/1024=72M

Logicalreads=1456187.0/1024/1024=1M

Blockchanges=446,863.9

2.3事务

分析结果2：每秒⽤户调⽤次数、解析次数、执⾏次数以及事务数都很⾼，初步判断数据库应

该为交易型

3Top10ForeroundEventsbyTotalWaitTime

DBCPU严格来说不是等待事件，⼀般排第⼀

等待事件类型和常见等待事件

分析结果1：logfilesync等待事件排名第⼆，且⽐第三占⽐过多，猜测应该不太正常。

logfilesync等待事件：当⽤户执⾏完事务（insert插⼊数据）执⾏commit命令后，Oracle后台LGWR进程需要redologbuffer-＞

onlineredologfiles，写⼊后返回Commitcomplete。⽤户等待返回的这个过程过慢则会发⽣LogFileSync等待事件。

分析结果2：只有logfilesync，没有logfileparallelwrite，结合之前事务量过多判断，可能

是cpu使⽤率较⾼、频繁提交或回滚等原因造成。

分析结果3：可以看到Commit⼗分频繁，建议使⽤批量批量提交。

进⼀步确定redo的⼤⼩和组数是否合适。

4CPU负载、IO、Memory

分析结果1：系统平均负载呈现下降趋势，%Idle34.