16.20 - DUMP EXPLAIN - Teradata Database - Teradata Vantage NewSQL Engine

Teradata Vantage™ SQLデータ操作言語

Product
Teradata Database
Teradata Vantage NewSQL Engine
Release Number
16.20
Release Date
2019年3月
Content Type
プログラミング リファレンス
Publication ID
B035-1146-162K-JPN
Language
日本語 (日本)

目的

問合わせの最適化ルーチン計画情報をキャプチャして、一連のINSERTリクエストを含むスクリプトの形式で要求元に返します。

インデックス分析の詳細は、以下を参照してください。
  • <Teradata Vantage™ SQLデータ定義言語 - 構文規則および例、B035-1144>の「BEGIN QUERY LOGGING」
  • <Teradata Vantage™ SQLデータ定義言語 - 構文規則および例、B035-1144>の「REPLACE QUERY LOGGING」
  • COLLECT DEMOGRAPHICS
  • COLLECT STATISTICS(QCD形式)
  • INITIATE INDEX ANALYSIS
  • INSERT EXPLAIN
  • RESTART INDEX ANALYSIS
  • Teradata Vantage™ SQLリクエストおよびトランザクション処理、B035-1142
  • Teradata Vantage™ - データベースの設計、B035-1094
  • Teradata® Index Wizardユーザー ガイド、B035-2506
  • Teradata® Viewpointユーザー ガイド、B035-2206、統計マネージャーのトピック
  • Teradata® Visual Explainユーザー ガイド、B035-2504
  • Teradata® System Emulation Toolユーザー ガイド、B035-2492

必要な権限

指定された問合わせキャプチャ データベースのすべてのテーブルに対するINSERT権限が必要です。

構文



構文要素

INTO QCD_name
ユーザー定義の問合わせキャプチャ データベースの名前。
QCD_nameという名前のデータベースはターゲット システム上に存在している必要はありません。ただし、生成されたスクリプトが実行されるテスト システム上には、QCD_nameという名前のデータベースが存在している必要があります。
Visual Explainツールのコントロール センター機能を使用して、QCDデータベースを作成します。
AS query_plan_name
問合わせ計画情報を格納するオプションのユーザー定義の名前を指定します。オブジェクト命名ルールの詳細については、<Teradata Vantage™ SQL基礎、B035-1141>を参照してください。
query_plan_nameを指定しない場合は、クエリー計画情報は名前なしで格納されます。各クエリー計画は、固有の非NULLクエリーID付きで格納されるので、特定のデータベース内のクエリー計画を区別できます。<Teradata Vantage™ SQLリクエストおよびトランザクション処理、B035-1142>を参照してください。クエリーIDは、複数のデータベース間で固有ではありません。
query_plan_nameは、固有である必要はありません。
query_plan_namequery_plan_nameとして格納できます。ただし、その場合は埋め込み文字で分離された語を"query plan name"のように単一引用符(u+0027)で囲む必要があります。
LIMIT
LIMIT SQL
LIMIT SQL=n
Query、Relation、ViewText、PredicateのそれぞれのQCDテーブルについてキャプチャされる問合わせ、DDL、ビュー テキスト、述部テキストのサイズを制限します。
この句を指定しないと、システムは完全なテキストをキャプチャします。
nの値は、キャプチャするテキストの量の上限を表わします。
LIMITだけを指定するかLIMIT SQLに値を指定しない場合、この句はLIMIT SQL = 0と同じであり、テキストはキャプチャされません。
CHECK STATISTICS
StatsRecs QCDテーブル内のSQL_requestのためのCOLLECT STATISTICS推奨事項をキャプチャすることを指定します。<Teradata Vantage™ SQLリクエストおよびトランザクション処理、B035-1142>を参照してください。
SQL_request
最適化ルーチン計画情報をキャプチャし、一連のINSERTリクエストとして要求元に返す対象となるDML文を指定します。
SQL_requestは、次に示す文に限定されます。
  • DELETE
  • EXEC (マクロ形式)
  • INSERT
  • MERGE
  • SELECT
  • UPDATE

ANSI準拠

DUMP EXPLAINは、ANSI SQL:2011規格に対するTeradataの拡張機能です。

呼び出し

通常は、クライアント ベースのデータベース問合わせ分析ツールを使用して呼び出されます。

既存のQCDなしのDUMP EXPLAINのアクション

DUMP EXPLAINによって作成されるスクリプトを初めて実行する前に、テスト システム上に既存のQCD_nameデータベースが存在していることを確認してください。Visual Explainツールのコントロール センター機能を使用して、QCDデータベースを作成することができます。

DUMP EXPLAINによって作成されるスクリプトを実行するときに、QCD_nameデータベースまたはそのテーブルのいずれか1つでも存在しない場合、あるいは1つ以上のQCD_nameデータベース テーブルに対するINSERT権限がない場合は、適切なエラー メッセージが表示され、スクリプトの実行が終了します。

DUMP EXPLAINで実行されるアクション

DUMP EXPLAINは、以下の動作を示されている順序で実行します。

  1. SQL_statementによって指定されたSQL DMLリクエストに対してEXPLAINを実行する。
  2. EXPLAINから最適化ルーチン計画出力をキャプチャする。
  3. ユーザー指定の問合わせキャプチャ データベースの適切なテーブルを更新するように設計された一連のINSERTリクエストを含むスクリプトとして出力を返す。

いくつかの異なるマシンから情報を収集していて、適切なマシン上の選択したQCDだけの結果の更新を確認する場合、またはワークロードの大きい期間にQCDを更新しない場合は、INSERT EXPLAINではなくDUMP EXPLAINを使用することができます。この場合は、ワークロードの小さい期間にDUMPリクエストをバッチ ジョブの一部として実行できます。

DUMP EXPLAINは、複文リクエスト内では無効

マルチ ステートメント リクエストの一部としてDUMP EXPLAINリクエストを実行することはできませんが、マルチ ステートメント リクエストに対してDUMP EXPLAINリクエストを実行することはできます。

DUMP EXPLAINリクエストを含むマルチ ステートメント リクエストを実行しようとすると、そのマルチ ステートメント リクエストはアボートされ、エラーが返されます。

次の例で示すDUMP EXPLAINリクエストは、マルチ ステートメント リクエストで有効な文のように見えます。事実、このリクエストによってDUMP EXPLAINに続くマルチ ステートメント リクエストのクエリー計画がキャプチャされます。つまり、このDUMP EXPLAINリクエストは、マルチ ステートメント リクエストの一部ではないということになります。その結果、このリクエストは他のDUMP EXPLAINと同様に扱われ、正常に完了します。

     DUMP EXPLAIN INTO qcd SELECT * FROM d1.t1
     ;SELECT * FROM d1.t1;

       *** Insert completed. One row added.
       *** Total elapsed time was 1 second.

DUMP EXPLAINは、XML出力のキャプチャをサポートしない

INSERT EXPLAINおよびEXPLAINリクエスト修飾子とは異なり、DUMP EXPLAIN文では、XMLドキュメントの問合わせ計画のキャプチャをサポートしてない

DUMP EXPLAINの結果に対するリクエスト キャッシュ参照の効果

データ パーセルがDUMP EXPLAINリクエストとともに実行されると、計画が参照済みUSINGとCURRENT_DATEやDATE値、または両方の値で生成されることがあります。これらの値が検査される場合、問合わせ計画によってこれらが示されます。

データ パーセルがDUMP EXPLAINリクエストとともに実行されない場合、結果の計画がUSING、CURRENT_DATEやDATE値を参照しないで生成されます。つまり定義による全般計画です。Visual Explain、Teradata System Emulation Tool、Teradata Index Wizardは、DUMP EXPLAINリクエストを使用してクエリー計画の取得中に入力としてUSINGデータを受け付けません。ただし、リクエストがBTEQまたはTeradata SQL Assistantを使用して実行された場合は除きます。

Teradata Index Wizardは内部でワークロード問合わせの計画を生成し、最適なインデックス推奨事項を決定するためのワークロードのコストを見積もります。ワークロードの問合わせによってUSINGリクエスト修飾子が指定される場合、計画はUSING値、CURRENT_DATE値、またはDATE値で検査されずに生成されます。これらの要因から、リクエスト キャッシュ参照は、結果のインデックスに影響を及ぼしません。ワークロード分析がUSING値と無関係である場合、この動作は正しく実行されます。

以下の例では、DUMP EXPLAINのさまざまな構文オプションを使用することで結果がどのように異なるかを示すために同じSELECTリクエストを使用しています。

各DUMP EXPLAINリクエストは、変更するSELECTリクエストについて、最適化ルーチンによって作成される問合わせ計画の一連のINSERTリクエストを生成します。

例: DUMP EXPLAINリクエスト

このDUMP EXPLAINリクエストの出力は、EmployeeSmithQueryデータベースの中でTLE_queriesという問合わせ計画名で参照されます。

     DUMP EXPLAIN INTO TLE_queries AS EmployeeSmithQuery
     SELECT emp_id, emp_address
     FROM employee
     WHERE emp_name = 'Smith';

例: NULLクエリー計画名を持つDUMP EXPLAINリクエスト

このDUMP EXPLAINリクエストの出力は、TLE_queriesデータベースの中で問合わせ計画名を持ちません。この例と例: DUMP EXPLAINリクエストの結果の相違は、クエリー計画に名前がないという点です。

     DUMP EXPLAIN INTO TLE_queries
     SELECT emp_id, emp_address
     FROM employee
     WHERE emp_name = 'Smith';

例: クエリー計画名を持つDUMP EXPLAINリクエスト

このDUMP EXPLAINリクエストの出力は、QCDデータベースの中でTLE_queriesという問合わせ計画名で参照されます。

     DUMP EXPLAIN INTO TLE_queries AS "Employee Smith Query"
     SELECT emp_id, emp_address
     FROM employee
     WHERE emp_name = 'Smith';