SQL および XQuery コンパイラーの処理

SQL および XQuery コンパイラーは、いくつかのステップを実行して、実行可能なアクセス・プランを作成します。

照会グラフ・モデル は、これらのステップで処理される照会を表す、内部のメモリー内データベースです ( 図 1を参照)。 一部のステップは、フェデレーテッド・データベースに対して実行される照会のみに該当することに注意してください。
図1: SQL および XQuery コンパイラーによって実行されるステップ
SQL および XQuery コンパイラーによって実行されるステップ
  1. 照会の構文解析

    SQL および XQuery コンパイラーは、照会を分析して構文の妥当性検査を行います。 構文エラーが検出されると、照会コンパイラーは処理を停止し、照会をサブミットしたアプリケーションに対して該当するエラーを戻します。 構文解析が完了すると、照会の内部表示が作成され、照会グラフ・モデルに保管されます。

  2. セマンティクスのチェック

    コンパイラーは、ステートメントのパーツ間に不整合がないことを確認します。 例えば、コンパイラーは、YEAR スカラー関数用に指定した列が日時データ・タイプで定義されていることを検査します。

    コンパイラーはまた、機能上のセマンティクスを照会グラフ・モデルに追加します。それには、参照制約、表チェック制約、トリガー、およびビューなどの結果が含まれます。 照会グラフ・モデルには、照会ブロック、副照会、相関、派生表、式、データ・タイプ、データ・タイプ変換、コード・ページ変換、および分散キーを含む、照会のセマンティクスすべてが含まれます。

  3. 照会の書き直し

    コンパイラーは、照会グラフ・モデルに保管されているグローバルなセマンティクスを使用して、照会をもっと最適化しやすい形にトランスフォームします。 その後、その結果を照会グラフ・モデルに保管します。

    例えば、コンパイラーは述部を移動して、適用されるレベルを変更することにより、照会のパフォーマンスを改善することがあります。 このタイプの操作のことを、 一般述部プッシュダウン といいます。 パーティション・データベース環境では、 以下の照会操作は、計算量が多くなります。
    • Aggregation
    • 行の再配分
    • 副照会の外側にある表の列への参照を含む副照会である相関副照会

    パーティション・データベース環境での一部の照会では、 照会の書き直しの一環として非相関化が行われます。

  4. プッシュダウン分析 (フェデレーテッド・データベースのみ)

    このステップの主な作業は、データ・ソースにおいて、ある操作をリモートで評価 (プッシュダウン) できるかどうかを、オプティマイザーに知らせることです。 このタイプのプッシュダウン・アクティビティーは、データ・ソース照会に特有のものであり、 一般の述部のプッシュダウン操作を拡張するものとなります。

  5. アクセス・プランの最適化

    コンパイラーのうちのオプティマイザーの部分は、 照会グラフ・モデルを入力データとして使用して、 照会に答えるための多数の代替実行プランを生成します。 これらの各プランの実行コストを見積もるため、オプティマイザーは表、索引、列、および関数の統計を使用します。 見積実行コストの最も低いプランを選択します。 オプティマイザーは、照会グラフ・モデルを使用して照会のセマンティクスを分析したり、索引、基本表、派生表、副照会、相関、および再帰を含め、広範囲にわたる要因に関する情報を獲得したりします。

    オプティマイザーの部分では、別のタイプのプッシュダウン操作である、集約およびソート を考慮することもできます。この操作では、各操作の評価をデータ管理サービス (DMS) コンポーネントに知らせることにより、パフォーマンスを改善することができます。

    さらにオプティマイザーでは、ページ・サイズの選択時に、別のサイズのバッファー・プールが存在するかどうかも考慮されます。 データベースがパーティション化されているかどうか、または対称型マルチプロセッサー (SMP) 環境で照会内並列処理の可能性があるかどうかが考慮されます。 この情報は、オプティマイザーが照会にとって最適のアクセス・プランを選択するのに使用されます。

    このステップでの出力はアクセス・プランです。このアクセス・プランに関する詳細は、Explain 表にキャプチャーされます。 アクセス・プランを生成するために使用される情報は、Explain スナップショットでキャプチャーできます。

  6. リモート SQL 生成 (フェデレーテッド・データベースのみ)

    オプティマイザーで選択した最終プランは、リモート・データ・ソースに対して実行される一連のステップで構成されています。 リモート SQL 生成のステップでは、データ・ソースごとに実行される操作のために、 そのデータ・ソースの SQL ダイアレクトに基づく有効な SQL ステートメントが作成されます。

  7. 実行可能コードの生成

    最終ステップでは、コンパイラーはアクセス・プランと照会グラフ・モデルを使用して、 照会の実行可能なアクセス・プラン、つまりセクションを作成します。 このコード生成ステップでは、照会グラフ・モデルの情報を使用して、1 回計算するだけで済む式が繰り返し実行されないようにします。 この種の最適化は、コード・ページ変換の場合やホスト変数が使用される場合に可能です。

    ホスト変数、特殊レジスター、またはパラメーター・マーカーを持つ静的または動的 SQL あるいは XQuery ステートメントの照会最適化または再最適化を有効にするには、REOPT BIND オプションを使用してパッケージをバインドします。 そのようなパッケージに属し、かつホスト変数、特殊レジスター、またはパラメーター・マーカーを含んだステートメントのアクセス・パスは、コンパイラーが選択するデフォルトの見積もりではなく、これらの変数の値を使って最適化されます。 照会の実行時に値が与えられてから、この最適化は実行されます。

    静的 SQL および XQuery ステートメントのアクセス・プランに関する情報は、 システム・カタログ表に保管されます。 パッケージが実行されると、 データベース・マネージャーはシステム・カタログに保管されている情報を使用して、 データのアクセス方法を決め、照会結果を提供します。 この情報は、db2expln ツールによって使用されます。

注: 頻繁に変更される表に対して、適切な間隔で RUNSTATS コマンドを実行してください。 オプティマイザーが最も効率的なアクセス・プランを作成するには、表とそのデータに関する最新の統計情報が必要です。 アプリケーションを再バインドして、更新済みの統計を利用してください。 RUNSTATS を実行しなかった (または、空かほぼ空の表に対してこのコマンドが実行されたとオプティマイザーが想定している) 場合には、オプティマイザーは、デフォルト値を使用するか、 あるいはディスク上に表を保管するために使用されるファイル・ページ数に基づいて特定の統計を導き出そうとします。 自動統計収集も参照してください。