oracle等待事件是衡量oracle執行狀況的重要依據及指示，等待事件分為兩類：空閒等待事件和非空閒等待事件, TIMED_STATISTICS = TRUE 那麼等待事件按等待的時間排序，= FALSE那麼事件按等待的數量排序。執行statspack期間必須session上設定TIMED_STATISTICS = TRUE，否則統計的資料將失真。空閒等待事件是oracle正等待某種工作，在診斷和優化資料庫時候，不用過多注意這部分事件，非空閒等待事件專門針對oracle的活動，指資料庫任務或應用程式執行過程中發生的等待，這些等待事件是我們在調整資料庫應該關注的。

對於常見的等待事件，說明如下：

1、db file scattered read 檔案分散讀取該事件通常與全表掃描或者fast full index scan有關。因為全表掃描是被放入記憶體中進行的進行的，通常情況下基於效能的考慮，有時候也可能是分配不到足夠長的連續記憶體空間，所以會將資料塊分散(scattered)讀入Buffer Cache中。該等待過大可能是缺少索引或者沒有合適的索引(可以調整optimizer_index_cost_adj) 。這種情況也可能是正常的，因為執行全表掃描可能比索引掃描效率更高。當系統存在這些等待時，需要通過檢查來確定全表掃描是否必需的來調整。因為全表掃描被置於LRU(Least Recently Used，最近最少適用)列表的冷端(cold end)，對於頻繁訪問的較小的資料表，可以選擇把他們Cache 到記憶體中，以避免反覆讀取。當這個等待事件比較顯著時，可以結合v$session_longops 動態效能檢視來進行診斷，該檢視中記錄了長時間(執行時間超過6 秒的)執行的事物，可能很多是全表掃描操作(不管怎樣，這部分資訊都是值得我們注意的)。
關於引數OPTIMIZER_INDEX_COST_ADJ＝n：該引數是一個百分比值，預設值為100，可以理解為FULL SCAN COST/INDEX SCAN COST。當n%* INDEX SCAN COST<FULL SCAN COST時，oracle會選擇使用索引。在具體設定的時候，我們可以根據具體的語句來調整該值。如果我們希望某個statement使用索引，而實際它確走全表掃描，可以對比這兩種情況的執行計劃不同的COST，從而設定一個更合適的值。

2、db file sequential read檔案順序讀取整程式碼,特別是表連線：最常見的等待事件

該事件說明在單個數據塊上大量等待，該值過高通常是由於表間連線順序很糟糕（沒有正確選擇驅動行源），或者使用了非選擇性索引。通過將這種等待與statspack報表中已知其它問題聯絡起來(如效率不高的sql),通過檢查確保索引掃描是必須的，並確保多表連線的連線順序來調整。

 每事務低於200算正常的，這裡是133。

何時會出現這種等待：http://www.askmaclean.com/archives/db-file-sequential-read-wait-event.html

3、buffer busy wait 緩衝區忙

增大DB_CACHE_SIZE,加速檢查點,調整程式碼：

當程序需要存取SGA中的buffer的時候，它會依次執行如下步驟的操作：

當緩衝區以一種非共享方式或者如正在被讀入到緩衝時,就會出現該等待。該值不應該大於1%。當出 現等待問題時，可以檢查緩衝等待統計部分(或V$WAITSTAT)，確定該等待發生在什麼位置：

如果等待是否位於段頭(Segment Header)。這種情況表明段中的空閒列表（freelist）的塊比較少。可以考慮增加空閒列表(freelist，對於Oracle8i DMT)或者增加freelist groups(在很多時候這個調整是立竿見影的(alter table tablename strorage(freelists 2))，在8.1.6之前，這個freelists引數不能動態修改;在8.1.6及以後版本，動態修改feelists需要設定COMPATIBLE至少為8.1.6)。也可以增加PCTUSED與PCTFREE之間距離（PCTUSED-to-pctfree gap），其實就是說降低PCTUSED的值，儘快使塊返回freelist列表被重用。如果支援自動段空間管理（ASSM），也可以使用ASSM模式，這是在ORALCE 920以後的版本中新增的特性。

如果這一等待位於undo header，可以通過增加回滾段(rollback segment)來解決緩衝區的問題。

如果等待位於undo block上，我們需要增加提交的頻率，使block可以儘快被重用；使用更大的回滾段；降低一致讀所選擇的表中資料的密度；增大DB_CACHE_SIZE。

如果等待處於data block，表明出現了hot block，可以考慮如下方法解決： ①將頻繁併發訪問的表或資料移到另一資料塊或者進行更大範圍的分佈(可以增大pctfree值 ，擴大資料分佈，減少競爭)，以避開這個"熱點"資料塊。②也可以減小資料塊的大小，從而減少一個數據塊中的資料行數，降低資料塊的熱度，減小競爭；③檢查對這些熱塊操作的SQL語句，優化語句。④增加hot block上的initrans值。但注意不要把initrans值設定的過於高了，通常設定為5就足夠了。因為增加事務意味著要增加ITL事務槽，而每個ITL事務槽將佔用資料塊中24個位元組長度。預設情況下，每個資料塊或者索引塊中是ITL槽是2個，在增加initrans的時候，可以考慮增大資料塊所在的表的PCTFREE值，這樣Oracle會利用PCTFREE部分的空間增加ITL slot數量，最大達到maxtrans指定。

如果等待處於index block，應該考慮重建索引、分割索引或使用反向鍵索引。為了防止與資料塊相關的緩衝忙等待，也可以使用較小的塊，在這種情況下，單個塊中的記錄就較少，所以這個塊就不是那麼"繁忙"。或者可以設定更大的PCTFREE,使資料擴大物理分佈，減少記錄間的熱點競爭。在執行DML (insert/update/ delete)時，Oracle向資料塊中寫入資訊，對於多事務併發訪問的資料表，關於ITL的競爭和等待可能出現，為了減少這個等待，可以增加initrans，使用多個ITL槽。在Oracle9i 中，可以使用ASSM這個新特性Oracle 使用點陣圖來管理空間使用，減小爭用。

【

當程序需要存取SGA中的buffer的時候，它會依次執行如下步驟的操作：1.獲得cache buffers chains latch，遍歷那條buffer chain直到找到需要的buffer header2.根據需要進行的操作型別(讀或寫)，它需要在buffer header上獲得一個共享或獨佔模式的buffer pin或者buffer lock3.若程序獲得buffer header pin，它會釋放獲得的cache buffers chains latch，然後執行對buffer block的操作4.若程序無法獲得buffer header pin，它就會在buffer busy waits事件上等待程序之所以無法獲得buffer header pin，是因為為了保證資料的一致性，同一時刻一個block只能被一個程序pin住進行存取，因此當一個程序需要存取buffer cache中一個被其他程序使用的block的時候，這個程序就會產生對該block的buffer busy waits事件。截至 9i，buffer busy waits事件的p1,p2,p3三個引數分別是file#,block#和id，分別表示等待的buffer block所在的檔案編號，塊編號和具體的等待原因編號，到了Oracle10g，前兩個引數沒變，第3個引數變成了塊型別編號，這一點可以通過查詢v$event_name檢視來進行驗證：

PHP code:Oracle 9iSQL>select parameter1,parameter2,parameter3 from v$event_name where name='buffer busy waits'PARAMETER1                  PARAMETER2                 PARAMETER3------------------------ ------------------------ ------------------------file#                            block#                          idOracle 10gPARAMETER1                  PARAMETER2                 PARAMETER3------------------------ ------------------------ ------------------------file#                            block#                          class#

在診斷buffer busy waits事件的過程中，獲取如下資訊會很有用：1.獲取產生buffer busy waits事件的等待原因編號，這可以通過查詢該事件的p3引數值獲得2.獲取產生此事件的SQL語句，可以通過如下的查詢獲得：select sql_text from v$sql t1,v$session t2,v$session_wait t3where t1.address=t2.sql_address and t1.hash_value=t2.sql_hash_valueand t2.sid=t3.sid and t3.event='buffer busy waits';3.獲取等待的塊的型別以及所在的segment，可以通過如下查詢獲得：

PHP code:select 'Segment Header'class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait bwhere a.header_file=b.p1and a.header_block=b.p2and b.event='buffer busy waits'unionselect 'Freelist Groups'class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait bwhere a.header_file=b.p1and b.p2 between a.header_block+1and (a.header_block+a.freelist_groups) and a.freelist_groups>1and b.event='buffer busy waits'unionselect a.segment_type||' block'class,a.segment_type,a.segment_name,a.partition_name from dba_extents a,v$session_wait bwhere a.file_id=b.p1and b.p2 between a.block_idand a.block_id+a.blocks-1and b.event='buffer busy waits'and not exists(select 1 from dba_segments whereheader_file=b.p1and header_block=b.p2);

查詢的第一部分：如果等待的塊型別是segment header，那麼可以直接拿buffer busy waits事件的p1和p2引數去dba_segments檢視中匹配header_file和header_block欄位即可找到等待的segment名稱和segment型別，進行相應調整查詢的第二部分：如果等待的塊型別是freelist groups，也可以在dba_segments檢視中找出對應的segment名稱和segment型別，注意這裡的引數p2表示的freelist groups的位置是在segment的header_block+1到header_block+freelist groups組數之間，並且freelist groups組數大於1查詢的第三部分：如果等待的塊型別是普通的資料塊，那麼可以用p1、p2引數和dba_extents進行聯合查詢得到block所在的segment名稱和segment型別對於不同的等待塊型別，我們採取不同的處理辦法：1.data segment header：程序經常性的訪問data segment header通常有兩個原因：獲取或修改process freelists資訊、擴充套件高水位標記，針對第一種情況，程序頻繁訪問process freelists資訊導致freelist爭用，我們可以增大相應的segment物件的儲存引數freelist或者freelist groups；若由於資料塊頻繁進出freelist而導致程序經常要修改freelist，則可以將pctfree值和pctused值設定較大的差距，從而避免資料塊頻繁進出freelist；對於第二種情況，由於該segment空間消耗很快，而設定的next extent過小，導致頻繁擴充套件高水位標記，解決的辦法是增大segment物件的儲存引數next extent或者直接在建立表空間的時候設定extent size uniform2.data block：某一或某些資料塊被多個程序同時讀寫，成為熱點塊，可以通過如下這些辦法來解決這個問題：(1)降低程式的併發度，如果程式中使用了parallel查詢，降低parallel degree，以免多個parallel slave同時訪問同樣的資料物件而形成等待降低效能(2)調整應用程式使之能讀取較少的資料塊就能獲取所需的資料，減少buffer gets和physical reads(3)減少同一個block中的記錄數，使記錄分佈於更多的資料塊中，這可以通過若干途徑實現：可以調整segment物件的pctfree值，可以將segment重建到block size較小的表空間中，還可以用alter table minimize records_per_block語句減少每塊中的記錄數(4)若熱點塊物件是類似自增id欄位的索引，則可以將索引轉換為反轉索引，打散資料分佈，分散熱點塊3.undo segment header：undo segment header爭用是因為系統中undo segment不夠，需要增加足夠的undo segment，根據undo segment的管理方法，若是手工管理模式，需要修改rollback_segments初始化引數來增加rollback segment，若是自動管理模式，可以減小transactions_per_rollback_segment初始化引數的值來使oracle自動增多rollback segment的數量4.undo block：undo block爭用是由於應用程式中存在對資料的讀和寫同時進行，讀程序需要到undo segment中去獲得一致性資料，解決辦法是錯開應用程式修改資料和大量查詢資料的時間小結：buffer busy waits事件是oracle等待事件中比較複雜的一個，其形成原因很多，需要根據p3引數對照Oracle提供的原因程式碼表進行相應的診斷，10g以後則需要根據等待的block型別結合引起等待時間的具體SQL進行分析，採取相應的調整措施

】

4、latch free：

當閂鎖丟失率高於0.5%時，需要調整這個問題。詳細的我們在後面的Latch Activity for DB部分說明。

latch是一種低階排隊機制，用於保護SGA中共享記憶體結構。latch就像是一種快速地被獲取和釋放的記憶體鎖。用於防止共享記憶體結構被多個使用者同時訪問。如果latch不可用，就會記錄latch釋放失敗(latch free miss )。有兩種與閂有關的型別:

　　■ 立刻。

　　■ 可以等待。

　　假如一個程序試圖在立刻模式下獲得閂，而該閂已經被另外一個程序所持有，如果該閂不能立可用的話，那麼該程序就不會為獲得該閂而等待。它將繼續執行另一個操作。

　　大多數latch問題都與以下操作相關:

　　沒有很好的是用繫結變數(library cache latch)、重作生成問題(redo allocation latch)、緩衝儲存競爭問題(cache buffers LRU chain)，以及buffer cache中的存在"熱點"塊(cache buffers chain)。

　　通常我們說，如果想設計一個失敗的系統，不考慮繫結變數，這一個條件就夠了，對於異構性強的系統，不使用繫結變數的後果是極其嚴重的。

　　另外也有一些latch等待與bug有關，應當關注Metalink相關bug的公佈及補丁的釋出。當latch miss ratios大於0.5%時，就應當研究這一問題。

　　Oracle的latch機制是競爭，其處理類似於網路裡的CSMA/CD，所有使用者程序爭奪latch，對於願意等待型別(willing-to-wait)的latch,如果一個程序在第一次嘗試中沒有獲得latch,那麼它會等待並且再嘗試一次,如果經過_spin_count次爭奪不能獲得latch, 然後該程序轉入睡眠狀態，持續一段指定長度的時間，然後再次醒來，按順序重複以前的步驟.在8i/9i中預設值是_spin_count=2000。

　　如果SQL語句不能調整，在8.1.6版本以上，Oracle提供了一個新的初始化引數: CURSOR_SHARING可以通過設定CURSOR_SHARING = force 在伺服器端強制繫結變數。設定該引數可能會帶來一定的副作用，對於Java的程式，有相關的bug，具體應用應該關注Metalink的bug公告。

***Latch問題及可能解決辦法
------------------------------
* Library Cache and Shared Pool (未繫結變數---繫結變數,調整shared_pool_size)
每當執行SQL或PL/SQL儲存過程,包,函式和觸發器時,這個Latch即被用到.Parse操作中此Latch也會被頻繁使用.
* Redo Copy (增大_LOG_SIMULTANEOUS_COPIES引數)
重做拷貝Latch用來從PGA向重做日誌緩衝區拷貝重做記錄.
* Redo Allocation (最小化REDO生成,避免不必要提交)
此Latch用來分配重做日誌緩衝區中的空間,可以用NOLOGGING來減緩競爭.
* Row Cache Objects (增大共享池)
資料字典競爭.過度parsing.
* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS應增大或設為質數)
"過熱"資料塊造成了記憶體緩衝鏈Latch競爭.
* Cache Buffers Lru Chain (調整SQL，設定DB_BLOCK_LRU_LATCHES,或使用多個緩衝區池)
掃描全部記憶體緩衝區塊的LRU(最近最少使用)鏈時要用到記憶體緩衝區LRU鏈Latch.太小記憶體緩衝區、過大的記憶體緩衝區吞吐量、過多的記憶體中進行的排序操作、DBWR速度跟不上工作負載等會引起此Latch競爭。

5、Enqueue

佇列是一種鎖，保護一些共享資源，防止併發的DML操作。佇列採用FIFO策略，注意latch並不是採用的FIFO機制。比較常見的有3種類型的佇列：ST佇列，HW佇列，TX4佇列。
ST Enqueue的等待主要是在字典管理的表空間中進行空間管理和分配時產生的。解決方法：1）將字典管理的表空間改為本地管理模式 2）預先分配分割槽或者將有問題的字典管理的表空間的next extent設定大一些。
HW Enqueue是用於segment的HWM的。當出現這種等待的時候，可以通過手工分配extents來解決。
TX4 Enqueue等待是最常見的等待情況。通常有3種情況會造成這種型別的等待：1）唯一索引中的重複索引。解決方法：commit或者rollback以釋放佇列。 2）對同一個點陣圖索引段（bitmap index fragment）有多個update，因為一個bitmap index fragment可能包含了多個rowid，所以當多個使用者更新時，可能一個使用者會鎖定該段，從而造成等待。解決方法同上。3）有多個使用者同時對一個數據塊作update，當然這些DML操作可能是針對這個資料塊的不同的行，如果此時沒有空閒的ITL槽，就會產生一個block-level鎖。解決方法：增大表的initrans值使建立更多的ITL槽；或者增大表的pctfree值，這樣oracle可以根據需要在pctfree的空間建立更多的ITL槽；使用smaller block size，這樣每個塊中包含行就比較少，可以減小衝突發生的機會。

AWR報告分析--等待事件-佇列.doc

6、Free Buffer 釋放緩衝區：

這個等待事件表明系統正在等待記憶體中的可用空間，這說明當前Buffer 中已經沒有Free 的記憶體空間。如果應用設計良好，SQL 書寫規範，充分繫結變數，那這種等待可能說明Buffer Cache 設定的偏小，你可能需要增大DB_CACHE_SIZE。該等待也可能說明DBWR 的寫出速度不夠，或者磁碟存在嚴重的競爭，可以需要考慮增加檢查點、使用更多的DBWR 程序，或者增加物理磁碟的數量,分散負載，平衡IO。

7、Log file single write：

該事件僅與寫日誌檔案頭塊相關，通常發生在增加新的組成員和增進序列號時。頭塊寫單個進行，因為頭塊的部分資訊是檔案號，每個檔案不同。更新日誌檔案頭這個操作在後臺完成，一般很少出現等待，無需太多關注。

8、log file parallel write：

從log buffer寫redo 記錄到redo log檔案，主要指常規寫操作(相對於log file sync)。如果你的Log group 存在多個組成員，當flush log buffer 時，寫操作是並行的，這時候此等待事件可能出現。儘管這個寫操作並行處理，直到所有I/O 操作完成該寫操作才會完成(如果你的磁碟支援非同步IO或者使用IO SLAVE，那麼即使只有一個redo log file member,也有可能出現此等待)。這個引數和log file sync 時間相比較可以用來衡量log file 的寫入成本。通常稱為同步成本率。改善這個等待的方法是將redo logs放到I/O快的盤中，儘量不使用raid5，確保表空間不是處在熱備模式下，確保redo log和data的資料檔案位於不同的磁碟中。

9、log file sync：

當一個使用者提交或回滾資料時，LGWR將會話的redo記錄從日誌緩衝區填充到日誌檔案中，使用者的程序必須等待這個填充工作完成。在每次提交時都出現，如果這個等待事件影響到資料庫效能，那麼就需要修改應用程式的提交頻率, 為減少這個等待事件，須一次提交更多記錄，或者將重做日誌REDO LOG 檔案訪在不同的物理磁碟上，提高I/O的效能。

當一個使用者提交或回滾資料時，LGWR 將會話期的重做由日誌緩衝器寫入到重做日誌中。日誌檔案同步過程必須等待這一過程成功完成。為了減少這種等待事件，可以嘗試一次提交更多的記錄(頻繁的提交會帶來更多的系統開銷)。將重做日誌置於較快的磁碟上，或者交替使用不同物理磁碟上的重做日誌，以降低歸檔對LGWR的影響。

　　對於軟RAID，一般來說不要使用RAID 5，RAID5 對於頻繁寫入得系統會帶來較大的效能損失，可以考慮使用檔案系統直接輸入/輸出，或者使用裸裝置(raw device)，這樣可以獲得寫入的效能提高。

Log file parallel write慢=> log file sync慢=>commit慢，commit慢則釋放行鎖慢。 Rac flush redo也受到寫redo慢的影響，則出現gc buffer busy release/acquire，前後相互作用è enq:TX大幅出現

10、log buffer space：

日誌緩衝區寫的速度快於LGWR寫REDOFILE的速度,可以增大日誌檔案大小，增加日誌緩衝區的大小，或者使用更快的磁碟來寫資料。

當你將日誌緩衝(log buffer)產生重做日誌的速度比LGWR 的寫出速度快，或者是當日志切換(log switch)太慢時，就會發生這種等待。這個等待出現時，通常表明redo log buffer 過小，為解決這個問題，可以考慮增大日誌檔案的大小，或者增加日誌緩衝器的大小。

　　另外一個可能的原因是磁碟I/O 存在瓶頸，可以考慮使用寫入速度更快的磁碟。在允許的條件下設定可以考慮使用裸裝置來存放日誌檔案，提高寫入效率。在一般的系統中，最低的標準是，不要把日誌檔案和資料檔案存放在一起，因為通常日誌檔案只寫不讀，分離存放可以獲得性能提升。

11、logfile switch：通常是因為歸檔速度不夠快。

表示所有的提交(commit)的請求都需要等待"日誌檔案切換"的完成。Log file Switch 主要包含兩個子事件:
log file switch (archiving needed) 這個等待事件出現時通常是因為日誌組迴圈寫滿以後，第一個日誌歸檔尚未完成，出現該等待。出現該等待，可能表示io 存在問題。解決辦法:①可以考慮增大日誌檔案和增加日誌組；②移動歸檔檔案到快速磁碟；③調整log_archive_max_processes。
log file switch (checkpoint incomplete) 當日志組都寫完以後，LGWR 試圖寫第一個log file，如果這時資料庫沒有完成寫出記錄在第一個log file 中的dirty 塊時(例如第一個檢查點未完成)，該等待事件出現。該等待事件通常表示你的DBWR 寫出速度太慢或者IO 存在問題。為解決該問題，你可能需要考慮增加額外的DBWR 或者增加你的日誌組或日誌檔案大小，或者也可以考慮增加checkpoint的頻率。

12、DB File Parallel Write：檔案被DBWR並行寫時發生。解決辦法：改善IO效能。

處理此事件時，需要注意

1）db file parallel write事件只屬於DBWR程序。

2）緩慢的DBWR可能影響前臺程序。

3）大量的db file parallel write等待時間很可能是I/O問題引起的。（在確認os支援非同步io的前提下，你可以在系統中檢查disk_asynch_io引數，保證為TRUE。可以通過設定db_writer_processes來提高DBWR程序數量，當然前提是不要超過cpu的數量。）DBWR程序執行經過SGA的所有資料庫寫入，當開始寫入時，DBWR程序編譯一組髒塊（dirty block），並且將系統寫入呼叫釋出到作業系統。DBWR程序查詢在各個時間內寫入的塊，包括每隔3秒的一次查詢，當前臺程序提交以清除緩衝區中的內容時：在檢查點處查詢，當滿足_DB_LARGE_DIRTY_QUEUE、_DB_BLOCK_MAX_DIRTY_TARGET和FAST_START_MTTR_TARGET閥值時，等等。雖然使用者會話從來沒有經歷過db file parallel write等待事件，但這並不意味著它們不會受到這種事件的影響。緩慢的DBWR寫入效能可以造成前臺會話在write complete waits或free buffer waits事件上等待。DBWR寫入效能可能受到如下方面的影響：I/O操作的型別（同步或非同步）、儲存裝置（裸裝置或成熟的檔案系統）、資料庫佈局和I/O子系統配置。需要檢視的關鍵資料庫統計是當db file parallel write、free buffer waits和write complete waits等待事件互相關聯時，系統範圍內的TIME_WAITED和AVERAGE_WAIT。如果db file parallel write平均等待時間大於10cs（或者100ms），則通常表明緩慢的I/O吞吐量。可以通過很多方法來改善平均等待時間。主要的方法是使用正確型別的I/O操作。如果資料檔案位於裸裝置（raw device）上，並且平臺支援非同步I/O，就應該使用非同步寫入。但是，如果資料庫位於檔案系統上，則應該使用同步寫入和直接I/O（這是作業系統直接I/O）。除了確保正在使用正確型別的I/O操作，還應該檢查你的資料庫佈局並使用常見的命令監控來自作業系統的I/O吞吐量。例如sar -d或iostat -dxnC。當db file parallel write平均等待時間高並且系統繁忙時，使用者會話可能開始在free buffer waits事件上等待。這是因為DBWR程序不能滿足釋放緩衝區的需求。如果free buffer waits事件的TIME_WAITED高，則應該在快取記憶體中增加緩衝區數量之前說明DBWR I/O吞吐量的問題。高db file parallel write平均等待時間的另一個反響是在write complete waits等待事件上的高TIME_WAITED。前臺程序不允許修改正在傳輸到磁碟的塊。換句話說，也就是位於DBWR批量寫入中的塊。前臺的會話在write complete waits等待事件上等待。因此，write complete waits事件的出現，一定標誌著緩慢的DBWR程序，可以通過改進DBWR I/O吞吐量修正這種延遲。

13、DB File Single Write：當檔案頭或別的單獨塊被寫入時發生，這一等待直到所有的I/O呼叫完成。解決辦法：改善IO效能。

14、DB FILE Scattered Read：當掃描整個段來根據初始化引數db_file_multiblock_read_count讀取多個塊時發生，因為資料可能分散在不同的部分，這與分條或分段）相關，因此通常需要多個分散的讀來讀取所有的資料。等待時間是完成所有I/O呼叫的時間。解決辦法：改善IO效能。

這種情況通常顯示與全表掃描相關的等待。當資料庫進行全表掃時，基於效能的考慮，資料會分散(scattered)讀入Buffer Cache。如果這個等待事件比較顯著，可能說明對於某些全表掃描的表，沒有建立索引或者沒有建立合適的索引，我們可能需要檢查這些資料表已確定是否進行了正確的設定。

然而這個等待事件不一定意味著效能低下，在某些條件下Oracle會主動使用全表掃描來替換索引掃描以提高效能，這和訪問的資料量有關，在CBO下Oracle會進行更為智慧的選擇，在RBO下Oracle更傾向於使用索引。

因為全表掃描被置於LRU（Least Recently Used，最近最少適用）列表的冷端（cold end），對於頻繁訪問的較小的資料表，可以選擇把他們Cache到記憶體中，以避免反覆讀取。

當這個等待事件比較顯著時，可以結合v$session_longops動態效能檢視來進行診斷，該檢視中記錄了長時間（執行時間超過6秒的）執行的事物，可能很多是全表掃描操作（不管怎樣，這部分資訊都是值得我們注意的）。

15、DB FILE Sequential Read：當前臺程序對資料檔案進行常規讀時發生，包括索引查詢和別的非整段掃描以及資料檔案塊丟棄等待。等待時間是完成所有I/O呼叫的時間。解決辦法：改善IO效能。

如果這個等待事件比較顯著，可能表示在多表連線中，表的連線順序存在問題，沒有正確地使用驅動表；或者可能索引的使用存在問題，並非索引總是最好的選擇。在大多數情況下，通過索引可以更為快速地獲取記錄，所以對於編碼規範、調整良好的資料庫，這個等待事件很大通常是正常的。有時候這個等待過高和儲存分佈不連續、連續資料塊中部分被快取有關，特別對於DML頻繁的資料表，資料以及儲存空間的不連續可能導致過量的單塊讀，定期的資料整理和空間回收有時候是必須的。

相關推薦