第5 章、解釋常見的與I/O 有關的等待事件

第5 章、解釋常見的與I/O 有關的等待事件

1.          Db file sequential read 等待事件：

1)         根據索引的順序讀取：

l  optimizer_index_cost_adj 和optimizer_index_caching 引數可能導致優化器錯誤的選擇索引掃描，相關session 的優化器設定可以在檢視v$ses_optimizer_env 中檢視。

l  在分析表和索引的統計資訊時，如果estimate 的值比較低，那麼Oracle 一般會採用單塊讀，這是會產生db file sequential read 等待事件。

2)      根據表的順序讀取：

通過從索引中獲得的rowid 開訪問表時使用單塊I/O。

3)      系統級診斷：

系統級的斬斷提供的統計功能非常有限，必須確保I/O 子系統中熱點的問題，確保資料庫安裝點只有Oracle 軟體，磁碟資料檔案的分佈情況等，可從v$filestat 檢視資料檔案單塊讀取相關的統計資訊。

2.        Db file scattered read 等待事件：

l  可導致優化器選擇全表掃描的初始化引數：db_file_multiblock_read_count （MBRC ）、hash_area_size 、optimizer_index_cost_adj 。

l  當分析帶有compute 引數時，Oracle 執行全表掃描，並新增v$session_event 和v$system_event 檢視的db file scattered read 統計資料。

l  Db file sequential read 出現在db_file scattered read 之後的原因：

1)         區邊界：如果一個區的最後一組塊中只有一個塊的時候，Oracle 就使用單塊讀取該塊。

2)      例如一個區中有9 個塊，MBRC=8 ，那麼第一次讀取8 塊，第二次是1塊，以此類推。在這種情況下，需要構建較大的區大小來增加全表掃描的效率。

3)      快取記憶體塊：即讀取時遇到某個塊在快取記憶體中，使用單塊讀，這沒有問題。

4)      連結的或遷移的行：Oracle 使用單塊讀來尋求每個連結或遷移的行。

5)      索引條目的建立：向具有索引的表中插入資料時，可能遇到此類事件，這沒有問題。

l  多塊讀取中讀取的塊數少於MBRC 的原因：

1)         受區大小影響，Oracle 每次多塊讀取都必須是在一個區間內，不能跨區讀取。

2)      受已快取塊的影響，如果在一次多塊讀中的塊號不能連續，即中間有塊已經被快取了，那麼就分成多次多塊讀。

l  MBRC 的設定收到多重的限制，你可以將MBRC 設定為一個巨大的值，但是永遠也不會達到此值。

3.        Direct path read 等待事件：

l  直接讀取可能按照同步和非同步的方式執行，取決於引數disk_asynch_io ，使用非同步IO時的系統級direct path read 可能不準確。

l  執行並行查詢的SQL 語句不會再direct path read 上等待，會在PX Deq 上等待（execute reply 等待事件），如果是由於SQL 函式的驅動，則有可能在父會話中出現direct path read 等待。

l  由於並行查詢和Oracle 計數等待事件的方式等原因，不應該根據v$session_event 來估計direct path read 等待事件，而是應該從v$sesstat 中檢視physical reads direct （此統計中包含了並行查詢中子程式的直接讀資料），但是這樣的方式缺點就是沒有時間元素。

l  Db_file_direct_io_count 引數可能影響direct path read 的效能，該引數是一個隱藏引數，控制著直接讀的I/O 緩衝區大小，直接讀取的大小限制，還可以從此事件的P3 引數看出來。

4.        Direct path write 等待事件：

l  基本上與直接讀相同，如果直接寫的時臨時檔案，那麼降低了直接寫也就是等於降低了直接讀。

5.        Db file parallel write 等待事件：

l  該事件只屬於DBWR 程式，即使沒有經db file parallel write 等待事件，也有可能受到此事件的影響，緩慢的DBWR 可能造成前臺會話在write complete wait 或free buffer waits 上的等待，所以檢視時，應該綜合這三個事件來看待問題。

l  如果將disk_asynch_io 設為false，則有可能在例項中看不到此等待，但只是看不到而已，還是會受到影響的。

6.        Log file parallel write 等待事件：

l  該事件只屬於LGWR 程式，LGWR 寫日誌的時機有：每隔3s、提交會回滾一個事務、滿足_log_io_size 值、log buffer 中有1M 的重做項時。

l  即使使用者沒有經歷log file parallel write 事件，但是也有可能受到影響，緩慢的LGWR 可能導致log file sync 事件的出現，導致使用者提交或回滾被掛起，直到LGWR 寫入完成，在檢視時，也需要綜合這兩個事件來看。

l  如果該事件的平均等待時間大於1cs （10ms ），則說明I/O 吞吐量緩慢。

l  使用nologging 方式建立的物件時不可恢復的，除非在破壞之前有備份，在nologging 時省下的I/O 將會花在備份上，以force logging 方式工作的資料庫會記錄所有的改變，忽略表空間和物件的設定。

7.        Control file parallel write 等待事件：

l  該事件通常是高日誌切換的症狀，正常情況下是CKPT 在此事件上有較高的等待，但是如果LGWR 在此事件上有較高等待，那麼就有可能是日誌切換太頻繁了。

l  如果是前臺程式在此事件上有較高的等待，那麼就有可能是nologging 操作的物件，nologging 操作改變資料庫時，必須在RMAN 中留下不可恢復的scn 。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24465008/viewspace-688060/，如需轉載，請註明出處，否則將追究法律責任。