【等待事件】db file sequential read

等待事件db file sequential read

等待事件說明

這個等待事件表示對一個IO 讀請求完成的等待。這個呼叫不同於 "db file scattered read" ，順序讀將資料讀取到連續記憶體中，而分散讀將讀取多個資料塊，並將他們分散到 SGA 中的不同緩衝區中。順序讀通常是單塊讀，有時候也可以看到多個塊的順序讀。

這個IO 是一個正常的活動，所以我們需要注意的是不必要或緩慢的 IO 活動。如果等待 IO 的時間很長，那麼我們可以確定 Oracle 需要訪問磁碟的那個段的速率。具體需要參考 AWR 報告中的“ Tablespace IO ”和“ File IO ”，以及 ADDR 和 ASH 的輸出，以獲得哪些表空間 / 檔案正在服務最多的 IO 請求的資訊，並獲得 IO 子系統的速度指示。如果等待讀的時間很長，那麼需要判斷 Oracle 正在哪個段上執行讀操作。發生讀操作的檔案可以透過檢視 v$filestat 找到。還需要參考 AWR 中“ SQL ordered by Reads ”，瞭解 SQL 導致高 IO 的線索。還可以檢視哪些會話正在執行讀操作，並跟蹤它們以檢視是否需要 IO 。這個語句可以用來檢視哪些會話需要跟蹤

SQL> SELECT sid, total_waits, time_waited

FROM v$session_event

WHERE event='db file sequential read'

and total_waits>0

ORDER BY 3,2;  

解決方法

資料塊的讀取是不可避免的，所以我們的目標應該是最小化不必要的IO 。這個可以透過改良應用程式和執行計劃來實現。對執行計劃的更改可能會導致效能的顯著變化。系統級別的調整隻能獲得百分比的增益，可以參考以下幾點：

- 檢查 SQL ，使用非選擇性 index scan

- 可以增大 buffer cache ，透過實際增加引數“ DB_CACHE_SIZE ”，不要增加 SGA 的大小，這可能會導致系統出現額外的分頁和交換

- 影響 IO 速率的一個不太明顯的問題，就是在資料塊存放的好壞程度。假設你經常透過索引掃描一個表，這個表要掃描的列在兩個值之間。如果每個索引塊中有 100 行，那麼兩個極端就是：

1）  每個錶行位於不同的物理塊中（每個索引塊需要讀取100 個塊）

2）  表中的所有行都在幾個相鄰的資料塊中（每個索引塊需要讀取幾個塊）

這種情況下，預先排序或重新組織資料可以幫助在嚴重的情況下解決這個問題。

- 看看是否可以使用分割槽來減少需要檢視的資料量

- 對於非基於 ASM 的資料庫，將這些資料檔案放在帶有 O/S 檔案系統快取的檔案系統上，這可以讓一些 Oracle 讀請求從快取讀（邏輯 IO ）而不是從真正的磁碟 IO 讀（物理 IO ）。

 

 

---- end ----