有些等待事件經(jīng)常記錯(cuò)，整理下：

Parse CPU to Parse Elapsd

?解析實(shí)際運(yùn)行時(shí)間/(解析實(shí)際運(yùn)行時(shí)間+解析中等待資源時(shí)間)，越高越好。計(jì)算公式為：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析實(shí)際運(yùn)行時(shí)間/(解析實(shí)際運(yùn)行時(shí)間+解析中等待資源時(shí)間)。如果該比率為100%，意味著CPU等待時(shí)間為0，沒有任何等待。

Non-Parse CPU

?SQL實(shí)際運(yùn)行時(shí)間/(SQL實(shí)際運(yùn)行時(shí)間+SQL解析時(shí)間)，太低表示解析消耗時(shí)間過多。計(jì)算公式為：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果這個(gè)值比較小，表示解析消耗的CPU時(shí)間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個(gè)比值將接近100%，這是很好的，說明計(jì)算機(jī)執(zhí)行的大部分工作是執(zhí)行查詢的工作，而不是分析查詢的工作。

SQL ordered by Parse Calls

• Total Parse Calls: 182,780

• Captured SQL account for 99.0% of Total

在這一部分，主要顯示PARSE與EXECUTIONS的對比情況。如果PARSE/EXECUTIONS>1，往往說明這個(gè)語句可能存在問題：沒有使用綁定變量，共享池設(shè)置太小，cursor_sharing被設(shè)置為exact，沒有設(shè)置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

顯示每個(gè)表空間的I/O統(tǒng)計(jì)。根據(jù)Oracle經(jīng)驗(yàn)，Av Rd(ms) [Average Readsin milliseconds]不應(yīng)該超過30，否則認(rèn)為有I/O爭用。

IO Stats

• Tablespace ? ? IO Stats

• File ? ? IO Stats

Back to Top

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

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

當(dāng)出現(xiàn)上面的問題，我們可以考慮以下的方法：

? ? ? 1）優(yōu)化操作該表空間或者文件的相關(guān)的語句。

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。