フェデレーションされたクエリープランナーを使用して情報を統合する際に、クエリー計画を表示して情報にアクセスおよび処理される方法をさらに理解し、問題のトラブルシューティングを行うと便利です。
クエリー計画(実行または処理計画としても知られる)は、ユーザーまたはアプリケーションが送信するコマンドを実行するためにクエリーエンジンによって作成される一連の命令です。クエリー計画の目的は、可能な限り効率的な方法でユーザーのクエリーを実行することです。
SET SHOWPLAN [ON|DEBUG]: 処理計画またはプランおよび完全なプランナーのデバッグログを返します。詳細は、『Client Developer's Guide』の「 Query planner and SET statement 」を参照してください。 上記のオプションを使用すると、org.teiid.jdbc.TeiidStatement
インターフェースにキャストするか、または SHOW PLAN ステートメントを使用して、クエリー計画が Statement オブジェクトから利用できます。詳細は、『Client Developer's Guide』の「 SHOW Statement 」を参照してください。または、EXPLAIN ステートメントを使用できます。詳細は、「 Explain statement 」を参照してください。
クエリー計画は、複数の Data Virtualization のツールで自動的に利用可能になります。
source pushdown xmvn-gitops 各ソースにプッシュされたクエリーの部分
特にインデックスに対して述語がプッシュされていることを確認します。
joins-1.6.0--で合成された結合は、非常にコストのかかる可能性があります。
join orderingfaillock-gitopsTypical impacting by costing
条件タイプの不一致に参加します。
join アルゴリズムを使用して、マージやネストされたループの強化などを行いました。
依存する参加などのフェデレーションされた最適化があること。
ヒントに、必要な影響があることを確認します。ヒントの使用に関する詳細は、以下の追加リソースを参照してください。
処理計画から前述のリスト内のすべての情報を確認できます。通常、最終処理計画のテキスト形式の分析に関心があります。デバッグまたはサポートに対して特定の決定が行われる理由を理解するには、中間計画ステップを含む完全なデバッグログと、特定のプッシュダウン決定が行われる理由へのアノテーションを取得します。
クエリー計画は、ツリー構造で整理されたノードのセットで構成されます。手順を実行している場合、クエリー計画全体には、周りの手順の実行に関連する追加情報が含まれます。
手順のコンテキストでは、子ノードの順序は実行の順序を意味します。ほとんどの場合、子ノードは並行しても任意の順序で実行できます。依存結合などの特定の最適化では、結合の子が順次実行されます。
リレーショナルデータベースクエリー計画のノードは以下のとおりです。
accessで source にアクセスします。ソースクエリーは、ソースに関連付けられた接続ファクトリーに送信されます。(依存する結合の場合、このノードは Dependent Access と呼ばれます。)
依存する手順は、複数の入力値のセットを使用してソースのストアドプロシージャーにアクセスします。
バッチの更新で、更新のセットをバッチとして処理します。
projectgitops-で、ノードから返された列をDefinines にします。返されたレコード数は変更しません。
プロジェクトを通常のプロジェクトと同様ですが、ターゲットテーブルに行を出力します。
プロジェクトにプランの実行で完了し、ソースクエリーではなくプランを実行します。通常、クエリー式を使用してビューに挿入するときに作成されます。
window function project336-TEMPLATESLike は通常のプロジェクトで使用されますが、ウィンドウ機能が含まれます。
pidgin-TEMPLATESSelect は、基準評価フィルターノード(WHERE / HAVING)です。
jointypes - join タイプ、結合基準、結合ストラテジー(merge または nested loop)に参加します。
このノードのプロパティーをすべて選択せずに、その子から行を渡します。トランザクションまたはソースクエリーの同時実行が許可されているかどうかなど、他の要素によっては、すべての結合子が並行して実行されるわけではありません。
ソートする列を並べ替える - ソートする列、各列のソート方向、重複を削除するかどうかを指定します。
dup removegitops-gitopsRemoves の重複行。処理はツリー構造を使用して重複を検出し、結果を IO 操作のコストが効率的にストリーミングできるようにします。
一連の行のセットをグループにグループ化し、集約関数を評価します。
行が生成されない null rhncfg-で、AnbileA ノード。通常は、基準が常に false(および下のツリー)である Select ノードを置き換えます。このノードのプロパティーはありません。
プランの実行 - 別のサブプランを実行します。通常、サブ計画は関係しないプランです。
依存する手順の実行 - 複数の入力値セットを使用してサブプランを実行します。
制限制限 - 指定した数行数を書き込んでから、処理を停止します。また、存在する場合はオフセットも処理します。
XML table PROVISIONING-gitopsEvaluates XMLTABLE.デバッグ計画には、最適化に関して XQuery/XPath に関する詳細情報が含まれます。詳細は「 XQuery optimization 」を参照してください。
テキストテーブル - Evaluates TEXTTABLE
array table - Evaluates ARRAYTABLE
Object table - Evaluates OBJECTTABLE
Expand 統計 説明 ユニット
ノード出力行
ノードからの出力のレコード数。
count
ノードの次のバッチプロセス時間
このノードの時間処理。
millisec
ノードの累積次のバッチプロセス時間
このノード + 子ノードにおける時間処理。
millisec
ノードの累積プロセス時間
処理の開始から終了までの経過時間。
millisec
ノードの次のバッチ呼び出し
ノードが処理のために呼び出された回数。
count
ノードブロック
このノードまたは子によってブロックされた例外がスローされた回数。
count
Show more
ノードの統計以外にも、一部のノードの表示コストにより、ノードで計算される予測が予測されます。
Expand Cost Estimates 説明 ユニット
推定ノードのカーディナリティー
ノードから出力されるレコードの推定数。不明な場合は -1。
count
Show more
ルートノードが追加情報を表示します。
Expand 最上位の統計 説明 ユニット
Data Bytes Sent
クライアントに送信されるシリアライズされたデータ結果(行と緩やかの値)のサイズ。
bytes
Show more
ツリーのリーフからルートへのデータフロー。手順実行のサブプランはインラインで示され、インデントが異なります。pm1 .g1.e1=pm1.g3.e1、pm1.g2.e2、pm1.g3.e3 のユーザークエリーが pm1.g1 の内部参加(pm1.g2 left outer は pm1.g2.e1=pm1.g3.e1)の pm1.g1.e1=pm1.g3.e1
で、結合をプッシュしないプロセッサープランのテキストは次のようになります。
ProjectNode
+ Output Columns:
0: e1 (string)
1: e2 (integer)
2: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Output Columns:
0: e1 (string)
1: e2 (integer)
2: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Output Columns:
0: e1 (string)
1: e1 (string)
2: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
AccessNode
+ Output Columns:e1 (string)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0
+ Model Name:pm1
+ Child 1:
AccessNode
+ Output Columns:
0: e1 (string)
1: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0 ORDER BY c_0
+ Model Name:pm1
+ Join Strategy:MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)
+ Join Type:INNER JOIN
+ Join Criteria:pm1.g1.e1=pm1.g3.e1
+ Child 1:
AccessNode
+ Output Columns:
0: e1 (string)
1: e2 (integer)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0 ORDER BY c_0
+ Model Name:pm1
+ Join Strategy:ENHANCED SORT JOIN (SORT/ALREADY_SORTED)
+ Join Type:INNER JOIN
+ Join Criteria:pm1.g3.e1=pm1.g2.e1
+ Select Columns:
0: pm1.g1.e1
1: pm1.g2.e2
2: pm1.g3.e3
ProjectNode
+ Output Columns:
0: e1 (string)
1: e2 (integer)
2: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Output Columns:
0: e1 (string)
1: e2 (integer)
2: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
JoinNode
+ Output Columns:
0: e1 (string)
1: e1 (string)
2: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Child 0:
AccessNode
+ Output Columns:e1 (string)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0
+ Model Name:pm1
+ Child 1:
AccessNode
+ Output Columns:
0: e1 (string)
1: e3 (boolean)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0 ORDER BY c_0
+ Model Name:pm1
+ Join Strategy:MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)
+ Join Type:INNER JOIN
+ Join Criteria:pm1.g1.e1=pm1.g3.e1
+ Child 1:
AccessNode
+ Output Columns:
0: e1 (string)
1: e2 (integer)
+ Cost Estimates:Estimated Node Cardinality: -1.0
+ Query:SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0 ORDER BY c_0
+ Model Name:pm1
+ Join Strategy:ENHANCED SORT JOIN (SORT/ALREADY_SORTED)
+ Join Type:INNER JOIN
+ Join Criteria:pm1.g3.e1=pm1.g2.e1
+ Select Columns:
0: pm1.g1.e1
1: pm1.g2.e2
2: pm1.g3.e3
Copy to Clipboard
Copied!
Toggle word wrap
Toggle overflow
ネストされた結合ノードはマージ結合を使用しており、各サイドのソースクエリーが結合の予想される順序を生成することを予想することに注意してください。親結合は強化されたソート結合で、受信行に基づいてソートの実行を遅らせることができます。null 内部値がクエリー結果に存在しないため、ユーザークエリーからの外部参加は内部参加に変更されています。
前述のプランは、以下の例のように XML 形式で表現することもできます。
<?xml version="1.0" encoding="UTF-8"?>
<node name="ProjectNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e2 (integer)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Child 0">
<node name="JoinNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e2 (integer)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Child 0">
<node name="JoinNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e1 (string)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Child 0">
<node name="AccessNode">
<property name="Output Columns">
<value>e1 (string)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Query">
<value>SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0</value>
</property>
<property name="Model Name">
<value>pm1</value>
</property>
</node>
</property>
<property name="Child 1">
<node name="AccessNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Query">
<value>SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0
ORDER BY c_0</value>
</property>
<property name="Model Name">
<value>pm1</value>
</property>
</node>
</property>
<property name="Join Strategy">
<value>MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)</value>
</property>
<property name="Join Type">
<value>INNER JOIN</value>
</property>
<property name="Join Criteria">
<value>pm1.g1.e1=pm1.g3.e1</value>
</property>
</node>
</property>
<property name="Child 1">
<node name="AccessNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e2 (integer)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Query">
<value>SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0
ORDER BY c_0</value>
</property>
<property name="Model Name">
<value>pm1</value>
</property>
</node>
</property>
<property name="Join Strategy">
<value>ENHANCED SORT JOIN (SORT/ALREADY_SORTED)</value>
</property>
<property name="Join Type">
<value>INNER JOIN</value>
</property>
<property name="Join Criteria">
<value>pm1.g3.e1=pm1.g2.e1</value>
</property>
</node>
</property>
<property name="Select Columns">
<value>pm1.g1.e1</value>
<value>pm1.g2.e2</value>
<value>pm1.g3.e3</value>
</property>
</node>
<?xml version="1.0" encoding="UTF-8"?>
<node name="ProjectNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e2 (integer)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Child 0">
<node name="JoinNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e2 (integer)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Child 0">
<node name="JoinNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e1 (string)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Child 0">
<node name="AccessNode">
<property name="Output Columns">
<value>e1 (string)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Query">
<value>SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0</value>
</property>
<property name="Model Name">
<value>pm1</value>
</property>
</node>
</property>
<property name="Child 1">
<node name="AccessNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e3 (boolean)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Query">
<value>SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0
ORDER BY c_0</value>
</property>
<property name="Model Name">
<value>pm1</value>
</property>
</node>
</property>
<property name="Join Strategy">
<value>MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)</value>
</property>
<property name="Join Type">
<value>INNER JOIN</value>
</property>
<property name="Join Criteria">
<value>pm1.g1.e1=pm1.g3.e1</value>
</property>
</node>
</property>
<property name="Child 1">
<node name="AccessNode">
<property name="Output Columns">
<value>e1 (string)</value>
<value>e2 (integer)</value>
</property>
<property name="Cost Estimates">
<value>Estimated Node Cardinality: -1.0</value>
</property>
<property name="Query">
<value>SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0
ORDER BY c_0</value>
</property>
<property name="Model Name">
<value>pm1</value>
</property>
</node>
</property>
<property name="Join Strategy">
<value>ENHANCED SORT JOIN (SORT/ALREADY_SORTED)</value>
</property>
<property name="Join Type">
<value>INNER JOIN</value>
</property>
<property name="Join Criteria">
<value>pm1.g3.e1=pm1.g2.e1</value>
</property>
</node>
</property>
<property name="Select Columns">
<value>pm1.g1.e1</value>
<value>pm1.g2.e2</value>
<value>pm1.g3.e3</value>
</property>
</node>
Copy to Clipboard
Copied!
Toggle word wrap
Toggle overflow
各プランのフォームに同じ情報が表示されます。場合によっては、デバッグ計画の最終プロセッサープランの簡略化された形式に従うのが簡単になります。以下の出力は、デバッグログが前述の XML 例のプランを表している方法を示しています。
OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
ProjectNode(0) output=[pm1.g1.e1, pm1.g2.e2, pm1.g3.e3] [pm1.g1.e1, pm1.g2.e2, pm1.g3.e3]
JoinNode(1) [ENHANCED SORT JOIN (SORT/ALREADY_SORTED)] [INNER JOIN] criteria=[pm1.g3.e1=pm1.g2.e1] output=[pm1.g1.e1, pm1.g2.e2, pm1.g3.e3]
JoinNode(2) [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)] [INNER JOIN] criteria=[pm1.g1.e1=pm1.g3.e1] output=[pm1.g3.e1, pm1.g1.e1, pm1.g3.e3]
AccessNode(3) output=[pm1.g1.e1] SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0
AccessNode(4) output=[pm1.g3.e1, pm1.g3.e3] SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0 ORDER BY c_0
AccessNode(5) output=[pm1.g2.e1, pm1.g2.e2] SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0 ORDER BY c_0
OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
ProjectNode(0) output=[pm1.g1.e1, pm1.g2.e2, pm1.g3.e3] [pm1.g1.e1, pm1.g2.e2, pm1.g3.e3]
JoinNode(1) [ENHANCED SORT JOIN (SORT/ALREADY_SORTED)] [INNER JOIN] criteria=[pm1.g3.e1=pm1.g2.e1] output=[pm1.g1.e1, pm1.g2.e2, pm1.g3.e3]
JoinNode(2) [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)] [INNER JOIN] criteria=[pm1.g1.e1=pm1.g3.e1] output=[pm1.g3.e1, pm1.g1.e1, pm1.g3.e3]
AccessNode(3) output=[pm1.g1.e1] SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0
AccessNode(4) output=[pm1.g3.e1, pm1.g3.e3] SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0 ORDER BY c_0
AccessNode(5) output=[pm1.g2.e1, pm1.g2.e2] SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0 ORDER BY c_0
Copy to Clipboard
Copied!
Toggle word wrap
Toggle overflow
共通
Output columns: このノードによって返されるタプルを構成する列。
送信されたデータバイト - メッセージングオーバーヘッドを含まないデータバイトの数がこのクエリーによって送信されました。
プランニング時間: クエリーの計画に費やした時間(ミリ秒単位)。
リレーショナル
リレーショナルノード ID336-TEMPLATES は、デバッグログ Node(id)に表示されるノード ID と一致します。
基準 2: フィルタリングに使用するブール式です。
Projection を定義する columns xmvn-gitopshe 列を選択します。
グループ化に使用する列のグルーピング - グループ化に使用する列。
マッピングのグルーピングにより、集約およびグルーピング列の内部名から式フォームへのマッピングが表示されます。
querygitops-gitopsThe source query.
モデル名で、モデル名を使用しない場合は、このモデル名が必要です。
同じソース結果を共有する ID Warehouse を共有すると、同じ共有 ID が設定されます。
依存結合結合が使用されている場合、依存する join が使用されています。
参加ストラテジーにジョインストラテジー(Nested Loop、Sort Merge、Enhanced Sort など)に参加します。
参加するタイプにジョインするタイプ(左の参加、Inner Join、Cross Join)
参加する条件(join predicates)に参加します。
実行プランでネストされた実行計画です。
挿入ターゲットにターゲットを使用。
挿入が upsert の場合は Upsert-1.6.1+If を挿入します。
並び替え列で、ソート用の列を並び替えます。
並べ替えモードにソートすると、ソートも、個別の削除のように別の機能を実行します。
ロールアップオプションにより、グループに rollup オプションがあります。
statisticsfaillock-gitopsThe processing statistics.
コスト予測 - 依存する結合コスト予測を含むコスト/カーディナリティー予測。
行のオフセット式に、行のオフセット式があります。
行の上限 - 行制限式。
with 節で、with 節を使用します。
ウィンドウ関数で計算されるウィンドウ関数。
テーブル関数(XMLTABLE、OBJECTTABLE、TEXTTABLE など)
streamingで XMLTABLE がストリーム処理を使用していること。
手順
式
結果セット
program
変数
次に、
その他