awr分析要点记录

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

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。
SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。
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