db file sequential read等待事件
原創 2017-07-22 Oracle 宅必備
開始講解awr報告Top 5 Timed Events部分
今天講db file sequential read 等待事件
db file sequential read
實體讀發生在一個使用者需要的資料塊不在SGA，進而将其從磁盤讀取到SGA中
如果此時别的會話需要該資料塊則必須等待這個過程結束，這時就産生了等待
順序讀是實體讀的一種方式,這裡的順序指的是讀取資料塊到一個連續的記憶體區域，而且總是讀取單個資料塊(single-block read)
如何該等待嚴重說明資料塊存在嚴重的争用情況
這點不同于scattered read，這個将在下節講述
何時會發生
單個資料塊讀(single-block read)是由SQL語句引起的(使用者發出或者遞歸調用)
一般發生在以下情況:
索引掃描
表掃描(access by rowid)
全表掃描(很少發生，例如剛好在extent邊緣恰巧被分割成單塊，或者已經在buffer cache中)
如何處理
由于實體讀是非常正常的，出現這個等待事件不意味着資料庫出現性能問題
但是如果我們在TOP 5 Wait Event中看到其處于非常前的位置(第二甚至第一)時就需要引起我們的注意了
特别需要關注Avg Waits 參數，最好小于10ms，這裡可采用如下方法進行解決
将資料檔案放在高速磁盤中，提高讀取性能，避免熱塊
将資料檔案放在LUN(即一些儲存設備)中，可確定資料塊分散在足夠多的磁盤中
在優化磁盤的同時，我們還需要注意應用程式的SQL語句問題，因為一般這種等待都是由SQL語句造成的，我們需要找出找出相應的SQL語句.
可能是索引使用不當導緻，這時我們可以定位到具體的表或索引，通過執行計劃判斷索引是否合理，是否需要走全表掃描等等方式來進行優化
如下是一些常用的診斷方式，通過如下方式定位到具體的會話，在通過sql_id或hash_value找出具體的語句用于優化
1.檢視目前正在等待的會話
我們可以檢視v$session_wait 視圖的TIME_WAITED欄位來定位目前哪個會話等待 sequential read過長時間(實時)
select * from v$session_Wait where event = 'db file sequential read'
P1代表File ID，可通過dba_data_File視圖的FILE_ID字段看出是哪個資料檔案
P2代表 First block，即該塊在資料檔案上開始的位置
P3代表塊數，由于sequential read為單塊讀，則該值始終為1
我們可以通過P1 P2參數得出對象的名稱和類型
select
segment_name,
segment_type
from
dba_extents
where
file_id = 128
and
3277531 between
(block_id and block_id + blocks - 1);
2. 檢視從執行個體啟動以來等待的會話
使用 v$session_event視圖來定位哪個會話等待 sequential read過長時間(非實時)
也可使用v$system_event視圖檢視系統整體的等待事件
SELECT sid, total_waits, time_waited
FROM v$session_event
WHERE event='db file sequential read'
and total_waits>0
ORDER BY 3 desc ,2
注意由于SID是可以複用的，這樣查出來的有可能有問題
比如檢視SID為617的會話對應的語句也有可能是上個SQL語句導緻的sequential read等待，這點需要注意
檢視高實體讀的資料檔案
我們可以通過awr報告中的 Tablespace IO Stats 和File IO Stats 區域來定位最多IO操作的表空間和資料檔案，如果可以請将其放置在高速的磁盤中(SSD)
檢視高實體讀的SQL語句
同樣可以檢視v$sql中高實體讀的語句以及awr SQL ordered by Reads區域
參考資料