這個等待事件在實際生產庫中經常可以看到，這是一個使用者操作引起的等待事件，當SESSION等待multi-block I/O完成時，會產生這個等待事件。

這通常發生在兩種情況下：全表掃描（FTS： Full Table Scan）和索引快速掃描（IFFS： index fast full scan）。

Oracle每次讀取一個連續塊的DB_FILE_MULTIBLOCK_READ_COUNT，並將它們分散到緩衝區快取中。如何做到這一點取決於平臺和您正在執行的Oracle的釋出。它也可能根據所讀取的裝置型別和請求的塊的數量而變化。

這個等待事件有三個引數：

select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'db file scattered read';
    EVENT# NAME                          PARAMETER1     PARAMETER2      PARAMETER3
---------- ----------------------------- -------------- --------------- ---------------
       154 db file scattered read        file#          block#          blocks

• File#： 要讀取的資料塊所在資料檔案的檔案號。

• Block#： 要讀取的起始資料塊號。

• Blocks：需要讀取的資料塊數目。

一、等待——定位

1. 會話資訊
   檢視哪些會話正在執行掃描，並跟蹤它們以檢視掃描是否被期望是很有用的。
   

   SELECT sid, total_waits, time_waited
     FROM v$session_event
   WHERE event='db file scattered read'
     AND total_waits>0
   ORDER BY 3,2;

   也在V$SESSTAT中查詢具有高“table scans blocks gotten”的會話
   當這個等待事件比較顯著時，可以結合v$session_longops 動態效能檢視來進行診斷，該檢視中記錄了長時間(執行時間超過6 秒的)執行的事物。

2. 表空間 & 資料檔案

   可以檢視AWR(或STATSPACK)報告的“Tablespace IO”和“File IO”部分，以及ADDM和ASH輸出。這些檔案應該顯示哪些tablespaces / files正在為大多數I/O請求提供服務，並顯示I/O子系統的速度。在“db file scattered read”中所涉及的 tablespaces/files 將有 "Av Blks/Rd" > 1。
   讀取檔案的檔案也可以透過檢視V$FILESTAT中BLKS_READ / READS > 1找到（大於1的比率指示出現了多個塊讀取）。

3. segments & objects
   檢視哪些 segments/objects 物件執行讀操作。

4. select event,p1,p2,p3,row_wait_obj# from gv$session where event = 'db file scattered read';
   select object_name,object_type from dba_objects where object_id=row_wait_obj#;

5. SQL
   可以檢視AWR報告的“Top SQL by Disk Reads”部分，以獲得任何導致高I/O的SQL的線索。如果啟用了統計資訊收集，那麼V$SQL_PLAN還可以使用完整掃描提供有關SQL語句的線索。
   V$SQL中高DISK_READS語句——在awr的“Top SQL by Disk Reads”部分中顯示。
   如果一個資料庫的大表掃描過多，那麼db file scattered read等待事件可能同樣非常顯著。如果table scans (long tables)的per Trans值大於0，你可能需要增加適當的索引來最佳化你的SQL語句

二、等待——降低

“db file scattered read”的一些具體點包括：

• 對SQL進行調優通常會獲得最大的收益。

• 考慮分割槽以減少需要掃描的資料量。

• 受影響的物件是否被稀疏地填充?如果是這樣，考慮縮減他們。

• 考慮高階壓縮，以減少需要訪問的塊的數量。

• 小心使用多個緩衝池和快取選項可能會有幫助。