有些等待事件經常記錯，整理下：

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%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。

SQL ordered by Parse Calls

• Total Parse Calls: 182,780

• Captured SQL account for 99.0% of Total

在這一部分，主要顯示PARSE與EXECUTIONS的對比情況。如果PARSE/EXECUTIONS>1，往往說明這個語句可能存在問題：沒有使用綁定變量，共享池設置太小，cursor_sharing被設置為exact，沒有設置session_cached_cursors等等問題。

SELECT *

FROM(SELECTSUBSTR(sql_text,1,40)sql,

? ? ? ? ? ? ? ? parse_calls,

? ? ? ? ? ? ? ? executions,

? ? ? ? ? ? ? ? hash_value,

? ? ? ? ? ? ? ? address

FROMv$sqlarea

WHEREparse_calls >0

ORDERBYparse_calls DESC)

WHEREROWNUM<=10;

Tablespace IO Stats

• ordered by IOs (Reads + Writes) desc

Tablespace	Reads	Av Reads/s	Av Rd(ms)	Av Blks/Rd	Writes	Av Writes/s	Buffer Waits	Av Buf Wt(ms)
ICCIDAT01	67,408	14	3.76	3.17	160,261	34	6	0.00
UNDOTBS1	10	0	12.00	1.00	57,771	12	625	0.02
TEMP	15,022	3	8.74	7.24	3,831	1	0	0.00
USERS	68	0	5.44	1.00	971	0	0	0.00
SYSAUX	263	0	5.48	1.00	458	0	0	0.00
SYSTEM	32	0	5.94	1.00	158	0	3	23.33
UNDOTBS2	6	0	16.67	1.00	6	0	0	0.00

顯示每個表空間的I/O統計。根據Oracle經驗，Av Rd(ms) [Average Readsin milliseconds]不應該超過30，否則認為有I/O爭用。

IO Stats

• Tablespace ? ? IO Stats

• File ? ? IO Stats

Back to Top

通常，在這里期望在各設備上的讀取和寫入操作是均勻分布的。要找出什么文件可能非常“熱”。一旦DBA了解了如何讀取和寫入這些數據，他們也許能夠通過磁盤間更均勻的分配I/O而得到某些性能提升。

在這里主要關注Av Rd(ms)列 (reads per millisecond)的值，一般來說，大部分的磁盤系統的這個值都能調整到14ms以下，oracle認為該值超過20ms都是不必要的。如果該值超過1000ms，基本可以肯定存在I/O的性能瓶頸。如果在這一列上出現######，可能是你的系統存在嚴重的I/O問題，也可能是格式的顯示問題。

當出現上面的問題，我們可以考慮以下的方法：

? ? ? 1）優化操作該表空間或者文件的相關的語句。

? ? ? 2）如果該表空間包含了索引，可以考慮壓縮索引，是索引的分布空間減小，從而減小I/O。

? ? ? 3）將該表空間分散在多個邏輯卷中，平衡I/O的負載。

? ? ? 4）我們可以通過設置參數DB_FILE_MULTIBLOCK_READ_COUNT來調整讀取的并行度，這將提高全表掃描的效率。但是也會帶來一個問題，就是oracle會因此更多的使用全表掃描而放棄某些索引的使用。為解決這個問題，我們需要設置另外一個參數OPTIMIZER_INDEX_COST_ADJ=30（一般建議設置10－50）。

總結

以上是生活随笔為你收集整理的等待事件备忘录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。