常見非空閑等待事件：影響性能-性能優(yōu)化

1、一些常見的非空閑等待事件有:. db file scattered read. db file sequential read. buffer busy waits. free buffer waits. enqueue. latch free. log file parallel write. log file sync下面結(jié)合AWR和statspack中的一些等待事件進(jìn)行講述。-收集整理-Top 5 Wait Events Wait % TotalEvent Waits Time (cs) Wt Time- - - -db file scattered read 26,877 12,850

2、 52.94db file parallel write 472 3,674 15.13log file parallel write 975 1,560 6.43direct path write 1,571 1,543 6.36control file parallel write 652 1,290 5.31-1）. db file scattered read: DB文件分散讀取。-一次讀取多個(gè)塊-可能full scan這個(gè)等待事件很常見，經(jīng)常在top5中出現(xiàn)，這表示，一次從磁盤讀數(shù)據(jù)進(jìn)來的時(shí)候讀了多于一個(gè)block的數(shù)據(jù)，而這些數(shù)據(jù)又被分散的放在不連續(xù)的內(nèi)存塊中，因?yàn)橐淮巫x進(jìn)來的是多

3、于一個(gè)block的。通常來說我們可以認(rèn)為是全表掃描類型的讀，因?yàn)楦鶕?jù)索引讀表數(shù)據(jù)的話一次只讀一個(gè)block，如果這個(gè)數(shù)字過大，就表明該表找不到索引，或者只能找到有限的索引，可能是全表掃描過多，需要檢查sql是否合理的利用了索引，或者是否需要建立合理的索引。當(dāng)全表掃描被限制在內(nèi)存時(shí)，它們很少會(huì)進(jìn)入連續(xù)的緩沖區(qū)內(nèi)，而是分散于整個(gè)緩沖存儲(chǔ)器中。盡管在特定條件下執(zhí)行全表掃描可能比索引掃描更有效，但如果出現(xiàn)這種等待時(shí)，最好檢查一下這些全表掃描是否必要,是否可以通過建立合適的索引來減少對于大表全表掃描所產(chǎn)生的大規(guī)模數(shù)據(jù)讀取。對于經(jīng)常使用的小表，應(yīng)該盡量把他們pin 在內(nèi)存中，避免不必要的老化清除及重復(fù)讀取

4、。2）. db file sequential read: DB文件連續(xù)讀取。-一次讀取一塊，單塊，可能表的連接順序不好，索引使用不好。-sql優(yōu)化通常顯示單個(gè)塊的讀取(通常指索引讀取)，表示的是讀進(jìn)磁盤的block被放在連續(xù)的內(nèi)存塊中。事實(shí)上大部分基本代表著單個(gè)block的讀入，可以說象征著 IO 或者說通過索引讀入的比較多。因?yàn)橐淮蜪O若讀進(jìn)多個(gè)的block，放入連續(xù)的內(nèi)存塊的幾率是很小的，分布在不同block的大量記錄被讀入就會(huì)遇到此事件。因?yàn)楦鶕?jù)索引讀數(shù)據(jù)的話，假設(shè)100條記錄，根據(jù)索引，不算索引本身的讀，而根據(jù)索引每個(gè)值去讀一下表數(shù)據(jù)，理論上最多可能產(chǎn)生100 buffer gets

5、，而如果是full table scan，則100條數(shù)據(jù)完全可能在一個(gè)block里面，則幾乎一次就讀過這個(gè)block了，就會(huì)產(chǎn)生這么大的差異。這種等待的數(shù)目很多時(shí)，可能顯示表的連接順序不佳，或者不加選擇地進(jìn)行索引。對于高級(jí)事務(wù)處理（high-transaction）、調(diào)整良好（welltuned）的系統(tǒng)，這一數(shù)值很大是很正常的，但在某些情況下，它可能暗示著系統(tǒng)中存在問題。你應(yīng)當(dāng)將這一等待統(tǒng)計(jì)量與Statspack 報(bào)告中的已知問題（如效率較低的SQL）聯(lián)系起來。檢查索引掃描，以保證每個(gè)掃描都是必要的，并檢查多表連接的連接順序。DB_CACHE_SIZE 也是這些等待出現(xiàn)頻率的決定因素。有問題的

6、散列區(qū)域（Hash-area）連接應(yīng)當(dāng)出現(xiàn)在PGA 內(nèi)存中，但它們也會(huì)消耗大量內(nèi)存，從而在順序讀取時(shí)導(dǎo)致大量等待。它們也可能以直接路徑讀寫等待的形式出現(xiàn)。表明有許多索引讀?。赫{(diào)優(yōu)代碼（特別是連接）3）. Free Buffer Wait: 釋放緩沖區(qū)。這種等待表明系統(tǒng)正在等待內(nèi)存中的緩沖，因?yàn)閮?nèi)存中已經(jīng)沒有可用的緩沖空間了。如果所有SQL 都得到了調(diào)優(yōu)，這種等待可能表示你需要增大DB_BUFFER_CACHE。釋放緩沖區(qū)等待也可能表示不加選擇的SQL 導(dǎo)致數(shù)據(jù)溢出了帶有索引塊的緩沖存儲(chǔ)器，沒有為等待系統(tǒng)處理的特定語句留有緩沖區(qū)。這種情況通常表示正在執(zhí)行相當(dāng)多數(shù)量的DML（插入更新刪除），并且可

7、能說明DBWR 寫的速度不夠快，緩沖存儲(chǔ)器可能充滿了相同緩沖器的多個(gè)版本，從而導(dǎo)致效率非常低。為了解決這個(gè)問題，可能需要考慮增加檢查點(diǎn)、利用更多的DBWR 進(jìn)程，或者增加物理磁盤的數(shù)量。4）. Buffer Busy Wait: 緩沖區(qū)忙。該等待事件表示正在等待一個(gè)以unshareable方式使用的緩沖區(qū)，或者表示當(dāng)前正在被讀入buffer cache。也就是當(dāng)進(jìn)程想獲取或者操作某個(gè)block的時(shí)候卻發(fā)現(xiàn)被別的進(jìn)程在使用而出現(xiàn)等待。一般來說Buffer Busy Wait不應(yīng)大于1%。檢查緩沖等待統(tǒng)計(jì)部分（或V$WAITSTAT），看一下等待是否位于段頭。如果是，可以考慮增加自由列表（free

8、list，對于Oracle8i DMT）或者增加freelist groups.其修改語法為：SQL> alter table sp_item storage (freelists 2);對于Oracle8i而言，增加freelist參數(shù)，在很多時(shí)候可以明顯緩解等待，如果使用LMT，也就是 Local Manangement Tablespace，區(qū)段的管理就相對簡單。還可以考慮修改數(shù)據(jù)塊的pctusedpctfree值，比如增大pctfree可以擴(kuò)大數(shù)據(jù)的分布，在某種程度上就可以減少熱點(diǎn)塊的競爭。如果這一等待位于undo header，可以通過增加回滾段（rollback segmen

9、t）來解決緩沖區(qū)的問題。如果等待位于undo block上，我們可能需要檢查相關(guān)應(yīng)用，適當(dāng)減少大規(guī)模的一致性讀取，或者降低一致性讀取(consistent read)的表中的數(shù)據(jù)密度或者增大DB_CACHE_SIZE。如果等待處于data block，可以考慮將頻繁并發(fā)訪問的表或數(shù)據(jù)移到另一數(shù)據(jù)塊或者進(jìn)行更大范圍的分布（可以增加pctfree 值，擴(kuò)大數(shù)據(jù)分布，減少競爭），以避開這個(gè)"熱點(diǎn)"數(shù)據(jù)塊，或者可以考慮增加表中的自由列表或使用本地化管理的表空間（Locally Managed Tablespaces）。如果等待處于索引塊，應(yīng)該考慮重建索引、分割索引或使用反向鍵索引。

10、反向鍵索引在很多情況下，可以極大地緩解競爭，其原理有點(diǎn)類似于hash分區(qū)的功效。反向鍵索引（reverse key index）常建在一些值是連續(xù)增長的列上，例如列中的值是由sequence產(chǎn)生的。為了防止與數(shù)據(jù)塊相關(guān)的緩沖忙等待，也可以使用較小的塊：在這種情況下，單個(gè)塊中的記錄就較少，所以這個(gè)塊就不是那么"繁忙"；或者可以設(shè)置更大的pctfree,使數(shù)據(jù)擴(kuò)大物理分布，減少記錄間的熱點(diǎn)競爭。在執(zhí)行DML (insert/update/ delete)時(shí)，Oracle向數(shù)據(jù)塊中寫入信息，對于多事務(wù)并發(fā)訪問的數(shù)據(jù)表，關(guān)于ITL的競爭和等待可能出現(xiàn)，為了減少這個(gè)等待，可以增加in

11、itrans，使用多個(gè)ITL槽。從本質(zhì)上講，這個(gè)等待事件的產(chǎn)生僅說明了一個(gè)會(huì)話在等待一個(gè)Buffer（數(shù)據(jù)塊），但是導(dǎo)致這個(gè)現(xiàn)象的原因卻有很多種。常見的兩種是：當(dāng)一個(gè)會(huì)話視圖修改一個(gè)數(shù)據(jù)塊，但這個(gè)數(shù)據(jù)塊正在被另一個(gè)會(huì)話修改時(shí)。當(dāng)一個(gè)會(huì)話需要讀取一個(gè)數(shù)據(jù)塊，但這個(gè)數(shù)據(jù)塊正在被另一個(gè)會(huì)話讀取到內(nèi)存中時(shí)。 Oracle 操作的最小單位是塊（Block），即使你要修改一條記錄，也需要對這條記錄所在的這個(gè)數(shù)據(jù)塊做操作。 當(dāng)你對這個(gè)數(shù)據(jù)塊做修改時(shí)，其他的會(huì)話將被阻止對這個(gè)數(shù)據(jù)塊上的數(shù)據(jù)做修改（即使其他用戶修改的不是當(dāng)前用戶修改的數(shù)據(jù)），但是可以以一致性的方式讀取這個(gè)數(shù)據(jù)塊（from undo）。當(dāng)前的用戶

12、修改完這個(gè)數(shù)據(jù)塊后，將會(huì)立即釋放掉加在這個(gè)數(shù)據(jù)塊上的排他鎖，這樣另一個(gè)會(huì)話就可以繼續(xù)修改它。 修改操作是一個(gè)非常短暫的時(shí)間，這種加鎖的機(jī)制我們叫Latch。 當(dāng)一個(gè)會(huì)話修改一個(gè)數(shù)據(jù)塊時(shí)，是按照以下步驟來完成的：以排他的方式獲得這個(gè)數(shù)據(jù)塊（Latch）修改這個(gè)數(shù)據(jù)塊。釋放Latch。 Buffer busy waits等待事件常見于數(shù)據(jù)庫中存在的熱快的時(shí)候，當(dāng)多個(gè)用戶頻繁地讀取或者修改同樣的數(shù)據(jù)塊時(shí)，這個(gè)等待事件就會(huì)產(chǎn)生。 如果等待的時(shí)間很長，我們在AWR或者statspack 報(bào)告中就可以看到。 這個(gè)等待事件有三個(gè)參數(shù)。 查看有幾個(gè)參數(shù)我們可以用以下SQL: SQL> select na

13、me, parameter1, parameter2, parameter3 from v$event_name where name=''buffer busy waits''NAME PARAMETER1 PARAMETER2 PARAMETER3- - - -buffer busy waits file# block# class# 在下面的示例中，查詢的方法和這個(gè)一樣，所以其他事件對參數(shù)的查詢將不做過多的說明。 File#: 等待訪問數(shù)據(jù)塊所在的文件id號(hào)。Blocks： 等待訪問的數(shù)據(jù)塊號(hào)。ID： 在10g之前，這個(gè)值表示一個(gè)等待時(shí)間的原因，10g之后

14、則表示等待事件的類別。5）. latch free: latch釋放latch 是一種低級(jí)排隊(duì)機(jī)制，用于保護(hù)SGA 中共享內(nèi)存結(jié)構(gòu)。latch就像是一種快速地被獲取和釋放的內(nèi)存鎖。latch用于防止共享內(nèi)存結(jié)構(gòu)被多個(gè)用戶同時(shí)訪問。如果latch不可用，就會(huì)記錄latch釋放失敗(latch free miss)。有兩種與閂有關(guān)的類型：立刻和可以等待。假如一個(gè)進(jìn)程試圖在立刻模式下獲得閂，而該閂已經(jīng)被另外一個(gè)進(jìn)程所持有，如果該閂不能立刻可用的話，那么該進(jìn)程就不會(huì)為獲得該閂而等待。它將繼續(xù)執(zhí)行另一個(gè)操作。大多數(shù)latch 問題都與以下操作相關(guān)：沒有很好的是用綁定變量（library cache la

15、tch）、重作生成問題（redo allocation latch）、緩沖存儲(chǔ)器競爭問題（cache buffers LRU chain），以及buffer cache中的存在"熱點(diǎn)"塊（cache buffers chain）。通常我們說，如果想設(shè)計(jì)一個(gè)失敗的系統(tǒng)，不考慮綁定變量，這一個(gè)條件就夠了，對于異構(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)研究這一問題。Oracle 的 latch 機(jī)制是競爭，其處理

16、類似于網(wǎng)絡(luò)里的CSMA/CD，所有用戶進(jìn)程爭奪latch，對于愿意等待類型(willing-to-wait)的latch,如果一個(gè)進(jìn)程在第一次嘗試中沒有獲得latch,那么它會(huì)等待并且再嘗試一次,如果經(jīng)過_spin_count 次爭奪不能獲得latch, 然后該進(jìn)程轉(zhuǎn)入睡眠狀態(tài)，持續(xù)一段指定長度的時(shí)間，然后再次醒來，按順序重復(fù)以前的步驟.在8i/9i 中默認(rèn)值是 _spin_count=2000。如果SQL語句不能調(diào)整，在8.1.6版本以上，Oracle提供了一個(gè)新的初始化參數(shù): CURSOR_SHARING，可以通過設(shè)置CURSOR_SHARING = force 在服務(wù)器端強(qiáng)制綁定變量。設(shè)

17、置該參數(shù)可能會(huì)帶來一定的副作用，對于Java的程序，有相關(guān)的bug，具體應(yīng)用應(yīng)該關(guān)注Metalink的bug公告。6）. enqueueenqueue 是一種保護(hù)共享資源的鎖定機(jī)制。該鎖定機(jī)制保護(hù)共享資源，如記錄中的數(shù)據(jù)，以避免兩個(gè)人在同一時(shí)間更新同一數(shù)據(jù)。enqueue 包括一個(gè)排隊(duì)機(jī)制，即FIFO（先進(jìn)先出）排隊(duì)機(jī)制。Enqueue 等待常見的有ST、HW 、TX 、TM 等。ST enqueue 用于空間管理和字典管理的表空間(DMT)的分配。對于支持LMT 的版本，可以考慮使用本地管理表空間，對于Oracle8i，因?yàn)橄嚓P(guān)bug 不要把臨時(shí)表空間設(shè)置為LMT. 或者考慮預(yù)分配一定數(shù)量的

18、區(qū)。HW enqueue 指段的高水位標(biāo)記相關(guān)等待；手動(dòng)分配適當(dāng)區(qū)段可以避免這一等待。TX 是最常見的enqueue 等待。TX enqueue 等待通常是以下三個(gè)問題之一產(chǎn)生的結(jié)果。第一個(gè)問題是唯一索引中的重復(fù)索引，你需要執(zhí)行提交（commit）/回滾（rollback）操作來釋放enqueue。第二個(gè)問題是對同一位圖索引段的多次更新。因?yàn)閱蝹€(gè)位圖段可能包含多個(gè)行地址（rowid），所以當(dāng)多個(gè)用戶試圖更新同一段時(shí)，等待出現(xiàn)。直到提交或回滾， enqueue 釋放。第三個(gè)問題，也是最可能發(fā)生的問題是多個(gè)用戶同時(shí)更新同一個(gè)塊。如果沒有自由的ITL 槽，就會(huì)發(fā)生塊級(jí)鎖定。通過增大initrans

19、和/或maxtrans 以允許使用多個(gè)ITL 槽，或者增大表上的pctfree值，就可以很輕松地避免這種情況。TM enqueue 在DML 期間產(chǎn)生，以避免對受影響的對象使用DDL。如果有外鍵，一定要對它們進(jìn)行索引，以避免這種常見的鎖定問題。7）. Log Buffer Space: 日志緩沖空間當(dāng)你將日志緩沖（log buffer）產(chǎn)生重做日志的速度比LGWR 的寫出速度快，或者是當(dāng)日志轉(zhuǎn)換（log switch）太慢時(shí)，就會(huì)發(fā)生這種等待。為解決這個(gè)問題，可以增大日志文件的大小，或者增加日志緩沖器的大小。另外一個(gè)可能的原因是磁盤I/O 存在瓶頸，可以考慮使用寫入速度更快的磁盤。8）. lo

20、g file switch (archiving needed)這個(gè)等待事件出現(xiàn)時(shí)通常是因?yàn)槿罩窘M循環(huán)寫滿以后，第一個(gè)日志歸檔尚未完成，出現(xiàn)該等待可能是 IO 存在問題。解決辦法：. 可以考慮增大日志文件和增加日志組 . 移動(dòng)歸檔文件到快速磁盤. 調(diào)整log_archive_max_processes .9）. log file switch (checkpoint incomplete): 日志切換（檢查點(diǎn)未完成）當(dāng)你的日志組都寫完以后，LGWR 試圖寫第一個(gè)log file，如果這時(shí)數(shù)據(jù)庫沒有完成寫出記錄在第一個(gè)log file 中的dirty 塊時(shí)（例如第一個(gè)檢查點(diǎn)未完成），該等待事件出

21、現(xiàn)。該等待事件說明你的日志組過少或者日志文件過小。你可能需要增加你的日志組或日志文件大小。10）. Log File Switch: 日志文件轉(zhuǎn)換所有的提交請求都需要等待"日志文件轉(zhuǎn)換（必要的歸檔）"或"日志文件轉(zhuǎn)換（chkpt.不完全）"。確保歸檔磁盤未滿，并且速度不太慢。 DBWR 可能會(huì)因?yàn)檩斎?輸出（IO）操作而變得很慢。你可能需要增加更多或更大的重做日志，而且如果DBWxR 是問題癥結(jié)所在的話，可能需要增加數(shù)據(jù)庫書寫器。11）. log file sync: 日志文件同步當(dāng)一個(gè)用戶提交或回滾數(shù)據(jù)時(shí)，LGWR 將session 會(huì)話的重做由red

22、o buffer 寫入到重做日志中。log file sync 必須等待這一過程成功完成(Oracle 通過寫redo log file 保證commit 成功的數(shù)據(jù)不丟失)，這個(gè)事件說明提交可能過于頻繁，批量提交可以最大化LGWR 的效率，過分頻繁的提交會(huì)引起LGWR頻繁的激活，擴(kuò)大了LGWR 的寫代價(jià)。為了減少這種等待事件，可以嘗試每次提交更多的記錄。將重做日志置于較快的磁盤上，或者交替使用不同物理磁盤上的重做日志，以降低歸檔對LGWR的影響。對于軟RAID，一般來說不要使用RAID 5，RAID5 對于頻繁寫入得系統(tǒng)會(huì)帶來較大的性能損失，可以考慮使用文件系統(tǒng)直接輸入/輸出，或者使用裸設(shè)備

23、（raw device），這樣可以獲得寫入的性能提高。12）. log file single write該事件僅與寫日志文件頭塊相關(guān)，通常發(fā)生在增加新的組成員和增進(jìn)序列號(hào)時(shí)。頭塊寫單個(gè)進(jìn)行，因?yàn)轭^塊的部分信息是文件號(hào)，每個(gè)文件不同。更新日志文件頭這個(gè)操作在后臺(tái)完成，一般很少出現(xiàn)等待，無需太多關(guān)注。13）. log file parallel write從log buffer 寫redo 記錄到redo log 文件，主要指常規(guī)寫操作(相對于log file sync)。如果你的Log group 存在多個(gè)組成員，當(dāng)flush log buffer 時(shí)，寫操作是并行的，這時(shí)候此等待事件可能出現(xiàn)

24、。盡管這個(gè)寫操作并行處理，直到所有I/O 操作完成該寫操作才會(huì)完成(如果你的磁盤支持異步IO或者使用IO SLAVE，那么即使只有一個(gè)redo log file member,也有可能出現(xiàn)此等待)。這個(gè)參數(shù)和log file sync 時(shí)間相比較可以用來衡量log file 的寫入成本。通常稱為同步成本率。14）. control file parallel write: 控制文件并行寫當(dāng)server 進(jìn)程更新所有控制文件時(shí)，這個(gè)事件可能出現(xiàn)。如果等待很短，可以不用考慮。如果等待時(shí)間較長，檢查存放控制文件的物理磁盤I/O 是否存在瓶頸。多個(gè)控制文件是完全相同的拷貝，用于鏡像以提高安全性。對于業(yè)

25、務(wù)系統(tǒng)，多個(gè)控制文件應(yīng)該存放在不同的磁盤上，一般來說三個(gè)是足夠的，如果只有兩個(gè)物理硬盤，那么兩個(gè)控制文件也是可以接受的。在同一個(gè)磁盤上保存多個(gè)控制文件是不具備實(shí)際意義的。減少這個(gè)等待，可以考慮如下方法：. 減少控制文件的個(gè)數(shù)(在確保安全的前提下). 如果系統(tǒng)支持，使用異步IO. 轉(zhuǎn)移控制文件到IO 負(fù)擔(dān)輕的物理磁盤 15）. control file sequential read/ control file single write控制文件連續(xù)讀/控制文件單個(gè)寫。對單個(gè)控制文件I/O 存在問題時(shí)，這兩個(gè)事件會(huì)出現(xiàn)。如果等待比較明顯，檢查單個(gè)控制文件，看存放位置是否存在I/O 瓶頸。使用查詢獲

26、得控制文件訪問狀態(tài)：select P1 from V$SESSION_WAIT where EVENT like 'control file%' and STATE='WAITING'解決辦法：. 移動(dòng)有問題的控制文件到快速磁盤. 如果系統(tǒng)支持，啟用異步I/O16）. direct path write: 直接路徑寫該等待發(fā)生在，等待確認(rèn)所有未完成的異步I/O 都已寫入磁盤。你應(yīng)該找到I/O 操作頻繁的數(shù)據(jù)文件，調(diào)整其性能。也有可能存在較多的磁盤排序，臨時(shí)表空間操作頻繁，可以考慮使用Local 管理表空間，分成多個(gè)小文件，寫入不同磁盤或者裸設(shè)備。17）. SQL

27、*Net message from dblink該等待通常指與分布式處理（從其他數(shù)據(jù)庫中SELECT）有關(guān)的等待。這個(gè)事件在通過DBLINKS 聯(lián)機(jī)訪問其他數(shù)據(jù)庫時(shí)產(chǎn)生。如果查找的數(shù)據(jù)多數(shù)是靜態(tài)的，可以考慮移動(dòng)這些數(shù)據(jù)到本地表并根據(jù)需要刷新，通過快照或者物化視圖來減少跨數(shù)據(jù)庫的訪問，會(huì)在性能上得到很大的提高。18）. slave wait: 從屬進(jìn)程等Slave Wait 是Slave I/O 進(jìn)程等待請求，是一個(gè)空閑參數(shù)，一般不說明問題。19）buffer latch 內(nèi)存中數(shù)據(jù)塊的存放位置是記錄在一個(gè)hash列表（cache buffer chains）當(dāng)中的。 當(dāng)一個(gè)會(huì)話需要訪問某個(gè)數(shù)據(jù)

28、塊時(shí)，它首先要搜索這個(gè)hash 列表，從列表中獲得數(shù)據(jù)塊的地址，然后通過這個(gè)地址去訪問需要的數(shù)據(jù)塊，這個(gè)列表Oracle會(huì)使用一個(gè)latch來保護(hù)它的完整性。 當(dāng)一個(gè)會(huì)話需要訪問這個(gè)列表時(shí)，需要獲取一個(gè)Latch，只有這樣，才能保證這個(gè)列表在這個(gè)會(huì)話的瀏覽當(dāng)中不會(huì)發(fā)生變化。 產(chǎn)生buffer latch的等待事件的主要原因是：Buffer chains太長，導(dǎo)致會(huì)話搜索這個(gè)列表花費(fèi)的時(shí)間太長，使其他的會(huì)話處于等待狀態(tài)。同樣的數(shù)據(jù)塊被頻繁訪問，就是我們通常說的熱快問題。 產(chǎn)生buffer chains太長，我們可以使用多個(gè)buffer pool的方式來創(chuàng)建更多的buffer chains，或者使

29、用參數(shù)DB_BLOCK_LRU_LATCHES來增加latch的數(shù)量，以便于更多的會(huì)話可以獲得latch，這兩種方法可以同時(shí)使用。 這個(gè)等待事件有兩個(gè)參數(shù)：Latch addr： 會(huì)話申請的latch在SGA中的虛擬地址，通過以下的SQL語句可以根據(jù)這個(gè)地址找到它對應(yīng)的Latch名稱： select * from v$latch a,v$latchname b whereaddr=latch addr - 這里的latch addr 是你從等待事件中看到的值 and a.latch#=b.latch#; chain#： buffer chains hash 列表中的索引值，當(dāng)這個(gè)參數(shù)的值等于s

30、 0xfffffff時(shí)，說明當(dāng)前的會(huì)話正在等待一個(gè)LRU latch。20） Control file parallel write當(dāng)數(shù)據(jù)庫中有多個(gè)控制文件的拷貝時(shí)，Oracle 需要保證信息同步地寫到各個(gè)控制文件當(dāng)中，這是一個(gè)并行的物理操作過程，因?yàn)榉Q為控制文件并行寫，當(dāng)發(fā)生這樣的操作時(shí)，就會(huì)產(chǎn)生control file parallel write等待事件?？刂莆募l繁寫入的原因很多，比如：日志切換太過頻繁，導(dǎo)致控制文件信息相應(yīng)地需要頻繁更新。系統(tǒng)I/O 出現(xiàn)瓶頸，導(dǎo)致所有I/O出現(xiàn)等待。 當(dāng)系統(tǒng)出現(xiàn)日志切換過于頻繁的情形時(shí)，可以考慮適當(dāng)?shù)卦龃笕罩疚募拇笮斫档腿罩厩袚Q頻率。當(dāng)系統(tǒng)出現(xiàn)大

31、量的control file parallel write 等待事件時(shí)，可以通過比如降低控制文件的拷貝數(shù)量，將控制文件的拷貝存放在不同的物理磁盤上的方式來緩解I/O 爭用。 這個(gè)等待事件包含三個(gè)參數(shù)： Files： Oracle 要寫入的控制文件個(gè)數(shù)。 Blocks： 寫入控制文件的數(shù)據(jù)塊數(shù)目。 Requests：寫入控制請求的I/O 次數(shù)。 21）. Control file sequential read當(dāng)數(shù)據(jù)庫需要讀取控制文件上的信息時(shí)，會(huì)出現(xiàn)這個(gè)等待事件，因?yàn)榭刂莆募男畔⑹琼樞驅(qū)懙?，所以讀取的時(shí)候也是順序的，因此稱為控制文件順序讀，它經(jīng)常發(fā)生在以下情況：備份控制文件RAC 環(huán)境下不同

32、實(shí)例之間控制文件的信息共享讀取控制文件的文件頭信息讀取控制文件其他信息 這個(gè)等待事件有三個(gè)參數(shù)： File#：要讀取信息的控制文件的文件號(hào)。 Block#： 讀取控制文件信息的起始數(shù)據(jù)塊號(hào)。 Blocks：需要讀取的控制文件數(shù)據(jù)塊數(shù)目。 22）Db file parallel read這是一個(gè)很容易引起誤導(dǎo)的等待事件，實(shí)際上這個(gè)等待事件和并行操作（比如并行查詢，并行DML）沒有關(guān)系。 這個(gè)事件發(fā)生在數(shù)據(jù)庫恢復(fù)的時(shí)候，當(dāng)有一些數(shù)據(jù)塊需要恢復(fù)的時(shí)候，Oracle會(huì)以并行的方式把他們從數(shù)據(jù)文件中讀入到內(nèi)存中進(jìn)行恢復(fù)操作。 這個(gè)等待事件包含三個(gè)參數(shù)： Files： 操作需要讀取的文件個(gè)數(shù)。 Block

33、s： 操作需要讀取的數(shù)據(jù)塊個(gè)數(shù)。 Requests：操作需要執(zhí)行的I/O次數(shù)。 23）. Db file parallel write這是一個(gè)后臺(tái)等待事件，它同樣和用戶的并行操作沒有關(guān)系，它是由后臺(tái)進(jìn)程DBWR產(chǎn)生的，當(dāng)后臺(tái)進(jìn)程DBWR想磁盤上寫入臟數(shù)據(jù)時(shí)，會(huì)發(fā)生這個(gè)等待。 DBWR會(huì)批量地將臟數(shù)據(jù)并行地寫入到磁盤上相應(yīng)的數(shù)據(jù)文件中，在這個(gè)批次作業(yè)完成之前，DBWR將出現(xiàn)這個(gè)等待事件。 如果僅僅是這一個(gè)等待事件，對用戶的操作并沒有太大的影響，當(dāng)伴隨著出現(xiàn)free buffer waits等待事件時(shí)，說明此時(shí)內(nèi)存中可用的空間不足，這時(shí)候會(huì)影響到用戶的操作，比如影響到用戶將臟數(shù)據(jù)塊讀入到內(nèi)存中。

34、當(dāng)出現(xiàn)db file parallel write等待事件時(shí)，可以通過啟用操作系統(tǒng)的異步I/O的方式來緩解這個(gè)等待。 當(dāng)使用異步I/O時(shí)，DBWR不在需要一直等到所有數(shù)據(jù)塊全部寫入到磁盤上，它只需要等到這個(gè)數(shù)據(jù)寫入到一個(gè)百分比之后，就可以繼續(xù)進(jìn)行后續(xù)的操作。 這個(gè)等待事件有兩個(gè)參數(shù)： Requests： 操作需要執(zhí)行的I/O次數(shù)。 Timeouts：等待的超時(shí)時(shí)間。 24）Db file single write這個(gè)等待事件通常只發(fā)生在一種情況下，就是Oracle 更新數(shù)據(jù)文件頭信息時(shí)（比如發(fā)生Checkpoint）。 當(dāng)這個(gè)等待事件很明顯時(shí)，需要考慮是不是數(shù)據(jù)庫中的數(shù)據(jù)文件數(shù)量太大，導(dǎo)致Or

35、acle 需要花較長的時(shí)間來做所有文件頭的更新操作（checkpoint）。 這個(gè)等待事件有三個(gè)參數(shù)：File#: 需要更新的數(shù)據(jù)塊所在的數(shù)據(jù)文件的文件號(hào)。Block#：需要更新的數(shù)據(jù)塊號(hào)。Blocks：需要更新的數(shù)據(jù)塊數(shù)目（通常來說應(yīng)該等于1）。 10. Direct path read這個(gè)等待事件發(fā)生在會(huì)話將數(shù)據(jù)塊直接讀取到PGA當(dāng)中而不是SGA中的情況，這些被讀取的數(shù)據(jù)通常是這個(gè)會(huì)話私有的數(shù)據(jù)，所以不需要放到SGA作為共享數(shù)據(jù)，因?yàn)檫@樣做沒有意義。 這些數(shù)據(jù)通常是來自與臨時(shí)段上的數(shù)據(jù)，比如一個(gè)會(huì)話中SQL的排序數(shù)據(jù)，并行執(zhí)行過程中間產(chǎn)生的數(shù)據(jù)，以及Hash Join，merge join

36、產(chǎn)生的排序數(shù)據(jù)，因?yàn)檫@些數(shù)據(jù)只對當(dāng)前的會(huì)話的SQL操作有意義，所以不需要放到SGA當(dāng)中。 當(dāng)發(fā)生direct path read等待事件時(shí)，意味著磁盤上有大量的臨時(shí)數(shù)據(jù)產(chǎn)生，比如排序，并行執(zhí)行等操作。 或者意味著PGA中空閑空間不足。 這個(gè)等待事件有三個(gè)參數(shù)：Descriptor address: 一個(gè)指針，指向當(dāng)前會(huì)話正在等待的一個(gè)direct read I/O。First dba: descriptor address 中最舊的一個(gè)I/O數(shù)據(jù)塊地址。Block cnt: descriptor address上下文中涉及的有效的buffer 數(shù)量。 11. Direct path write

37、這個(gè)等待事件和direct path read 正好相反，是會(huì)話將一些數(shù)據(jù)從PGA中直接寫入到磁盤文件上，而不經(jīng)過SGA。 這種情況通常發(fā)生在：使用臨時(shí)表空間排序（內(nèi)存不足）數(shù)據(jù)的直接加載（使用append方式加載數(shù)據(jù)）并行DML操作。 這個(gè)等待事件有三個(gè)參數(shù)： Descriptor address: 一個(gè)指針，指向當(dāng)前會(huì)話正在等待的一個(gè)direct I/O. First dba: descriptor address 中最舊的一個(gè)I/O數(shù)據(jù)塊地址。 Block cnt: descriptor address 上下文中涉及的有效地 buffer 數(shù)量。 12. EnqueueEnqueue 這

38、個(gè)詞其實(shí)是lock 的另一種描述語。 當(dāng)我們在AWR 報(bào)告中發(fā)現(xiàn)長時(shí)間的enqueue 等待事件時(shí)，說明數(shù)據(jù)庫中出現(xiàn)了阻塞和等待，可以關(guān)聯(lián)AWR報(bào)告中的enqueue activity部分來確定是哪一種鎖定出現(xiàn)了長時(shí)間等待。 這個(gè)等待事件有2個(gè)參數(shù)： Name： enqueue 的名稱和類型。Mode： enqueue的模式。 可以使用如下SQL 查看當(dāng)前會(huì)話等待的enqueue名稱和類型：/* Formatted on 2010/8/12 11:00:56 (QP5 v5.115.810.9015) */ SELECT CHR (TO_CHAR (BITAND (p1, -16777216)

39、 / 16777215) | CHR (TO_CHAR (BITAND (p1, 16711680) / 65535) "Lock", TO_CHAR (BITAND (p1, 65535) "Mode" FROM v$session_wait WHERE event = ''enqueue'' Oracle 的enqueue 包含以下模式： Oracle的enqueue 有如下類型：Enqueue 縮寫縮寫解釋BL Buffer Cache managementBR Backup/RestoreCF Controlfil

40、e transactionCI Cross-instance Call InvocationCU Bind EnqueueDF DatafileDL Direct Loader Index CreationDM Database MountDR Distributed Recovery ProcessDX Dirstributed TransactionFP File ObjectFS File SetHW High-water LockIN Instance NumberIR Instance RecoveryIS Instance StateIV Library Cache Invalid

41、ationJI Enqueue used during AJV snapshot refreshJQ Job QueueKK Redo Log “Kick”KO Multiple Object CheckpointLA-p Library Cache LockLS Log start or switchMM Mount DefinitionMR Media recoveryNA-Z Library Cache binPE Alter system set parameter =valuePF Password filePI Parallel slavesPR Process startupPS

42、 Parallel slave synchronizationQA-Z Row CacheRO Object ReuseRT Redo ThreadRW Row WaitSC System Commit NumberSM SMONSN Sequence NumberSQ Sequence Number EnqueueSR Synchronized replicationSS Sort segmentST Space management transactionSV Sequence number ValueTA Transaction recoveryTC Thread CheckpointT

43、E Extend TableTM DML enqueueTO Temporary Table Object EnqueueTS Temporary Segement(also TableSpace)TT Temporary TableTX TransactionUL User-defined LocksUN User nameUS Undo segment, SerializationWL Being Written Redo LogXA Instance Attribute LogXI Instance Registration Lock關(guān)于enqueue 可以參考如下的連接： Wait E

44、vents - Enqueue Waits 25) Library cache lock這個(gè)等待時(shí)間發(fā)生在不同用戶在共享中由于并發(fā)操作同一個(gè)數(shù)據(jù)庫對象導(dǎo)致的資源爭用的時(shí)候，比如當(dāng)一個(gè)用戶正在對一個(gè)表做DDL 操作時(shí)，其他的用戶如果要訪問這張表，就會(huì)發(fā)生library cache lock等待事件，它要一直等到DDL操作完成后，才能繼續(xù)操作。 這個(gè)事件包含四個(gè)參數(shù)： Handle address: 被加載的對象的地址。Lock address： 鎖的地址。Mode： 被加載對象的數(shù)據(jù)片段。Namespace： 被加載對象在v$db_object_cache 視圖中namespace名稱。 16.

45、 Library cache pin這個(gè)等待事件和library cache lock 一樣是發(fā)生在共享池中并發(fā)操作引起的事件。通常來講，如果Oracle 要對一些PL/SQL 或者視圖這樣的對象做重新編譯，需要將這些對象pin到共享池中。 如果此時(shí)這個(gè)對象被其他的用戶特有，就會(huì)產(chǎn)生一個(gè)library cache pin的等待。 這個(gè)等待事件也包含四個(gè)參數(shù)： Handle address: 被加載的對象的地址。Lock address： 鎖的地址。Mode： 被加載對象的數(shù)據(jù)片段。Namespace： 被加載對象在v$db_object_cache 視圖中namespace名稱。 17. Lo

46、g file parallel write后臺(tái)進(jìn)程LGWR 負(fù)責(zé)將log buffer當(dāng)中的數(shù)據(jù)寫到REDO 文件中，以重用log buffer的數(shù)據(jù)。 如果每個(gè)REDO LOG組里面有2個(gè)以上的成員，那么LGWR進(jìn)程會(huì)并行地將REDO 信息寫入這些文件中。 如果數(shù)據(jù)庫中出現(xiàn)這個(gè)等待事件的瓶頸，主要的原因可能是磁盤I/O性能不夠或者REDO 文件的分布導(dǎo)致了I/O爭用，比如同一個(gè)組的REDO 成員文件放在相同的磁盤上。 這個(gè)等待事件有三個(gè)參數(shù)： Files： 操作需要寫入的文件個(gè)數(shù)。 Blocks： 操作需要寫入的數(shù)據(jù)塊個(gè)數(shù)。 Requests：操作需要執(zhí)行的I/O次數(shù)。 18. Log bu

47、ffer space當(dāng)log buffer 中沒有可用空間來存放新產(chǎn)生的redo log數(shù)據(jù)時(shí)，就會(huì)發(fā)生log buffer space等待事件。 如果數(shù)據(jù)庫中新產(chǎn)生的redo log的數(shù)量大于LGWR 寫入到磁盤中的redo log 數(shù)量，必須等待LGWR 完成寫入磁盤的操作，LGWR必須確保redo log寫到磁盤成功之后，才能在redo buffer當(dāng)中重用這部分信息。 如果數(shù)據(jù)庫中出現(xiàn)大量的log buffer space等待事件，可以考慮如下方法：（1） 增加redo buffer的大小。（2） 提升磁盤的I/O性能 19. Log file sequential read這個(gè)等待事件通常發(fā)生在對redo log信息進(jìn)行讀取時(shí)，比如在線redo 的歸檔操作，ARCH進(jìn)程需要讀取redo log的信息，由于redo log的信息是順序?qū)懭氲?，所以在讀取時(shí)也是按照順序的方式來讀取的。 這個(gè)等待事件包含三個(gè)參數(shù)： Log#： 發(fā)生等待時(shí)讀取的redo log的sequence號(hào)。 Block#： 讀取的數(shù)據(jù)塊號(hào)。 Blocks： 讀取的數(shù)據(jù)塊個(gè)數(shù)。 20. Log file single write這個(gè)等待事件發(fā)生在更新redo log文件的文件頭時(shí)，當(dāng)為日志組增加新的日志成員時(shí)