変更の開始

動的 SQL プランの固定化

動的SQLプランの安定性を使用可能にすると、Db2は、指定された動的SQLステートメントのステートメント・キャッシュ構造体をDb2カタログに保管します。 安定化された動的SQLステートメントが発行時に動的ステートメント・キャッシュに存在しない場合、Db2は、Db2カタログからステートメント・キャッシュ構造をロードし、完全な準備操作を回避することができます。 この目的は、キャッシュに入れられた動的 SQL ステートメントを繰り返して使用する場合に、静的 SQL ステートメントに相当するアクセス・パスの固定化を実現することです。

動的 SQL ステートメントは、静的 SQL ステートメントよりもアクセス・パスの回帰の影響を受けやすいことが多くあります。 Db2 パッケージがバインドされる際に、静的SQL文用のアクセスパスを準備し、パッケージの次のBINDまたはREBINDが行われるまで、同じアクセスパスが再利用されます。 動的 SQL ステートメントの場合、 Db2 は、固定化されていない限り、動的ステートメント・キャッシュ内にないすべての動的 SQL ステートメントに対して完全な準備プロセスを使用します。 例えば、 Db2 サブシステムで以下のイベントが発生した場合、安定化された動的SQLステートメントは、動的ステートメントキャッシュからステートメントを無効化または削除する完全な準備プロセスにさらされることはありません

  • Db2が停止して、再始動しました
  • ステートメントが動的ステートメント・キャッシュから取り出され、再び入れられる
  • データを変更するために RUNSTATS やその他のユーティリティーによって統計が収集される
  • サブシステム・パラメーターが変更される
  • 保守がDb2に適用されます
  • リリース・マイグレーション

動的 SQL プランの安定度のもう 1 つのパフォーマンス上の利点は、週末のアクティビティーの後にアプリケーション・ワークロードが再開する場合など、 キャッシュ・ロード の負荷が高い期間にも実現できます。 Db2 安定化された動的SQL文の完全な準備プロセスを回避し、 カタログからキャッシュ構造をロードすることができます。 Db2

Db2は、以下のいずれかのイベントが発生した場合に、安定した動的SQLステートメントに対して、完全準備処理を再度使用します。

  • ステートメントがカタログから除去される
  • ステートメントが無効化される
  • キャッシュ・ミスを生じるその他の変更。例えば、APPLCOMPAT サブシステム・パラメーターや、特定の特殊レジスター (特に DEGREE や OPTHINT など)。

ただし、動的 SQL ステートメントの固定化を行う場合、そのトレードオフが生じます。 多くの場合、アクセス・パスを変更するとパフォーマンスが向上するため、固定化を行う場合に、こうしたパフォーマンス向上の可能性を手放すことになります。 固定化された動的 SQL ステートメントも、ランタイム構造を保管するために Db2 カタログ内のストレージ・スペースを使用します。

さらに、固定化された動的 SQL を管理するために、以下のような作業も必要になります。

  • 固定化する照会を特定し、使用する実行しきい値を決定する
  • Db2が安定化照会のための新しいアクセス・パスを選択できるようにするタイミングを識別します
  • カタログ・オブジェクトによって使用されるスペースを管理する
  • 照会を実行しなくなり、照会を解放できるタイミングを決定する

グループの固定化

固定化グループ とは、固定化された動的 SQL ステートメントの関連性のある集合をまとめるラベルのことです。 これは、目印として、また、複数の固定化されたステートメントをグループとして管理するためのコマンド入力として使用できます。

固定化された動的 SQL ステートメントの解放

変更の開始 Db2 カタログストレージを完全に準備したり、未使用の安定化された動的SQLステートメントを再利用したりするには、無料のSTABILIZED DYNAMIC QUERYコマンドを発行します。 詳細は、「 Db2 カタログから安定化された動的SQLステートメントを削除する 」を参照してください。変更の終わり

変更の終わり