可能的原因（導(dǎo)致該等待成為瓶頸）：

1. 存儲(chǔ) I/O 性能不足 (最常見)：
   • 高 I/O 延遲： 磁盤響應(yīng)時(shí)間過長（特別是機(jī)械磁盤的尋道和旋轉(zhuǎn)延遲）。SSD 延遲低，但如果隊(duì)列深度不足或過載，延遲也會(huì)上升。
   • I/O 吞吐量瓶頸： 存儲(chǔ)帶寬（MB/s）或 IOPS（每秒 I/O 操作數(shù)）達(dá)到上限。
   • 存儲(chǔ)控制器/網(wǎng)絡(luò)/HBA 卡瓶頸： 存儲(chǔ)陣列控制器、SAN 交換機(jī)、主機(jī) HBA 卡過載或配置不當(dāng)。
   • 存儲(chǔ)爭(zhēng)用： 同一存儲(chǔ)上運(yùn)行的其他數(shù)據(jù)庫或應(yīng)用消耗了大量 I/O 資源。
2. 操作系統(tǒng) I/O 子系統(tǒng)配置問題：
   • 文件系統(tǒng)緩存或 I/O 調(diào)度器（如 cfq, deadline, noop）配置不當(dāng)。
   • OS 級(jí)別的 I/O 隊(duì)列深度 (max_sectors_kb, nr_requests, queue_depth) 設(shè)置過低，限制了并行處理能力。
   • 異步 I/O (AIO) 未啟用或配置不當(dāng)（Oracle 推薦使用 AIO 來優(yōu)化并行讀）。
3. 數(shù)據(jù)庫配置不當(dāng)：
   • db_file_multiblock_read_count 設(shè)置過高： 這個(gè)參數(shù)控制單次 I/O 請(qǐng)求讀取的最大連續(xù)塊數(shù)。如果設(shè)置得非常高（遠(yuǎn)大于存儲(chǔ)系統(tǒng)能高效處理的單次 I/O 大?。?dāng) Oracle 進(jìn)行離散讀取 (parallel read) 時(shí)，它可能會(huì)嘗試提交非常大的離散 I/O 請(qǐng)求列表，超過存儲(chǔ)的最佳處理能力，反而導(dǎo)致延遲增加。需要根據(jù)存儲(chǔ)特性（如 SSD 條帶大小、RAID 配置）進(jìn)行合理設(shè)置。
   • I/O 分布不均衡： 熱點(diǎn)數(shù)據(jù)文件位于慢速磁盤或 I/O 繁忙的存儲(chǔ)路徑上。未使用 ASM 或文件系統(tǒng)條帶化，導(dǎo)致單個(gè)文件成為瓶頸。
   • filesystemio_options 設(shè)置不當(dāng)： 未啟用 SETALL 或 ASYNCH，限制了 Oracle 使用異步和直接 I/O 的能力。
4. 數(shù)據(jù)庫負(fù)載/設(shè)計(jì)問題：
   • 低效 SQL： 產(chǎn)生大量物理 I/O 的 SQL（全表掃描大表、低效索引使用、笛卡爾積等）是根源。它們觸發(fā)了大量的 db file parallel read 請(qǐng)求。
   • 索引碎片化： 導(dǎo)致 IFFS 需要讀取大量離散的索引塊。
   • 表碎片化/高水位線問題： 導(dǎo)致 FTS 需要讀取大量離散的表塊。
   • 頻繁訪問 ASSM 位圖塊： 在 DML 繁忙的系統(tǒng)上，對(duì) ASSM 位圖塊的爭(zhēng)用可能導(dǎo)致對(duì)這些塊的讀取成為瓶頸（這些讀取常是 parallel read)。
   • 檢查點(diǎn)過慢： 雖然主要等待是 db file parallel write，但檢查點(diǎn)期間也需要讀取文件頭等信息，可能涉及 parallel read。
5. 主機(jī)資源瓶頸 (間接)：
   • CPU 過載導(dǎo)致處理 I/O 中斷和 Oracle 進(jìn)程喚醒延遲。
   • 內(nèi)存不足導(dǎo)致 Buffer Cache 命中率低，增加物理 I/O 需求。

詳細(xì)排查過程：

排查的核心思路是：定位引發(fā)大量 db file parallel read 的 SQL 和對(duì)象，分析 I/O 性能，確定是 SQL/設(shè)計(jì)問題還是存儲(chǔ)/配置問題。

1. 確認(rèn)問題存在：

   • AWR/ASH 報(bào)告： 這是最重要的起點(diǎn)。查看 Top 5 Timed Foreground Events 或 Top Wait Events 部分，確認(rèn) db file parallel read 是否在 Top 事件中，并且其 Total Wait Time (s) 和 Avg Wait (ms) 是否顯著高于正常水平。注意 % DB time。
   • 實(shí)時(shí)監(jiān)控： 使用 v$session_wait (當(dāng)前等待) 或 v$active_session_history (近歷史) / DBA_HIST_ACTIVE_SESS_HISTORY (歷史 ASH) 查看當(dāng)前或歷史會(huì)話是否正在經(jīng)歷或經(jīng)歷過長時(shí)間的 db file parallel read 等待。

     -- 當(dāng)前等待的會(huì)話
     SELECT sid, serial#, event, p1, p2, p3, seconds_in_wait, state
     FROM v$session
     WHERE event = 'db file parallel read';
     
     -- 最近15分鐘內(nèi)經(jīng)歷該等待的會(huì)話 (ASH)
     SELECT sample_time, session_id, session_serial#, sql_id, event, wait_time_micro, current_obj#
     FROM v$active_session_history
     WHERE event = 'db file parallel read'
     AND sample_time > SYSDATE - 15/1440; -- 15分鐘
     

2. 定位引發(fā)等待的 SQL：

   • ASH 報(bào)告： SQL Statistics -> SQLs with Top DB Time / SQLs with Top Event Waits。查找在 db file parallel read 上消耗時(shí)間最多的 SQL_ID。
   • AWR 報(bào)告： SQL Statistics -> SQL ordered by Elapsed Time / SQL ordered by User I/O Wait Time。結(jié)合 Elapsed Time 和 User I/O Wait Time 高的 SQL。
   • 從會(huì)話定位 SQL： 使用步驟 1 中查詢到的 SID 和 SERIAL# 或 SQL_ID：

     -- 當(dāng)前 SQL
     SELECT sql_id, sql_child_number, sql_exec_id, prev_sql_id
     FROM v$session
     WHERE sid = &sid AND serial# = &serial#;
     
     -- 獲取 SQL 文本
     SELECT sql_fulltext FROM v$sql WHERE sql_id = '&sql_id';
     

3. 分析 SQL 執(zhí)行計(jì)劃：

   • 使用 DBMS_XPLAN (SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&sql_id', &child_number));) 或 AWR 報(bào)告中的執(zhí)行計(jì)劃。
   • 重點(diǎn)關(guān)注：
     • 是否存在 全表掃描 (TABLE ACCESS FULL)？掃描的對(duì)象是什么？有多大？
     • 是否存在 索引快速全掃描 (INDEX FAST FULL SCAN)？掃描的是哪個(gè)索引？
     • 是否存在 多個(gè)索引訪問 (INDEX RANGE SCAN, INDEX UNIQUE SCAN) 然后進(jìn)行 JOIN 或 CONCATENATION？
     • 檢查估算的 E-Rows (Estimated Rows) 和實(shí)際的 A-Rows (Actual Rows - 如果收集了執(zhí)行統(tǒng)計(jì)) 是否偏差巨大？偏差大可能導(dǎo)致選擇了低效的計(jì)劃。
     • 檢查 Buffers / Reads 列，了解邏輯讀和物理讀的總量。

4. 定位引發(fā)等待的數(shù)據(jù)庫對(duì)象：

   • 使用 ASH 查詢結(jié)果中的 CURRENT_OBJ# 或 P1/P2 值（結(jié)合 v$session_wait 的 P1=files count, P2=blocks count，但通常不如 ASH 直接）。
   • 更常用的是結(jié)合找到的 SQL 和執(zhí)行計(jì)劃，直接確定被全表掃描或索引快速全掃描的表或索引。
   • 查詢具體對(duì)象：

     SELECT owner, object_name, object_type, subobject_name
     FROM dba_objects
     WHERE object_id = &current_obj#; -- 來自 ASH
     

5. 檢查 I/O 性能：

   • 數(shù)據(jù)庫層面：
     • AWR/ASH 報(bào)告： IOStat by Function/Filetype / IOStat by File / Tablespace IO Stats。查看：
       • Av Rd (ms) / Avg Wait Time (ms)： 單塊讀取平均等待時(shí)間（db file sequential read）和 db file parallel read 的平均等待時(shí)間。理想情況下（特別是 SSD），應(yīng)該 < 10ms，最好 < 5ms。機(jī)械盤可能 10-20ms 算正常，超過 20ms 通常表示 I/O 慢。
       • Read Total (MB) / Reads： 總的物理讀量和 I/O 次數(shù)。
       • Read IOPS： 每秒物理讀次數(shù)。
       • % of Total Read I/O： 哪些文件/表空間是熱點(diǎn)。
     • 動(dòng)態(tài)性能視圖：

       -- 文件級(jí) I/O 統(tǒng)計(jì) (自實(shí)例啟動(dòng))
       SELECT file_id, file_name,
              phyrds "Physical Reads",
              phyblkrd "Physical Blocks Read",
              readtim "Read Time (cs)", -- 厘秒
              ROUND(readtim / DECODE(phyrds, 0, 1, phyrds), 3) "Avg Read Time (ms)"
       FROM v$filestat fs
       JOIN dba_data_files df ON fs.file# = df.file_id
       ORDER BY readtim DESC;
       
       -- 系統(tǒng)級(jí) I/O 統(tǒng)計(jì)
       SELECT stat_name, value
       FROM v$sysstat
       WHERE stat_name LIKE '%physical read%'
          OR stat_name LIKE '%read IO requests%';
       

   • 操作系統(tǒng)層面：
     • 使用 OS 工具監(jiān)控磁盤性能：
       • Linux: iostat -dxm 5 (看 await, svctm, %util, r/s, rkB/s), vmstat 1, dstat, sar -d
       • AIX: iostat -DRl 1, vmstat 1, filemon
       • Solaris: iostat -xnz 5, vmstat 1, dtrace
     • 關(guān)鍵指標(biāo)：
       • 服務(wù)時(shí)間 (svctm, service time): 磁盤處理一個(gè) I/O 請(qǐng)求的時(shí)間。SSD 應(yīng) < 1ms，機(jī)械盤 < 20ms。
       • 等待時(shí)間 (await): I/O 請(qǐng)求在 OS 隊(duì)列中等待時(shí)間 + 服務(wù)時(shí)間。高 await 通常表示磁盤飽和或慢。await 應(yīng)接近 svctm，遠(yuǎn)高于 svctm 說明隊(duì)列長。
       • 利用率 (%util): 磁盤繁忙程度百分比。持續(xù) > 70-80% 通常表示飽和。SSD 可以處理接近 100%，但延遲可能升高。
       • IOPS (r/s): 每秒讀操作數(shù)。與存儲(chǔ)規(guī)格對(duì)比。
       • 吞吐量 (rkB/s): 每秒讀數(shù)據(jù)量 (KB/s)。與存儲(chǔ)帶寬對(duì)比。
       • 隊(duì)列長度 (avgqu-sz): 平均隊(duì)列長度。持續(xù) > 2-3 可能表示飽和。
   • 存儲(chǔ)陣列層面： 使用存儲(chǔ)廠商的管理工具監(jiān)控 LUN/Volume 的性能：延遲、IOPS、吞吐量、緩存命中率、前端/后端端口狀態(tài)等。

6. 檢查數(shù)據(jù)庫配置：

   -- 重要 I/O 相關(guān)參數(shù)
   SHOW PARAMETER db_file_multiblock_read_count
   SHOW PARAMETER filesystemio_options
   SHOW PARAMETER disk_asynch_io -- (通常 TRUE, 表示嘗試使用 AIO)
   -- 檢查數(shù)據(jù)文件分布 (是否都放在同一慢速盤上?)
   SELECT tablespace_name, file_name FROM dba_data_files;
   -- 檢查表/索引碎片 (可能需要定期分析)
   EXEC DBMS_STATS.GATHER_TABLE_STATS('OWNER', 'TABLE_NAME');
   -- 檢查 ASSM 段位圖塊訪問 (v$segstat 或 AWR 的段統(tǒng)計(jì))
   

7. 區(qū)分問題根源：

   • 如果 Avg Wait (ms) 很高 (e.g., > 20ms) 且 OS/存儲(chǔ)監(jiān)控也顯示高延遲： 問題很可能是存儲(chǔ) I/O 性能不足或配置不當(dāng)（OS I/O 參數(shù)、db_file_multiblock_read_count 過大）。需要優(yōu)化存儲(chǔ)或調(diào)整配置。
   • 如果 Avg Wait (ms) 在可接受范圍 (e.g., < 10ms)，但等待事件的 Total Wait Time (s) 很高： 問題根源是應(yīng)用產(chǎn)生了過多的物理 I/O 請(qǐng)求（低效 SQL、缺乏索引、全掃大表）。需要優(yōu)化 SQL 和數(shù)據(jù)庫設(shè)計(jì)。
   • 如果 db file parallel read 的等待次數(shù) (Waits) 和等待時(shí)間 (Total Wait Time) 很高，但 Avg Wait (ms) 很低： 表明雖然每次并行讀很快，但數(shù)據(jù)庫不得不發(fā)起極其大量的并行讀操作。這通常指向極其低效的 SQL 或嚴(yán)重碎片化的對(duì)象，導(dǎo)致 Oracle 需要讀取海量離散塊。

優(yōu)化建議：

1. 優(yōu)化 SQL (最根本)：
   • 重寫低效 SQL，避免不必要的全表掃描。
   • 添加合適的索引，讓查詢能走索引范圍掃描或唯一掃描。
   • 優(yōu)化連接條件和連接順序。
   • 考慮使用物化視圖或查詢重寫。
   • 確保統(tǒng)計(jì)信息準(zhǔn)確。
2. 優(yōu)化數(shù)據(jù)庫設(shè)計(jì)：
   • 對(duì)大表進(jìn)行分區(qū)（Partitioning），減少每次需要掃描的數(shù)據(jù)量。
   • 定期重組碎片化的表和索引 (ALTER TABLE ... MOVE, ALTER INDEX ... REBUILD)，特別是頻繁 DML 的表?？紤]使用 SHRINK SPACE。
   • 評(píng)估使用 IOT（索引組織表）或聚簇表是否合適。
   • 考慮對(duì)大表啟用表壓縮。
   • 調(diào)整 PCTFREE/PCTUSED 以減少行遷移和碎片。
3. 優(yōu)化存儲(chǔ)配置：
   • 升級(jí)硬件： 使用更快的存儲(chǔ)介質(zhì)（如 SSD/NVMe）。
   • 優(yōu)化存儲(chǔ)配置： 確保 RAID 級(jí)別合適（如 RAID 10 for performance），條帶化（striping）配置得當(dāng)，LUN 分布均勻，避免熱點(diǎn)。
   • 使用 ASM： Oracle ASM 能自動(dòng)進(jìn)行條帶化和負(fù)載均衡，通常比傳統(tǒng)文件系統(tǒng)管理更優(yōu)。
   • 增加存儲(chǔ)帶寬： 更多/更快的 HBA 卡，升級(jí) SAN 交換機(jī)/鏈路。
   • 調(diào)整存儲(chǔ)緩存策略： 確保讀緩存策略有效（但需注意寫緩存的安全性）。
4. 優(yōu)化 OS 配置：
   • 確保啟用了異步 I/O (AIO) 并且工作正常（filesystemio_options=SETALL 或 ASYNCH）。
   • 調(diào)整 OS I/O 調(diào)度器（如 Linux 用 deadline 或 noop for SSD）和隊(duì)列深度參數(shù) (queue_depth, nr_requests)。
   • 確保文件系統(tǒng)（如果使用）合理對(duì)齊（partition alignment）。
5. 優(yōu)化數(shù)據(jù)庫配置：
   • 謹(jǐn)慎調(diào)整 db_file_multiblock_read_count： 不要盲目設(shè)大。參考存儲(chǔ)的最佳 I/O 大小（如 SSD 的條帶大小/RAID 條帶大?。┻M(jìn)行設(shè)置。通常 128 是一個(gè)較高的上限，很多場(chǎng)景下 32 或 64 可能更優(yōu)。測(cè)試是關(guān)鍵。ALTER SYSTEM SET db_file_multiblock_read_count=64 SCOPE=SPFILE/BOTH;
   • 增加 Buffer Cache (db_cache_size)： 減少物理 I/O 需求（但治標(biāo)不治本，仍需優(yōu)化 SQL）。
   • 使用多DBWR進(jìn)程： 如果寫是瓶頸（間接影響讀），可以增加 db_writer_processes。
   • 優(yōu)化檢查點(diǎn)： 調(diào)整 fast_start_mttr_target 或相關(guān)隱含參數(shù)（需謹(jǐn)慎），避免過于頻繁或過長的檢查點(diǎn)。
   • 分散 I/O： 將熱點(diǎn)數(shù)據(jù)文件移動(dòng)到不同的物理磁盤或存儲(chǔ)控制器上。

總結(jié)：

db file parallel read 是 Oracle 優(yōu)化離散塊讀取性能的一種機(jī)制。它本身不是錯(cuò)誤，而是數(shù)據(jù)庫工作的體現(xiàn)。當(dāng)它成為系統(tǒng)的主要瓶頸等待事件時(shí)，表示系統(tǒng)在執(zhí)行大量離散物理讀操作，并且/或者這些操作的延遲較高。

排查的核心是：

1. 找到源頭 SQL 和對(duì)象。
2. 分析 I/O 性能（數(shù)據(jù)庫報(bào)告 + OS/存儲(chǔ)監(jiān)控），確定延遲是否正常。
3. 區(qū)分是“讀得太慢”（存儲(chǔ)問題/配置問題）還是“讀得太多”（SQL/設(shè)計(jì)問題）。

根據(jù)分析結(jié)果，采取針對(duì)性的優(yōu)化措施，優(yōu)先優(yōu)化 SQL 和數(shù)據(jù)庫設(shè)計(jì)，其次是存儲(chǔ)和配置調(diào)整。

到此這篇關(guān)于Oracle數(shù)據(jù)庫面試寶典之db file parallel read等待事件處理過程的文章就介紹到這了,更多相關(guān)Oracle db file parallel read等待事件處理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！