关于AWR报告的解析

其实，网上关于AWR的解析已经足够多了。但总以为经过收集资料，再加工写出来的资料能便于本身理解其中的各项内容，所以我对AWR进行一篇详尽的解析。但愿能分几回完成

从AWR报告的第一部分包含了数据库的名称、数据库的ID号、实例名、实例数、启动的时间、数据库版本和是否为RAC。此外也包含了系统的部分信息。

该部分最关键的内容是第三个模块，里面记录了snapshot的开始时间和结束时间，以及数据库运行时间和用户级别调用(session)所消耗的时间。

DB CPU：Amount of CPU time (in microseconds) spent on database user-level calls. This does not include the CPU time spent on instance background processes such as PMON.

 

这里就涉及一个问题，经过数据库用户调用的时间能够算出数据库繁忙的程度。首先来看看Elapsed Time为1664.70 mins 折算成秒为

Elasped Time=(1664*60+.7*60)/3600 hours

看下snapshot begin to end 时间为27 hours 44 mins 42 sec 恰好就是Elasped Time的时间。

 

系统有32个CPUs，由于并行做业的缘故，总计DB在CPU上消耗的时间应为32*1664.7 而DB Time的时间为在全部CPUs上消耗的时间106.76 mins。

从这里咱们就能够算出数据库用户级别消耗的时间比：106.76/32*1664.7*100%≈0.2%

也就是说DB在CPU上的使用率为0.2%,idle rate达到99.8%。说明数据库负载至关的低。

 

DB Time既然为用户级别的调用，具体包含什么呢？我这里直接引用网上的公式。

DB Time= DB CPU + Non-Idle Wait + Wait on CPU queue

 

经过查看CPU的负载大概能够印证这个数据。

 

第二部分

报告概要的Cache Sizes很简单，主要包含buffer的尺寸、shared pool大小、标准块大小、日志buffer的大小。

正如咱们所知的，Oracle DB采用LRU算法，将数据块内容缓存至Buffer中，进行数据的加速读取访问操做，而对于已经修改过的Dirty Buffer，又经过Cache和DBWR进程写回到数据文件中。所以对于一个OLTP（On-Line Transaction Processing）型数据库Buffer Cache是至关重要的。

 

数据库CPU负载情况分析

DB Time(s)=DB Time/Elasped,这里得出的是近似值。能够理解为在数据库运行的这个时段中，DB在调用方面消耗的时间。

DB CPU(s) 表示DB Time时间内，有约0.1S是消耗在CPU上的。

而CPU繁忙程度则须要观察Instance CPU中的Busy CPU项

能够看出该数据库该时间段内CPU 繁忙度为45.4%也是至关空闲的。

Transactions：说明数据库每秒处理事务的个数为71.2,那么这段时间段内总处理的事务数公式：

总事务数=Transactions*Elasped=71.2*1664.7*60=

 

事务的效能比

Buffer Nowait：非等待Buffer事件比

Buffer Hit：Buffer命中率

Library Hit %：库命中率,主要针对数据库的字典信息的查询

Execute to Parse：用于解析的执行比

Parse CPU to Parse Elapsd：CPU解析在整个解析中的时间比

Redo Nowait：非等待Redo事件比

In-memory Sort：内存中的排序的事件比

Soft Parse：在总的解析次数中软解析比率

Latch Hit：闩的命中率

% Non-Parse CPU：非解析CPU使用比

 

共享池状态

SQL with executions：超过1次被调用的SQL语句比例

Memory for SQL w/exec：内存中SQL写操做超过1次比例

 

占用时间前五的前台事件(Top 5 Timed Foreground Events)

DB CPU：占用的时间6411秒, 在整个DB Time时间中占用比为100.09% 说明CPU消耗很高。

log file sync：写入日志文件时间为424秒 占比424/6411*100%近似值

direct path read：

SQL*Net message to client：客户端链接时间

cursor: pin S 游标时间

 

这里Avg wait(ms)的换算是有Time(s)/Waits得到的。上面反映的数据 如log file sync几乎为0，说在该时段内log file sync单次等待的时间近乎为0毫秒（实际值0.06ms) 。这里代表没有发生因日志的写致使的IO迟缓的问题。

 

按SQL执行耗时排序 

 

而DB CPU通常都发生在执行SQL语句和调用Procedure的时候，这里咱们来观察SQL order by CPU

上面的显示了SQL执行的时间占CPU Time前10的SQL语句，在上面Top 5 foreground events中CPU time总计消耗了6411秒，而SQL执行消耗DB CPU时间总计为5359.64秒(%Total)。占了约83.6%的比例。

%CPU是在语句执行消耗的时间中CPU Time的时间比，即CPU Time(s)/Elasped Time(s)

%IO是语句执行的IO时间和Elasped Time比，即IO Time(s)/Elasped Time(s) in Read，经过IO的比能够看到哪些语句的物理读占用比较多，一样能够在SQL order by Read表中获取

 

 经过Reads表能够观察到SQL的物理读的状况，这里的Elasped Time(s)就是用于计算%IO的基数。

经过这个观察，能够看到其中IO读最多的一个语句是SQLPLUS工具中调用了一个语句，很明显该语句的参数了大量的物理读操做。那么就要考虑该语句的优化了。接下来能够观察SQL的逻辑读部分。Gets表示的是SQL语句在Buffer中获取的数据量

 里面统计的Total Buffer Gets总值为527,755,991，%Total=Buffer Gets/Total Buffer Gets

这里的SQL发生总Buffer Gets为784,209,002

 

To Be Continue...... : P