High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access

最近某些系統AWR的top 5中“Db File Sequential Read”占據的時間百分比非常大，通常這種等待事件是一種正常的。但目前系統性能是有些問題的，并發量大，有些緩慢，是以需要判斷這種等待事件是否能夠減少。MOS有幾篇關于這種等待事件的介紹，這是其中一篇。

High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access (文檔 ID 875472.1)

即使執行計劃已經是最優的了，但一次查詢仍能夠等待“db file sequential read'”這種事件很長的時間。通常是因為索引掃描的結果集非常大。例如：

在大多數這樣的例子中，執行查詢語句在“TABLE ACCESS BY INDEX ROWID”上的等待要比INDEX SCAN上需要更多的。這是因為随機通路表行的代價要比索引掃描更大。

為此，可以有以下幾種方法調試：

1. 檢查是否有更好的索引或執行計劃。可能需要重新設計索引。

2. 嘗試全表掃描。全表掃描通常比索引掃描要快，盡管CBO成本比索引掃描的成本高。

SELECT /*+ FULL(BIG_TABLE) */  D 

FROM BIG_TABLE 

WHERE A = 1253 

AND B in ('CA', 'CO') 

AND C > 210 ;

3. 如果僅僅有很少的列出現在SELECT和WHERE子句中，可以考慮為查詢建立一個複合索引避免回表。

例如：

<code>CREATE INDEX &lt;INDEX_NAME&gt; ON BIG_TABLE (A, B, C, D);</code>

注意：僅針對SELECT語句有效。如果是UPDATE語句，這種做法可能沒用。

4. 将表移動到更大block塊大小的表空間。更大的block塊會有更多的行，是以對減少block塊IO會有幫助。重新組織表也會有幫助，因為這樣做可以讓索引有一個更小的clustering聚類因子。

5. 可以考慮增加buffer cache的大小，以至于可以緩存更多的塊大小。如果表是頻繁通路的，使用keep buffer池也是一個不錯的選擇。

6. 考慮使用IOT(索引組織表)。IOT可能減少IO，原因就是他會将資料存儲于一個B樹索引結構。例如，如果A列是表BIG_TABLE的主鍵，可以按照如下方法建立IOT：

create table BIG_TABLE (A number primary key, B char(2), C number, D varchar2(10)) organization index;

7. 如果伺服器有足夠的空閑資源(CPU，記憶體)，考慮使用并行執行。這種方式不會減少IO，但是有助于降低執行時間。

8. 較差的磁盤IO也可能是一個原因。可以提高表所在磁盤裝置的IO。這可能需要系統管理者的協助。