AWR 报告分析

* 在分析awr报告之前，首先要确定我们的系统是属于oltp，还是olap（数据库在安装的时候，选择的时候，会有一个选项，是选择oltp，还是olap）

对于不同的系统，性能指标的侧重点是不一样的，比如，library hit和buffer hit，在olap系统中几乎可以忽略这俩个性能指标，而在oltp系统中，这俩个指标就非常关键了

* 首先要看俩个时间

Elapsed: 240.00 (mins) 表明采样时间是240分钟，任何数据都要通过这个时间来衡量，离开了这个采样时间，任何数据都毫无疑义

DB Time: 92,537.95 (mins) 表明用户操作花费的时候，包括cpu时间和等待时间，也许有人会觉得奇怪，为什么在采样的240分钟过程中，用户操作时间竟然有92537分钟呢，远远超过了

采样时间，原因是awr报告是一个数据的集合，比如在一分钟之内，一个用户等待了30秒，那么10个用户就等待了300秒，对于cpu的话，一个cpu处理了30秒，16个cpu就是4800秒，这些时间都是以累积的方式记录在awr报告中的。

列出下面这两个来做解释：

Report A:

Snap Id Snap Time Sessions Curs/Sess

--------- ------------------- -------- ---------

Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1

End Snap: 4612 24-Jul-08 23:00:25 17 1.7

Elapsed: 59.51 (mins)

DB Time: 466.37 (mins)

Report B:

Snap Id Snap Time Sessions Curs/Sess

--------- ------------------- -------- ---------

Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6

End Snap: 3102 13-Nov-07 22:00:15 40 16.4

Elapsed: 59.63 (mins)

DB Time: 19.49 (mins)

服务器是AIX的系统，4个双核cpu,共8个核:

/sbin> bindprocessor -q

The available processors are: 0 1 2 3 4 5 6 7

先说Report A,在snapshot间隔中，总共约60分钟，cpu就共有60*8=480分钟，DB time为466.37分钟，则：

cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)

也就是说cpu有 466.37/480*100% 花费在处理Oracle的操作上，这还不包括后台进程

看Report B，总共约60分钟，cpu有 19.49/480*100% 花费在处理Oracle的操作上

很显然，2中服务器的平均负载很低。

从awr report的Elapsed time和DB Time就能大概了解db的负载

=========================================

1. Buffer Nowait 说明 在从内存取数据的时候，没有经历等待的比例，期望值是100%

2. Buffer Hit 说明从内存取数据的时候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因为这只是一个比例而已，举个例子，执行一条 sql语句，# 执行计划是需要取10000个数据块，结果内存中还真有这10000个数据块，那么比例是100%，表面上看是性能最高的，还有一个执行计划是需要500 个数据块，内存中有250个，另外250个需要在物理磁盘中取，

这种情况下，buffer hit是50%，结果呢，第二个执行计划性能才是最高的，所以说100%并不代表性能最好

3. Library Hit 说明sql在Shared Pool的命中率，期望值是100%

4. Execute to Parse 说明解析sql和执行sql之间的比例，越高越好，说明一次解析，到处执行，如果parse多，execute少的话，还会出现负数，因为计算公式是100*（1-parse/execute）

5. Parse CPU to Parse Elapsd 说明在解析sql语句过程中，cpu占整个的解析时间比例，，期望值是100%，说明没有产生等待，需要说明的是，即使有硬解析，只要cpu没有出现性能问题，也是可以容忍的，比较硬解析也有它的好处的

6. Redo NoWait 说明在产生日志的时候，没有产生等待，期望值是100%

7. Soft Parse 说明软解析的比例，期望值是100%，有一点要说明的是，不要单方面的追求软解析的高比例，而去绑定变量，要看性能的瓶颈在哪里

8. Latch Hit 说明latch的命中率，期望值是100%，latch类似锁，是一种内存锁，但只会产生等待，不会产生阻塞，和lock还是有区别的，latch是在并发的情况下产生的

9. Non-Parse CPU 说明非解析cpu的比例，越高越好，用100减去这个比例，可以看出解析sql所花费的cpu，100-99.30=0.7，说明花费在解析sql上的cpu很少

==========================

4.1 SQL ordered by Elapsed Time

记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)。

Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time

CPU Time(s): 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。

Executions: SQL语句在监控范围内的执行次数总计。

Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。

% Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。

SQL ID: SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。

SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。

SQL Text: 简单的sql提示，详细的需要点击SQL ID。

4.2 SQL ordered by CPU Time:

记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。

4.3 SQL ordered by Gets:

记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。

4.4 SQL ordered by Reads:

记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。

4.5 SQL ordered by Executions:

记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

4.6 SQL ordered by Parse Calls:

记录了SQL的软解析次数的TOP SQL。说到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。

4.7 SQL ordered by Sharable Memory:

记录了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)：占用library cache的大小，单位是byte。

4.8 SQL ordered by Version Count:

记录了SQL的打开子游标的TOP SQL。

4.9 SQL ordered by Cluster Wait Time:

记录了集群的等待时间的TOP SQL