ORACLE 常見等待事件

Davis_itpub發表於2018-06-27
Oracle事件
1、db file sequential read
將資料讀到連續的記憶體,等待時間是由於執行對索引，回滾（undo）段，和表（當藉助rowid來訪問），控制檔案和資料檔案頭的單塊讀操作SQL語句（使用者和遞迴）引起的。
db file sequential read的最佳化方法：
從讀取開始，增加SGA中buffer cache的大小，避免每次都從硬碟中去讀數；
最佳化sql語句，減少不必要的塊讀取；
db file scattered read  
db file scattered read發出離散讀，將儲存上連續的資料塊離散的讀入到多個不連續的記憶體位置。這個事件表明使用者程式正在讀資料到Buffer Cache中，等待直到I/O呼叫返回引起的等待。
2、direct path read/write （直接路徑讀／寫）：
直接路徑讀（direct path read）通常發生在Oracle直接讀資料到程式PGA時，這個讀取不需要經過SGA。
DB file Sequential ReadDB file Scattered ReadDirect Path Read
這類讀取通常在以下情況被使用：
1.磁碟排序IO操作；
2.並行查詢從屬程式；
3.預讀操作。
直接路徑寫（direct path write）通常發生在Oracle直接從PGA寫資料到資料檔案或臨時檔案，這個寫操作可以繞過SGA。
這類寫入操作通常在以下情況被使用：
1.直接路徑載入；
2.並行DML操作；
3.磁碟排序；
最佳化方法：1.增加pga_aggregate_target  2.並行查詢導致效能問題，修改並行度
3、Buffer busy waits  ---hot block
這個等待事件的產生僅說明了一個會話在等待一個Buffer（資料塊）， 當多個使用者頻繁地讀取或者修改同樣的資料塊時，這個等待事件就會產生。如果等待的時間很長，我們在AWR或者statspack報告中就可以看到。
這個等待事件有三個引數。檢視有幾個引數我們可以用以下SQL:
SQL> select name,parameter1,parameter2,parameter3,wait_class 
        from v$event_name 
        where name='direct path write';
P1 P2 P3別代表檔案號、起始資料塊號、資料塊的數量
解決hot block的方法有：
1、出現此情況通常可能透過幾種方式調整：增大data  buffer；
2、增加freelist，減小pctused；怎樣的目的是將一個block上可以使用的空間減少，這樣的話：一個block上的資料存放的較少，可以提高應用的訪問併發率，減少hot block的產生；
3、增加回滾段數目，增大initrans，考慮使用LMT, 確認是不是由於熱點塊造成(如果是可以用反轉索引,或者用更小塊大小)；
3、可以建立block較小的表空間，見熱點物件移動到此表空間上去；
4、最佳化應用，最佳化索引，提高索引的命中率；
◎ Oracle會話正在等待釘住一個緩衝區。必須在讀取或修改緩衝區前將它釘住。在任何時刻只有一個程式可以釘住一個緩衝區。
◎ buffer busy waits表明讀/讀、讀/寫、寫/寫爭用。
◎ 採取的適當措施取決於P3引數中的原因碼。
   
A、如果等待處於欄位頭部，應增加自由列表（freelist）的組數，或者增加pctused到pctfree之間的距離。
B、如果等待處於回退段（undo）頭部塊，可以透過增加回滾段(rollback segment)來解決緩衝區的問題；
C、如果等待處於回退段（undo）非頭部塊上，就需要降低驅動一致讀取的表中的資料密度,或者增大DB_CACHE_SIZE；
D、如果等待處於資料塊，可以將資料移到另一資料塊以避開這個"熱"資料塊、增加表中的自由列表或使用LMT表空間；
E、如果等待處於索引塊，應該重建索引、分割索引或使用反向鍵索引。
4、log file sync
等待時間發生在redo log從log buffer寫入到log file期間。
此等待事件使用者發出提交或回滾宣告後,等待提交完成的事件,提交命令會去做日誌同步,也就是寫日誌快取到日誌檔案， 在提交命令未完成前,使用者將會看見此等待事件.
解決辦法：
當發生log file sync等待後,判斷是否由於緩慢的日誌I/O造成的,可以檢視兩個等待事件的等待時間,如果比較接近,就證明 日誌I/O比較緩慢或重做日誌過多,這時,造成log file sync的原因是因為log file parallel write。
如果log file sync的等待時間很高,而log file parallel write的等待時間並不高,這意味著log file sync的原因並不是緩慢的日誌I/O,而是 使用者過多的提交造成。
  當log file sync的等待時間和 log file parallel write等待時間基本相同，說明是IO問題造成的log file sync等待事件。
5、Log File Switch等待事件  
這個等待出現時，表示所有的提交(commit)的請求都需要等待"日誌檔案切換"的完成。
Log file Switch 主要包含兩個子事件:
log file switch (archiving needed)
log file switch (checkpoint incomplete)
其中log file switch (archiving needed)
這個等待事件出現時通常是因為日誌組迴圈寫滿以後，第一個日誌歸檔尚未完成，出現該等待。出現該等待，可能表示io 存在問題。解決辦法:
可以考慮增大日誌檔案和增加日誌組
移動歸檔檔案到快速磁碟
調整log_archive_max_processes
而log file switch (checkpoint incomplete)-日誌切換(檢查點未完成)
當你的日誌組都寫滿以後，LGWR 試圖寫第一個log file，如果這時資料庫沒有完成寫出記錄在第一個log file 中的dirty 塊時(例如第一個檢查點未完成)，該等待事件出現。
該等待事件通常表示你的DBWR 寫出速度太慢或者IO 存在問題。
為解決該問題，你可能需要考慮增加額外的DBWR 或者增加你的日誌組或日誌檔案大小。
6、log buffer space
日誌緩衝(log buffer)產生重做日誌的速度比LGWR 的寫出速度快，或者是當日志切換(log switch)太慢時，就會發生這種等待。這個等待出現時，通常表明redo log buffer 過小，為解決這個問題，可以考慮增大日誌檔案的大小，或者增加日誌緩衝器的大小。
    另外一個可能的原因是磁碟I/O 存在瓶頸，可以考慮使用寫入速度更快的磁碟。在允許的條件下設定可以考慮使用裸裝置來存放日誌檔案，提高寫入效率。在一般的系統中，最低的標準是，不要把日誌檔案和資料檔案存放在一起，因為通常日誌檔案只寫不讀，分離存放可以獲得效能提升。


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

相關文章