與IO相關的等待事件troubleshooting-系列4

與資料檔案IO相關的等待事件：

接下來的等待事件是與資料檔案的IO操作時產生的。

'db file sequential read'

        這是一種最常見的IO相關的等待。大多數情況下，他指的是單塊讀，例如索引資料塊或通過索引訪問的表資料塊，也能在讀取資料檔案頭塊時看到這種等待事件。在更早的版本中，這種等待事件也會產生於從磁碟的排序段通過多快讀的方式讀入Buffer Cache的連續("sequential")緩衝。

        如果這種等待事件佔據了大部分的等待時間，可以嘗試以下的若干方法：

1. 找到物理讀Top前幾位的SQL語句(從Statspack或AWR報告的“SQL ordered by Reads”節或V$SQL檢視)，進行調優以減少IO請求：

(1) 如果使用了索引範圍掃描(Index Range scans)，且索引選擇性較差，那麼就需要訪問比正常情況更多的塊。通過強制使用選擇性更好的索引，訪問同一張表可以讀取更少的索引塊(花費更少的物理IO)。

(2) 如果碎銀出現碎片化，可能仍舊會訪問更多的塊，因為單塊包含的索引資料更少。

(3) 如果索引的Clustering Factor非常大，需要訪問更多的表資料塊，才能在每個索引塊上得到行資料。通過重建表，根據特定的索引列對行進行排序，能夠降低Clustering Factor，以及每個索引塊需要訪問的表資料塊數量。例如，如果表包含A，B，C和D列，索引是B，D，那麼重建表為：CREATE TABLE new AS SELECT * FROM old ORDER BY b,d;

(3) 使用分割槽以減少每個使用分割槽剪裁的SQL語句需要訪問的索引和表資料塊的數量。

2. 如果沒有特殊的SQL語句使用了較差的執行計劃，但仍舊產生了比正常更多的物理IO，以下情況可能發生：

(1) 特殊的資料檔案IO可能處理非常緩慢，原因可能是磁碟的過度訪問。這種情況下，檢視Statspack的"File I/O Statistics"節(或V$FILESTAT)可以幫我們找到這樣的熱磁碟，通過手工移動這些資料檔案到其它的儲存以分散IO，或者充分利用條帶化，RAID和其它的技術，自動執行IO負載均衡。

(2) 從Oracle 9.2開始，通過使用來自V$SEGMENT_STATISTICS檢視的段統計資訊，我們也能找到哪些段(表或索引)存在最多的物理讀。然後我們能詳細研究下這些段的細節，例如索引是否需要重建或者是否需要使用分割槽來降低IO。Statspack也可以在level 7級別上產生“段統計資訊”的報告。

3. 如果沒有SQL使用較差的執行計劃，IO也平均地分不到所有磁碟，但響應時間仍舊較長，那麼一個大的Buffer Cache緩衝可能有幫助：

        在Oracle 8i，用逐漸增長的DB_BLOCK_BUFFERS做個實驗。

        通過從Statspack中衡量Buffer Cache Hit Ratio，直到沒有任何提高為止。

(1) 在Oracle 9i之前的版本，可以使用Buffer Cache Advisory工具(從Statspack報告中可以得到)來調整Buffer Cache的容量。

(2) Oracle 10g之前的版本，ASMM(Automatic Shared Memory Management)能夠用來讓資料庫根據當前負載，自動判斷Buffer Cache的最佳容量。(可參考：Document 257643.1 Oracle Database 10g Automated SGA Memory Tuning)

(3) 對於熱段，多Buffer Pools的使用可以幫助解決問題，可以將這樣的“熱”索引和表放到KEEP緩衝池。(可參考：Document 76374.1 Multiple Buffer Pools)

4. 最後，還可以考慮降低經常訪問的段中包含的資料量(例如將舊的、不需要的資料移出資料庫)，或將這些段移動到更快的磁碟中，以降低其IO所需要的響應時間。

(未完待續)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7192724/viewspace-773818/，如需轉載，請註明出處，否則將追究法律責任。