実行計画とバインドピーク

どーなんOracle。。。と言いたい内容。
というよりも使い方を理解していないから発生する問題なのか。
一度動作したSQLの修正は検討の余地ありだな。

■SELECT文の実行Step
（１）構文のチェック
（２）表、列の定義チェック
（３）アクセスするオブジェクトへの権限チェック
（４）実行計画の生成
（５）共有プール上に実行計画を含め解析結果をキャッシュ

共有プールには実行計画がキャッシュされるので、
SQL実行時に以下の２パターンで実行処理が行われる。

HARD PARSE：共有プールに解析済みの同一のSQL文が存在しない場合に実行される解析処理
SOFT PARSE：共有プールにすでに解析済みの同一のSQL文が存在した場合に、それを再実行する処理

もちろんHARD PARSEの方がパフォーマンスに影響を与える。

■実行計画
DML文(SELECT,UPDATE,DELETEなど)を実行するためのステップ(索引/行の読み込み、ソート、変換などの様々な動作)が含まれる組み合わせ。
以下の２つのアプローチが存在する。
CBO：コストベース・アプローチ
RBO：ルールベース・アプローチ

■統計情報
統計情報とは、表、索引などのレコード件数や、使用している領域、カーディナリティ、データ分布 などのデータ特性を表す情報。

■バインドピーク
HardParse時にバインド変数にセットされていた値を考慮して実行計画を決定する機能
（Oracle9i以降）

■URL
Oracle SQLチューニング講座（6）　パフォーマンスを向上させるSQLの記述法
http://www.atmarkit.co.jp/fdb/rensai/orasql06/orasql06_1.html

Oracle SQLチューニング講座（3）　SQLチューニングの必須知識を総ざらい（後編）
http://www.atmarkit.co.jp/fdb/rensai/orasql03/orasql03_2.html

パフォーマンスチューニング
http://www15.ocn.ne.jp/~tashi/html/oracle/dev_tuning.html