AWR报告模板
Report Summary
一、DB Time远远小于Elapsed时间，说明数据库比较空闲。如果是大于则说明数据库比较繁忙
举例介绍：
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 A,在snapshot间隔中，总共约60分钟，cpu就共有60*8=480分钟，DB time为466.37分钟，则：
cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)
也就是说cpu有 466.37/480*100% 花费在处理Oracle的操作上，这还不包括后台进程
二、Report Summary-->Load Profile（显示数据库负载情况）
|— Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。
|— Redo size：每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。
|— Parses：SQL解析的次数.每秒解析次数，包括fast parse，soft parse和hard parse三种数量的综合。 软解析每秒超过300次意味着你的"应用程序"效率不高，调整session_cursor_cache。在这里，fast parse指的是直接在PGA中命中的情况（设置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse则是指都不命中的情况。
|— Hard parses：其中硬解析的次数，硬解析太多，说明SQL重用率不高。每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不优。
|— Executes：每秒/每事务SQL执行次数
|— Transactions：每秒事务数.每秒产生的事务数，反映数据库任务繁重与否。
|— Rollback per transaction：每事务的回滚率.看回滚率是不是很高，因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下:
Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%
三、Report Summary-->Instance Efficiency Percentages (Target 100%)（包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率）
本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio，Library Hit ratio也称Library Cache Hit ratio。同Load Profile一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的DSS环境，20%的Buffer Hit Ratio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。根据Oracle的经验，对于OLTPT系统，Buffer Hit Ratio理想应该在90%以上。
|-- Buffer Nowait表示在内存获得数据的未等待比例。在缓冲区中获取Buffer的未等待比率。Buffer Nowait的这个值一般需要大于99%。否则可能存在争用，可以在后面的等待事件中进一步确认。
|-- buffer hit表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存。数据块在数据缓冲区中的命中率，通常应在95%以上。否则，小于95%，需要调整重要的参数，小于90%可能是要加db_cache_size。一个高的命中率，不一定代表这个系统的性能是最优的，比如大量的非选择性的索引被频繁访问，就会造成命中率很高的假相（大量的db file sequential read），但是一个比较低的命中率，一般就会对这个系统的性能产生影响，需要调整。命中率的突变，往往是一个不好的信息。如果命中率突然增大，可以检查top buffer get SQL，查看导致大量逻辑读的语句和索引，如果命中率突然减小，可以检查top physical reads SQL，检查产生大量物理读的语句，主要是那些没有使用索引或者索引被删除的。
|-- Redo NoWait表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。当redo buffer达到1M时，就需要写到redo log文件，所以一般当redo buffer设置超过1M，不太可能存在等待buffer空间分配的情况。当前，一般设置为2M的redo buffer，对于内存总量来说，应该不是一个太大的值。
|-- library hit表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的library hit ratio会导致过多的解析，增加CPU消耗，降低性能。如果library hit ratio低于90%，可能需要调大shared pool区。STATEMENT在共享区的命中率，通常应该保持在95%以上，否则需要要考虑：加大共享池；使用绑定变量；修改cursor_sharing等参数。
|-- Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。
|-- Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。
|-- Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的CPU时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。
|-- Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。计算公式为：Execute to Parse =100 * (1 - Parses/Executions)。本例中，差不多每execution 5次需要一次parse。所以如果系统Parses > Executions，就可能出现该比率小于0的情况。该值<0通常说明shared pool设置或者语句效率存在问题，造成反复解析，reparse可能较严重,或者是可能同snapshot有关，通常说明数据库性能存在问题。
|-- In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA(10g)。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。
|-- Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。 sql在共享区的命中率，小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用
四、Shared Pool Statistics（共享池统计）
|-- Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。这个数字应该长时间稳定在75%～90%。如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内.
|-- SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。
|-- Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与% SQL with executions>1非常接近，除非有某些查询任务消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
Main Report
一、SQL Statistics（sql数据）
SQL ordered by Elapsed Time（按运行时间排序的SQL）
SQL ordered by CPU Time（按CPU时间排序的SQL）
SQL ordered by User I/O Wait Time（按用户I/O等待时间排序的SQL）
SQL ordered by Gets（按get排序的SQL）
SQL ordered by Reads（按读排序的SQL）
SQL ordered by Physical Reads (UnOptimized)（按物理读取顺序排列的SQL(未经优化)）
SQL ordered by Executions（按执行顺序排列的SQL）
SQL ordered by Parse Calls（按解析调用排序的SQL）
SQL ordered by Sharable Memory（按可共享内存排序的SQL）
SQL ordered by Version Count（按版本数排序的SQL）
SQL ordered by Cluster Wait Time（按集群等待时间排序的SQL）
Complete List of SQL Text（完整的SQL文本列表）
本节列出消耗资源最严重的SQL语句，在STATSPACK报告中，没有完整的SQL语句，可使用报告中的Hash Value通过下面语句从数据库中查到：
SELECT sql_text
FROM stats$sqltext
WHERE hash_value = &hash_value
ORDER BY piece;
1、SQL ordered by Gets（按get排序的SQL）
这一部分，通过Buffer Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程，因为存储过程执行的单独的语句的数目被总计出来。在这里的Buffer Gets是一个累积值，所以这个值大并不一定意味着这条语句的性能存在问题。通常我们可以通过对比该条语句的Buffer Gets和physical reads值，如果这两个比较接近，肯定这条语句是存在问题的，我们可以通过执行计划来分析，为什么physical reads的值如此之高。另外，我们在这里也可以关注gets per exec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。
另外说明一点：大量的逻辑读往往伴随着较高的CPU消耗。所以很多时候我们看到的系统CPU将近100％的时候，很多时候就是SQL语句造成的，这时候我们可以分析一下这里逻辑读大的SQL。
SELECT *
FROM ( SELECT SUBSTR (sql_text, 1, 40) sql,
buffer_gets,
executions,
buffer_gets / executions "Gets/Exec",
hash_value,
address
FROM v$sqlarea
WHERE buffer_gets > 0 AND executions > 0
ORDER BY buffer_gets DESC)
WHERE ROWNUM <= 10;
2、SQL ordered by Reads（按读排序的SQ）
这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL，即物理I/O。当我们的系统如果存在I/O瓶颈时，需要关注这里I/O操作比较多的语句。
SELECT *
FROM ( SELECT SUBSTR (sql_text, 1, 40) sql,
disk_reads,
executions,
disk_reads / executions "Reads/Exec",
hash_value,
address
FROM v$sqlarea
WHERE disk_reads > 0 AND executions > 0
ORDER BY disk_reads DESC)
WHERE ROWNUM <= 10;
3、SQL ordered by Executions（按执行顺序排列的SQL：执行次数最多的SQL语句）
Total Executions: 9,210,909（总执行:9210909）
Captured SQL account for 62.9% of Total（捕获的SQL占总数的62.9%）
这部分告诉我们在这段时间中执行次数最多的SQL语句。为了隔离某些频繁执行的查询，以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询，这可能是很有用的。或许一个查询正在一个循环的内部执行，而且它可能在循环的外部执行一次，可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的飞快，任何被执行几百万次的操作都将开始耗尽大量的时间。
SELECT *
FROM ( SELECT SUBSTR (sql_text, 1, 40) sql,
executions,
rows_processed,
rows_processed / executions "Rows/Exec",
hash_value,
address
FROM v$sqlarea
WHERE executions > 0
ORDER BY executions DESC)
WHERE ROWNUM <= 10;
4、SQL ordered by Parse Calls（按解析调用排序的SQL）
在这一部分，主要显示PARSE与EXECUTIONS的对比情况。如果PARSE/EXECUTIONS>1，往往说明这个语句可能存在问题：没有使用绑定变量，共享池设置太小，cursor_sharing被设置为exact，没有设置session_cached_cursors等等问题。
SELECT *
FROM ( SELECT SUBSTR (sql_text, 1, 40) sql,
parse_calls,
executions,
hash_value,
address
FROM v$sqlarea
WHERE parse_calls > 0
ORDER BY parse_calls DESC)
WHERE ROWNUM <= 10;
5、SQL ordered by Sharable Memory（按可共享内存排序的SQL）
在这一部分，主要是针对shared memory占用的情况进行排序。
SELECT *
FROM ( SELECT SUBSTR (sql_text, 1, 40) sql,
sharable_mem,
executions,
hash_value,
address
FROM v$sqlarea
WHERE sharable_mem > 1048576
ORDER BY sharable_mem DESC)
WHERE ROWNUM <= 10;
6、Running Time top 10 sql
SELECT *
FROM ( SELECT t.sql_fulltext,
(t.last_active_time
- TO_DATE (t.first_load_time, 'yyyy-mm-dd hh24:mi:ss'))
* 24
* 60,
disk_reads,
buffer_gets,
rows_processed,
t.last_active_time,
t.last_load_time,
t.first_load_time
FROM v$sqlarea t
ORDER BY t.first_load_time DESC)
WHERE ROWNUM < 10;