性能劣化はなぜ起こる？
「アプリケーションの変更は行なっていないし、データも同じなのに、特定の処理が遅くなってしまった！！ハードウェアの性能は上がっているのになぜ？」
このような状況が発生した時、なぜ性能劣化が起こったかわかりますか？
それは、アップグレードをきっかけに、SQLの実行計画が変わってしまったからです。
実行計画とは、どのように表に対して検索を行うかを書いた、SQLの実行手順書のようなものです。そして、SQLの実行手順書を作成するのが、「オプティマイザ」というOracleデータベースの内部機能です。
このオプティマイザは、データベースのバージョンが上がる度に、よりSQL実行時のデータの状態を考慮した実行計画を作成するように、改良が加えられています。そのため、新しいバージョンのオプティマイザが必要とする情報を、正しく与えられていない場合は、最適ではない実行計画が作成されてしまうことがあります。
性能劣化を起こさない安全なアップグレードを行うためには、オプティマイザが必要とする情報を知ることが重要なポイントになります。
2種類のオプティマイザ
バージョンが上がる度に、改良が行われているオプティマイザですが、特に大きな変化は、使用できるオプティマイザの種類が変わったことです。
Oracle 9i Database以前のバージョンでは、ルールベース・オプティマイザが利用可能でしたが、Oracle Database 10g以降のバージョンでは、コストベース・オプティマイザの利用が必須となりました。
ルールベース・オプティマイザは、表の記述順序や、索引を追加した順番といった、SQL文の構文ルールにのっとって実行計画を決定します。
一方、コストベース・オプティマイザは、SQL文に加え、統計情報と呼ばれる表や索引の件数などの情報を基にコスト（処理量）を見積もって実行計画を決定します。
それでは、2つのオプティマイザの特徴を、路線検索に置き換えて考えてみましょう。
このように、ルールベース・オプティマイザは、あらかじめ決められたルールにのっとって手順を作成します。
そのため、ルールを覚えてしまえば、意図した実行計画を作成しやすいメリットがあります。しかし、データの変動には追随できないので、データ分布やデータ量を考慮してSQL文を作りこむ必要があります。
一方、コストベース・オプティマイザは、データの状態を考慮した実行計画を作成します。
ただし、コストベース・オプティマイザは、一番コストが低いアクセスパス（テーブルにアクセスする方法）を、与えられた情報を元に予測しているのであり、実際に試しているわけではありません。
たとえば上の例で、今週から時刻表が改正され、朝の8時にも飛行機が飛ぶようになっていたとします。その場合も、あくまでも与えられた情報を元に予測を立てるため、実際は飛行機のほうが早く着くのに、新幹線を選んでしまいます。
正しいデータ特性の情報を与えれば、その時のシステムの状態に合わせた柔軟な実行計画を作成できることが、コストベース・オプティマイザの最大のメリットになります。しかし、正しいデータ特性の情報を与えられていない場合は、最適ではない実行計画を、一番コストが低いアクセスパスであると予測してしまいます。
そのため、SQL文を作り込むより、SQL実行時のデータの状態を正しくオプティマイザに伝えることを意識してください。
このように、オプティマイザの種類によって、実行計画を作成するための重要なポイントが異なります。そのため、全く同一のアプリケーションであったとしても、ルールベース・オプティマイザからコストベース・オプティマイザへ移行すると、SQLの実行計画が変わる可能性があるのです。
