關于AWR報表的解讀

一、運作$ORACLE_HOME/rdbms/admin下awrrpt.sql生成awr報表

二、報表中比較重要的部分

1.load profile

Per Second	Per Transaction
Redo size:	1,053.75	11,886.69
Logical reads:	36.31	409.59
Block changes:	6.36	71.73
Physical reads:	0.21	2.37
Physical writes:	0.34	3.82
User calls:	0.10	1.11
Parses:	1.43	16.14
Hard parses:	0.21	2.31
Sorts:	0.89	10.09
Logons:	0.03	0.36
Executes:	3.31	37.34
Transactions:	0.09

% Blocks changed per Read:	17.51	Recursive Call %:	99.65
Rollback per transaction %:	0.00	Rows per Sort:	77.83

這個表裡應該注重：

1）logical reads和physical reads，同時也可以得到平均每個邏輯讀導緻多少實體讀，即0.21/36.31=0.57%。平均每個事務産生了409.59個邏輯讀，這個數字應該越小越好。

2）parses 和hard parses：從表中可以看到cpu平均每秒進行了1.43個解析（超過100個應該注意），每秒進行0.21（超過10個應該注意）次硬解析，即cpu每秒要處理0.21個全新的sql，應該說很閑。

3）% Blocks changed per Read 17.51%，說明82.49%（1-17.51%）的邏輯讀是用于隻讀而不是修改資料塊。

4）Recursive Call%标明通過pl/sql來執行sql的比率。

5）rollback per transaction 表明事務復原的百分比，對這個資料的分析應該參考前面transactions（0.09），這個值應該越小越好。

2.Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:	100.00	Redo NoWait %:	100.00
Buffer Hit %:	99.42	In-memory Sort %:	100.00
Library Hit %:	91.99	Soft Parse %:	85.67
Execute to Parse %:	56.77	Latch Hit %:	100.00
Parse CPU to Parse Elapsd %:	98.27	% Non-Parse CPU:	74.28

1）buffer nowait,不應低于99%；

2）buffer hit，不應低于99%；

3）library hit，不應低于95%--本系統為91.99%，說明該資料庫中可能存在library cache 的争用；

4）soft parse，不應低于95%，說明sql語句的重用性不好；

5）latch hit，此數值如果低于95%說明資料庫存在嚴重問題；

6）execute to parse%，說明sql語句執行與解析的比率。本資料庫為56.77%，說明有43.23%的sql為新sql；

7）Parse CPU to Parse Elapsd %，=98.27%，說明如果cpu解析語句需要1秒，需要1/0.9827=1.02的總時間完成，說明cpu解析sql有0.02秒的時間來等待某種資源的釋放，該值越小越好；

8）Non-parse CPU，說明花費在十幾工作的時間和花費在解析上的時間的對比。

3.Shared Pool Statistics

Begin	End
Memory Usage %:	99.08	96.00
% SQL with executions>1:	83.62	81.22
% Memory for SQL w/exec>1:	91.76	88.96

1）Memory Usage ，說明在shared pool中，被使用的部分占shared pool總尺寸的百分比。這個值應保持适中，(如85%）,如果太高，則會引起shared pool中的對象被刷出記憶體，進而導緻sql語句的硬解析增加，太低則浪費記憶體；

2）SQL with executions>1，執行次數大于1次的sql占總sql數的百分比，越大越好；

3）Memory for SQL w/exec>1，在shared pool中執行次數大于1次的sql語句所消耗的記憶體占shared pool的百分比。

4.Top 5 Timed Events

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
CPU time	202	69.1
control file sequential read	57,817	111	2	38.1	System I/O
os thread startup	2,124	79	37	27.2	Concurrency
db file sequential read	18,814	71	4	24.2	User I/O
db file parallel write	31,698	20	1	7.0	System I/O

檢視這個可以檢視前五位的等待時間，oracle的等待事件有800多種，且大都互相關聯，往往解決好前五位的等待事件就能夠解決大多數的等待事件，收到事半功倍的效果。

5.SQL Statistics -->SQL ordered by Gets

• Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
• Total Buffer Gets: 4,967,556
• Captured SQL account for 49.4% of Total

Buffer Gets	Executions	Gets per Exec	%Total	CPU Time (s)	Elapsed Time (s)	SQL Id	SQL Module	SQL Text
674,362	13.58	32.51	57.14	b6usrg82hwsa3	DBMS_SCHEDULER	call dbms_stats.gather_databas...
539,858	1,762	306.39	10.87	48.84	54.27	6gvch1xu9ca3g	DECLARE job BINARY_INTEGER := ...
463,562	3	154,520.67	9.33	1.08	1.09	gfjvxb25b773h	select o.owner#, o.obj#, decod...
203,851	1,444	141.17	4.10	0.78	0.96	cvhk2j2gymzhd	DBMS_SCHEDULER	SELECT SU.NAME, SO.NAME, A.S...
155,683	1,319	118.03	3.13	13.19	14.03	abtp0uqvdb1d3	CALL MGMT_ADMIN_DATA.EVALUATE_...
88,060	1,960	44.93	1.77	6.26	7.07	8a1pvy4cy8hgv	insert into histgrm$(obj#, int...
78,038	25,918	3.01	1.57	2.85	2.85	803b7z0t84sq7	select job, nvl2(last_date, ...
71,659	9,999	7.17	1.44	0.54	0.56	6769wyy3yf66f	select pos#, intcol#, col#, sp...
70,539	1,044	67.57	1.42	6.23	6.94	4y1y43113gv8f	delete from histgrm$ where obj...
65,695	19,196	3.42	1.32	4.91	5.23	3c1kubcdjnppq	update sys.col_usage$ set eq...
64,291	7,544	8.52	1.29	3.41	3.45	7ng34ruy5awxq	select i.obj#, i.ts#, i.file#,...
62,092	1,444	43.00	1.25	0.19	0.19	g1xapjmt4vm5c	DBMS_SCHEDULER	SELECT SU.NAME, SO.NAME, A.S...
59,666	5,500	10.85	1.20	1.28	1.28	0h6b2sajwb74n	select privilege#, level from ...
57,990	36	1,610.83	1.17	2.38	3.37	70vs1d7ywk5m0	MMON_SLAVE	begin dbms_stats.copy_table_st...
52,548	3,328	15.79	1.06	0.71	0.91	cqgv56fmuj63x	select owner#, name, namespace...

在這裡我們可以看到哪些sql語句掃描過多的資料塊才能傳回結果，這些語句需要優化。

6.IO Stats -->Tablespace IO Stats

Tablespace	Reads	Av Reads/s	Av Rd(ms)	Av Blks/Rd	Writes	Av Writes/s	Buffer Waits	Av Buf Wt(ms)
SYSAUX	9,553	4.07	1.65	19,729	0.00
UNDOTBS	7,879	3.21	1.00	8,252	20	5.50
SYSTEM	2,496	4.74	1.62	4,469	0.00
USERS	364	3.08	1.57	4	0.00
TEMP	34	3.24	12.35	25	0.00
TEST2	4	47.50	1.00	4	0.00

1）可以找到具有頻繁讀寫活動的表空間或資料檔案，如果臨時表空間的寫入數量最高，說明排序太多太大；

2）從AVG BLKS/RD列可以看出，哪些表空間上經曆了最多的全表掃描，如果值大于1，則應該将該值與初始化參數db_file_multiblock_read_count的值進行比較，如果他們越接近，說明在該表空間上進行的大部分是全表掃描；

3）檢查AV RD(MS),該清單明I/O讀的時間，值應該小于20ms，如果過大應該檢查是否将讀寫很頻繁的檔案放在了同一個磁盤上。

7.Segment Statistics

1）Segments by Logical Reads或Segments by Physical Reads 可以找到邏輯讀或實體讀比較大的對象，并查找原因，是否可以通過建立新索引、或采用分區表等來降低對象的邏輯讀以及實體讀；

2）Segments by Row Lock Waits ，通過這個報表可以找到獲得行級鎖最嚴重的對象，需要跟開發人員探讨解決方法；

3）Segments by ITL Waits ，這個報表可以标明獲得ITL等待最嚴重的對象，如果發現了ITL等待很嚴重的對象，則應該将對象的initrans參數設定為并發操作該對象的程序個數；

4）Segments by Buffer Busy Waits，獲得buffer busy waits最嚴重的對象。在同一時刻隻有一個程序能夠通路同一個資料塊，其它程序必須等待。解決的關鍵是優化那些掃描了過多資料塊的sql語句，減少他們要掃描的資料塊。如果已經優化了sql語句，則可以考慮增大pctfree的值，進而減少一個資料塊中能夠包含的資料行數，進而将對象的資料行分部到更多的資料塊裡去。

六、執行個體活動統計資料

比較在記憶體中和磁盤中的排序量，如果磁盤排序太高就需要增加PGA_AGGREGATE_TARGET(或者舊版本中增大SORT_AREA_SIZE)

如果磁盤的讀操作較高，表明可能執行了全表掃描，如果目前存在大量的較大的對較大表的全表掃描，就應當評估最常用的查詢

并通過增加索引來提高效率。大量的非一緻性讀操作意味着使用了過多的索引或者使用了非選擇性索引。如果髒讀緩沖區數量高于

所請求的空閑緩沖區的數量（超過5%），那麼說明DB_CACHE_SIZE太小，或者沒有建立足夠多的檢查點。如果葉節點的分裂數量很高

可以考慮重建已增長或已經碎化的索引。

consistent gets:沒有使用select for update子句的查詢在緩沖中通路的資料塊數量，這個數量加上DB BLOCK GETS統計資訊的值

就是邏輯讀操作總數

DB BLOCK GETS:使用了INSERT UPDATE DELETE OR SELECT FOR UPDATE語句在緩存中通路的資料塊數量。

PHYSICAL READS:沒有從緩存中度取得資料量。可以從磁盤，作業系統緩存或者磁盤緩存中讀取，以滿足SELECT,SELECT FOR UPDATE,

INSERT,UPDATE,DELETE語句

LOGICAL READS=CONSISTENT GETS+DB BLOCK GETS

緩存命中率HIT RATIO=(LOGICAL READS- PHYSICAL READS)/LOGICAL READS *100%

        =(CONSISTENT GETS+DB BLOCK GETS- PHYSICAL READS)/(CONSISTENT GETS+DB BLOCK GETS) *100%

緩存命中率應該高于95%，否則需要增加DB_CACHE_SIZE。

DIRTY BUFFERS INSPECTED:從LRU清單中清除掉的髒讀（經過修改的）資料緩沖區的數量，如果此值超過0，可以考慮增加DB_WR程序。

ENQUEUE TIMEOUTS:請求入列的次數（鎖定），以及所請求的特定隊列不可用的次數。如果這個統計資訊大于0，就需要調查鎖定問題。

FREE BUFFER INSPECTED:由于是髒讀資料、被固定或者正忙等原因兒跳過的緩沖區數量。如果數量很大的話就說明緩沖區緩存太小了。

PARSE COUNT:一條SQL語句被解析的次數。

RECURSIVE CALLS:資料庫中遞歸調用的數量。如果某個程序中的遞歸調用數量大于4，就應當檢查資料字典緩存的命中率，

以及是否有表或者索引的範圍過大。除非使用了大量PL/SQL，否則在使用者調用中，遞歸調用所占的比例應該低于10%。

REDO SIZE:寫入日志中，以位元組為機關的重做資訊的數量。該資訊将有助于确定重做日志的大小。

SORTS(DISK):磁盤排序的數量。磁盤排序除以記憶體排序數量不應該高于5%.否則需要調整SORT_AREA_SIZE,PGA_AGGREGATE_TARGET的大小

注意：SORT_AREA_SIZE配置設定的記憶體是面向每個使用者的，PGA_AGGREGATE_TARGET配置設定的記憶體是面向所有會話的。

SORTS(MEMORY):在記憶體中排序的數量。

SORTS(ROWS):參加排序的資料行的數量。

TABLE FETCH BY ROWID:通過通路ROWID通路的資料行的數量。該值很高通常意味着就擷取資料的操作而言，應用程式調整的不錯。

TABLE FETCH CONTINUED ROW:擷取的資料行的數量，可以是鍊化資料行，也可以是遷移的資料行。

七、表空間和檔案I/O統計資料

對于帶緩存的磁盤I/O時間通常少于1ms.

在init.ora檔案中可以設定參數DB_FILE_MULTIBLOCK_READ_COUNT有助于磁盤讀取時間，該參數控制在全表掃描時一次I/O中讀入的

資料塊數量，這将減少掃描一張表所需的I/O數量，進而提高全表掃描的性能。但是，設定該參數的結果是優化器可能會執行更多的

全表掃描，是以需要将OPTIMIZER_INDEX_COST_ADJ設為一個值，例如10，來消除這個問題，并且驅動索引的使用。

資料字典和庫緩存的統計資料

如果報表中PCT MISS值很高，你應當提高應用程式中遊标的共享程度或者增加共享池的尺寸。

AWR報表和STATSPACK輸出結果中首先需要檢視的10項内容

1）首要的5個等待時間；

2）負載簡檔；

3）實力效率和命中率；

4）等待事件；

5）闩鎖等待；

6）首要的SQL;

7）執行個體活動；

8）檔案I/O和段統計資料；

9）記憶體配置設定；

10）緩沖區等待；

http://blog.sina.com.cn/s/blog_6ceed3280100tlz3.html