アクセス・プランに対する変更の検出と修正
アプリケーション内の SQL ステートメントやそのアプリケーションの環境を変更したり、そのアプリケーションをデプロイしたりすると、いずれもアクセス・プランに変化が生じる可能性があります。 パッケージを再バインドする場合も同様です。InfoSphere® Optim™ Query Workload Tuner を使用すると、複数のアクセス・プラン間の変化を見つけてから、それらの変更を修正できます。
アプリケーション内の SQL ステートメントの追加、削除、または変更後の、アクセス・プランに対する変更の検出と修正
通常、ソース・プログラムの SQL ステートメントが追加、削除、または変更された場合、
ACTION(REPLACE)
サブオプションを指定した
BIND
コマンドを実行して、関連の DB2® パッケージを再バインドする必要があります。 このコマンドを実行すると、SQL ステートメントのアクセス・プランが変更されたり、パフォーマンスに影響を与えたりすることがあります。
リリース・マイグレーション後または保守フィックス適用後の、アクセス・プランに対する変更の検出と修正
リリース・マイグレーションには、DB2 のバージョン間のアップグレード (例えば、DB2 for z/OS® バージョン 9 から DB2 for z/OS 10 へのマイグレーション) や DB2 の保守レベルのアップグレード (例えば、APAR や PTF の適用) があります。リリース・マイグレーションでは、新機能が導入されて DB2 SQL オプティマイザーの動作が変更される場合があります。リリース・マイグレーション後に DB2 パッケージを再バインドすると、SQL ステートメントのアクセス・プランが変更されたり、パフォーマンスに影響を与えたりすることがあります。
データベース構造または許可を変更した後の、アクセス・プランに対する変更の検出と修正
データベース構造の更新 (表の変更、索引の作成、索引の削除など) およびユーザー許可の変更によって、SQL ステートメントのアクセス・プランが変更されたり、パフォーマンスに影響を与えたりすることがあります。
テスト・システムから実動システムにアプリケーションをデプロイした後の、アクセス・プランに対する変更の検出と修正
テスト・システム上の SQL ステートメントを実動システム上にデプロイした場合に、これらの SQL ステートメントのアクセス・プランが同じままかどうかを調べることができます。実動システム上のいずれかのアクセス・プランを改善する必要がある場合には、問題のある SQL ステートメントをチューニングしたり、テスト・システム上で使用していたアクセス・プランに戻ったりできます。
パッケージを再バインドした後の、アクセス・プランに対する変更の検出と修正
パッケージを別のコレクションに再バインドしたり、新しいバージョンのパッケージを単一のコレクションに再バインドしたりした後に生じたアクセス・プランの変化を見つけることができます。
親トピック:
複数アクセス・プランの修正または比較のシナリオ
関連資料
:
比較時の EXPLAIN スナップショットの使用に関する前提条件
比較時のパッケージの使用に関する前提条件
EXPLAIN 情報のスナップショットを使用したアクセス・プランの比較
フィードバック