http://blog.sina.com.cn/s/blog_854ec93b01018rwt.html Oracle_AWR_报告分析实例讲解
1、选择能够代表性能问题的时间段：因为数据库的负载总是集中在一段时间内。
2、shared pool主要包括library cache和dictionary cache：
library cache用来存储最近解析（或编译）后SQL、PL/SQL和Java classes等。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。
3、Load Profile：（系统负载 ）
显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。
4、Instance Efficiency Percentages (Target 100%)--实例效率
|
Buffer Nowait %: |
100.00 |
Redo NoWait %: |
100.00 |
|
Buffer Hit %: |
98.72 |
In-memory Sort %: |
99.86 |
|
Library Hit %: |
99.97 |
Soft Parse %: |
99.92 |
|
Execute to Parse %: |
89.09 |
Latch Hit %: |
99.99 |
|
Parse CPU to Parse Elapsd %: |
7.99 |
% Non-Parse CPU: |
99.95 |
本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。
根据Oracle的经验，对于OLTPT系统，Buffer Hit Ratio理想应该在90%以上。
buffer hit：表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存
Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。
Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。
Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。
Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA。
Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。
5、Shared Pool Statistics
|
|
Begin |
End |
|
Memory Usage %: |
47.19 |
47.50 |
|
% SQL with executions>1: |
88.48 |
79.81 |
|
% Memory for SQL w/exec>1: |
79.99 |
73.52 |
1 Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。
2 SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。
3 Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。
6、Top 5 Timed Events
|
Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
|
CPU time |
|
515 |
|
77.6 |
|
|
SQL*Net more data from client |
27,319 |
64 |
2 |
9.7 |
Network |
|
log file parallel write |
5,497 |
47 |
9 |
7.1 |
System I/O |
|
db file sequential read |
7,900 |
35 |
4 |
5.3 |
User I/O |
|
db file parallel write |
4,806 |
34 |
7 |
5.1 |
System I/O |
这是报告概要的最后一节，显示了系统中最严重的5个等待，按所占等待时间的比例倒序列示。
当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。例如如果‘buffer busy wait’是较严重的等待事件，我们应当继续研究报告中Buffer Wait和File/Tablespace IO区的内容，识别哪些文件导致了问题。
如果最严重的等待事件是I/O事件，我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O，并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待，就需要察看详细的LATCH统计识别哪些LATCH产生的问题。
在这里，log file parallel write是相对比较多的等待，占用了7%的CPU时间。
通常，在没有问题的数据库中，CPU time总是列在第一个。
在上面的分析中，并没有涉及到RAC的相关性能数据的分析，上面的基本上是系统分析的概要，可以概括这个instance的基本性能问题，下一步会增加RAC相关性能数据的说明。
by taowang2016 on 2013-04-22 9:48:01