SQL構文解析プログラム - Advanced SQL Engine - Teradata Database

SQL構文解析プログラム

SQL構文解析プログラムは、PE (パーシング エンジン)の構成要素です。

パーシング エンジンには、クエリー処理に関連する2つの主要コンポーネント(構文解析プログラムとディスパッチャ)があります。

パーシング エンジンは、以下の簡易な図に示すように、リクエスト パーセルからAMPステップを生成します。

パーシング エンジンの要素のプロセス

主要なパーシング エンジン コンポーネントの概要を次に示します。

1. 構文解析ルーチンは高レベルな文の構文分析を行なって、エラーを調べます。

   構文が検査をパスすると、SQLリクエストの構成要素は構文解析ツリーと呼ばれるデータ構造に変換されます。この構造は、元の問合わせテキストの正確なマッピングです(SQLリクエストの構文解析ツリー表記を参照)。

   この骨組み解析ツリーをSynTreeと言います。次に、構文解析ルーチンは意味解釈ルーチンに引き継ぎます。SynTreeは、その問合わせのBlack Treeとも呼ばれます。

2. 意味解釈ルーチンはSynTreeを取得して、それに必要なデータ変換および任意のアクセス制御セキュリティ チェックに関する情報を付加します。また、列名を追加し、他のデータベース オブジェクトとの基礎的関係に関連した注釈を付けます。そして、さらに情報が付加されたツリー(ResTreeと言います)をパラメータ化された値ピーク処理に渡します。

   ResTreeは、その問合わせのRed Treeとも呼ばれます。

3. クエリー リライト サブシステムは、ResTreeを受け取り、次のような各種の書き換えを実行します。
   • 外部結合を内部結合に変換
   • タイプ1およびタイプ2のビューの折重ね
   • ビューへの射影の後付け
   • ビューへの条件の後付け
   • 実現可能性および推移閉包
   • 結合の削除

     次に、クエリー リライト サブシステムは、意味的に同等の改訂されたResTree’を最適化ルーチンに渡します。詳細については、クエリー リライト、統計、および最適化を参照してください。

4. 最適化ルーチンは、データベースおよびシステム ハードウェアの構成要素に関するさまざまな統計および構成データを使ってResTree'を分析し、リクエストに対して最適な計画を決定します。このサブシステムには次の内容が含まれます。

   • アクセス計画
   • 結合計画
   • 結合インデックス計画
   • 複雑な外部結合計画
   • Subquery 計画
   • 集約計画
   • 挿入、削除および更新計画
   • Index Wizard
   • 最適化ルーチンのクエリー リライト

   最適化ルーチンは、最初に統計キャッシュを検査して、必要な統計がデータ ディクショナリから取得されているかどうかを確認します。取得されていない場合は、必要な統計をデータ ディクショナリから取得します。

   次に、最適化ルーチンはSQLリクエストによって設定されたロックを調べ、その設定を最適化してパフォーマンスの向上とデッドロックの回避を試みます。

   次に、最適化された構文解析ツリーは、単純文ツリーから完全な操作ツリーに変換されてステップの生成ルーチンに渡され、さらに処理が続けられます。

   この最適化されたバージョンの構文解析ツリーは、そのリクエストのホワイト ツリー、または操作ツリーと呼ばれます。ResTreeが操作ツリーに変換されるとき、それはピンク ツリーと呼ばれることがあります。レッドとホワイトの混合の中間点となるため、ピンクとなります。

   リクエストのEXPLAINを実行するときにシステムが生成するレポートは、そのリクエストに対して最適化ルーチンが生成するホワイト ツリーを言葉で説明したものに、Teradata動的ワークロード管理ソフトウェアが使用するためにTeradata Databaseがホワイト ツリーに挿入する、コストが見積もられていないステップに関する追加情報を加えたものです。

   詳細については、クエリー リライト、統計、および最適化、<Teradata® Workload Analyzerユーザー ガイド、B035-2514>、および<Teradata Vantage™ - SQLデータ操作言語、B035-1146>と<Teradata® Visual Explainユーザー ガイド、B035-2504>にあるEXPLAIN修飾子の説明を参照してください。

5. ステップの生成ルーチンは、ホワイト ツリーからプラスチック ステップを作成します。プラスチック ステップとは、最適化された解析ツリーから派生したAMP命令の、データ フリーな(文のリテラルを除く)骨組みツリーです。

   次に、完成したプラスチック ステップ ツリーがリクエスト キャッシュとステップのパッケージ化に渡され、さらに処理が続けられます。

6. ステップのパッケージ化では、さまざまなユーザーとセッションに固有の情報を統合することによって、プラスチック ステップにコンテキストを追加します。

   データ パーセルがパラメータ化されたリクエストを使って構文解析プログラムに渡された場合、そのデータもステップ ツリーに追加されます(ここでは、data parcelという用語は、常にデータ パーセル セットを指します。繰り返しリクエストは複数のデータ パーセルと関連付けられますが、非繰り返しリクエストが関連付けられるデータ パーセルは1つのみです。また、リクエストがどのデータ パーセルにも関連付けられないこともあります)。

   このプロセスの最終成果をコンクリート ステップと言います。

7. ステップのパッケージ化はコンクリート ステップをディスパッチャに渡して、AMPへの割り当てを行ないます。
8. ディスパッチャは少しずつ順番に、自動的にコンクリート ステップ(プロセスのこの時点ではAMPステップまたは破棄ステップと呼ぶ)をBYNETを介して適切なAMPに伝送し、処理します。
9. ディスパッチャは必要となる可能性のあるアボート処理を管理します。
10. ディスパッチャはAMPステップの結果をBYNETから受け取り、それを要求元のアプリケーションに戻します。