オプティマイザの判断ミスを疑ってみよう：Oracleパフォーマンス障害の克服（4）（2/3 ページ）

Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。（編集局）

[高橋潤，＠IT]

問題解決！ オプティマイザの挙動を正確に理解する

サンプル表の作成

　それでは統計情報がどのように実行計画に影響を与えるか、確認していきます。まずリスト5のサンプル表と索引を作成します。以降、オプティマイザのモードは「CHOOSE」であるとします。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

統計情報の有無による実行計画の違い

　まずは統計情報を取得せずに、AUTOTRACEを実行し実行計画を確認してみます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

図1　統計情報を取得する前の実行計画（クリックで拡大します）

　「INDEX (RANGE SCAN) OF 'IDX_TEST_TABLE' (NON-UNIQUE)」と表示され、インデックス・スキャンが行われたことが分かります。オプティマイザ・モードが「CHOOSE」であるため、統計情報の存在しないテーブルはルールベースを採用した検索となります。

　次に、test_tableとidx_test_tableにANALYZEコマンドで統計情報を作成し、同じSQLを発行します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

図2　統計情報を取得した後の実行計画（クリックで拡大します）

　「TABLE ACCESS (FULL) OF 'TEST_TABLE' (Cost=2 Card=100 Bytes=1300)」と表示されました。オプティマイザ・モードが「CHOOSE」で統計情報が存在するため、コストベースを採用した検索となり、ここではフル・スキャンが行われました。

実行計画の検証とオプティマイザの挙動

　索引が存在するのに、なぜインデックス・スキャンが採用されないのでしょうか。コストベースでは、テーブル全体の構成を統計情報から取得し、NO列の10から10000までのテーブルデータを取得する際に、索引を使用して検索するよりも、表データを1行目から順に見ていき、10より大きいデータを採用する方がコスト的に有効であると判断したからです。

　以下のSQL文では1000行のデータから1行を取得するので索引を使用した方が有効と判断され、「INDEX (RANGE SCAN) OF 'IDX_TEST_TABLE'(NON-UNIQUE) (Cost=1 Card=1)」の表示からインデックス・スキャンが採用されたことが分かります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

図3　インデックス・スキャンが採用された（クリックで拡大します）

（次ページに続く）