Vantageの最適化ルーチンのプロセス - Advanced SQL Engine - Teradata Database

ここでは、最適化ルーチンによって実行される問合わせ最適化の各段階について概説します。この情報が提供されているのは、最適化ルーチンが実行する作業と、その実行時の相対的な順序とを理解できるようにするために過ぎません。

問合わせ最適化のプロセス

次のプロセスは、最適化ルーチンがDMLリクエストを最適化する際のプロセスの論理的な順序を示しています。ここに示したプロセスには、特定のリクエストに対して最適化ルーチンが特定計画と汎用計画のどちらを生成するかを判断するための、パラメータ化された値ピーク処理の影響は含まれていません(パラメータ化されたリクエストを参照)。ただし、そのルーチンによってその判断が下されることに留意することは除きます。

最適化ルーチンへの入力は、クエリー リライトResTree'です(クエリー リライト、統計、および最適化を参照)。最適化ルーチンは最適化されたホワイト ツリーを生成し、それを生成ルーチンと呼ばれる最適化ルーチンのサブコンポーネントに渡します(生成ルーチンを参照)。

最適化ルーチンは、可能性のあるすべての計画案のコストを計算して最もコストの低い計画を選択することによって処理対象のすべてのリクエストに関する静的計画を生成し、ほとんどの場合、リクエストに対して静的計画を使用することを選択します。静的計画の生成プロセスにおいて、最適化ルーチンは、認識しているコンパイル時のデモグラフィック情報のすべてが正確であると仮定して、リクエスト全体に対する計画を生成します。ただし、特に、派生統計や拡張原価計算式などのTeradata Databaseによって使用される高度なデモグラフィック見積もり方法のすべてで、貧弱な静的計画につながるような計画の中間段階の不正確なカーディナリティ、CPU使用率、およびI/Oカウントが生成される可能性がある複雑な問合わせの場合は、この仮定が常に正しいとは限りません。

非相関サブクエリー、折り重ねられていない派生テーブルまたはビュー、リモート テーブル演算子、またはこれらの組み合わせなど、いくつかの独立コンポーネントを含むリクエストが発生した場合、最適化ルーチンはリクエストをリクエスト フラグメントと呼ばれる小さいコンポーネントに断片化します。 計画フラグメントの実行からのデモグラフィックと推測データを使用して以降のリクエスト フラグメントが計画されます。 リクエスト フラグメントは計画されて少しずつ実行されます。 このプロセスの詳細については、増分計画および実行を参照してください。

最適化ルーチンは、まず、リクエストに関する静的計画を生成してから、その計画を実行するか、動的計画を生成して実行するかを判断します。静的計画の生成中に収集された情報がこの判断の一部として使用されます。

最適化ルーチンは、完全な静的計画またはサマリー情報を最初の動的計画フラグメントの一部として静的計画からディスパッチャに送信して、ワークロード フィルタ、スロットル、および分類基準をリクエストに適用します。この動作は、 内部DBS制御フィールドによって制御されます。このフィールドを変更する必要がある場合は、Teradataカスタマー サポートに問い合わせてください。

リクエストからフィルタとスロットルが渡された場合は、最適化ルーチンは増分計画および実行(IPE)によってリクエストの処理を続行します。システムは、ワークロード フィルタ、スロットル、および分類基準を動的計画の計画フラグメントに適用しません。代わりに、動的計画は、静的計画に基づいてリクエストに対して決定されたワークロード定義を使用して実行されます。動的計画の計画フラグメントの実行中に、累積実行時測定基準に基づくワークロード例外が適用されます。

システムは、リクエストを最適化するための以下の処理段階を採用しています。

1. クエリー リライトResTree'を入力として受け取ります。
2. リクエストがまだ処理されていない場合は、特定計画を生成するか、それに関する汎用計画を生成するかを判断します。
3. 以下の段階で要求に関する静的計画を生成します。
   1. 相関subquery を、入れ子になっていないSELECTまたは簡単な結合に変換することによって処理します。
   2. 非相関スカラー サブクエリーは、サブクエリーを具体化し、その値をクエリーのUSING行に配置することによって処理します。
   3. 相関結合またはハッシュ インデックスを検索します。
   4. Subqueryをスプールへ実体化します。
   5. 以下の段階で実体化されたサブクエリーの最適化の可能性を分析します。
      1. 条件を相互に分離します(述部の整理を参照)。
      2. 述部を後付けします(述部の後付けと後出しを参照)。
      3. 接続情報を生成します。
      4. 複合結合を見つけます。
      5. 集約処理および部分的GROUP BY最適化処理の実行可能性を検出します。
   6. さらなる処理に必要なスプールのサイズおよび内容の見積もりを生成します(最適化ルーチンでの統計プロファイルの使用を参照)。
   7. 最適な単一のテーブルのアクセス パスを生成します。
   8. ステージ3.e.IVで識別した複合結合を簡略化して最適化します。
   9. ローカル接続についての情報を生成します。接続条件は、外部問合わせとsubquery とを接続するという条件です。次のいずれかの条件が検出されれば、2つのテーブルの間には直接接続が存在します。
      • AND演算されたバインド用語。不等式、ANDおよびORなどの様々な用語や、2つのテーブルの間の従属情報を満たす交差結合、外部結合、またはマイナス結合。
      • 外部テーブルと接続する、相関関係のないサブクエリーEXIST述部のスプール。
   10. 結合計画で使用される可能性のあるインデックスについての情報を生成します。この場合、関係するテーブルと、他の有用なインデックスの表記述子へのポインタのプライマリ インデックスが含まれます。
   11. パーティション化されたテーブルに対して行および列のパーティション排除を実行します。
   12. 再帰的追求1テーブル先取りアルゴリズムを使用して、最善の結合計画を生成します(結合の順序の確認を参照)。
   13. 段階3.mで示された結合計画が、適切な結合計画の経験則ベースの基準を満たしていない場合、nテーブル先取りアルゴリズムを使用して、最善の結合計画を別に生成します(結合の順序の確認を参照)。
   14. 段階3.mおよび3.nで生成された2つの結合計画のうち、より適切な計画を選択します。
   15. 識別された結合計画を経験則で適切であると判断した場合は、スター結合計画を生成します(スターおよびスノーフレークの結合の最適化を参照)。
   16. 段階oで選択したより適切な計画と、段階3.pで生成したスター結合計画を選択します。
4. 静的計画を実行するか、IPEを使用して動的計画を生成するかを決定します。

   最適化ルーチンの決定	継続するプロセス段階
   静的計画の使用	7
   動的計画の生成	6

5. 静的計画または静的計画のサマリーをディスパッチャに送信して、ワークロード フィルタ、スロットル、および分類基準をリクエストに適用します。リクエストからフィルタとスロットルが渡された場合は、最適化ルーチンはIPE処理の評価を続行します。
6. 静的計画に基づくIPEフレームワークの下で、以下の処理段階を使用して、リクエストに関する動的計画を生成します。
7. 最適化したホワイト ツリーを生成ルーチンに渡します。

次に、生成ルーチン(生成ルーチンを参照)が段階3.qまたは段階6で選択された計画に関するプラスチック ステップを生成します。