AWR报表解读-01

一、报表头

WORKLOAD REPOSITORY report for

DB Name	DB Id	Instance	Inst num	Release	RAC	Host
ORA10G	4018937891	ora10g	1	10.2.0.1.0	NO	FS-62

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	12242	16-3月 -11 12:43:35	99	1.7
End Snap:	12269	17-3月 -11 15:01:41	145	8.3
Elapsed:		1,578.09 (mins)
DB Time:		210.48 (mins)

Report Summary

Cache Sizes

	Begin	End
Buffer Cache:	408M	480M	Std Block Size:	8K
Shared Pool Size:	160M	88M	Log Buffer:	6,968K

 

二、负载简档

Load Profile

	Per Second	Per Transaction
Redo size:	4,976.63	11,231.44
Logical reads:	1,318.04	2,974.60
Block changes:	42.99	97.02
Physical reads:	3.64	8.22
Physical writes:	0.88	1.99
User calls:	87.23	196.86
Parses:	15.06	34.00
Hard parses:	2.71	6.13
Sorts:	11.96	26.99
Logons:	0.57	1.30
Executes:	42.91	96.85
Transactions:	0.44

% Blocks changed per Read:	3.26	Recursive Call %:	67.23
Rollback per transaction %:	24.00	Rows per Sort:	72.96

如果重做数据块增加，块更改变得频繁，以及每次读操作%BLOCKS增加，都意味着DML语句活动的增加；

如果SQL语句不再共享池中分析，就会呈现硬分析，硬分析超过100次/秒就意味着绑定变量的使用效率不高，

应当使用CURSOR_SHARING初始化参数；或者说明共享池大小有问题；

如果SQL语句在共享池中运行就会出现软分析，软分析超过300次/秒就说明应用程序效率不高，语句被反复分析，

而不是对应每个会话应只分析语句一次，以保证高效率。

 

三、实例的效率

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: 100.00 Redo NoWait %: 99.99Buffer Hit %: 99.80 In-memory Sort %: 100.00Library Hit %: 94.51 Soft Parse %: 81.98Execute to Parse %: 64.90 Latch Hit %: 99.96Parse CPU to Parse Elapsd %: 78.02 % Non-Parse CPU: 82.86

BUFFER NOWAIT%

低于99： 这是一个对特定缓冲区的请求命中率，在内存中该缓冲区应该立即可用。如果命中率下降，

在BUFFER WAIT部分将发现当前存在热数据块的争用想象；

BUFFER HIT%低于95：这是一个对特定缓冲区的请求命中率，并且缓冲区位于内存中，而无需物理磁盘的IO操作。

如果你在访问时经常使用非选择性索引，它将使命中率很高，这将导致很多DBA误认为系统性能很好。

高命中率不说明系统性能一定高，但低命中率一定说明低性能；

LIBRARY HIT%低于95：较低的库命中率通常意味着SQL过早的被推出缓冲池（可能是因为缓冲池太小了）。较低的命中率

还意味着没有使用绑定变量或者一些其他问题造成SQL没有被重用；

OLTP中的IN MEMORY SORT%低于95：在一个OLTP系统中，调整PGA_AGGREGATE_TARGET,SORT_AREA_SIZE可以有效解决该问题；

SOFT PARSE%低于95：软分析低于80说明SQL没有被重用；

LATCH HIT%低于99：通常是个大问题，找到特定的闩锁可以解决问题。

 

四、五个最重要的等待事件

Top 5 Timed Events

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
SQL*Net more data to client	762,278	8,827,093	11,580	69,895.5	Network
log file sync	14,068	8,298,607	589,892	65,710.8	Commit
db file sequential read	55,449	5,286,862	95,346	41,862.9	User I/O
log file parallel write	51,756	3,060,269	59,129	24,232.1	System I/O
db file parallel write	43,403	2,095,949	48,290	16,596.3	System I/O

 

首要等待事件是整个报表中最能揭示问题的部分，如果TIMED_STATISTICS是TRUE，那么事件将按照等待的时间排序，否则将按照等待的数量排序。

 

Wait Events

s - second cs - centisecond - 100th of a second ms - millisecond - 1000th of a second us - microsecond - 1000000th of a second ordered by wait time desc, waits desc (idle events last)

Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txnSQL*Net more data to client 762,278 0.00 8,827,093 11580 18.17log file sync 14,068 0.00 8,298,607 589892 0.34db file sequential read 55,449 0.00 5,286,862 95346 1.32log file parallel write 51,756 0.00 3,060,269 59129 1.23db file parallel write 43,403 0.00 2,095,949 48290 1.03db file scattered read 34,260 0.00 1,644,941 48013 0.82control file parallel write 31,887 0.00 1,600,072 50179 0.76direct path read 25,188 0.00 1,479,752 58748 0.60control file sequential read 23,095 0.00 815,458 35309 0.55SQL*Net message to client 8,573,047 0.00 177,975 21 204.34latch: session allocation 720 0.00 151,013 209741 0.02library cache pin 1,256 0.00 150,085 119494 0.03enq: RO - fast object reuse 129 0.00 131,440 1018915 0.00latch: library cache 1,536 0.00 119,347 77700 0.04os thread startup 320 1.88 84,768 264901 0.01latch: shared pool 1,062 0.00 72,219 68003 0.03SQL*Net break/reset to client 1,616 0.00 51,430 31825 0.04latch: cache buffers chains 412 0.00 37,860 91893 0.01reliable message 105 0.00 31,729 302176 0.00latch free 388 0.00 30,572 78794 0.01SQL*Net more data from client 38,992 0.00 28,933 742 0.93LGWR wait for redo copy 3,825 0.10 21,912 5729 0.09enq: TX - row lock contention 125 0.00 16,048 128386 0.00library cache load lock 444 0.00 11,228 25288 0.01log buffer space 9 0.00 10,088 1120838 0.00kksfbc child completion 109 100.00 8,504 78016 0.00latch: library cache lock 72 0.00 6,406 88968 0.00read by other session 36 0.00 6,067 168540 0.00log file switch completion 26 7.69 5,803 223200 0.00buffer busy waits 35 0.00 4,248 121379 0.00rdbms ipc reply 285 0.00 4,012 14077 0.01latch: enqueue hash chains 2 0.00 3,036 1518074 0.00latch: messages 3 0.00 3,026 1008799 0.00enq: SQ - contention 34 0.00 2,917 85786 0.00latch: library cache pin 43 0.00 2,744 63811 0.00log file switch (checkpoint incomplete) 5 60.00 2,279 455745 0.00latch: row cache objects 17 0.00 2,217 130424 0.00cursor: mutex X 1,351 0.00 1,876 1388 0.03latch: cache buffers lru chain 2 0.00 1,044 522002 0.00SGA: allocation forcing component growth 10 40.00 35 3516 0.00direct path write 232 0.00 3 12 0.01buffer exterminate 3 0.00 2 568 0.00latch: In memory undo latch 2 0.00 1 600 0.00log file sequential read 20 0.00 0 18 0.00log file single write 20 0.00 0 13 0.00row cache lock 11 0.00 0 23 0.00db file parallel read 1 0.00 0 13 0.00enq: CF - contention 1 0.00 0 5 0.00undo segment extension 456 100.00 0 0 0.01direct path write temp 428 0.00 0 0 0.01latch: redo allocation 8 0.00 0 0 0.00cursor: mutex S 5 0.00 0 0 0.00SQL*Net message from client 8,572,916 0.00 512,942,718 59833 204.34pipe get 84,729 0.22 3,037,535 35850 2.02SGA: MMAN sleep for component shrink 892 55.61 568,172 636964 0.02Streams AQ: qmn coordinator idle wait 6,858 50.83 190,038 27710 0.16Streams AQ: waiting for time management or cleanup tasks 2,929 58.89 114,168 38978 0.07jobq slave wait 34,360 92.11 102,569 2985 0.82virtual circuit status 3,156 100.00 94,324 29887 0.08Streams AQ: qmn slave idle wait 3,372 0.00 94,291 27963 0.08class slave wait 55 100.00 269 4897 0.00DB FILE SCATTERED READ ： 该等待事件意味着等待与全表扫描或快速全索引扫描有关，该指数过大说明缺少索引或者限制使用索引，这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。DB_FILE_MULTIBLOCK_READ_COUNT能够加快全扫描（但也可能影响ORACLE完成更多扫描）。可以将表或者索引分区，以便至扫描其中一部分。缓慢的磁盘IO也会导致该等待；

DB FILE SEQUENTIAL READ：该等待事件通常指单一的数据块读操作，例如索引的读取，该值过大说明表的连接顺序很糟糕，或者使用了非选择性索引。在一个高事务量，做过较好调整的系统中该数字通常较大。以排序的方式加载数据有助于范围扫描，还可以减少块读取的数量，分区也有帮助，分区可以排除一些块。注意非选择性索引会导致许多快读取。

BUFFER BUSY WAITS IDS:当一个缓冲区以一种非共享方式被使用或者正被读入缓存时会出现这种等待，

BUFFER BUSY WAIT不应该高于1%；

buffer busy/Segment Header:如果等待针对一个段的头信息，就增加空闲列表或者空闲列表组的数量，

或者扩大PCTUSED与PCTFREE之间的间隔。

buffer busy/Undo Header:如果等待是针对一个撤销请求的头信息，则可以通过增加会滚段或者增加

撤销区域来解决；

Buffer Busy/Undo Block:如果是针对一个撤销的数据块，应该适当加快提交（不能过快，否则会引起

日志同步问题）或者使用更大的回滚段或者撤销区。需要减少驱动一致性读操作的表上的数据密集度

或者增加DB_CACHE_SIZE;

Buffer Busy/Data Block:如果等待是发生在一个数据快上，就可以将数据移动到另外一个数据快上，

以避开这个热数据块，或者使用更小的数据块（以减少每个数据块的行数，降低他的热度）；

Buffer Busy/Index Block：

Latch Free：闩锁是底层的队列机制（更加准确得说是互斥机制），用于保护系统全局去SGA的共享

内存结构。如果闩锁不可用，就会记录一次闩锁丢失。多大多数的闩锁丢失问题都与使用绑定变量失

败（库缓存闩锁和共享池闩锁）、生成重做日志问题、缓存的征用问题以及缓存的热数据块有关系。闩锁

也与BUG有关，当闩锁丢失率高于0.5%就应当到oracle.com/support查找一下METLINK的BUG报告；

ENQUEUE:入列是保护共享资源的一种锁机制。这种锁保护共享资源，例如一条记录中的数据，以防止两个人

同时更新同一条数据，排队机制是FIFO（ORACLE的栓锁机制不是FIFO）；

Log File Switch: 确保归档的磁盘未满，并且速度足够快。由于IO的原因，DBWR可能速度很慢。可能需要

增加更多更大的日志文件，并且如果DBWR存在问题，你可能需要增加DBWR进程数；

LOG BUFFER SPACE:数据库发生改变时，改变的块被复制到日志缓冲区。如果日志缓冲区不能足够快的

写入重做日志，就会导致LOG BUFFER SPACE问题。当一次提交大量事务时也会产生这个问题。

这种等待出现在写日志缓冲区的速度快于LGWR写重做日志的速度，或者是日志切换太慢了，但通常不是因为

日志缓冲区太小。可以增加日志文件的尺寸，或者使用更快的磁盘写日志，但最终手段可以增加日志缓冲

区的尺寸。

LOG FILE SYNC:为了减少日志文件同步等待，可以尝试一次批量提交更多的记录而不是逐条提交，

可以使用更快的磁盘或者裸设备或者RAID10(而不是RAID5,RAID5写性能太差)；

Global Cache CR Request:当使用多个实例时（RAC）当一个实例等待另一个实例缓存的数据块时就会发生

Global Cache CR Request;

Log File Parallel Write:将重做日志放到较快的磁盘上，不要使用RAID5,将日志文件和数据文件分开存放；

Direct Path Read：ORACLE通常使用DIRECT PATH READS直接将数据块读入PGA，它可用于排序、并行查询

和提前读操作。这里的时间并不总是反映实际等待时间。这通常是文件I/O的问题。使用异步I/O可以减少消耗时间，

但是不会减少等待时间；

Direct Path Write:

Async Disk I/O:ORACLE等待异步写操作完成，或者等待写入的异步从属。问题可能是DBWR,LGWR,ARCH,CKPT

有关的I/O问题，但通常是某个文件I/O问题。

IDEL EVENTS:闲置时间保存在STATS$IDLE_EVENT表中。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23754390/viewspace-689772/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23754390/viewspace-689772/