開発データベースと本番データベースのクエリを比較しています。
どちらも Oracle 9i ですが、ほぼすべてのクエリの実行計画は、データベースによってまったく異なります。
すべてのテーブル/インデックスは同じですが、dev データベースには各テーブルの約 1/10 の行があります。
本番環境では、ほとんどのクエリに対して選択されるクエリ実行プランが開発とは異なり、コストが 1000 倍になることもあります。本番環境でのクエリも、場合によってはクエリに正しいインデックスを使用していないようです (完全なテーブル アクセス)。
私は最近、両方のデータベースで dbms_utility.analyze スキーマを実行しましたが、CBO が何かを解明してくれることを期待しています。
これを引き起こしている可能性のある他の基本的なオラクル構成はありますか?
私は主に開発者であるため、この種の DBA 分析は最初はかなり混乱します..
1) 最初に確認することは、データベース パラメーターが Prod と Dev で同等かどうかです。コスト ベース オプティマイザーの決定に影響を与えるパラメーターの 1 つが異なる場合、すべての賭けは無効になります。パラメータは v$parameter ビューで確認できます。
2) オブジェクト統計を最新のものにすることは素晴らしいことですが、指摘した大きな違いに注意してください。Dev には Prod の行の 10% があります。この行数は、CBO がクエリを実行する最善の方法を決定する際に考慮されます。行数に大きな違いがあることを考えると、計画が同じになるとは思えません。
状況に応じて、オプティマイザーは 20,000 行 (Dev) のテーブルのフル テーブル スキャンを選択する場合があります。200,000 行 (Prod) のテーブルではインデックスのコストが低いと判断される場合があります。(デモンストレーションのためだけの数値です。CBO は、絶対値ではなく、FTS とインデックス スキャンの対象を決定するためにコスト計算アルゴリズムを使用します)。
3) システム統計も実行計画に組み込まれます。これは、CPU およびディスク I/O の特性を表す一連の統計です。両方のシステムのハードウェアが異なる場合、システム統計が異なると予想され、これが計画に影響を与える可能性があります。Jonathan Lewis からの良い議論はこちら sys.aux_stats$ ビューを介してシステム統計を表示できます。
なぜ異なる計画があなたにとって悪いことなのかわかりません...統計が最新で、パラメーターが正しく設定されている場合、サイズの違いに関係なく、どちらのシステムからもまともなパフォーマンスが得られるはずです...
ただし、Prod システムから統計をエクスポートして、Dev システムにロードすることは可能です。これにより、Prod 統計が Dev データベースで利用できるようになります。
DBMS_STATS パッケージ、特に EXPORT_SCHEMA_STATS、EXPORT_SYSTEM_STATS、IMPORT_SCHEMA_STATS、IMPORT_SYSTEM_STATS プロシージャについては、Oracle のドキュメントを確認してください。10g/11g で午後 10 時の夜間統計ジョブを無効にする必要がある場合があることに注意してください... または、インポート後にロック統計を調査して、夜間ジョブによって更新されないようにすることができます。