連携クエリ・プランナーを使用して情報を統合する場合、作成されたクエリ・プランナーを見て、情報がどのようにアクセスされ処理されているかをよりよく理解し、問題のトラブルシューティングを行うことができます。

クエリプランは、ユーザーまたはアプリケーションによって送信されたコマンドを実行するためにクエリエンジンによって作成された命令のセットです。Query Plansの目的は、UserのQueryをできるだけ効率的に実行することです。

Getting a Query Plan

  • 任意の問い合わせに対して、EXPLAINコマンドを使用して、問い合わせ計画を生成することができます。結果に DEBUG_LOGを含めるかどうかは、ENABLE_EXPLAIN_LOG_OUTPUTの設定で制御できます；
  • SHOW PLANコマンドは、現在のセッションで最後に実行された問い合わせの PLAN_TEXT , PLAN_XML , DEBUG_LOG , DATA_LINEAGE_XMLの計画を表示します。結果にDEBUG_LOGを含めるかどうかは、設定SHOWPLANで制御できます；

  • SYSLOG.QueryLogテーブルに存在する問い合わせに対して、SYSADMIN.getQueryLogPlanプロシージャを使用して、計画の XML 表現を取得することができます：

    SELECT queryPlan FROM (CALL "SYSLOG.getQueryLogPlan"("logId" => <the id of the query>)) a;;

Query Plansの分析

Query Plansが取得されると、最も一般的な検索が行われます：

  • ソース Pushdown - クエリのどの部分が各ソースにプッシュされたか；
  • 注文に参加します；
  • 使用される Join アルゴリズム - Merge または Nested Loop；
  • Dependent JoinなどのFederated Optimizationsの有無；
  • JOIN Criteria タイプの不一致。

これらすべての問題は、リレーショナルクエリに特化した計画のサブセクションで提示されます。プロシージャを実行する場合、またはXML文書を生成する場合、全体的なQuery Planには、周辺のプロシージャ実行に関連する追加情報が含まれます。

Query Plansは、ツリー構造で構成されたノードの集合で構成されます。上記の例のように、通常、プランのテキスト形式の分析に関心があるでしょう。

プロシージャコンテキストでは、子ノードの順序は実行順序を意味します。その他のほとんどの状況では、子ノードはどのような順番で実行されても、並列に実行されてもかまいません。Dependent Joinのような特定のOptimizationにおいてのみ、joinの子はシリアルに実行されます。

Relational Plans

リレーショナルプランは、論理的なリレーショナル操作の基本的な構成要素であるノードで構成される処理プランを表します。物理リレーショナル計画は論理リレーショナル計画とは異なり、オプティマイザによって選択された追加操作と実行仕様が含まれます。

リレーショナル・クエリ・プランのノードは以下のとおりです：

  • Access - ソースにアクセスします。ソースクエリは、ソースに関連付けられた接続ファクトリに送信されます。[従属Joinの場合、このノードはDependent Selectと呼ばれます]。
  • Project - ノードから返されるカラムを定義します。これは返されるレコード数を変更しません。[SELECT句にサブクエリがある場合、このノードはDependent Projectと呼ばれます]。
  • Project Into - 通常のプロジェクトのように、ターゲットテーブルに行を出力します。
  • SELECT - SELECTはCriteria評価フィルタノードです ( WHERE / HAVING )。[Criteria に Subquery がある場合、このノードは Dependent Select と呼ばれます]。
  • Join - Join Type、Join Criteria、Join Strategy（MergeまたはNested Loop）を定義します。
  • UNION - このノードにはプロパティがありません。
  • Sort - ソートするカラム、各カラムのソート方向、重複を削除するかどうかを定義します。
  • Dup Removal - Sortと同じプロパティですが、removeDupsプロパティが設定されています。TRUE
  • Group - 行の設定をグループにまとめ、Aggregate関数を評価します。
  • NULL - 行を生成しないノード。通常は、Criteriaが常にfalseであるSelectノード（およびその下にあるツリー）を置き換えます。このノードのプロパティはありません。
  • プラン実行 - 別のサブプランを実行します。
  • LIMIT - 指定された行数を返し、処理を停止します。オフセットがある場合はオフセットも処理します。

Node Statistics

各ノードには出力される統計情報のセットがあります。これらは、ノードを流れるデータ量を決定するために使用できます。

Statistic

Description

Units

Node Output Rows

Number of records output from the node

count

Node Process Time

Time processing in this node only

millisec

Node Cumulative Process Time

Elapsed time from the beginning of processing to end

millisec

Node Cumulative Next Batch Process Time

Time processing in this node + child nodes

millisec

Node Next Batch Calls

Number of times a node was called for processing

count

Node Blocks

Number of times a blocked exception was thrown by this node or a child

count

ノード統計に加えて、ノードで計算されたコスト推定値を表示するノードもあります。

Cost Estimates

Description

Units

Estimated Node Cardinality

Estimated number of records that will be output from the node; -1 if unknown

count

Reading a Processor Plan

Query Plansは、プレーンテキストまたはXML形式で取得できます。通常、プレーンテキスト形式の方が読みやすく、XML形式の方がツールによる処理が容易です。可能であれば、ツリー構造が深くネストしている可能性があるため、計画を調査するためにツールを使用する必要があります。

データはツリーの葉から根に流れます。プロシージャ実行のためのサブプランはインラインで表示することができ、異なるインデントによって区別されます。 SELECT pm1.g1.e1, pm1.g2.e2, pm1.g3.e3 from pm1.g1 inner join (pm1.g2 left outer join pm1.g3 on pm1.g2.e1=pm1.g3.e1) on pm1.g1.e1=pm1.g3.e1というUser Queryがある場合、結合をプッシュダウンしないプロセッサプランのテキストは以下のようになります：

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


ネストされたjoinノードはマージjoinを使用し、各サイドからのソースクエリがjoinの期待される順序を生成することを期待することに注意してください。親ジョインは、入力された行に基づいてソートを実行する決定を遅らせることができる拡張ソートジョインです。Userクエリからの外側joinは、クエリ結果にNULL内側値が存在しないため、内側joinに変更されていることに注意してください。

同じプランを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>


同じ情報が各計画書式に記載されていることにご留意ください。場合によっては、最終的なプロセッサプランのデバッグプランの簡略化されたフォーマットに従う方が簡単なこともあります。  Debug Log ,上記と同じプランは、以下のように表示されます：

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

Node Properties

Common

  • Output Columns - このノードが返すタプルを構成するカラム

  • Data Bytes Sent - このクエリによって送信されたデータ・バイト数（メッセージング・オーバーヘッドを含まない）

  • Planning Time - クエリの計画に費やした時間（ミリ秒）

Relational

  • Relational Node ID - デバッグ・ログで見られるノード ID と一致 Node(id)

  • Criteria - フィルタリングに使用されるブーリアン式

  • Select Columns - プロジェクションを定義する列を選択します

  • Grouping Columns - グループ化に使用される列

  • Grouping Mapping - 集計およびグループ化カラムの内部名とその表現形式とのマッピングを示します

  • Query - ソースのクエリ

  • Model Name - モデル名

  • Sharing ID - 同じソース結果を共有するノードは、同じ共有IDを持ちます

  • Dependent Join - 依存Joinが使用されている場合

  • Join Strategy - 結合ストラテジー（Nested Loop、Sort Merge、Enhanced Sortなど）

  • Join Type - 結合タイプ（Left Outer Join、Inner Join、Cross Join）

  • Join Criteria - 結合述語

  • Execution Plan - 入れ子になった実行計画

  • Into Target - 挿入ターゲット

  • Sort Columns - 並べ替えの列

  • Sort Mode - 並べ替えが他の機能、例えば区別の除去も行う場合

  • Statistics - 処理統計

  • Cost Estimate - Dependent Joinのコスト見積もりを含む、コスト/カーディナリティの見積もり

  • Row Offset - 行オフセット式

  • Row Limit - 行数制限式

  • With - with 句

  • Window Functions - 計算されるWindow 関数

  • Table Function - テーブル機能 (XMLTABLE, OBJECTTABLE, TEXTTABLE, etc.)

Procedure

  • Expression

  • Result Set

  • Program

  • Variable

  • Then

  • Else

Other Plans

プロシージャの実行（トリガーの代わりを含む）は、リレーショナル計画を含む中間計画および最終計画形式を使用します。一般に、XML/プロシージャー・プランの構造は、その論理的な形式と密接に一致します。ネストされたリレーショナル・プランは、パフォーマンス問題を分析する際に注目されます。