Oracleでも断片化が進むと、思っている以上にスループットに影響する

SQL Serverだとテーブルやインデックスの断片化が進むと、オプティマイザに影響し、インデックスが使われなくなったり、SQLがパラレル処理されなくなるなどで、SQLの実行時間が極端に長くなる事象を、以前、実験結果から得ていましたが、Oracleでも同じ事象が発生し得るのか、My Oracle Supportで確認してみました。

結論的には、OracleでもSQL Serverと同じ事象が発生します。

要約すると下記が問題になります。

・Truncateした後に統計情報を更新しないと、DMLを処理するとき、残った不適切な統計情報により、効率的によくない実行計画を生成し性能が落ちる場合がある。
・インデックスを作成していないテーブルでも、結合処理を行う場合は統計情報の影響を受ける。
  例えば統計情報により、Nest Loopを選択するのか、Hash Joinを選択するのかを判断しますので、統計情報が不正の場合は効率がよくない結合処理を選択する可能性がある。
・統計情報が乖離する問題は、Truncateだけではなく、INSERT/UPDATE/DELETEいずれでも、大量に処理した場合は起こり得る。
・デフォルトでは毎晩、自動で統計情報を収集するジョブが実行されるので、統計情報の乖離が原因でSQLの実行計画が良くない選択をするのはまれ。

・テーブルの断片化が進むと索引のクラスタ化係数は大きくなります。実行計画を生成するとき、索引を使うかどうかはクラスタ化係数も考慮しているので、断片化が進むと実行計画に影響する。
・Oracleは自動的に断片化を解消する仕組みはない。
・DML(INSERT/UPDATE/DELETE)を繰り返すと、セグメントレベルの断片化が進行する。
・TRUNCATE TABLEを実行すると、セグメントレベルの断片化は解消するが、表レベルの断片化が起きる。
・セグメントレベルの断片化が進行すると、SQL実行時の実行計画が、インデックスを使用しない、SQLをパラレル実行しない、と選択し始める。
・Delete,Insertによるセグメントの断片化より、TRUNCATEによる表領域の断片化の方がスループットを低下させない。
・特定のテーブルでセグメントの断片化が進行しても、同じ表領域にある他のテーブルには影響しない。
・断片化が進行した場合、インデックスを使わないDMLでもスループットは低下する。

関連するOracleナレッジベースのドキュメントID
1720974.1
1751631.1