Oracle的等待事件是衡量Oracle運(yùn)行狀況的重要依據(jù)及指標(biāo)。等待事件的概念是在Oracle7.0.1.2中引入的，大致有100個(gè)等待事件。在Oracle 8.0中這個(gè)數(shù)目增加到了大約150個(gè)，在Oracle8i中大約有200個(gè)事件,在Oracle9i中大約有360個(gè)等待事件。主要有兩種類別的等待事件，即空閑(idle)等待事件和非空閑(non-idle)等待事件。
空閑事件指Oracle正等待某種工作,在診斷和優(yōu)化數(shù)據(jù)庫(kù)的時(shí)候,我們不用過(guò)多注意這部分事件。
常見(jiàn)的空閑事件有:
dispatcher timer
lock element cleanup
Null event
parallel query dequeue wait
parallel query idle wait - Slaves
pipe get
PL/SQL lock timer
pmon timer- pmon
rdbms ipc message
slave wait
smon timer
SQL*Net break/reset to client
SQL*Net message from client
SQL*Net message to client
SQL*Net more data to client
virtual circuit status
client message
非空閑等待事件專門針對(duì)Oracle的活動(dòng),指數(shù)據(jù)庫(kù)任務(wù)或應(yīng)用運(yùn)行過(guò)程中發(fā)生的等待，這些等待事件是我們?cè)谡{(diào)整數(shù)據(jù)庫(kù)的時(shí)候應(yīng)該關(guān)注與研究的。
一些常見(jiàn)的非空閑等待事件有:
db file scattered read
db file sequential read
buffer busy waits
free buffer waits
enqueue
latch free
log file parallel write
log file sync
1. db file scattered read-DB 文件分散讀取
這種情況通常顯示與全表掃描相關(guān)的等待。當(dāng)數(shù)據(jù)庫(kù)進(jìn)行全表掃時(shí)，基于性能的考慮，數(shù)據(jù)會(huì)分散(scattered)讀入Buffer Cache。如果這個(gè)等待事件比較顯著，可能說(shuō)明對(duì)于某些全表掃描的表，沒(méi)有創(chuàng)建索引或者沒(méi)有創(chuàng)建合適的索引，我們可能需要檢查這些數(shù)據(jù)表已確定是否進(jìn)行了正確的設(shè)置。
然而這個(gè)等待事件不一定意味著性能低下，在某些條件下Oracle 會(huì)主動(dòng)使用全表掃描來(lái)替換索引掃描以提高性能，這和訪問(wèn)的數(shù)據(jù)量有關(guān)，在CBO 下Oracle 會(huì)進(jìn)行更為智能的選擇，在RBO 下Oracle 更傾向于使用索引。
因?yàn)槿頀呙璞恢糜贚RU(Least Recently Used，最近最少適用)列表的冷端(cold end)，對(duì)于頻繁訪問(wèn)的較小的數(shù)據(jù)表，可以選擇把他們Cache 到內(nèi)存中，以避免反復(fù)讀取。
當(dāng)這個(gè)等待事件比較顯著時(shí)，可以結(jié)合v$session_longops 動(dòng)態(tài)性能視圖來(lái)進(jìn)行診斷，該視圖中記錄了長(zhǎng)時(shí)間(運(yùn)行時(shí)間超過(guò)6 秒的)運(yùn)行的事物，可能很多是全表掃描操作(不管怎樣，這部分信息都是值得我們注意的)。
2. db file sequential read-DB 文件順序讀取。
這一事件通常顯示與單個(gè)數(shù)據(jù)塊相關(guān)的讀取操作(如索引讀取)。如果這個(gè)等待事件比較顯著，可能表示在多表連接中，表的連接順序存在問(wèn)題，可能沒(méi)有正確的使用驅(qū)動(dòng)表;或者可能說(shuō)明不加選擇地進(jìn)行索引。
在大多數(shù)情況下我們說(shuō)，通過(guò)索引可以更為快速的獲取記錄，所以對(duì)于一個(gè)編碼規(guī)范、調(diào)整良好的數(shù)據(jù)庫(kù)，這個(gè)等待很大是很正常的。但是在很多情況下，使用索引并不是最佳的選擇，比如讀取較大表中大量的數(shù)據(jù)，全表掃描可能會(huì)明顯快于索引掃描，所以在開(kāi)發(fā)中我們就應(yīng)該注意，對(duì)于這樣的查詢應(yīng)該進(jìn)行避免使用索引掃描。
3. Free Buffer-釋放緩沖區(qū)
這個(gè)等待事件表明系統(tǒng)正在等待內(nèi)存中的可用空間，這說(shuō)明當(dāng)前Buffer 中已經(jīng)沒(méi)有Free 的內(nèi)存空間。如果應(yīng)用設(shè)計(jì)良好，SQL 書(shū)寫(xiě)規(guī)范，充分綁定變量，那這種等待可能說(shuō)明Buffer Cache 設(shè)置的偏小，你可能需要增大DB_BUFFER_CACHE。
Free Buffer 等待可能說(shuō)明DBWR 的寫(xiě)出速度不夠，或者磁盤存在嚴(yán)重的競(jìng)爭(zhēng)，可以需要考慮增加檢查點(diǎn)、使用更多的DBWR 進(jìn)程，或者增加物理磁盤的數(shù)量,分散負(fù)載，平衡IO。
4. Buffer Busy-緩沖區(qū)忙
該等待事件表示正在等待一個(gè)以u(píng)nshareable方式使用的緩沖區(qū)，或者表示當(dāng)前正在被讀入buffer cache。一般來(lái)說(shuō)Buffer Busy Wait不應(yīng)大于1%。檢查緩沖等待統(tǒng)計(jì)部分(或V$WAITSTAT)，看一下等待是否位于段頭(Segment Header)。如果是，可以考慮增加自由列表(freelist，對(duì)于Oracle8i DMT)或者增加freelist groups(在很多時(shí)候這個(gè)調(diào)整是立竿見(jiàn)影的，在8.1.6之前，這個(gè)freelists參數(shù)不能動(dòng)態(tài)修改;在8.1.6及以后版本，動(dòng)態(tài)修改feelists需要設(shè)置COMPATIBLE至少為8.1.6).
如果這一等待位于undo header，可以通過(guò)增加回滾段(rollback segment)來(lái)解決緩沖區(qū)的問(wèn)題。如果等待位于undo block上，我們可能需要檢查相關(guān)應(yīng)用，適當(dāng)減少大規(guī)模的一致性讀取，或者降低一致性讀取(consistent read)的表中的數(shù)據(jù)密度或者增大DB_CACHE_SIZE。
如果等待處于data block，可以考慮將頻繁并發(fā)訪問(wèn)的表或數(shù)據(jù)移到另一數(shù)據(jù)塊或者進(jìn)行更大范圍的分布(可以增加pctfree值 ，擴(kuò)大數(shù)據(jù)分布，減少競(jìng)爭(zhēng))，以避開(kāi)這個(gè)"熱點(diǎn)"數(shù)據(jù)塊，或者可以考慮增加表中的自由列表或使用本地化管理的表空間(Locally Managed Tablespaces)。
如果等待處于索引塊，應(yīng)該考慮重建索引、分割索引或使用反向鍵索引。為了防止與數(shù)據(jù)塊相關(guān)的緩沖忙等待，也可以使用較小的塊:在這種情況下，單個(gè)塊中的記錄就較少，所以這個(gè)塊就不是那么"繁忙";或者可以設(shè)置更大的pctfree,使數(shù)據(jù)擴(kuò)大物理分布，減少記錄間的熱點(diǎn)競(jìng)爭(zhēng)。
在執(zhí)行DML (insert/update/ delete)時(shí)，Oracle向數(shù)據(jù)塊中寫(xiě)入信息，對(duì)于多事務(wù)并發(fā)訪問(wèn)的數(shù)據(jù)表，關(guān)于ITL的競(jìng)爭(zhēng)和等待可能出現(xiàn)，為了減少這個(gè)等待，可以增加initrans，使用多個(gè)ITL槽。在Oracle9i 中，引入了一個(gè)新概念:ASSM(Segment Space Management Auto)。通過(guò)這個(gè)新特性O(shè)racle 使用位圖來(lái)管理空間使用。
ASSM 結(jié)合LMT 徹底改變了Oracle 的存儲(chǔ)機(jī)制，位圖freelist 能夠減輕緩沖區(qū)忙等待(buffer busy wait)，這個(gè)問(wèn)題在Oracle9i 以前的版本里曾是一個(gè)嚴(yán)重的問(wèn)題。
Oracle 宣稱ASSM 顯著地提高了DML 并發(fā)操作的性能，因?yàn)?同一個(gè))位圖的不同部分可以被同時(shí)使用，這樣就消除了尋找剩余空間的串行化。根據(jù)Oracle 的測(cè)試結(jié)果，使用位圖freelist 會(huì)消除所有分段頭部(對(duì)資源)的爭(zhēng)奪，還能獲得超快的并發(fā)插入操作。在Oracle9i 之中，Buffer Busy wait 不再常見(jiàn)
5. latch free-latch 釋放
latch是一種低級(jí)排隊(duì)機(jī)制，用于保護(hù)SGA中共享內(nèi)存結(jié)構(gòu)。latch就像是一種快速地被獲取和釋放的內(nèi)存鎖。用于防止共享內(nèi)存結(jié)構(gòu)被多個(gè)用戶同時(shí)訪問(wèn)。如果latch不可用，就會(huì)記錄latch釋放失敗(latch free miss )。有兩種與閂有關(guān)的類型:
■ 立刻。
■ 可以等待。
假如一個(gè)進(jìn)程試圖在立刻模式下獲得閂，而該閂已經(jīng)被另外一個(gè)進(jìn)程所持有，如果該閂不能立可用的話，那么該進(jìn)程就不會(huì)為獲得該閂而等待。它將繼續(xù)執(zhí)行另一個(gè)操作。
大多數(shù)latch問(wèn)題都與以下操作相關(guān):
沒(méi)有很好的是用綁定變量(library cache latch)、重作生成問(wèn)題(redo allocation latch)、緩沖存儲(chǔ)競(jìng)爭(zhēng)問(wèn)題(cache buffers LRU chain)，以及buffer cache中的存在"熱點(diǎn)"塊(cache buffers chain)。
通常我們說(shuō)，如果想設(shè)計(jì)一個(gè)失敗的系統(tǒng)，不考慮綁定變量，這一個(gè)條件就夠了，對(duì)于異構(gòu)性強(qiáng)的系統(tǒng)，不使用綁定變量的后果是極其嚴(yán)重的。
另外也有一些latch等待與bug有關(guān)，應(yīng)當(dāng)關(guān)注Metalink相關(guān)bug的公布及補(bǔ)丁的發(fā)布。當(dāng)latch miss ratios大于0.5%時(shí)，就應(yīng)當(dāng)研究這一問(wèn)題。
Oracle的latch機(jī)制是競(jìng)爭(zhēng)，其處理類似于網(wǎng)絡(luò)里的CSMA/CD，所有用戶進(jìn)程爭(zhēng)奪latch， 對(duì)于愿意等待類型(willing-to-wait)的latch,如果一個(gè)進(jìn)程在第一次嘗試中沒(méi)有獲得latch,那么它會(huì)等待并且再嘗試一次,如果經(jīng)過(guò)_spin_count次爭(zhēng)奪不能獲得latch, 然后該進(jìn)程轉(zhuǎn)入睡眠狀態(tài)，持續(xù)一段指定長(zhǎng)度的時(shí)間，然后再次醒來(lái)，按順序重復(fù)以前的步驟.在8i/9i中默認(rèn)值是_spin_count=2000。
如果SQL語(yǔ)句不能調(diào)整，在8.1.6版本以上，Oracle提供了一個(gè)新的初始化參數(shù): CURSOR_SHARING可以通過(guò)設(shè)置CURSOR_SHARING = force 在服務(wù)器端強(qiáng)制綁定變量。設(shè)置該參數(shù)可能會(huì)帶來(lái)一定的副作用，對(duì)于Java的程序，有相關(guān)的bug，具體應(yīng)用應(yīng)該關(guān)注Metalink的bug公告。
6. Log Buffer Space-日志緩沖空間
當(dāng)你將日志緩沖(log buffer)產(chǎn)生重做日志的速度比LGWR 的寫(xiě)出速度快，或者是當(dāng)日志切換(log switch)太慢時(shí)，就會(huì)發(fā)生這種等待。這個(gè)等待出現(xiàn)時(shí)，通常表明redo log buffer 過(guò)小，為解決這個(gè)問(wèn)題，可以考慮增大日志文件的大小，或者增加日志緩沖器的大小。
另外一個(gè)可能的原因是磁盤I/O 存在瓶頸，可以考慮使用寫(xiě)入速度更快的磁盤。在允許的條件下設(shè)置可以考慮使用裸設(shè)備來(lái)存放日志文件，提高寫(xiě)入效率。在一般的系統(tǒng)中，最低的標(biāo)準(zhǔn)是，不要把日志文件和數(shù)據(jù)文件存放在一起，因?yàn)橥ǔＨ罩疚募粚?xiě)不讀，分離存放可以獲得性能提升。
7. Log File Switch-日志文件切換
當(dāng)這個(gè)等待出現(xiàn)時(shí)，表示所有的提交(commit)的請(qǐng)求都需要等待"日志文件切換"的完成。
Log file Switch 主要包含兩個(gè)子事件:
log file switch (archiving needed)
log file switch (checkpoint incomplete)
log file switch (archiving needed)
這個(gè)等待事件出現(xiàn)時(shí)通常是因?yàn)槿罩窘M循環(huán)寫(xiě)滿以后，第一個(gè)日志歸檔尚未完成，出現(xiàn)該等待。出現(xiàn)該等待，可能表示io 存在問(wèn)題。解決辦法:
可以考慮增大日志文件和增加日志組
移動(dòng)歸檔文件到快速磁盤
調(diào)整log_archive_max_processes .
log file switch (checkpoint incomplete)-日志切換(檢查點(diǎn)未完成)
當(dāng)你的日志組都寫(xiě)完以后，LGWR 試圖寫(xiě)第一個(gè)log file，如果這時(shí)數(shù)據(jù)庫(kù)沒(méi)有完成寫(xiě)出記錄在第一個(gè)log file 中的dirty 塊時(shí)(例如第一個(gè)檢查點(diǎn)未完成)，該等待事件出現(xiàn)。
該等待事件通常表示你的DBWR 寫(xiě)出速度太慢或者IO 存在問(wèn)題。
為解決該問(wèn)題，你可能需要考慮增加額外的DBWR 或者增加你的日志組或日志文件大小。
8. log file sync-日志文件同步
當(dāng)一個(gè)用戶提交或回滾數(shù)據(jù)時(shí)，LGWR 將會(huì)話期的重做由日志緩沖器寫(xiě)入到重做日志中。日志文件同步過(guò)程必須等待這一過(guò)程成功完成。為了減少這種等待事件，可以嘗試一次提交更多的記錄(頻繁的提交會(huì)帶來(lái)更多的系統(tǒng)開(kāi)銷)。將重做日志置于較快的磁盤上，或者交替使用不同物理磁盤上的重做日志，以降低歸檔對(duì)LGWR的影響。
對(duì)于軟RAID，一般來(lái)說(shuō)不要使用RAID 5，RAID5 對(duì)于頻繁寫(xiě)入得系統(tǒng)會(huì)帶來(lái)較大的性能損失，可以考慮使用文件系統(tǒng)直接輸入/輸出，或者使用裸設(shè)備(raw device)，這樣可以獲得寫(xiě)入的性能提高。
9. log file single write該事件僅與寫(xiě)日志文件頭塊相關(guān)，通常發(fā)生在增加新的組成員和增進(jìn)序列號(hào)時(shí)。
頭塊寫(xiě)單個(gè)進(jìn)行，因?yàn)轭^塊的部分信息是文件號(hào)，每個(gè)文件不同。更新日志文件頭這個(gè)操作在后臺(tái)完成，一般很少出現(xiàn)等待，無(wú)需太多關(guān)注。
10. log file parallel write
從log buffer 寫(xiě)redo 記錄到redo log 文件，主要指常規(guī)寫(xiě)操作(相對(duì)于log file sync)。如果你的Log group 存在多個(gè)組成員，當(dāng)flush log buffer 時(shí)，寫(xiě)操作是并行的，這時(shí)候此等待事件可能出現(xiàn)。
盡管這個(gè)寫(xiě)操作并行處理，直到所有I/O 操作完成該寫(xiě)操作才會(huì)完成(如果你的磁盤支持異步IO或者使用IO SLAVE，那么即使只有一個(gè)redo log file member,也有可能出現(xiàn)此等待)。
這個(gè)參數(shù)和log file sync 時(shí)間相比較可以用來(lái)衡量log file 的寫(xiě)入成本。通常稱為同步成本率。
11. control file parallel write-控制文件并行寫(xiě)
當(dāng)server 進(jìn)程更新所有控制文件時(shí)，這個(gè)事件可能出現(xiàn)。如果等待很短，可以不用考慮。如果等待時(shí)間較長(zhǎng)，檢查存放控制文件的物理磁盤I/O 是否存在瓶頸。
多個(gè)控制文件是完全相同的拷貝，用于鏡像以提高安全性。對(duì)于業(yè)務(wù)系統(tǒng)，多個(gè)控制文件應(yīng)該存放在不同的磁盤上，一般來(lái)說(shuō)三個(gè)是足夠的，如果只有兩個(gè)物理硬盤，那么兩個(gè)控制文件也是可以接受的。在同一個(gè)磁盤上保存多個(gè)控制文件是不具備實(shí)際意義的。減少這個(gè)等待，可以考慮如下方法:
減少控制文件的個(gè)數(shù)(在確保安全的前提下)
如果系統(tǒng)支持，使用異步IO
轉(zhuǎn)移控制文件到IO 負(fù)擔(dān)輕的物理磁盤
12. control file sequential read/ control file single write 控制文件連續(xù)讀/控制文件單個(gè)寫(xiě)對(duì)單個(gè)控制文件I/O 存在問(wèn)題時(shí)，這兩個(gè)事件會(huì)出現(xiàn)。如果等待比較明顯，檢查單個(gè)控制文件，看存放位置是否存在I/O 瓶頸。
13. direct path write-直接路徑寫(xiě)該等待發(fā)生在，系統(tǒng)等待確認(rèn)所有未完成的異步I/O 都已寫(xiě)入磁盤。對(duì)于這一寫(xiě)入等待，我們應(yīng)該找到I/O 操作最為頻繁的數(shù)據(jù)文件(如果有過(guò)多的排序操作，很有可能就是臨時(shí)文件)，分散負(fù)載，加快其寫(xiě)入操作。
如果系統(tǒng)存在過(guò)多的磁盤排序，會(huì)導(dǎo)致臨時(shí)表空間操作頻繁，對(duì)于這種情況，可以考慮使用Local管理表空間，分成多個(gè)小文件，寫(xiě)入不同磁盤或者裸設(shè)備。
14. Idle Event-空閑事件
最后我們來(lái)看幾個(gè)空閑等待事件。一般來(lái)說(shuō)，空閑等待是指系統(tǒng)因?yàn)闊o(wú)事可做的等待，或者等待用戶的請(qǐng)求或響應(yīng)等，通常我們可以忽略這些等待事件。空閑事件可以通過(guò)stats$idle_event 表查詢得到。
我們看一下系統(tǒng)的主要空閑等待事件，對(duì)這些事件大家應(yīng)該有個(gè)大致的印象，如果你的Top 5 等待事件中，主要都是這些事件，那么一般來(lái)說(shuō)你的系統(tǒng)是比價(jià)清閑的。
