其实，网上关于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
