ORACLE AWR性能报告和ASH性能报告的解读

数据库的性能分析可分为会话级和系统级：如果确定某个会话存在性能问题，最常见的分析方式是对这个会话做一个SQL_TRACE或者10046事件，通过分析trace文件来定位问题所在。如果无法确定哪个会话性能有问题，就需要从实例级别来分析问题所在。



awr是oracle 10g下提供的一种性能收集和分析工具，它能够提供一个时间段内整个系统资源使用情况的报告。

awr默认收集最近7天的采集信息，也可通过以下方法修改快照收集时间间隔信息。





awr由运行在oracle的后台进程自动、定期收集数据库的性能数据并保存，每一个小时，awr都生成一次性能数据快照，为DBA提供某个时刻数据库性能分析的数据信息。

执行$ORACLE_HOME/RDBMS/ADMIN/awrrpt.sql生成awr报告。



awr报告要根据系统实际情况(OLAP or OLTP)来进行分析,例如对于一个OLTP系统，library hit和buffer hit应比较关注。而对于OLAP不甚重要。



awr报告不需要全面阅读，全面阅读可能思路会更乱，如果性能问题由某个原因引起，那么会在报表的各个部分都会有相应呈现。



在RAC结构的数据库里做性能分析，通常需要对每个实例做一个awr性能报告，原因是无法知道每个用户连接到哪个实例当中去。



对于一个系统，需要多做几次awr报告，以便得到所有时间段的系统性能数据。在查看awr报告时，如果了解数据库业务,应该有针对性

的看一些可能存在性能问题的部分，并结合业务的实际情况来判断；也可以从TOP5的等待事件触发，按照等待事件的类型，

到相应的部分获取详细的信息来对系统性能问题作出判断。



通过awr报告可以：1）查看系统的负载和繁忙程度；2）查看系统的瓶颈，发生的等待事件；3）查看可优化的sql；



一、Report Summary:

1、SESSIONS：实例连接的会话数，数据库大概的并发用户数；

2、cursors/session：每个会话平均打开的游标数；

3、DB time：用户操作花费的时间的合集，包括CPU时间和等待事件；

4、cache sizes：列举awr在性能采集开始和结束的时候，数据缓冲池和共享池的大小，可以了解系统内存消耗的变化，可以判断SGA的内存分配是否合理；

5、load profile：数据库资源负载的一个明细列表，用来判断系统的繁忙程度。分割为每秒钟的资源负载和每个事务的资源负载情况。

6、Instance Efficiency Percentages：内存效率的统计信息，对于OLTP系统，应尽可能的接近100%。如果哪个数据偏低，就要做相关的分析研究。

    1）buffer nowait：非等待方式获取数据库；

    2）redo nowait：非等待方式获取redo数据；

    3）buffer hit：内存数据块命中率；

    4）in-memory sort：数据块在内存中排序的百分比；

    5）library hit：共享池中sql解析的命中率；

    6）execute to parse：执行次数对分析次数的百分比；

    7）latch Hit：latch命中率百分比；

    8）parse cpu to parse elapsed：解析总时间中消耗CPU的时间百分比；

    9）non-parse cpu：cpu非分析时间在整个cpu时间的百分比；

7、TOP 5 TIMED EVENTS：查看最高5个耗费时间及等待事件，要联系报告的采集周期来看耗费时间是否合理。一般来说，CPU time出现在TOP5中的第一位，并且消耗时间占总时间的大部分比例。可以说明系统在正常运行。

对于ORACLE常见的等待事件可参考http：//blog.itpub.net/29371470/viewspace-1063994/

以上这部分就是awr报告的总体概要，是需要重点关注的部分，根据这些信息可以知道等待时间比较长的事件，然后根据这些事件，去下面具体的部分查找问题原因。



二、Wait Events Statistics：

1、Time Model Statistics列出了各种操作占用的数据库时间比例；

2、Foreground Wait Class列出了等待事件类型，可以看到等待时间最长的事件；

3、Foreground Wait Events是第一部分TOP 5 TIMED EVENTS的详细部分；

4、Background Wait Events实例的后台进程等待事件；



三、SQL Statistics：

1、SQL ordered by Elapsed Time：按照sql的执行时间从长到短的排序；

   1）CPU time：sql消耗的CPU时间；

   2）elapsed time：sql执行时间；

   3）executions：sql执行的次数；

   4）elapsed per exec：每次执行消耗的执行时间；

2、SQL ordered by CPU Time：按照sql的CPU时间从长到短排序：

3、SQL ordered by User I/O Wait Time：

4、SQL ordered by Gets：按照sql获取的内存数据块的数量排序： 

5、SQL ordered by Reads按照sql执行物理读排序： 

6、SQL ordered by Physical Reads (UnOptimized)：

7、SQL ordered by Executions：按照sql的执行次数的排序；

8、SQL ordered by Parse Calls：按照sql被分析次数（不区分软解析还是硬解析）的信息排序；

9、SQL ordered by Version Count：sql产生多版本的信息；version count是sql的版本数；

以上指标孤立起来看都没有实际意义，需要看系统的类型和性能问题是什么方面，有侧重的进行分析。例如SQL ordered by Executions和SQL ordered by Parse Calls对OLTP比较重要，而OLAP系统不需要太关注。



四、Instance Activity Statistics：

cpu used by this session：oracle消耗的cpu单位,可以看出cpu的负载情况；如果total为1000，per sec 为80，cpu个数为2；

那么就是整个统计周期消耗了1000个cpu单位，每秒钟消耗了80个cpu单位，对应实际的时间是80/100=0.8秒；每秒钟每个cpu消耗80/2=40个cpu单位；每秒钟中每个cpu处理使用的时间是40/100=0.4秒。



五、IO Stats：

Tablespace IO Stats：表空间的IO性能统计；

File IO Stats：

   1）reads：发生了多少次物理读；

   2）writes：发生了多少次写；

   3）Av reads：每秒钟物理读的次数；

   4）Av Rd：平均一次物理读的时间；

   5）Blks/Rd：每次读多少个数据块；

   6）Av writes：每秒钟写的次数；

   7）buffer waits：获取内存数据块等待的次数；

segments by logical reads和segment by physical reads从对象角度来展现了IO情况，分析这两部分信息，可以具体知道哪些对象的访问导致了IO性能下降。





ASH侧重于当前数据中活动会话的信息分析，被长期保存在数据字典中，可以通过查询视图V$ACTIVE_SESSION_HISTROY来得到。

运行脚本为$ORACLE_HOME/RDBMS/ADMIN/ashrpt.sql

使用同目录下的ashrpti.sql脚本可以生成其他数据库或者实例的ASH性能报告，也可以对一个session ID、SQL_ID、某个程序或者某一类等待事件

来生成ASH报告，如下图：



ASH报告分析如下：

DATA SOURCE如果来自DBA_HIST_ACTIVE_SESS_HISTORY,那么说明这些信息来自于AWR的快照；如果来自于V$ACTIVE_SESSION_HISTORY,那么

视图的信息就意味着性能数据存放到内存中的信息。

1、top user events:用户会话的等待事件的信息；

2、top event p1/p2/p3 values:等待事件的具体描述；

3、top service/module:按照活动频率列出前五位的应用程序；

4、top sql command types:列出了数据库中活动最频繁的操作；

5、top sql statements:按活动频繁程度列出sql语句；

6、top session:列出活动最频繁的会话或进程；

7、top sessions running PQs:列出活动频繁的前几位并行执行的会话信息；

8、top DB files：IO最频繁的数据文件；

9、activity over time:按照一个时间间隔对采集时间周期分组后，生成的每个时间间隔里的等待事件信息。