共計 3042 個字符，預計需要花費 8 分鐘才能閱讀完成。
這篇文章主要介紹“ORACLE 常見等待事件有哪些”，在日常操作中，相信很多人在 ORACLE 常見等待事件有哪些問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”ORACLE 常見等待事件有哪些”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！
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 存在瓶頸，可以考慮使用寫入速度更快的磁盤。在允許的條件下設置可以考慮使用裸設備來存放日志文件，提高寫入效率。在一般的系統中，最低的標準是，不要把日志文件和數據文件存放在一起，因為通常日志文件只寫不讀，分離存放可以獲得性能提升。
到此，關于“ORACLE 常見等待事件有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！
