NonStop SQL/MXクエリ・ガイド

NonStop SQL/MX
クエリ・ガイド
概要
本書は、クエリ実行プランを理解して、HP NonStop™ SQL/MX データ
ベース用の最適なクエリを記述する方法を説明しています。本書は、
SQL/MX を使用して SQL/MX データベースのクエリを実行し、クエ
リ・パフォーマンスの問題に特に興味のあるデータベース管理者およ
びアプリケーション開発者を対象としています。
製品バージョン
NonStop SQL/MX Release 2.0
対象となるリリース・バージョン・アップデート (RVU)
本書は、次の版が発行されるまで、G06.23 およびそれ以降すべての G
シリーズ RVU を対象とします。
マニュアル番号
523728-001J
発行
2004 年 11 月
日本ヒューレット・パッカード株式会社
523728-001J
-i
本書のプログラムを含むすべての内容は、著作権法上の保護を受けて
おります。著者、発行者の許諾を得ず、無断で複写、複製をすること
は禁じられております。
原 典
Document History
Part Number
Product Version
Published
429826-001
NonStop SQL/MX Release 1.0
March 2001
429856-001
NonStop SQL/MX Release 1.5
November 2001
522677-001
NonStop SQL/MX Release 1.8
December 2002
523728-001
NonStop SQL/MX Release 2.0
April 2004
Ordering Information
For manual ordering information: domestic U.S. customers, call 1-800-243-6886; international customers, contact
your local sales representative.
Document Disclaimer
Information contained in a manual is subject to change without notice. Please check with your authorized
representative to make sure you have the most recent information.
Export Statement
Export of the information contained in this manual may require authorization from the U.S. Department of
Commerce.
Examples
Examples and sample programs are for illustration only and may not be suited for your particular purpose. The
inclusion of examples and sample programs in the documentation does not warrant, guarantee, or make any
representations regarding the use or the results of the use of any examples or sample programs in any
documentation. You should verify the applicability of any example or sample program before placing the software
into productive use.
U.S. Government Customers
FOR U.S. GOVERNMENT CUSTOMERS REGARDING THIS DOCUMENTATION AND THE ASSOCIATED
SOFTWARE:
These notices shall be marked on any reproduction of this data, in whole or in part.
NOTICE: Notwithstanding any other lease or license that may pertain to, or accompany the delivery of, this
computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in
Section 52.227-19 of the FARS Computer Software—Restricted Rights clause.
RESTRICTED RIGHTS NOTICE: Use, duplication, or disclosure by the Government is subject to the
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at
DFARS 52.227-7013.
RESTRICTED RIGHTS LEGEND: Use, duplication or disclosure by the Government is subject to restrictions
as set forth in paragraph (b)(3)(B) of the rights in Technical Data and Computer Software clause in
DAR 7-104.9(a). This computer software is submitted with “restricted rights.” Use, duplication or disclosure is
subject to the restrictions as set forth in NASA FAR SUP 18-52 227-79 (April 1985) “Commercial Computer
Software—Restricted Rights (April 1985).” If the contract contains the Clause at 18-52 227-74 “Rights in Data
General” then the “Alternate III” clause applies.
U.S. Government Users Restricted Rights — Use, duplication or disclosure restricted by GSA ADP Schedule
Contract.
Unpublished — All rights reserved under the Copyright Laws of the United States.
-ii
523728-001J
目次
目次
本書について ...................................................................................................................................... xi
対象読者 .................................................................................................................................... xi
構成
...................................................................................................................................xii
関連マニュアル.......................................................................................................................xiii
表記規約 ................................................................................................................................. xvii
第1章
クエリのコンパイルと実行
1.1
1.2
コンパイラの動作 .................................................................................................................. 1-2
1.1.1
コンパイル手順 ...................................................................................................... 1-2
1.1.2
構文解析、結合、正規化 .......................................................................................1-2
1.1.3
クエリ・プラン・キャッシング ............................................................................1-5
1.1.4
クエリ・パフォーマンスの向上 ............................................................................1-5
エグゼキュータによるプランの処理方法 ..........................................................................1-15
第 2 章 SQL/MX データへのアクセス
2.1
2.2
第3章
アクセス方法 ..........................................................................................................................2-2
2.1.1
ストレージ・キー・アクセス.................................................................................2-2
2.1.2
インデックス・オンリ・アクセス .........................................................................2-3
2.1.3
代替インデックス・アクセス.................................................................................2-4
2.1.4
フル・テーブル・スキャン ....................................................................................2-5
2.1.5
予期しないアクセス・パス ....................................................................................2-6
MultiDimensional Access Method (MDAM)........................................................................2-10
2.2.1
MDAM の指定 .......................................................................................................2-10
2.2.2
MDAM と単一サブセット・アクセスの比較 .....................................................2-11
2.2.3
MDAM によるクエリ処理 ....................................................................................2-12
2.2.4
オプティマイザが MDAM を選択しやすくする方法 .........................................2-14
2.2.5
MDAM が使用するキー・カラム数の制御 .........................................................2-15
2.2.6
DENSE アルゴリズムと SPARSE アルゴリズム ................................................2-15
統計情報の更新
3.1
ヒストグラム統計情報 ..........................................................................................................3-2
3.1.1
3.2
サンプリングと UPDATE STATISTICS...............................................................................3-6
3.2.1
523728-001J
ヒストグラム統計情報の更新.................................................................................3-3
サンプリングにおけるパフォーマンスの問題と精度 ..........................................3-6
iii
目次
3.2.2
3.3
第4章
UPDATE STATISTICS の結果のテスト .............................................................................. 3-8
3.3.1
SQL/MP テーブルの結果のテスト ........................................................................ 3-8
3.3.2
SQL/MX テーブルに対する結果のテスト ............................................................ 3-8
クエリ実行プランの確認
4.1
4.2
4.3
クエリ実行プランの表示 ....................................................................................................... 4-2
4.1.1
DISPLAY_EXPLAIN ショートカットの使用 ...................................................... 4-3
4.1.2
Visual Query Planner の使用 .................................................................................. 4-3
4.1.3
オプティマイザとエグゼキュータ ........................................................................ 4-4
4.1.4
EXPLAIN 関数の結果 ............................................................................................ 4-4
4.1.5
実行プランの選択カラムの表示 ............................................................................ 4-6
4.1.6
埋め込み SQL プログラムからの EXPLAIN 出力の抽出 .................................... 4-7
実行プランの確認 .................................................................................................................. 4-8
4.2.1
DISPLAY_EXPLAIN コマンドの使用 .................................................................. 4-8
4.2.2
DAM アクセスの検証 .......................................................................................... 4-13
4.2.3
Visual Query Planner の使用 ................................................................................ 4-14
4.2.4
実行プランのグラフィカル表示 .......................................................................... 4-14
実行時統計情報の確認 ........................................................................................................ 4-21
4.3.1
第5章
簡単なクエリの例 ................................................................................................. 4-21
実行プランの強制
5.1
プラン強制の目的 .................................................................................................................. 5-2
5.2
プラン強制のチェックリスト ............................................................................................... 5-3
5.3
最適化プランの表示 .............................................................................................................. 5-4
5.4
最適化プランの確認 .............................................................................................................. 5-5
5.5
演算子ツリーをテキスト形式に変換 .................................................................................... 5-7
5.6
iv
複数カラムの統計情報の収集 ................................................................................ 3-7
5.5.1
SHOWSHAPE と SET SHOWSHAPE によるテキスト形式の表示 .................... 5-7
5.5.2
Visual Query Planner によるシェイプの取得 ........................................................ 5-8
5.5.3
シェイプの手動書き込み........................................................................................ 5-8
強制シェイプ・ステートメントの書き込み ...................................................................... 5-10
5.6.1
CONTROL QUERY SHAPE の有効範囲 ............................................................ 5-10
5.6.2
演算子ツリーの部分的シェイプ .......................................................................... 5-10
5.6.3
論理指定と物理指定の使用 .................................................................................. 5-10
5.6.4
ビューでのシェイプの強制 .................................................................................. 5-11
5.6.5
プランが返されない場合..................................................................................... 5-11
5.6.6
SQL/MP からの強制シェイプの移行 .................................................................. 5-12
523728-001J
目次
第6章
5.6.7
Data Access Manager に対する Group By 操作の強制 ........................................5-12
5.6.8
パラレル・プランの強制 ......................................................................................5-14
クエリ・プラン・キャッシング
6.1
キャッシュ可能なクエリのタイプ ........................................................................................6-3
6.1.1
キャッシュ可能な式の例 ........................................................................................6-3
6.1.2
キャッシュ不可能なクエリの例 .............................................................................6-5
6.2
クエリ・キャッシュの適切サイズ ........................................................................................6-7
6.3
クエリ・プラン・キャッシングの統計情報 .........................................................................6-8
6.4
クエリ・プラン・キャッシング属性のデフォルト・テーブル設定 ...................................6-9
6.4.1
QUERYCACHE 関数 ............................................................................................6-11
6.4.2
QUERYCACHEENTRIES 関数 ............................................................................6-12
6.4.3
クエリ・プラン・キャッシング仮想テーブルに対するクエリ .........................6-14
6.4.4
DISPLAY_QC コマンドと DISPLAY_QC_ENTRIES コマンドを使用した、
クエリ・プラン・キャッシング統計情報の確認 ...............................................................6-16
第7章
演算子と演算子グループ
7.1
523728-001J
演算子グループと演算子の一覧 ............................................................................................7-2
7.1.1
CALL 演算子 ...........................................................................................................7-3
7.1.2
CURSOR_DELETE 演算子.....................................................................................7-5
7.1.3
CURSOR_UPDATE 演算子 ....................................................................................7-5
7.1.4
ESP_EXCHANGE 演算子 .......................................................................................7-6
7.1.5
EXPLAIN 演算子.....................................................................................................7-7
7.1.6
EXPR 演算子 ...........................................................................................................7-8
7.1.7
FILE_SCAN 演算子.................................................................................................7-8
7.1.8
FILE_SCAN_UNIQUE 演算子 .............................................................................7-10
7.1.9
HASH_GROUPBY 演算子 ....................................................................................7-11
7.1.10
HASH_PARTIAL_GROUPBY_LEAF 演算子 .....................................................7-12
7.1.11
HASH_PARTIAL_GROUPBY_ROOT 演算子 ....................................................7-13
7.1.12
HYBRID_HASH_ANTI_SEMI_JOIN 演算子 ......................................................7-14
7.1.13
HYBRID_HASH_JOIN 演算子 .............................................................................7-15
7.1.14
HYBRID_HASH_SEMI_JOIN 演算子 .................................................................7-16
7.1.15
INDEX_SCAN 演算子...........................................................................................7-17
7.1.16
INDEX_SCAN_UNIQUE 演算子 .........................................................................7-18
7.1.17
INSERT 演算子 ......................................................................................................7-20
7.1.18
INSERT_VSBB 演算子 .........................................................................................7-21
7.1.19
LEFT_HYBRID_HASH_JOIN 演算子 .................................................................7-21
v
目次
vi
7.1.20
LEFT_MERGE_JOIN 演算子 ............................................................................... 7-22
7.1.21
LEFT_NESTED_JOIN 演算子 ............................................................................. 7-23
7.1.22
LEFT_ORDERED_HASH_JOIN 演算子 ............................................................. 7-23
7.1.23
MATERIALIZE 演算子 ........................................................................................ 7-24
7.1.24
MERGE_ANTI_SEMI_JOIN 演算子 ................................................................... 7-26
7.1.25
MERGE_JOIN 演算子 .......................................................................................... 7-26
7.1.26
MERGE_SEMI_JOIN 演算子 ............................................................................... 7-27
7.1.27
MERGE_UNION 演算子 ...................................................................................... 7-28
7.1.28
NESTED_ANTI_SEMI_JOIN 演算子 .................................................................. 7-29
7.1.29
NESTED_JOIN 演算子 ......................................................................................... 7-30
7.1.30
NESTED_SEMI_JOIN 演算子 ............................................................................. 7-31
7.1.31
ORDERED_HASH_ANTI_SEMI_JOIN .............................................................. 7-31
7.1.32
ORDERED_HASH_JOIN 演算子......................................................................... 7-32
7.1.33
ORDERED_HASH_SEMI_JOIN 演算子 ............................................................. 7-33
7.1.34
PACK 演算子 ........................................................................................................ 7-35
7.1.35
PARTITION_ACCESS 演算子 ............................................................................. 7-36
7.1.36
ROOT 演算子 ........................................................................................................ 7-37
7.1.37
SAMPLE 演算子 ................................................................................................... 7-39
7.1.38
SEQUENCE 演算子 .............................................................................................. 7-39
7.1.39
SHORTCUT_SCALAR_AGGR 演算子 ............................................................... 7-40
7.1.40
SORT 演算子 ......................................................................................................... 7-40
7.1.41
SORT_GROUPBY 演算子 .................................................................................... 7-41
7.1.42
SORT_PARTIAL_AGGR_LEAF 演算子............................................................. 7-42
7.1.43
SORT_PARTIAL_AGGR_ROOT 演算子 ............................................................ 7-43
7.1.44
SORT_PARTIAL_GROUPBY_LEAF 演算子 ..................................................... 7-43
7.1.45
SORT_PARTIAL_GROUPBY_ROOT 演算子 .................................................... 7-44
7.1.46
SORT_SCALAR_AGGR 演算子 .......................................................................... 7-44
7.1.47
SPLIT_TOP 演算子 ............................................................................................... 7-45
7.1.48
SUBSET_DELETE 演算子 ................................................................................... 7-46
7.1.49
SUBSET_UPDATE 演算子 .................................................................................. 7-47
7.1.50
TRANSPOSE 演算子 ............................................................................................ 7-48
7.1.51
TUPLE_FLOW 演算子 ......................................................................................... 7-48
7.1.52
TUPLELIST 演算子 .............................................................................................. 7-49
7.1.53
UNIQUE_DELETE 演算子................................................................................... 7-49
7.1.54
UNIQUE_UPDATE 演算子 .................................................................................. 7-50
7.1.55
UNPACK 演算子................................................................................................... 7-52
7.1.56
VALUES 演算子 ................................................................................................... 7-53
523728-001J
目次
第8章
並列性
8.1
8.2
8.3
8.4
8.5
SQL/MX での並列性タイプ...................................................................................................8-2
8.1.1
パーティション化並列性 ........................................................................................8-2
8.1.2
パイプライン並列性 ................................................................................................8-2
8.1.3
独立並列性 ...............................................................................................................8-2
パラレル実行の原理 ...............................................................................................................8-3
8.2.1
データ・フロー・ツリーとしてのクエリ・プラン ..............................................8-3
8.2.2
Exchange ノードとプラン・フラグメント ............................................................8-3
8.2.3
DAM と ESP 並列性................................................................................................8-5
パラレル・プラン生成 ...........................................................................................................8-6
8.3.1
スキャン、更新、削除 ............................................................................................8-6
8.3.2
マッチング・パーティションによるジョイン ......................................................8-6
8.3.3
内部テーブルへのパラレル ・アクセスによるジョイン ......................................8-9
8.3.4
UNION ...................................................................................................................8-10
8.3.5
Group By ................................................................................................................8-11
8.3.6
ソート .....................................................................................................................8-11
8.3.7
挿入、選択 .............................................................................................................8-11
8.3.8
異なるタイプの並列性を結合する .......................................................................8-11
パラレル・プランの Explain ...............................................................................................8-12
8.4.1
パラレル・プランが使用されているかどうかの確認方法 .................................8-12
8.4.2
プラン・フラグメント ..........................................................................................8-15
8.4.3
並列度 .....................................................................................................................8-20
パラレル・プランに影響を与える ......................................................................................8-24
8.5.1
並列性に影響を与えるデフォルト設定 ...............................................................8-24
索引
523728-001J
vii
目次
viii
523728-001J
更新情報
更新情報
マニュアル情報
概要
本書は、クエリ実行プランを理解して、HP NonStop SQL/MX データベース用の最適なクエリを記述す
る方法を説明しています。本書は、SQL/MX を使用して SQL/MX データベースのクエリを実行し、クエ
リ・パフォーマンスの問題に特に興味のあるデータベース管理者およびアプリケーション開発者を対象と
しています。
製品バージョン
NonStop SQL/MX Release 2.0
対象となるリリース・バージョン・アップデート (RVU)
本書は次の版が発行されるまで、G06.23 およびそれ以降すべての G シリーズ RVU を対象とします。
マニュアル番号
523728-001
発行
2004 年 8 月
マニュアル履歴
マニュアル番号
製品バージョン
発行
429826-001
NonStop SQL/MX 1.0
March 2001
429856-001
NonStop SQL/MX 1.5
November 2001
522677-001
NonStop SQL/MX 1.8
November 2002
523728-001
NonStop SQL/MX 2.0
April 2004
523728-002
NonStop SQL/MX 2.0
August 2004
523728-001J
ix
更新情報
新規情報と変更内容
x
章
名前
新規情報と変更内容
第1章
1-5 ページの「クエ
リ・パフォーマンス
の向上」
OR 最適化に関する情報を追加。
第2章
2-5 ページの「フル・
テ ー ブ ル・ス キ ャ
ン」
フル・テーブル・スキャンの説明を訂正。
第4章
4-14
ページの
「Vi s u a l
Query
Planner の要件」
オンライン・トランザクション (OLT) 最適化に関する情報を
改訂。
VQP セッションの前にクエリ・キャッシングをオフにするた
めの注意を追加。
4-10 ページの「最適化のヒント」を改訂。
523728-001J
本書について
本書について
本書は、クエリの使用と記述方法、クエリ実行プランを理解する方法、NonStop SQL/MX データベース
のパフォーマンスに反映させる方法を説明しています。また、次の点についても説明しています。
□ クエリ・パフォーマンスを向上させる方法 □ SQL/MX オプティマイザがクエリ実行プランを選択する方法
□ オプティマイザのプラン選択に対し、影響を与える方法
対象読者
本書は、SQL/MX を使用して SQL/MX データベースにクエリを発行しクエリ・パフォーマンスの問題に
特に興味のある、データベース管理者とアプリケーション・プログラマを対象としています。読者は、デー
タベース管理システムのパフォーマンスに関する一般的な問題に精通し、リレーショナル・データベース
の理論や専門用語を理解しているデータ処理の専門家であることを前提としています。
また、オペレーティング・システム、および C/C++ や COBOL などのホスト・プログラミング言語に精
通している必要もあります。
523728-001J
xi
本書について
構成
章または付録
説明
第 1 章「クエリのコンパイルと実行」
SQL/MX コンパイラとエグゼキュータを説明しま
す。
第 2 章「SQL/MX データへのアクセス」
アクセス方法について説明します。
第 3 章「統計情報の更新」
統計情報の更新とヒストグラム統計について説明
します。
第 4 章「クエリ実行プランの確認」
クエリ実行プランをどのように理解するのかを説
明します。
第 5 章「実行プランの強制」
クエリ実行プランをどのように強制するかを説明
します。
第 6 章「クエリ・プラン・キャッシング」
クエリ・プラン・キャッシングがどのように動作
し、クエリ・プラン・キャッシングの統計情報をど
のように表示するのかを説明します。
第 7 章「演算子と演算子グループ」
クエリ実行プランで使用される演算子の一覧を示
します。
第 8 章「並列性」
SQL/MX の並列性を説明します。
本書で使用されている例は、SQL/MX 会話型インタフェース (MXCI) および Visual Query Planner で使
用されるような会話形式で表示されています。
xii
523728-001J
本書について
関連マニュアル
本書は、以下のマニュアルから構成される SQL/MX マニュアル・ライブラリの一部です。
入門ガイド
『NonStop SQL/MP ユ ー ザ の た め の
SQL/MX 比較ガイド』
SQL/MP と SQL/MX における SQL の違いについて説明していま
す。
『NonStop SQL/MX ク イ ッ ク・ス タ ー
ト』
SQL/MX 会話型インタフェース (MXCI) で SQL を使用するため
の基本的な技術について説明しています。また、サンプル・デー
タベースのインストール方法についても説明しています。
リファレンス・マニュアル
『NonStop SQL/MX リ フ ァ レ ン ス・マ
ニュアル』
SQL/MX ステートメントの構文、MXCI コマンド、関数、および
その他の SQL/MX 言語要素を説明しています。
『S Q L / M X C o n n e c t i v i t y S e r v i c e
Command Reference』
SQL/MX 会話型インタフェース (MXCI) で使用可能な SQL/MX
管理コマンド・ライブラリ (MACL) を説明しています。
『DataLoader/MX Reference Manual』
SQL/MX データベースをロードするツールである DataLoader/
MX の特徴と機能を説明しています。
『SQL/MX Messages Manual』
SQL/MX のメッセージを説明しています。
『SQL/MX Glossary』
SQL/MX の用語の定義しています。
プログラミング・マニュアル
『HP NonStop SQL/MX プ ロ グ ラ ミ ン
グ・マニュアル C および COBOL 言語
用』
SQL/MX ステートメントを ANSI C および COBOL プログラムに
埋め込む方法を説明しています。
『HP NonStop SQL/MX Programming
Manual for Java』
SQL/MX ステートメントを SQLJ 標準に準拠してJava プログラム
に埋め込む方法を説明しています。
523728-001J
xiii
本書について
専門ガイド
xiv
『SQL/MX Installation and Management
Guide』
SQL/MX データベースの計画、インストール、作成、および管理
の方法を説明しています。インストレーションおよび管理のコマ
ンドとユーティリティについて説明しています。
『NonStop SQL/MX クエリ・ガイド』
クエリ実行プランを理解して SQL/MX データベースの最適なク
エリを作成する方法を説明しています。
『SQL/MX Data Mining Guide』
知識発見プロセスを実行するための SQL/MX データ構造とオペ
レーションを説明しています。
『NonStop SQL/MX キューイングとパ
ブリッシュ / サブスクライブ・サービ
ス』
SQL/MX がトランザクション・キューとパブリッシュ /サブスク
ライブ・サービスをデータベース・インフラストラクチャの中に
どのように統合するかを説明します。
『SQL/MX Report Writer Guide』
NonStop SQL/MX データベースのデータを使用し、フォーマット
されたレポートを作成する方法を説明しています。
『S Q L / M X C o n n e c t i v i t y S e r v i c e
Manual』
SQL/MX Connectivity Service (MXCS) をインストールし管理す
る 方 法 を 説 明 し て い ま す。MXCS を 使 用 す る こ と に よ り、
Microsoft ODBC (Open Database Connectivity ) ア プ リ ケ ー シ ョ
ン・プログラミング・インタフェース (API) やその他の接続性を
提供する API 向けに開発されるアプリケーションが SQL/MX を
使用できるようになります。
『HP NonStop SQL/MX ストアド・プロ
シージャ・ガイド』
Java で記述されたストアド・プロシージャをSQL/MX で使用する
方法を説明しています。
523728-001J
本書について
オンライン・ヘルプ
SQL/MX オンライン・ヘルプは、以下で構成されています。
Reference Help
『NonStop SQL/MX リファレンス・マニュアル』の概要と参照項目
で構成されています。
Messages Help
『SQL/MX Messages Manual』のソース別にグループ分けされた
個々のメッセージで構成されています。
Glossary Help
『SQL/MX Glossary』の用語と定義で構成されています。
NSM/web Help
コンテキスト依存のヘルプトピックで、NSM/web 管理ツールの
使用方法を説明しています。
Visual Query Planner Help
コンテキスト依存のヘルプトピックで、Visual Query Planner グラ
フィカル・ユーザ・インタフェース の使用方法を説明します。
NSM/web アプリケーションと Visual Query Planner アプリケーションからは、それぞれに対応するヘル
プ・システムにアクセスできます。$SYSTEM.ZMXHELP サブボリュームまたは HP NonStop Technical
Library (NTL) から、Reference、Messages、および Glossary オンライン・ヘルプをダウンロードできます。
オンライン・ヘルプのダウンロードの詳細は、
『SQL/MX Installation and Management Guide』を参照してく
ださい。
以下のマニュアルは SQL/MP マニュアル・ライブラリの一部であり、SQL/MP データ定義言語 (DDL) の
情報および NonStop SQL/MP のインストールと管理に関する重要なリファレンス・マニュアルです。
関連する SQL/MP マニュアル
『NonStop SQL/MP Reference Manual』
SQL/MP の言語要素、式、述語、関数、ステートメントを説明し
ています。
『NonStop SQL/MP インストールと管
理ガイド』
SQL/MP データベースを計画、インストール、作成、管理する方
法、および SQL/MP のインストールと管理コマンド、SQL/MP カ
タログとファイルについて説明しています。
523728-001J
xv
本書について
次の図は、SQL/MX ライブラリのマニュアルを示します。
プログラミング・マニュアル
入門ガイド
NonStop
SQL/MP
ユーザのため
の NonStop
SQL/MX
比較ガイド
HP NonStop
SQL/MX プロ
グラミング・マ
ニュアル C お
よび COBOL
言語用
NonStop
SQL/MX
クイック・
スタート
HP NonStop
SQL/MX
Programming
Manual for
Java
リファレンス・マニュアル
NonStop
SQL/MX
リファレンス・
マニュアル
SQL/MX
Messages
Manual
SQL/MX
Connectivity
Service
Administrative
Command
Reference
SQL/MX
Glossary
DataLoader/MX
Reference
Manual
専門ガイド
SQL/MX
Installation
and
Management
Guide
NonStop
SQL/MX
クエリ・ガイド
SQL/MX
Data Mining
Guide
NonStop
SQL/MX
キューイングと
パブリッシュ /
サブスクライブ・
サービス
SQL/MX
Report
Writer
Guide
SQL/MX
Connectivity
Service
Manual
SQL/MX オンライン・ヘルプ
HP NonStop
SQL/MX Java
ストアド・
プロシージャ・
ガイド
Reference
Help
Messages
Help
Glossary
Help
NSM/web
Help
Visual Query
Planner Help
vst001.vsd
xvi
523728-001J
本書について
表記規約
構文の表記
以下のリストは、このマニュアルの構文上の表記規則をまとめたものです。
大文字
キーワードと予約語を示します。この項目は、表記どおりに正確に入力する必要があります。大カッコ
で囲まれていない項目は必須項目です。
MAXATTACH
斜体の小文字
ユーザ指定の変数項目を示します。大カッコで囲まれていない項目は必須です。
file-name
コンピュータ・タイプ
テキスト内のコンピュータ・タイプの文字は、C およびオープン・システム・サービス (OSS) のキーワー
ドと予約語を示します。この項目は表記どおりに正確に入力する必要があります。大カッコで囲まれてい
ない項目は必須です。
myfile.c
斜体のコンピュータ・タイプ
テキスト内の斜体のコンピュータ・タイプの文字 は、C およびオープン・システム・サービス (OSS) の
ユーザ指定の変数項目を示します。大カッコで囲まれていない項目は必須です。
pathname
[ ] 大カッコ
オプションの構文項目を囲みます。
TERM [\system-name.]$terminal-name
INT[ERRUPTS]
大カッコで囲んだ項目のリストは、そのリストから 1 つの項目を選択するか、何も選択しなくてもよい
ことを意味します。リスト内の項目については、各項目を大カッコで囲んで垂直に並べるか、リストを大
523728-001J
xvii
本書について
カッコで囲んで各項目を縦線で区切って水平に並べています。
FC [ num ]
[ -num ]
[ text ]
K [ X | D ] address
{ } 中カッコ
中カッコで囲んだ項目のリストは、選択できる項目のリストです。リスト内の 1 つの項目を選択する必
要があります。リスト内の項目については、各項目を中カッコで囲んで垂直に並べるか、リストを中カッ
コで囲んで各項目を縦線で区切って水平に並べています。
LISTOPENS PROCESS { $appl-mgr-name }
{ $process-name }
ALLOWSU { ON | OFF }
| 縦線
大カッコまたは中カッコで囲まれた項目を区切ります。
INSPECT { OFF | ON | SAVEABEND }
… 省略記号
大カッコまたは中カッコの直後の省略記号は、カッコ内の構文項目の並びを、任意の回数、繰り返せる
ことを示します。
M address [ , new-value ]…
[ - ] {0|1|2|3|4|5|6|7|8|9}…
1 つの構文項目の直後の省略記号は、その構文項目を任意の回数、繰り返せることを示します。
"s-char…"
区切り記号
カッコ、コンマ、セミコロン、およびその他の区切り記号は表記どおりに入力する必要があります。
error := NEXTFILENAME ( file-name ) ;
LISTOPENS SU $process-name.#su-name
大カッコや中カッコのような記号を囲む引用符は、その記号を表記どおりに入力する必要があることを
示します。
"[" repetition-constant-list "]"
xviii
523728-001J
本書について
項目間のスペース
項目がカッコやコンマのような区切り記号以外の場合、項目間にあるスペースは必須です。
CALL STEPMOM ( process-id ) ;
2 つの項目間にスペースが書かれていない場合は、スペースを入れることはできません。次の例では、ピ
リオドとそれ以外の項目の間にスペースを入れることはできません。
$process-name.#su-name
複数行にまたがる場合
コマンドの構文が長すぎて 1 行に収まらない場合、後続の各行は 3 つのスペースでインデントし、空白
行で区切ります。この空白行は、後続の行内の項目と、垂直に並んだ選択リスト内の項目とを区別します。
ALTER [ / OUT file-spec / ] LINE
[ , attribute-spec ]…
523728-001J
xix
本書について
xx
523728-001J
第 1 章 クエリのコンパイルと実行
この章では、クエリがどのようにコンパイルされ実行されるのかを説明します。この章は以下の内容を
扱います。
□ 1-2 ページの「コンパイラの動作」
□ 1-15 ページの「エグゼキュータによるプランの処理方法」
SQL/MX での SQL クエリのコンパイルと実行は、次の 2 つの基本手順で行われます。
1. SQL コンパイラがクエリを処理し、クエリ実行プランを実行する。
CONTROL QUERY SHAPE
ステートメント
クエリ
SQL コンパイラ
DEFAULTS
テーブル
クエリ実行プラン
メタデータ
(統計情報など)
VST110.vsd
2. エグゼキュータが実行プランを処理し、クエリの結果を生成する。
クエリ実行プラン
SQL エグゼキュータ
結果
VST120.vsd
ステップ 1 に示されているように、次の動作はクエリの最適化に影響を与えます。
□ CONTROL QUERY SHAPE ステートメントでプランを強制する
□ DEFAULTS テーブルでデフォルト設定を変更する
□ UPDATE STATISTICS ステートメントで統計情報を最新状態にする
□ インデックス、カラム、パーティションを追加または削除することで、データベースを変更する
詳細については、1-5 ページの「クエリ・パフォーマンスの向上」を参照してください。
523728-001J
1-1
第 1 章 クエリのコンパイルと実行
1.1
コンパイラの動作
クエリをコンパイルするには、クエリにリストされているテーブルおよびクエリ環境についての情報が
必要です。必要なテーブル情報は、SQL/MX カタログのスキーマ・メタデータ・テーブルにリストされて
います。クエリ環境情報は DEFAULTS テーブルの影響を受けます。デフォルトの詳細については、
『NonStop SQL/MX リファレンス・マニュアル』を参照してください。
1.1.1 コンパイル手順
SQL コンパイラは、いくつかの手順を踏んでクエリをコンパイルします。対応するコンパイラ・コン
ポーネントは、以下の手順を実行します。
パーサ (構文解析)
構文チェックを行い、
SQL/MX クエリを構文的に正しいクエリ・ツリーに変換する。
バインダ
(結合)
構文的に正しいクエリ・ツリーを取得し、論理 (ANSI) 名を物理名に変換して、
多くのセマンティック・チェックを実行する。また、クエリにリストされている
ビューを展開し、テーブル情報のメタデータを調べて、意味的に正しいクエリ・
ツリーを生成する。
ノーマライザ
(正規化)
意味的に正しいクエリ・ツリーを取得し、定数畳み込みやサブクエリ除外などの
特定の無条件変換を実行し、値の等価グループによる表現で等価式を認識する。
このような変換により、クエリ表現が最適化に適したものになる。この変換は、
コストベースではない。また、オプティマイザへの入力として、正規化されたク
エリ・ツリー (正規形式で意味的に正しいクエリ・ツリー ) が生成される。
オプティマイザ
(最適化)
正規化されたクエリ・ツリーを取得し、コストベースでルール指向のプランを多
数生成して、その中からクエリに最適な実行プランを選択できるようにする。そ
れぞれのプランごとにコストを計算し、最もコストの低いプランを最適なクエリ
実行プランとして選択する。
コードジェン
(コード生成)
適切なクエリ実行プランを取得し、エグゼキュータが実行可能なコードに変換す
る (1-15 ページの「エグゼキュータによるプランの処理方法」を参照)。
クエリは、内部的には 1 つの演算子ツリーとして表現されます。各手順では新たな情報が追加され、入
力ツリーが修正されます。最後の手順で作成されるツリーは、クエリ実行プランと呼ばれます。
1.1.2 構文解析、結合、正規化
構文解析、結合、正規化といったコンパイルの初期手順では、オプティマイザに渡すクエリを作成しま
す。クエリの最適化を開始する前に、パーサにより生成されたクエリ・ツリーがメタデータの情報と結合
されます。クエリの最適化に必要なデフォルト値に加えて、特定のクエリ処理命令が処理されます。デフォ
ルト設定が変更されている場合、パーサは、DEFAULTS テーブルから調整済みの値を読み取ります。すべ
てのサブクエリは、取り除かれるか、ジョインやセミ・ジョインに変換されます。また、特定の述語は書
き直され、最も早く評価されるようにプッシュ・ダウン (push down) されます。結合と標準化の手順では、
オプティマイザへの入力となる正規化クエリ・ツリーが生成されます。
1-2
523728-001J
第 1 章 クエリのコンパイルと実行
クエリの最適化
SQL/MX では、クエリを最適化するために最適化の方法をユニークに組み合わせて使用します。
分岐と境界プログラミング
この手法は、論理的な計算式の演算子ツリーから始めるトップダウン・アプローチで構成されます。論
理式 には実装を表さない関係演算子 (join、group by、scan など) が含まれます。最適化ルールを使用して、
オプティマイザはツリーの最上位演算子の実行方法を決定します。オプティマイザは、最上位演算子より
も下位の演算子に対して最適なソリューションを生成し、これらのソリューションを最上位ノードの実行
方法 (物理演算子) と組み合わせます。物理演算子とは、実際の実装またはランタイム・アルゴリズムを指
定する関係演算子 (merge join、hash group by、file scan など) のことです。
join
join
scan
scan
scan
VST011.vsd
最初に検出される実現可能なソリューションは、検出された時点でのコスト上限となります。コスト上
限を超えるソリューションはすぐに破棄され、オプティマイザはそのソリューションの構文をそれ以上解
析しないように記録します。オプティマイザにより検出されたその他のソリューションは検索スペースに
移動し、そこで検索メモリに保存されます。
最適化の原則
このストラテジでは、小さな問題に対するソリューションを結び付けることで、全体の問題に対する最
適なソリューションを形成します。
検索スペース 爆発の回避
オプティマイザは、クエリ・ツリーのノードごとにできるだけ多くのプランを試そうとします。その結
果、検索スペースが爆発する危険があります。検索スペースには、オプティマイザが検討するすべての可
能なプランが含まれます。等価式はグループに編成されます。規則の適用により 2 つの式のいずれか一方
の式がもう一方の式から派生する場合、この 2 つの式は同じグループになります。検索メモリを組織化す
ると、検索スペースを大幅に削減することができます。OPTIMIZATION_LEVEL 属性を設定すると、オプ
ティマイザがグローバルに最適なプランを検出するときに実行する最適化の量に影響を与えることができ
ます。OPTIMIZATION_LEVEL 属性の設定についての詳細は、第 4 章「クエリ実行プランの確認」を参照
してください。
523728-001J
1-3
第 1 章 クエリのコンパイルと実行
ルール・ベースのソリューション
オプティマイザは操作に関連するコストを確認するほかに、ルールも使用します。最適化ルールでは、
クエリ・ツリーまたはそのサブツリーの 1 つが、意味的に等価なクエリ・ツリーにどのように変換できる
かを定義します。これらのルールは、次のように論理式と物理式を区別します。
□ ソリューションを検出するためにオプティマイザが実行すること。変換ルールは、1 つの論理式を、意
味的に等価な別の論理式に変換するルールです。論理式にはこれらに関連するコストはなく、これら
の指定された物理プロパティすべてを持っているわけではありません。つまり、オプティマイザは指
示された演算子ツリーを使用するのではなく、別のツリーを作成します。たとえば、テーブル T1 と
テーブル T2 の join は、テーブル T2 とテーブル T1 の join に変換されたとき、等価な論理式を生成し
ます。
join
join
T2
T1
T1
T2
VST012.vsd
□ オプティマイザによるソリューションの検出方法。実装ルールは、論理式を、ルート・ノードが物理
演算子である意味的に等価な式に変換する規則です。実装ルールを再帰的に適用することで、物理演
算子のみで構成されるクエリ・ツリーが生成されます。このようなプランまたはサブプランには物理
プロパティがあり、これらのコストはオプティマイザで予測できるので、これらはエグゼキュータで
実行できます。実装ルール・フェーズでは、物理ノードを生成する初期のルールが改良されます。論
理演算子と物理演算子についての詳細は、第 5 章「実行プランの強制」を参照してください。
実装ルールでは、プランを決定することにより、1 つの問題を 1 つ以上の小さな問題に変換します。こ
のルールは、
「最適な部分ソリューションを結合して、全体の問題に対する最適なソリューションを形
成する」という最適化の原理に従っています。たとえば、次の実装ルールでは、A と B の join が A と
B の hash join に変換されています。最適化の原理では、A と B の最適なサブプランは、hash join を使
用するプランでも維持されます。
join
A
hash join
B
B
A
VST013.vsd
マルチパス最適化
オプティマイザは、マルチパス最適化手法をサポートすることで、コストベースのプルーニング (pruning)
を使用します。最適化前のパイロット・フェーズでは、予測ロー数に基づいて、テーブルを昇順に並べま
1-4
523728-001J
第 1 章 クエリのコンパイルと実行
す。つまり、大きいテーブルは最後にスキャンされます。最初のパスでは、(合理的なコストを持つ) 実行
可能なプランを生成する必要があるルールだけが使用されます。以降のパスでは、以前のパスで生成され
たコストをコスト上限として使用することが可能になり、よりコストベースのプルーニングが行われます。
このストラテジでは、より小さな検索スペースを展開しながら最適なプランを生成することにより、コン
パイル時間を短縮するという効果があります。
マルチパス最適化では、エラー回復も使用できます。2 番目以降のパスでエラーが発生すると、最初の
パスから生成されたプランが返されます。
1.1.3 クエリ・プラン・キャッシング
SQL/MX コンパイラは、特定のクエリのプランをキャッシュに格納することができます。このクエリ・
キャッシング機能は、類似したクエリが生成され、SQL のコンパイル時間が SQL の実行時間に比べて重
要な意味を持つ環境で使用すると有効です。
この機能は、完全にコンパイルしなくてもプランをキャッシュから生成できる場合に、コンパイラのパ
フォーマンスを向上させます。プラン・キャッシングの対象となるクエリには、単純な TP スタイルの
INSERT、UPDATE、DELETE、SELECT および JOIN があります。2 つのクエリは、その正規形式が同じ
であればキャッシング目的という観点では等価とみなされます。クエリ・キャッシングを可能にするには、
クエリの正規形式を次のようにします。
□ 意味のない余白文字の違いをなくす。
□ 意味のない大文字と小文字の違いをなくす。
□ SELECT リストでの「*」標記を展開する。
□ すべてのオブジェクト名を完全修飾名にする。
□ ほとんどの定数リテラルをパラメータに置き換える。
□ 現在の SQL/MX コンパイラ・セッションで以前に実行された CONTROL QUERY DEFAULT ステート
メントおよび CONTROL TABLE ステートメントをすべてエンコードする。
クエリ・キャッシングが有効な場合、SQL/MX はキャッシュ可能なステートメントのコンパイル済みプ
ランをキャッシュに格納します。等価のクエリが再発行されると、SQL コンパイルの大部分はスキップさ
れ、クエリ・プランはキャッシュから生成されます。クエリ・プランのキャッシング統計情報は、格納さ
れたプランの現在の状態と同様に、キャッシング手順に関する重要な情報を知るために使われます。
キャッシュ可能なクエリのタイプ、クエリ・プランのキャッシング統計情報、クエリ・キャッシングに
影響を与えるデフォルト設定については、第 6 章「クエリ・プラン・キャッシング」で説明します。
1.1.4 クエリ・パフォーマンスの向上
SQL コンパイラは、クエリに対して最も適したプランを生成するにあたって、一連の内部変換を実行し
ます。これらの変換については、この後で説明します。クエリ・パフォーマンスに影響を与えるために実
行できるアクションは、「クエリ・パフォーマンスへの影響」で説明します。
注． SQL コンパイラは、最大 12 個のテーブルの multitable join (複数テーブル join) に対する質の高いクエ
リ・プランを生成できるように機能が拡張されました。
523728-001J
1-5
第 1 章 クエリのコンパイルと実行
コンパイラによるクエリ処理
クエリの構文を解析することにより取得されるクエリ・ツリーでは、多くの変換が行われます。バイン
ダとコードジェン では比較的簡単な変更が行われ、より複雑な変換はノーマライザとオプティマイザで行
われます。
ノーマライザでは後続の最適化に対してより適したクエリ・ツリーを作成するために、無条件変換が適
用されます。主な変換を次に示します。
□ 無条件述語変換
□ サブクエリから join へ変換する
□ 述語をできるだけプッシュ・ダウン (push down) する
□「=」述語の transitive closure (推移的閉包) を計算し、これに基づいて述語要因を書き直す
□ クエリ・ツリーで、テーブルの正規再配列を行う
□ 定数を畳み込む (constant folding)
□ 構文的および意味的なソートを取り除く
オプティマイザでは、変換は条件付き、かつコスト・ベースで実行されます。また、これらの変換には
ルールも適用されます。1-4 ページの「ルール・ベースのソリューション」を参照してください。
クエリのパフォーマンスを向上させるためのさまざまなオプションが用意されています。その中には、
システムのデフォルトを変更する単純なものや、クエリ・プランを詳しく調べてよりよいクエリあるいは
クエリ・プランを作成する複雑なオプションもあります。
クエリ・パフォーマンスへの影響
次のいずれか 1 つ以上を行うことで、オンライン・トランザクション環境でのクエリのパフォーマンス
に影響を与えることができます。
□ インデックスの追加によるデータベースの拡大や修正。
□ クエリで使用するすべてのカラムに対して統計情報を追加することによる、テーブルの統計情報の精
度の向上。クエリが使用するすべてのカラムに対する統計情報が使用できるかどうかを確認する。詳
細については、第 3 章「統計情報の更新」を参照。
□ ユニークでない SELECT ... INTO クエリに対して FIRST 1 構文を使用する。
SELECT [FIRST 1] a INTO :hv ...
□ 可能な限り、読み取り専用の SELECT ステートメントを使用する。
CONTROL QUERY DEFAULT readonly_cursor 'TRUE'
□ NOT NULL の CAST ステートメントを使用する。
CAST(<value> AS <datatype> NOT NULL
□ CAST を使用すると、オプティマイザは通常インデックスを活用しなくなるためパフォーマンスに影
響する。可能であれば、CAST を使用しない式に書き換える。
1-6
523728-001J
第 1 章 クエリのコンパイルと実行
例として、ある特定の日 (2004-07-03) に発生したすべての取引を解析するための次の式を取り上げる。
WHERE ...
CAST (TRADE_DATE AS DATETIME YEAR TO DAY ) =
CAST '2004-07-03' AS DATEIME YEAR to DAY) ...
この CAST 式は、インデックスを使用するには汎用的すぎるため、オプティマイザが最も効果的なプ
ランを選択するのを妨げることになる可能性がある。この式をリテラルを使用するよう書き換えること
で、オプティマイザははるかに良いプランを選択できるようになる。
WHERE ...
TRADE_DATE BETWEEN DATETIME '2004-07-30:00:00:00.000000'
YEAR TO FRACTION AND DATETIME '2004-07-30:23:59:59.999999'
YEAR TO FRACTION ...
□ MXCMP コスト・モデルが正しく動作するようにするために、テーブルとインデックスに対して FUP
RELOAD を定期的に実行する。
□ CONTROL
QUERY
SHAPE
ユーティリティ、または
CONTROL
QUERY
DEFAULT
JOIN_ORDER_BY_USER によるプランの強制。詳細については、第 5 章「実行プランの強制」を参照。
□ 可能であれば、データベース・カラムとタイプが一致するホスト変数を使用する。次の 3 つの例では、
col は hvar とまったく同じタイプになっている。
z WHERE 述語での一致
SELECT a FROM t WHERE col = :hvar
z INSERT のソースとターゲットでの一致
INSERT INTO t(col) VALUES (:hvar)
z UPDATE での一致
UPDATE t SET col = :hvar ...
□ 別のデフォルト値の設定。デフォルト値は、コンパイル時と実行時の両方に影響を与える。パフォー
マンス関連のデフォルト値には、オプティマイザがクエリの最適化で使用するレベルを指示する
OPTIMIZATION_LEVEL がある。その他のデフォルト設定には、並列性に関連するデフォルト設定が
ある。すべてのデフォルト設定については、
『NonStop SQL/MX リファレンス・マニュアル』を参照。
□ パーティションの追加や削除は、パラレル・プランを取得するかどうかに影響を与える。パラレル・
プランの詳細については、第 8 章「並列性」を参照。
□ 可能な限り、除算の代わりに乗算を使用したクエリを使用する。たとえば、除算を使用している次の
クエリは、乗算を使用するように書き直すことができる。
-- 除算
SELECT A/10 FROM T WHERE B > C/100
-- 乗算に書き直し
SELECT A*0.1 FROM T WHERE B > C*0.01
□ プランが、「よくないプラン」すなわち最適でないクエリ・プランである疑いがある場合、コンパイラ
を調べる前に、コンパイラへの入力を確認する。
523728-001J
1-7
第 1 章 クエリのコンパイルと実行
オンライン・トランザクション (OLT) 最適化の有効化
OLTP アプリケーションのパフォーマンスに問題がある場合は、単一ローにアクセスするタイプのクエ
リで olt_optimization トークンが有効になっていることを確認します。olt 最適化を可能にする Control
Query Default は OLT_QUERY_OPT で、デフォルトでオンになっています。olt 最適化が実際に使用され
ているかどうかをチェックするには、DISPLAY EXPLAIN 出力の OLT_OPTIMIZATION: USED を探しま
す。
O L T 最 適 化 ト ー ク ン は、R O O T 演 算 子、P A R T I T I O N _ A C C E S S 演 算 子、D P 2 演 算 子
( I N D E X _ S C A N _ D E L E T E 、I N S E R T 、F I L E _ S C A N _ U N I Q U E 、U N I Q U E _ D E L E T E 、お よ び
UNIQUE_UPDATE) の 3 つのレベルで表されます。
DISPLAY_EXPLAIN オプション ‘f’ コマンドを使用すると、クエリの演算子を表示できます。次の例の
ように、OPT カラムが o という文字になっているエントリをチェックして、olt_optimization が有効になっ
ているかどうかを調べます。
LC
-2
1
.
RC
-.
.
.
OP
-3
2
1
OPERATOR
OPT
------------root
o
partition_access o
insert
o
DESCRIPTION
-----------r
T
CARD
------1.00E+0
1.00E+0
1.00E+0
注． DISPLAY_EXPLAIN オプション ‘f’ コマンドの使用方法に関する詳細は、
『NonStop SQL/MX リファ
レンス・マニュアル』を参照してください。
クエリが olt_optimization を使用するかどうかを決定するには、クエリ・タイプと演算子をチェックして
ください.
表 1-1 OLT の最適化で有効なクエリと演算子 (１ / ２)
1-8
クエリ
ROOT 演算子
PARTITION_ACCESS
演算子
DP2 演算子
ユニークな埋め込み UPDATE
有効
有効
有効
ユニークな埋め込み DELETE
有効
有効
有効
ユニークな埋め込み INSERT
有効
有効
有効
ユニークな埋め込み SELECT ...
into
有効
有効
有効
ユニークでない埋め込み
UPDATE
有効
有効
無効
ユニークでない埋め込み
DELETE
有効
有効
無効
値リストを伴う埋め込み
INSERT
有効
無効
有効
523728-001J
第 1 章 クエリのコンパイルと実行
表 1-1 OLT の最適化で有効なクエリと演算子 (２ / ２)
クエリ
ROOT 演算子
PARTITION_ACCESS
演算子
DP2 演算子
ユニークでない埋め込み
SELECT ... into
有効
無効
無効
動的 MXCI と ODBC クエリ
無効
埋め込みクエリと同じ点
に留意
埋め込みクエリ
と同じ点に留意
複合ステートメント
有効
DP2/DAM の 使 用 を 強 制
する場合のみ.
有効
ローセット
無効
無効
ユニークなアク
セスのみ
クエリが olt_optimization を使用しているにもかかわらずパフォーマンスに問題がある場合は、データ
ベースまたはクエリの設計方法がパフォーマンスに影響している可能性もあります。パフォーマンスに影
響を与えている可能性がある問題を特定するために役立つヒントとガイドラインについては、
『SQL/MX
Programming Manual for C 』、『SQL/MX Programming Manual for COBOL 』、『HP NonStop SQL/MX
Programming Manual for Java』、および『SQL/MX Installation and Management Guide』を参照してください。
述語での OR 演算子の使用
OR 演算子が含まれるクエリのサブセットを絞り込むために、SQL/MX では OR 最適化と呼ばれる機能
が使用されています。OR 最適化では、複数のアクセス・パスを使用してデータを取得します。多くの場
合、OR 最適化によってクエリの実行が飛躍的に速くなります。パーティション化されていない場合であっ
ても OR 最適化のメリットはありますが、テーブルがパーティション化されている場合の方が、さらに多
くのパフォーマンス上のメリットがあります。
注． SQL/MX の OR 最適化では、SQL/MP の同等の機能よりもさらに条件が限定されます。
OR 最適化とアプリケーション例
OR 最適化は、大規模なトランザクション・テーブルから数ローだけを要求するようなクエリにおいて有
効です。OR 最適化が有効となる例としては、大規模な SQL/MX テーブルに全世界の支店での預け入れと
引き出しの記録が格納されていて、その中から極端に金額が高い取引やある疑わしい支店からの取引といっ
た、ごく限られた件数の結果だけを探し出すクエリを実行する、金融/不正検出アプリケーションが考えら
れます。
MDAM と OR 最適化
OR 演算子に関連するもう 1 つの機能として、MDAM があります。MDAM は、OR 最適化の機能には
ない次の機能を提供します。
□ MDAM は、実行時に OR 述語の重複キー値を取り除く。この操作は、SQL/MX がどのテーブルにアク
セスするよりも前に行われるため、パフォーマンスに悪影響を与えることはない。
523728-001J
1-9
第 1 章 クエリのコンパイルと実行
□ MDAM は 1 つのクエリで複数テーブルを処理できる。nested join の内部テーブルと外部テーブル、お
よびソート・マージ、ハッシュ、キー順 merge join の外部テーブルに対して使用できる。
□ WHERE 句は、論理和の通常形式である必要はない。つまり WHERE 句 には OR 演算子の 2 つ以上の
レベルを含めることができる。
MDAM はデフォルトで有効です。
最適化された OR プランの選択
SQL は、次のすべての条件を満たす場合に最適化された OR プランを使用します。
□ OR 演算子で接続されている 2 つ以上の検索条件。
□ 各検索条件には、インデックスのキーとして使用される述語が含まれる。つまり、その述語にはイン
デックスのキー接頭辞に属するカラムを伴う。
□ 検索条件は、単純な OR 述語に限定される。
L_SUPPKEY = 2407 OR L_PARTKEY > 34567
OR 最適化を使用する実行プランでは、オプティマイザは nested join を用いたインデックス-キー検索に
加えてインデックス・オンリ・アクセスを検討します。ただし、インデックス・オンリ・アクセスは、ク
エリの中で参照されているすべてのカラムがそのインデックスに含まれている場合だけ可能です。インデッ
クス-キー検索は、多くの場合に nested join で実行されます。
PREPARE XXZ FROM SELECT * FROM LINEITEM
WHERE L_SUPPKEY = 2407 OR L_PARTKEY = 34567;
例 1-1 LINETINEM テーブルの LX1 インデックスと LX2 インデックスを使用する nested join の
EXPLAIN PLAN
1-10
LC
---
RC
---
OP
---
OPERATOR
--------
OPT
---
15
7
10
12
11
.
9
8
.
3
5
4
.
2
1
.
.
14
13
.
.
.
.
.
.
6
.
.
.
.
.
.
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
root
merge_union
nested_join
split_top
partition_access
file_scan_unique
split_top
partition_access
index_scan
fs
nested_join
split_top
partition_access
file_scan_unique
split_top
partition_access
index_scan
fs
DESCRIPTION
-----------
CARD
----
4.30E+1
1.70E+1
1.40E+1
1:4(logph)
3.49E-1
3.49E-1
fr ORCAT.LINEITEM(s) 3.49E-1
1:4(logph)
4.00E+1
4.00E+1
fr ORCAT.LX2(s)
4.00E+1
3.00E+0
1:4(logph)
1.00E+0
1.00E+0
fr ORCAT.LINEITEM(s) 1.00E+0
1:4(logph)
3.00E+0
3.00E+0
fr ORCAT.LX1(s)
3.00E+0
523728-001J
第 1 章 クエリのコンパイルと実行
追加インデックスによって、追加カラムに対する OR 最適化が可能になることがあります。
OR 最適化を使用しないプラン
一般的に、次の場合は OR 最適化は使用されません。
□ クエリに複数のテーブルが関連している。
□ 述語にあるカラムがキー接頭辞の一部ではない。
□ 少なくとも 1 つの単一述語、すなわち AND 演算子で結合された述語セットに非キー述語だけが含ま
れている。
□ 検索条件に AND 演算子が含まれている。
□ 少なくとも 1 つの単一述語、すなわち AND 演算子で結合された述語セットにキー述語でない任意の
述語が含まれている。
OR 最適化の例
これらの例に対する DDL については、1-13 ページの例1-1「OR 最適化の DDL」を参照してください。
プライマリ・キーは L_ORDERKEY + L_LINENUMBER で、L_PARTKEY (LX1) と L_SUPPKEY (LX2)
上にインデックスが設定されています。
テーブル LINEITEM に対するクエリにこれらの述語が含まれていると、OR 最適化が実行される可能性
があります。
WHERE ( L_PARTKEY = 200001 OR L_SUPPKEY = 10
OR 最適化は、最初の述語に対しては LX1 を使用したインデックス・アクセスを、2 番目の述語に対し
ては LX2 を使用したインデックス・アクセスを使用します。インデックスが存在しないと、SQL はテーブ
ルを順次に読み取ってクエリを満足するローを検索します。
単一インデックスと MDAM との間にもう 1 つ別のオプションがあります。テーブル LINEITEM は、カ
ラム (L_PARTKEY,L_SUPPKEY)、(L_SUPPKEY)、(L_LINESTATUS) 上に 3 つのインデックスが設定さ
れています。クエリは、これら 3 つのインデックスすべてを使用することも、最初の 2 つの論理和述語に
対しては MDAM を使用して最後の論理和述語に対してはインデックス L_LINESTATUS を使用すること
もできます。
SELECT * FROM LINEITEM
WHERE L_PARTKEY=10999765 OR L_SUPPKEY=19 OR L_LINESTATUS=30
OR 最適化が行われない例
□ OR 最適化が考慮されるためには、インデックスが存在している必要があります。テーブル LINEITEM
のセカンダリ・インデックスが L_PARTKEY カラムと L_SUPPKEY カラムに設定されている場合は、
次のクエリでは L_LINESTATUS カラムにインデックスが設定されていないために OR 最適化は検討
されません。
SELECT * FROM LINEITEM
WHERE L_PARTKEY=1099987 OR L_SUPPKEY=20 OR L_LINESTATUS='S'
523728-001J
1-11
第 1 章 クエリのコンパイルと実行
□ 次のような論理和述語と論理積述語の組み合わせでは、OR 最適化は行われません。
SELECT * FROM LINEITEM
WHERE L_PARTKEY=10998765 OR L_SUPPKEY=20
AND L_LINESTATUS='Y'
□ SQL/MX は SQL/MP とは異なり、テーブル LINEITEM にインデックス L_PARTKEY、L_PARTKEY、
L_SHIPINSTRUCT が存在する場合であっても、次のような種類のクエリでは OR 最適化を検討しませ
ん。
SELECT * FROM LINEITEM
WHERE(L_PARTKEY=10997965 AND L_SHIPINSTRUCT='SAIL')
OR L_SUPPKEY=20 AND L_SHIPMODE ='ANCH')
1-12
523728-001J
第 1 章 クエリのコンパイルと実行
例 1-2 OR 最適化の DDL
CREATE TABLE LINEITEM
(
L_ORDERKEY
INT NOT NULL
, L_PARTKEY
INT NOT NULL
, L_SUPPKEY
INT NOT NULL
, L_LINENUMBER
INT NOT NULL
, L_QUANTITY
NUMERIC(12, 2) not null
, L_EXTENDEDPRICE
NUMERIC(12, 2) NOT NULL
, L_DISCOUNT
NUMERIC(12, 2) NOT NULL
, L_TAX
NUMERIC(12, 2) NOT NULL
, L_RETURNFLAG
CHAR(1)
NOT NULL
, L_LINESTATUS
CHAR(1) NOT NULL
, L_SHIPDATE
DATE NOT NULL
, L_COMMITDATE
DATE NOT NULL
, L_RECEIPTDATE
DATE NOT NULL
, L_SHIPINSTRUCT
CHAR(25)
NOT NULL
, L_SHIPMODE
CHAR(10) NOT NULL
, L_COMMENT
VARCHAR(44) NOT NULL
, PRIMARY KEY (L_ORDERKEY ASC, L_LINENUMBER ASC)
)
organization key sequenced
catalog $data09.orcat
PARTITION (
$data08.orcat.lineitem
catalog $data09.orcat
FIRST KEY ( 100001),
$data07.orcat.lineitem
catalog $data09.orcat
FIRST KEY ( 200001),
$data06.orcat.lineitem
catalog $data09.orcat
FIRST KEY ( 300001)
)
;
CREATE INDEX LX1 ON LINEITEM
(
L_PARTKEY ASC
)
catalog $data09.orcat
partition ($data08.orcat.lx1 first key(100001),
$data07.orcat.lx1 first key (200001),
$data06.orcat.lx1 first key (300001));
ATTRIBUTES EXTENT (1024, 1024), MAXEXTENTS 512
;
CREATE INDEX LX2 ON LINEITEM
(
L_suppkey
)
catalog $data09.orcat
partition ($data08.orcat.lx2 first key(2500),
$data07.orcat.lx2 first key (5000),
$data06.orcat.lx2 first key (7500));
ATTRIBUTES EXTENT (1024, 1024), MAXEXTENTS 512
523728-001J
1-13
第 1 章 クエリのコンパイルと実行
コンパイル時間に影響を与える要因
□ join されるテーブルの数。これはクエリの複雑性を決定する上で最も重要な要因である。
□ group by、union、サブクエリの数など、その他のクエリ複雑性の要因。
□ クエリの述語数と述語でのカラム数。
□ インデックスの有無。新規アクセス・パスを考慮する必要があるほど複雑になる。
□ 統計情報の更新の有無と、ヒストグラムのインターバル数。
□ デフォルト設定 (第 4 章「クエリ実行プランの確認」参照)。特に OPTIMIZATION_LEVEL などの最適
化制御。
join の数は、コンパイル時間だけに影響を与える要因ではありません。たとえば、200 カラムあるテーブ
ルで 4 ウェイの natural join (自然結合) を行う場合、カラムが数個のテーブル間で 8 ウェイの star join (ス
ター結合) を行う場合よりもかなりの時間がかかります。
1-14
523728-001J
第 1 章 クエリのコンパイルと実行
1.2
エグゼキュータによるプランの処理方法
SQL/MX は、データ・フローとスケジューラ指向のタスク・モデルを使用してクエリを実行します。1
つのクエリが最適化された後、オプティマイザは最適化された実行可能なクエリ・プランを生成し、エグ
ゼキュータに送ります。エグゼキュータは、各演算子に対して 1 つのノードを作成します。
各演算子は独立したタスクであり、演算子間のデータは、メモリ内部のキュー ( アップ・キューとダウ
ン・キュー ) またはプロセス間通信により行き来します。キューのペアは、2 つの演算子間で動作します。
タスク間のキューにより、演算子は複数の要求や結果ローを同時に交換できます。スケジューラは入力
キューのいずれかにデータがある場合、タスクの実行を調整します。
タスク
Join
Scan
Group by
キュー
Scan
VST014.vsd
タスク・モデルでは、すべての内部操作が非同期で容易に実行できるため、1 つのサーバ・スレッドが
複数の未処理の入出力を持つことができます。このモデルはまた、共用メモリと分散メモリの両方のアー
キテクチャで並列性を可能にしています。メモリ内のキューは通信に使用され、Exchange 演算子は分散メ
モリに対して使用されます。
同時実行動作またはオーバラップする動作は、実行プランの異なるステージにまたがり、ロー上で実行
できます。たとえば、nested-loop join の左の子ノードが複数のローを生成するかまたは HP NonStop Data
Access Manager (DAM) プロセスからの応答を待機する一方、右の子ノードは左の子ノードですでに生成さ
れたローの上でマッチするものを取得できます。並列性の詳細については、第 8 章「並列性」を参照して
ください。
523728-001J
1-15
第 1 章 クエリのコンパイルと実行
1-16
523728-001J
第 2 章 SQL/MX データへのアクセス
アクセス方法は、キー順テーブルのデータおよびインデックスに対するアクセスにおいて、複数レベル
の効率性を提供します。この章では、SQL/MX が使用する様々なアクセス方法を説明します。
□ 2-2 ページの「アクセス方法」
□ 2-10 ページの「MultiDimensional Access Method (MDAM)」
523728-001J
2-1
第 2 章 SQL/MX データへのアクセス
2.1
アクセス方法
ここでは、SQL コンパイラが使用するアクセス方法を説明します。
□ ストレージ・キー・アクセス(Storage-key access)
□ インデックス・オンリ・アクセス (Index-only access)
□ 代替インデックス・アクセス (Alternate index access)
各アクセス方法とそれに伴うコストについては、次の項で説明します。キー順アクセスに対する代替策
の 1 つは、フル・テーブル・スキャンです。詳細については2-5 ページの「フル・テーブル・スキャン」を
参照してください。
2.1.1 ストレージ・キー・アクセス
ストレージ・キーとは、ディスクに格納されている実テーブルのローの物理的な順序のことです。この
キーは、テーブルで定義されているキーのタイプにより、プライマリ・キー、クラスタ化キー (clustering
key)、syskey にすることができます。
オプティマイザは、次のような場合にストレージ・キー・アクセスを選択します。
□ WHERE 句にストレージ・キー値が含まれている。
□ ストレージ・キー・アクセスの予測コストが、インデックス・オンリ・アクセスまたは代替インデッ
クス・アクセスの予測コストより低い。
次の図は、WHERE 句にストレージ・キー値 (empnum) が含まれているクエリの例です。エグゼキュー
タは、WHERE 句の情報で指示された値に直接移動し、ローを取り出します。図の右側には、このクエリ
から生成されたクエリ・プランが示されています。
employee テーブル
empnum
first_name
last_name
deptnum
jobcode
salary
93
ROOT
実テーブル
SELECT * From employee WHERE empnum = 93;
PARTITION_ACCESS
FILE_SCAN_UNIQUE
クエリ・プラン
VST021.vsd
2-2
523728-001J
第 2 章 SQL/MX データへのアクセス
ストレージ・キーの概算コスト
ストレージ・キーにより情報を取り出すときのコストは、アクセスする必要のあるデータ・ブロック数
により異なります。
2.1.2 インデックス・オンリ・アクセス
インデックス・オンリ・アクセスは、クエリを完全に満足するインデックスを参照し、実テーブルには
アクセスしません。つまり、クエリが参照するすべてのカラムはインデックスで見つけることができます。
順次アクセスの場合、インデックス・オンリ・スキャンは、実テーブルのストレージ・キー・アクセスよ
り優れています。インデックスのローのサイズは通常、実テーブルのローのサイズより非常に小さくなり
ます (そのため、物理 I/O ごとに取り出されるローが多くなります)。
インデックスには、1 つ以上のカラムと、クラスタ化キーを構成するカラムが含まれています。インデッ
クスが最大の効果を発揮するのは、クエリが必要とするすべてのカラムがそのインデックスに存在する場
合です。インデックスはスキャンのパフォーマンスを向上させることができますが、UPDATE、DELETE、
INSERT では非常に大きなコストがかかります。インデックスは通常、プライマリ・キー以外のキーにあ
るので、データへの代替アクセス・パスとなります。
オプティマイザは、次の条件が 1 つでも満たされた場合に、インデックスによるアクセスを選択する可
能性が高くなります。
□ SELECT 句と WHERE 句が、インデックスにあるカラムを参照している。
□ 実テーブルにアクセスするよりも低いコストで、すべての情報をインデックスから取り出すことがで
きる (インデックス・オンリ・スキャン)。
□ ORDER BY、GROUP BY、または DISTINCT が指定され、インデックスを使用することでこれらを満
たすことができる。
次の条件が 1 つでも満たされた場合、インデックス・オンリ・スキャンは使用されません。
□ クエリが必要とするカラムのうち、インデックスに含まれていないカラムがある場合。
□ クエリが更新を実行する場合。インデックスにそのカラムが含まれている場合でも、実テーブルのカ
ラム (およびその他のインデックスに含まれるカラム) も更新する必要がある。
次の図のクエリには、インデックス付きカラム (deptnum) が WHERE 句に含まれています。また、empnum
カラムもインデックス付き項目であり、クラスタ化キー値が含まれています (インデックスには、1 つ以上
のカラムに加えてクラスタ化キーを構成するカラムが含まれていることに注意してください)。コンパイラ
がインデックスに直接移動し、情報を取り出す理由は以下のとおりです。
□ フル・テーブル・スキャンを使用するよりコストが低いため。
□ クエリが、インデックスに含まれる情報を要求するため。
523728-001J
2-3
第 2 章 SQL/MX データへのアクセス
employee テーブル
empnum
first_name
last_name
deptnum
jobcode
salary
ROOT
PARTITION_ACCESS
実テーブル
SELECT empnum FROM employee
WHERE deptnum = 3100;
xempdept インデックス
deptnum
INDEX_SCAN
empnum
クエリ・プラン
3100
43
3100
93
3100
3100
3100
3100
3100
228
229
993
994
995
deptnum のインデックス
vst022.vsd
クエリ・プランは、インデックス・オンリ・アクセスを示します。
インデックス・オンリの概算コスト
インデックス・オンリ・アクセスの概算コストは、ストレージ・キー・アクセスとほぼ同じです。通常、
インデックス・テーブルは実テーブルより小さいので、コストが低くなることもあります。
2.1.3 代替インデックス・アクセス
代替インデックス・アクセスとは、プライマリ・インデックスを使用せずに行うアクセスのことです。
代替インデックス・アクセスでは、インデックスと実テーブル間 (インデックス―実テーブル・ジョイン)、
または 2 つのインデックス間 (インデックス―インデックス・ジョイン) でジョインが行われます。
インデックス・ローは、要求されたデータを示すことで位置が特定されます。インデックスに必要なデー
タがすべて揃っていない場合、必要なデータを用意するために、インデックスは実テーブルまたは他のイ
ンデックスとジョインされます。インデックスを使用して実テーブルにアクセスする場合、実テーブルの
ローは通常ランダムに読み取られ、これらのローを含むいくつかのブロックが複数回読み取られます。
次の図は、WHERE 句を満たすすべてのカラムを要求するクエリの例です。インデックスにはカラムの
サブセットだけが含まれているので、クエリ・プランは、インデックス (図の INDEX_SCAN 演算子) と実
テーブル (図のFILE_SCAN 演算子) をジョインする nested join を示します。WHERE 句を満たすローを取
り出すために、このインデックスと実テーブルとのジョインが行われます。
2-4
523728-001J
第 2 章 SQL/MX データへのアクセス
employee テーブル
empnum
first_name
last_name
deptnum
jobcode
salary
1
Roger
Green
9000
100
1755000.00
337
Dinah
Clark
9000
900
37000.00
実テーブル
ROOT
NESTED JOIN
SELECT * FROM employee
WHERE deptnum = 9000;
xempdept インデックス
deptnum
empnum
9000
9000
100
900
PARTITION_ACCESS
PARTITION_ACCESS
INDEX_SCAN
FILE_SCAN
クエリ・プラン
deptnum のインデックス
VST023.vsd
代替アクセスの概算コスト
代替インデックス・アクセスは、インデックスと実テーブル、または 2 つのインデックスのジョインに
依存するので、読み取るロー数によってはストレージ・キー・アクセスやインデックス・オンリ・アクセ
スの 2 倍以上のコストになります。
2.1.4 フル・テーブル・スキャン
フル・テーブル・スキャンでは、SQL は実テーブル全体をストレージ・キー順で最初の値から最後の値
まで読み取ります (必要な場合、テーブルを逆順に読み取ることもできます)。フル・テーブル・スキャン
は、パフォーマンスという点ではコストが非常にかかるものです。応答時間は、処理されるロー数または
ブロック数に正比例します。
次のような場合に、オプティマイザはテーブル全体をスキャンすることを選択します。
□ 処理するテーブルが小さい場合。
□ 適当なインデックスがない場合。
□ インデックスと対応する実テーブルのローを読み取る予測コストが、テーブル全体の読み取りコスト
を超えている場合。
523728-001J
2-5
第 2 章 SQL/MX データへのアクセス
テーブル・スキャンを回避するには、以下を実行します。
□ WHERE 句で、キー述語を確実に使用する。
□ 頻繁に使用されるクエリが必要とするカラムだけで構成される新しいインデックスを定義する。
□ MDAM を無効にしない。詳細については、2-10 ページの「MultiDimensional Access Method (MDAM)」
を参照。
フル・テーブル・スキャンを確認するには、EXPLAIN 関数を使用します。スキャン・ノードに対する
EXPLAIN の出力の中で開始キーと終了キーのエントリに各キー・カラムの最小値と最大値が含まれてい
る場合は、そのスキャンはテーブル全体を読み取っています。キー・カラムの最大値は、そのカラムのデー
タタイプによって異なります。
開始値
SELECT * FROM TABLE employee;
ROOT
PARTITION_ACCESS
FILE_SCAN
クエリ・プラン
終了値
employee テーブル
VST024.vsd
フル・テーブル・スキャンの概算コスト
フル・テーブル・スキャンは、他の方法よりはるかにコストがかかります。
2.1.5 予期しないアクセス・パス
オプティマイザによって選択されたアクセス・パスが、必ずしも適したものや予期したものであるとは
限りません。このような場合、以下を確認します。
□ 取り出す必要のあるカラムが原因でインデックス・オンリ・アクセスが不可能になったのかどうか。
□ 代替インデックスの使用を確認するために、ランダムに取り出す必要がある実テーブルのローが多す
ぎるのかどうか (2-7 ページの「WHERE 句による実テーブル・アクセスの指示」を参照)。
□ 対応するインデックスのない実テーブルのカラムを WHERE 句が参照しているかどうか。
□ インデックス・カラムを UPDATE する要求かどうか (2-7 ページの「コンパイラによる Halloween 更
新問題の回避方法」を参照)。
2-6
523728-001J
第 2 章 SQL/MX データへのアクセス
□ 他のアクセス・パスを使用するように、CONTROL QUERY SHAPE がコンパイラがに指示したのかど
うか。
WHERE 句による実テーブル・アクセスの指示
WHERE 句による制限により、十分にコストの低いアクセスが生成されず、代替インデックス・アクセ
スが使用されないことがあります。たとえば、全体の予測コストは、ストレージ・キー・アクセスよりも
代替インデックス・アクセスを使用した方が高くなることがあります。
コンパイラによる Halloween 更新問題の回避方法
カーソルまたはスタンドアロンの集合更新が代替インデックスの一部であるカラムに対して指定されて
いる場合、代替インデックスは無視されることがあります。代替インデックス・カラムを更新すると、現
在のローの位置に続く代替インデックス・ローが削除され、再挿入されることがあります。そしてその後、
この更新されたローは再び検出され、何度も更新されることがあります ( いわゆる Halloween 更新問題で
す。この問題が発見された休日の名前に由来します)。
たとえば、PRICE がインデックスの最初のカラムで、10% ずつ増加されるとします。このカラムを更新
すると、そのローは、オリジナルのロー位置の後に挿入されます。カーソルまたは集合更新を行うと、こ
のローが再び検出され、値が 10% 増加されます。
UPDATE クエリにインデックスを選択すると、実行時に終了しないクエリ・プランが生成されることが
あります。次のようなクエリを考えてみます。
UPDATE INVNTRY SET RETAIL_PRICE = RETAIL_PRICE * 1.1;
このクエリは、INVNTRY テーブルのすべての商品価格を 10% 増やします。RETAIL_PRICE にユニー
クではないインデックスがあり、更新前にはこのインデックスに次のローがあるとします。
RETAIL_PRICE
-----------10
40
また、RETAIL_PRICE のインデックスは、以下の述語を満たすローを要求するクエリのアクセス・プラ
ンの中で選択されたものであるとします。
RETAIL_PRICE > 20
SQL コンパイラは、RETAIL_PRICE カラムが 40 になっているローを検出し、44 に更新します。システ
ムが述語を満たす次のローを検索すると、同じロー (ただし、RETAIL_PRICE の値は 44) が検出されます。
このプロセスは永遠につづきます。
SQL コンパイラは、常にこのような更新状況を回避します。1 つの解決策としては、更新されるカラム
(上記の例の RETAIL_PRICE) のインデックスを無視して、アクセス・パスとして別のインデックスを選択
する方法がありますが、この方法では効率の悪いアクセス・パスが生成されます。しかし、そのインデッ
クスを使用することが適していれば、インスタンスは残ります。たとえば、RETAIL_PRICE のインデック
スは、次のクエリには適しています (RETAIL_PRICE が更新されるにしても)。
UPDATE INVNTRY
SET RETAIL_PRICE = 200
WHERE RETAIL_PRICE BETWEEN 300 AND 400;
523728-001J
2-7
第 2 章 SQL/MX データへのアクセス
INVNTRY テーブルに他のインデックスがなく、RETAIL_PRICE のインデックスが使用されない場合、
テーブル全体を読み取る必要があります。テーブルが大きければ、インデックスの使用によって効率はさ
らに高まります。
次のいずれかの場合、SQL は更新のスキャン操作に代替インデックスを使用します。
□ 代替インデックスに更新されるカラムが含まれていない場合。
□ スキャンが確実にユニークなアクセスである場合。この場合、コンパイラは同じローを何度も評価し
ません。
□ 更新されるすべてのカラムに対して、次のように、WHERE 句で等述語が使用されている場合。
UPDATE INVNTRY
SET RETAIL_PRICE = RETAIL_PRICE * 1.1
WHERE RETAIL_PRICE = 20 AND ITEM = 7;
ローは更新されるか、または前と同じ値に更新されます。前者の場合には選択条件は更新された新しい
ローには適用されず、後者の場合にはインデックス・ローは変更されません。
□ 次のように、SET 句の右側でカラムが参照されていない場合。
UPDATE INVNTRY
SET RETAIL_PRICE = 20
WHERE RETAIL_PRICE > 80 AND ITEM > 10;
カラムが定数に更新されるため、Halloween 更新問題は回避されます。
このような様々な更新問題は、新しく挿入されたインデックス・ローがクエリの検索条件を満たす場合
に発生します。この場合、一部のローが 2 回更新され、報告される更新ロー数が、検索条件を満たす実際
のロー数を超えることになります。
アクセス・パスの強制
CONTROL QUERY SHAPE ステートメントを使用して、クエリのアクセス・パスを強制することができ
ます。CONTROL QUERY SHAPE ステートメントは、すべての DML ステートメントに使用できます。
EXPLAIN の出力をチェックして、使用されるアクセス・パスが希望のパスであるかどうかを確認してく
ださい。アクセス・パスが希望のものでなければ、CONTROL QUERY SHAPE ステートメントでクエリ・
プランを強制することができます。第 5 章「実行プランの強制」の指示に従い、実行プランの新しいアク
セス・パスを指定します。
CONTROL QUERY SHAPE オプションのいずれかを使用すると有効であると思われる場合は、本番環境
のデータからの実際の統計情報を使用して、プランを強制した場合と強制しない場合とで、アプリケーショ
ンをチェックします。
オプションをいずれか 1 つ使用する場合は、次のような理由により、強制されたシェイプを後で変更す
ることがあります。
□ クエリが、将来作成される可能性のあるより効率的なインデックスを使用できない。
□ クエリが、将来の SQL への拡張を利用できない。
□ データベース構造を変更する場合 (インデックスの削除など)、オプションを使用していると再コンパ
イルする必要がある。
2-8
523728-001J
第 2 章 SQL/MX データへのアクセス
そのため、次の手段のうちの 1 つ以上を行うことにより、CONTROL QUERY SHAPE の検出と変更を容
易にします。
□ 強制されたシェイプが、目的のステートメントおよびテーブルだけに適用されるようにする。操作が
終了したらすぐに、強制されたシェイプをオフにする (CONTROL QUERY SHAPE OFF)。
□ 強制されたシェイプを独自のセクションに隔離し、インライン・アプリケーション・コードから実行
する。
□ 強制されたシェイプにより影響を受けるすべてのステートメントを個別のモジュールに置き、他のモ
ジュールでサービスと呼ばれる個別のモジュールに置く。
523728-001J
2-9
第 2 章 SQL/MX データへのアクセス
2.2
MultiDimensional Access Method (MDAM)
MultiDimensional Access Method (MDAM) を使用すると、述語にキー・カラムが含まれている場合に、
特定のタイプの情報への最適なアクセスが提供されます。MDAM は指定する述語に基づいてレコードの最
小集合を読み取り、キー順でローを取り出します。これにより、オプティマイザは可能であればソートを
回避し、merge join を行うことができます。キー述語がクエリに含まれ、そのキーの統計情報が存在する
場合は必ず、MDAM はオプティマイザによりコストがかけられます。MDAM を選択するかどうかは、そ
のアクセス・コストが単一のサブセット・アクセスより低いかどうかにより決まります。
MDAM の利点は以下のとおりです。
□ インデックスの節約。MDAM を使用すると、必要なインデックスの数が少ないので、余分なインデッ
クスに関連するメンテナンスやスペースを節約できる。
□ リソースの節約。
□ 以前はフル・テーブル・スキャンが必要であった状況で、パフォーマンスが向上する。
□ パフォーマンスを低下させずに、簡単にローをテーブルに追加できる。
2.2.1 MDAM の指定
MDAM は、デフォルトで有効になっています。有効であるとは、SQL/MX コンパイラがより質の高い
プランを作成できる場合に MDAM を選択できることを意味します。SQL/MX コンパイラには、MDAM に
影響を与える制御用の設定がいくつかあります。
□ CONTROL QUERY DEFAULT は、現行セッションに対するシステム全体のマスタ・スイッチとして
機能します。MDAM をオフまたはオンにすることや、無効になっている MDAM を有効にすることが
できます。
□ CONTROL QUERY SHAPE を使用すると、MDAM でカラムが使用されるよう強制でき、列挙アルゴ
リズムを強制することもできます。列挙アルゴリズムについては、2-15 ページの「DENSE アルゴリ
ズムと SPARSE アルゴリズム」を参照してください。
□ CONTROL TABLE を使用すると、現行プロセスあるいは特定のテーブルまたはインデックスに対す
る MDAM を制御することができます。* ( アスタリスク) オプションは、すべてのテーブルを指しま
す。CONTROL TABLE * MDAM ‘OFF‘ と指定すると、すべてのテーブルとインデックスに対して
MDAM が無効になります。CONTROL TABLE * MDAM ‘ON’ と指定した場合は、すべてのインデッ
クスとテーブルに対して MDAM アクセスのみが試みられます。
注．CONTROL TABLE tablename MDAM ‘OFF’ を使用しても、コンパイラは、そのテーブルのイン
デックスには MDAM を使用することがあります。
MDAM ではない方がクエリを効率よく実行できると判断できる場合だけ、MDAM をオフにしてくださ
い。
2-10
523728-001J
第 2 章 SQL/MX データへのアクセス
2.2.2 MDAM と単一サブセット・アクセスの比較
MDAM を使用しない場合、テーブルは単一サブセット・アクセス方式でアクセスされます。
開始値
単一サブセット・アクセス
要求されたロー
要求されたロー
終了値
テーブル T1
VST025.vsd
この図は、テーブル T1 での単一サブセット・アクセスを示しています。このテーブルの線は、クエリの
述語によりアクセスされるローを示しています。最初から最後までの全体の範囲がスキャンされ、要求さ
れるローが返される点に注意してください。要求されたローと次の要求されたローの間は、不要な情報が
含まれているローです。
単一サブセット・アクセス は、値の範囲、すなわち開始キーから終了キーまでの範囲をスキャンするの
で、開始キーと終了キーの間のすべてのローが読み取られるという特徴があります。単一サブセット・ア
クセスに必要なコストは、次のようにして求められます。
N 個のブロックの読み取りコスト
+ M 個の述語を R 個のレコードに適用するときのコスト
+ 渡されるレコードを移動するコスト
渡されるレコードを移動するコストは固定コストなので、変えることはできません。ただし、それ以外
のコストは改善することができます。
次の図に示すように、単一サブセット・アクセスのスキャンは、開始値から始まり、最後のローが読み
取られた終了値で終わります。N 個のブロックの読み取りコストを削減するには、ヒット率の高い一連の
より小さな範囲にテーブルを分割します。読み取るブロック数を減らすと、スキャンされるレコードも減
るので、述語をレコードに適用するときのコストも減らすことができます。
MDAM によるアクセスは、キー・カラム述語に基づいて行われ、テーブル内の一連のより小さい開始と
終了の範囲がアクセスされます。このシナリオでは、より多くのキーの位置決めが必要になります。
523728-001J
2-11
第 2 章 SQL/MX データへのアクセス
開始
要求されたロー
MDAM Access
終了
要求されていない
ロー
開始
終了
開始
終了
開始
終了
開始
終了
テーブル T1
VST26.vsd
MDAM では、開始キーと終了キーの範囲は実行時に判別されます。エグゼキュータは、オプティマイザ
が提供した情報を使用してキーを配置します。
MDAM アクセスのコストは、次に示す公式により決定されます。
N
+
+
+
個のブロックの読み取りコスト ( 範囲により処理 )
M 個の述語を R 個のレコードに適用するコスト
渡されたローを移動するコスト ( 固定コスト )
必要とされるキー位置の数
この公式は、あまり選択されないカラムに対して最も効果を発揮します (ユニーク・エントリ・カウント
(UEC) が低い = キー配置が少ない)。
2.2.3 MDAM によるクエリ処理
MDAM は、クエリの処理にあたって次のことを行います。
□ キー・カラムの先頭または中間に範囲述語 (range predicate) を適用する。
□ キー・カラムの先頭または中間に欠落述語 (missing predicate) を適用する。
□ 複数のキー・カラムで IN リストを処理する。
□ 一般的な OR 最適化を実行する。
□ 冗長である述語や矛盾する述語を取り除く。
□ 同じローを 2 度は読み取らない。
□ ソート順序を管理する。
2-12
523728-001J
第 2 章 SQL/MX データへのアクセス
範囲述語の介入
範囲述語の介入は、次のように、最初の述語の後にもう 1 つ別のキー・カラム述語が続くときに発生し
ます。
A > 5 AND B = 2
MDAM は、範囲が指定されたカラムの既存値のすべてを扱うことにより範囲述語を処理します。範囲外
のデータはディスクから読み取られず、処理されることはありません。
欠落キー述語
MDAM は、先頭または中間のキー・カラムに対して述語が指定されていない場合でも、キー順アクセス
のために後続のカラムを使用できます。MDAM は、読み飛ばされた (述語のない) カラムのユニーク・エ
ン ト リ・カ ウ ン ト (UEC) が 少 な い 場 合 に 最 も 効 率 的 で す。イ ン デ ッ ク ス に DEPT、SALES_DATE、
ITEM_CLASS、および STORE がこの順序で含まれている次のクエリを例として取り上げます。
SELECT SALES_DATE, SUM(TOTAL_SALES)
FROM SALES
WHERE SALES_DATE BETWEEN DATE'06/01/95' AND DATE'06/30/95'
AND ITEM_CLASS=20 AND STORE=250 GROUP BY DEPT, SALES_DATE;
最初のキー・カラム DEPT を使用している述語がないことに注意してください。MDAM を使用しない
と、コンパイラはこのクエリにフル・テーブル・スキャンを用いる必要があります。DEPT に対する述語
がないので、MDAM はその述語の範囲を、暗黙的に MIN_VALUE から MAX_VALUE (NULL 値を含む)
とします。これらの値は、そのキー・カラムのデータ・タイプがサポートしている最小値と最大値です。
OR 述語
MDAM は OR 演算子とともに機能し、次のことを行います。
□ 重複を回避する。
A IN (1, 2, 3, 2)
MDAM は 1、2、3 を読み取ります。最後の 2 は読み取られません。
□ WHERE 句は、論理和の通常形式である必要はない。つまり、WHERE 句には、OR 演算子の 2 つ以上
のレベルを含めることができる。
IN リスト
IN 述語は、IN 述語が一連の OR に変換された場合の結果と同等です。
COL1 IN (1, 2, 3)
この IN は次のように変換されます。
COL1 = 1 OR COL1 = 2 OR COL1 = 3
523728-001J
2-13
第 2 章 SQL/MX データへのアクセス
次のクエリを考察します。
SELECT * FROM T WHERE
((A = 4 AND B IN (2,5))
OR (A = 7 AND B IN (6,9)) ;
オプティマイザは、このクエリを以下のような述語の集まりに変換します。
(A
(A
(A
(A
=
=
=
=
4
4
7
7
AND
AND
AND
AND
B
B
B
B
=
=
=
=
2) OR
5) OR
6) OR
9)
冗長で矛盾する述語
MDAM は、他の述語と競合する述語を取り除きます。たとえば、次に示すクエリでは、述語が競合して
います。
SELECT * FROM T1
WHERE DIMENSION_2
BETWEEN 2 AND 3 AND DIMENSION_2=1;
MDAM は、これらの述語が競合すると認識し、これら両方を取り除きます。その結果、アクセスされる
テーブルはなくなります ( つまり、DIMENSION_2 は、1 および [2 ∼ 3] のいずれでもありません)。さら
に、実行時に MDAM は競合する述語を解決し、オーバラップする範囲と IN リストを単一の論理和述語に
まとめます。
重複ロー
MDAM は、読み取った後に重複を排除する操作をする必要がないようにするために、同じデータを 2 度
は読み取りません。MDAM は、オーバラップする論理和述語をまとめ、さらにそれをアクセスが重ならな
いように分割します。
ソート順序
MDAM は、アクセスされるインデックスの順序で取り出しを行います。この順序は、昇順または降順の
どちらでも可能です。MDAM では、並べ替え要件を満たし、クエリのソートを禁止するインデックスを逆
順に読み取る場合でも、インデックス順序を管理します。
2.2.4 オプティマイザが MDAM を選択しやすくする方法
インデックスを設計する際にキー・カラムの順番を考慮することで、オプティマイザがアクセス・パス
として MDAM を選択しやすくすることができます。
□ 先頭カラムに対して UPDATE STATISTICS を実行する。先頭カラムの UEC が増えるにつれ (また、ク
エリでこのカラムに対する述語がない場合)、テーブルへのシーク回数が増加する。先頭カラムの UEC
は、MDAM アクセスにおいて最も重要な要素である。
□ 最も頻繁にアクセスするカラムの順序で、キー・カラムを並べる。たとえば、部門番号を使用するク
エリを頻繁に実行する場合であれば、キー・カラム・インデックスに DEPTNUM カラムを含める。
2-14
523728-001J
第 2 章 SQL/MX データへのアクセス
た と え ば、EMPLOYEE テ ー ブ ル に、カ ラ ム STATE 、JOBCODE 、DEPTNUM、LAST_NAME 、
FIRST_NAME が含まれていて、JOBCODE、STATE、DEPTNUM に基づくクエリを頻繁に実行する場
合には、この順にカラムを並べます。
2.2.5 MDAM が使用するキー・カラム数の制御
通常、MDAM の処理で使用されるキー・カラム数を MDAM が選択できるようにすべきです。MDAM
が選択したキー・カラム数が、予測していたものより多い場合や少ない場合があります。このような場合
は、CONTROL QUERY SHAPE ステートメントで、MDAM が使用するキー・カラム数を MDAM に指定
することができます。MDAM CONTROL QUERY SHAPE の使用についての詳細は、第 5 章「実行プラン
の強制」を参照してください。
キーの 4 つのカラムに述語があり、ある述語で使用される 3 つ目のキー・カラムのユニーク・エントリ・
カウント (UEC) が決定されているとします (統計情報を更新したり、そのカラムの UEC を問い合わせたり
すると、UEC が分かります)。MDAM に、この 3 つ目のカラムの異なる値の一部だけを評価させたい場合
には、MDAM で使用されるカラム数を指定することができます。2 を指定すると、最初の 2 つのキー・カ
ラムの述語だけが使用されます。
0 以下のカラム数を指定すると、SQL からエラーが返されます。インデックスに使用できるキー・カラ
ム数を超える値を指定すると、オプティマイザは、各述語集合で MDAM が使用できる最大キー・カラム
数を使用します。キー・カラム数に SYSTEM を指定すると、MDAM がキー・カラム数を選択できるよう
になります。
2.2.6 DENSE アルゴリズムと SPARSE アルゴリズム
DENSE キー・カラムとは、そのカラムで可能なすべて (またはほとんどすべて) の値が含まれているカ
ラムのことです。あるカラムに 100 のユニークな値があり、そのカラムに含まれる値の範囲が 0 ∼ 99 の場
合、そのカラムは DENSE (密) であると見なされます。DENSE カラムであると認識されると、MDAM は
直前の値に 1 だけを加算して、そのカラムの次の値を検出します。
SPARSE キー・カラムとは、欠落値があるカラムです。カラムの実際の値の数がすべての可能な値の集
合より小さい場合、そのカラムは SPARSE (疎) であると見なされます。SPARSE カラムには、キー・カラ
ムに指定された範囲にすき間があります。オプティマイザは、カラムの UEC、および上限値と下限値を解
析することにより、これらのすき間を検出します。
コンパイラとエグゼキュータは、先頭キー・カラムにのみ適応性のある DENSE アルゴリズムと SPARSE
アルゴリズムを使用します。エグゼキュータは、コンパイラが選択したアルゴリズムに厳格に従わない場
合もあります。たとえば、オプティマイザが DENSE アルゴリズムを選択し、エグゼキュータがその DENSE
アルゴリズムはカラムのアクセスには効率的ではないと認識すると、エグゼキュータは、多くの値の欠落
を発見した段階で、適用するアルゴリズムを SPARSE アルゴリズムに切り替えます。エグゼキュータは、
データの疎密に応じて適切なアルゴリズムを選択します。
コンパイラが SPARSE アルゴリズムを選択すると、エグゼキュータは SPARSE アルゴリズムだけを使
用し、DENSE アルゴリズムに切り替えることはありません。
CONTROL QUERY SHAPE ステートメントで SPARSE オプションまたは DENSE オプションを指定す
ると、アルゴリズムの選択を強制できます。DENSE アルゴリズムを強制すると、エグゼキュータは適切な
DENSE または SPARSE を使用し、アクセスするカラムに対して選択されたアルゴリズムが効率的ではな
いと判断した場合には、アルゴリズムを切り替えます。SPARSE アルゴリズムを強制すると、エグゼキュー
523728-001J
2-15
第 2 章 SQL/MX データへのアクセス
タは SPARSE アルゴリズムだけを使用します。
次の図に示すテーブル A のカラム 1 には、常に 1 ずつ増加する値が含まれています。コンパイラが
MDAM DENSE を選択すると、エグゼキュータは DENSE で開始し、要求されている有益な情報ですき間
を検出すると SPARSE に切り替えます。SPARSE アルゴリズムでは、エグゼキュータはローを取り出して、
カラムの次の実際の値を決定します。コンパイラが SPARSE を選択した場合には、エグゼキュータは
DENSE を使用しません。
テーブル A、カラム 1
Dense
5
6
7
Sparse
Dense
15
16
17
18
19
VST027.vsd
2-16
523728-001J
第 3 章 統計情報の更新
統計情報を更新すると、ヒストグラム・テーブル内のテーブル情報が更新されて、その情報が、データ
ベースの現在の内容と構造をより正確に表すようになります。この章では、統計情報を更新すべき時期と
その理由について理解します。
UPDATE STATISTICS ステートメントは、ユーザが実行する必要があります。SQL/MX が統計情報を自
動的に更新することはありません。
□ 3-2 ページの「ヒストグラム統計情報」
□ 3-5 ページの「統計情報を更新する際の注意点」
□ 3-5 ページの「統計情報の更新により発生しうる影響の解析」
□ 3-6 ページの「サンプリングと UPDATE STATISTICS」
□ 3-8 ページの「UPDATE STATISTICS の結果のテスト」
523728-001J
3-1
第 3 章 統計情報の更新
3.1
ヒストグラム統計情報
ヒストグラムは、オプティマイザが複数のプランの違いを判断するにあたり、とても重要な情報です。
オプティマイザは、ヒストグラムを使用してクエリ実行プランの各演算子によって導き出されるロー数を
見積もり、プランの合計コストを計算します。そして、異なるいくつかのプランを比較して、最適なプラ
ンを見つけ出します。
最適なプランを得るには、クエリに関連するすべてのテーブル・カラム (つまり、述語、ジョイン、group
by、order by で使用されるすべてのカラム) に対する統計情報を更新しておくことが重要です。ただし、統
計情報を更新するコストをかけても、オプティマイザの精度が確実に上がる保証はないと判断できること
もあります。その場合には、ヒストグラムのデフォルト設定の定数を調整することができます。ヒストグ
ラムのデフォルト設定については、
『NonStop SQL/MX リファレンス・マニュアル』の「デフォルト・テー
ブル」を参照してください。
統計情報を更新すると、各カラムまたはカラムの集合に対してなど、カラムのグループまたは個々のカ
ラムのヒストグラム統計情報が収集されます。
□ テーブル内の現在のロー数
□ テーブル内のユニークなエントリ数
□ テーブル・カラムの最大値
□ テーブル・カラムの最小値
□ ヒストグラム内のインターバル数
□ 各インターバル内のユニーク・エントリ・カウント (UEC)
□ 各インターバル内のロー数
□ インターバル境界
ヒストグラム統計情報は、ON 句が指定された UPDATE STATISTICS ステートメントによって更新され
ます。ヒストグラム統計情報はユーザ・カタログに格納され、テーブル全体およびカラムについての情報
が HISTOGRAM と HISTOGRAM_INTERVALS に格納されます。ヒストグラム統計情報については、この
後の「ヒストグラム統計情報の更新」で説明します。
UPDATE STATISTICS ステートメントの構文、およびヒストグラム・テーブルについては、『NonStop
SQL/MX リファレンス・マニュアル』を参照してください。
注． テーブルとカラムに関する更新済みの統計情報が存在しないと、コンパイラはデフォルトの 統計情報
を使用します。コンパイラがデフォルトの統計情報を使用する場合、作成される実行プランは最適な
プランではないこともあります。統計情報が更新されていないと、コンパイラはファイル・ラベルの
ブロック・カウントを使用します。ただし、ブロック・カウントが 0 の場合には、コンパイラは
HIST_NO_STATS_ROWCOUNT 属性のデフォルト値を使用します。テーブルに含まれているローの
数がデフォルトの HIST_ROWCOUNT_REQUIRING_STATS で定義されている値より多く、関連する
カラムに対する統計情報が生成されていない場合には、コンパイラから警告が返されます。
3-2
523728-001J
第 3 章 統計情報の更新
3.1.1 ヒストグラム統計情報の更新
カラムまたはカラムのグループに対する統計情報を更新すると(ON 句を使用) 、SQL/MX はヒストグラ
ム統計情報を生成します。ヒストグラム統計情報によって、オプティマイザは効率的なアクセス・プラン
を作成することができます。
ヒストグラム統計情報は、2 つのテーブルに格納されます。これらのテーブルの名前と場所は、次のよ
うに、SQL/MX と SQL/MP のどちらを使用しているかによって異なります。
表 3-2 ヒストグラム一時テーブル
SQL/MX オブジェクト
SQL/MP オブジェクト
登録
テーブルと同じ catalog.schema に登録
される。
テーブルのプライマリ・パーティション
のカタログに登録される。
場所
テーブルと同じ catalog.schema に置か
れる。
プ ラ イ マ リ・パ ー テ ィ シ ョ ン と 同 じ
\node.$vol の ZZMXTEMP サブボリュー
ムに置かれる。
ファイル名
catalog.schema.
SQLMX_tablename
\node.$vol.ZZMXTEMP.tablename
サイズの制限
ファイルは常に Format 2 になり、1 TB
またはディスク・ボリュームの空きス
ペース容量がサイズの上限となる
実テーブルのプライマリ・パーティショ
ンのフォーマットによって、ファイル・
フォーマットが決まる。
Format 1: 一時テーブルの上限は 2 GB
Format 2: 一時テーブルの上限は 1 TB ま
たはディスク・ボリュームの空きスペー
ス容量のいずれか
表 3-3 ヒストグラム統計情報テーブル
SQL/MX オブジェクト
SQL/MP オブジェクト
登録
テーブルと同じ catalog.schema に登録
される。
テーブルのプライマリ・パーティション
のカタログに登録される。
場所
テーブルと同じ catalog.schema に置か
れる。
カタログと同じ\node.$vol.subvol に置か
れる。
ファイル名
catalog.schema.HISTOGRAMS
catalog.schema.
HISTOGRAM_INTERVALS
\node.$vol.subvol.HISTOGRM
\node.$vol.subvol.HISTINTS
HISTOGRAMS テーブルと HISTGRM テーブルには、ヒストグラムに固有のテーブルとカラムに関する
情報が格納されます。HISTOGRAM_INTERVAL テーブルと HISTINTS テーブルには、カラムまたはカラ
ムのグループのデータ分布に関するインターバル情報が格納されます。同じユーザ・テーブルに対して
UPDATE STATISTICS を再度実行すると、以前に生成されてヒストグラム・テーブルに格納されていた
データが新しいデータに置き換わります。
523728-001J
3-3
第 3 章 統計情報の更新
HISTOGRAMS テーブルと HISTGRM テーブルから、カラムまたはカラムのグループという観点でデー
タがどのように分布されているかがわかります。テーブルのヒストグラムを生成するときに、SQL/MX は
指定されたカラムの値を複数のインターバルに配分します。インターバルは、そのカラムの値の範囲を表
します。すべてのインターバルにテーブル内のローがほぼ均等に分布されるように、SQL/MX は各インター
バルに対する値の範囲を選択します。
たとえば、テーブルに 100 万ローがあり、UPDATE STATISTICS によってそのテーブルのあるカラムに
対して 20 個のインターバルを生成する場合、各インターバルは 50,000 ローとなります (これは、ヒストグ
ラム・インターバルへの「均等な」分布とも呼ばれます)。オプティマイザは各インターバルに対応する統
計情報を計算し、その統計情報を使用して最適なプランを算出します。
UPDATE STATISTICS に ON EVERY COLUMN 句を指定すると、テーブルの各カラムと、プライマリ・
キーおよびインデックスを構成する複数カラムがあれば、それに対する個別のヒストグラム統計情報が生
成されます。
あるテーブルに、カラム A、B、C、D、E があるとします。ON EVERY COLUMN オプションを使用す
ると、カラム A、B、C、D、E に対して、単一カラムのヒストグラムが生成されます。また、プライマリ・
キーやインデックスの定義によって、複数カラムのヒストグラムが生成されます。プライマリ・キーが A、
B、C に定義されていて、インデックスは定義されていない場合であれば、SQL/MX は (A、B、C) と (A、
B) の 2 つの複数カラム・ヒストグラムを生成します。次の例では、これと同じテーブルとカラムを使用し
て、プライマリ・キーと定義済みインデックスを基準にして複数カラム・ヒストグラムを生成しています。
テーブルには、カラム A、B、C、D、E があります。
例 1
キー (KEY): (A, B, C,) => (A, B, C), (A, B)
インデックス (INDEX): なし
=> なし
結果 (RESULT): (A, B, C), (A, B)
次の例 2 では、ユニークでないインデックス (E) が定義されているため、INDEX の末尾に KEY が追加
され、インデックスは INDEX+KEY となります。
例 2
キー (KEY): (A, B, C) => (A, B, C), (A, B)
インデックス (INDEX): (E) ユニークではない => (E, A, B, C), (E, A, B), (E, A)
結果 (RESULT): (A, B, C), (A, B), (E, A, B, C), (E, A, B), (E, A)
次の例 3 では、ユニークなインデックス (E) が定義されているため、INDEX の末尾に KEY は追加され
ません。インデックスは INDEX となります。このインデックスは単一カラムであるため、単一カラム・ヒ
ストグラムとしてのみ処理され、複数カラム・ヒストグラムは生成されません。
例 3
KEY: (A, B, C) => (A, B, C), (A, B)
INDEX: (E) ユニーク = > 複数カラム・ヒストグラムなし
RESULT: (A, B, C), (A, B)
テーブルを更新しても、そのテーブルの統計情報が格納されているヒストグラム・テーブルは自動的に
は更新されません。ヒストグラム統計情報を最新の状態に保つには、テーブルを大幅に更新した後に
UPDATE STATISTICS ステートメントを実行するようにしてください。
SQL/MX では、ヒストグラムをキャッシュに格納することにより、複雑性の低いクエリのコンパイル時
間を短縮します。ヒストグラムがキャッシュに格納されていれば、同じテーブルに対してそれ以降に実行
3-4
523728-001J
第 3 章 統計情報の更新
するクエリでは、ディスクからではなくキャッシュからヒストグラムを取得できます。ヒストグラムを
キャッシュに格納することで、より速くヒストグラムにアクセスできるようになります。
一部のヒストグラム・テーブルのデフォルト設定を変更することができます。詳細については、
『NonStop
SQL/MX リファレンス・マニュアル』の「デフォルト・テーブル」の項を参照してください。
統計情報を更新する際の注意点
統計情報の更新にあたっては、次の点を考慮してください。
□ サンプリングを使用して、統計情報の更新に必要な時間を短縮する。3-6
ページの「サンプリングと
UPDATE STATISTICS」を参照。
□ テーブルにデータがロードされた後にだけ、統計情報を更新する。
応答時間が短縮した場合に検討しなければならないパフォーマンスの注意点には、その他にも次のよう
なものがあります。
□ テーブルが存在するノード上で、長いアドホック・クエリあるいはレポートが原因で大量のディスク・
スペースが使用されている場合がある。
□ テーブルまたはインデックスが分散している場合、ネットワークが再経路指定されるあるいは使用率
が上昇している可能性がある。
□ 統計情報を更新しても、SQL/MX はプログラムを自動的には再コンパイルしない。
統計情報の更新により発生しうる影響の解析
テーブルのサイズによっては、統計情報の更新時間が予想より長くなる場合があります。したがって、
高パフォーマンスが要求される時を避けて統計情報を更新するようにしてください。
既存のクエリ実行プランを保持したい場合には、統計情報の更新によってオプティマイザが異なるプラ
ンを選択する可能性があることに注意してください。通常は、テーブルの統計情報を更新して現在の状態
を反映させれば、パフォーマンスを向上させることができます。ただし、次に示すように、統計情報を更
新してもパフォーマンスが改善されないこともあります。
□ 統計情報を判別するために、統計情報を更新してローのサンプリングを実行することができます。サ
ンプル・サイズによって異なりますが、この手順には時間がかかることがあります (つまり、サンプル
が大きいほど時間がかかります)。これは統計的なサンプリング手法なので、収集された統計情報は正
「サ
確ではありません。正確ではない (10% 以上異なる) 統計情報は、プランに悪影響を及ぼします。
ンプリングと UPDATE STATISTICS」を参照してください。
□ UPDATE STATISTICS ステートメントを使用してもプログラムは自動的に再コンパイルされないの
で、関連するプログラムは無効になりません。新しい統計情報を利用したい場合には、関連するプロ
グラムを明示的に再コンパイルする必要があります。
523728-001J
3-5
第 3 章 統計情報の更新
3.2
サンプリングと UPDATE STATISTICS
サンプリングを行うことで、統計情報の算出にかかる時間を制御できます。サンプリングを指定しない
と、テーブル全体をスキャンして統計情報が収集されます。オプションの SAMPLE 句には、比率に基づい
てヒストグラムを決定するためのサンプル・セットを生成するいくつかの方法があります。サンプリング
方法の詳細については、『NonStop SQL/MX リファレンス・マニュアル』を参照してください。
テーブル全体の統計情報の更新に必要となる時間を考えると、サンプリングを使用したいと考える場合
があるでしょう。サンプリング手法では大きなテーブル全体をスキャンすることはないため、パフォーマ
ンスの面で大きなメリットがあります。ロー数を指定せずに SAMPLE を使用することもできます。SQL/MX
は、デフォルトではテーブルの 2% (最大で 200 万ロー ) をサンプリングします。サンプル・サイズを明示
的に大きくすればより統計情報の精度を上げることができ、小さくすれば実行時間をより短縮できます。
UPDATE STATISTICS で SAMPLE オプションを使用すると、テーブルのプライマリ・パーティション
と同じボリュームに一時テーブルが作成されます。この一時テーブルはデータの収集と計算の目的で使用
されるため、システムには作業に十分なディスク・スペースが必要です。
更新するカラムのロー数をサンプリング・オプションで指定すると、効率が上がります。次のステート
メントで、EMPLOYEE テーブルの EMPNUM カラムのロー数を取得できます。
SELECT COUNT(*) FROM EMPLOYEE;
この SELECT COUNT (*) ステートメントから返された値 (125000) を、UPDATE STATISTICS ステート
メントの有効なロー・カウントとして指定できます。
UPDATE STATISTICS FOR TABLE EMPLOYEE ON (EMPNUM)
SAMPLE 5000 ROWS SET ROWCOUNT 125000
3.2.1 サンプリングにおけるパフォーマンスの問題と精度
他と比べてより精度の高い統計情報を作成できるサンプリング・オプションもありますが、精度が高け
ればパフォーマンス上でトレードオフがあります。サンプルの精度や質を上げる必要がある場合は、ラン
ダム・ロー・サンプリングを使用します。この方法では、サンプリングされた中間テーブルがスキャンさ
れ、各ローが n/100 (n はサンプルのパーセンテージ) の確率で選択されます。
ランダム・ロー・サンプリングより速い代替策はクラスタ・サンプリングです。この方法は、パフォー
マンスを優先する場合や、サンプルの質は十分に確保されている場合に使用するもので、統計情報が更新
されているテーブルの情報に基づくサンプリングです。
クラスタ・サンプリングでは、実際に結果セットの一部となるディスク・ブロックだけを読み取り処理
します。この方法では一般的にはサンプリングのパーセンテージが小さくなるので、他のサンプリング方
法と比べてパフォーマンスの点で大きなメリットがあります。たとえば、2 つのクエリがあり、1 つ目のク
エリではあるテーブルの 1 パーセントのローのサンプルが選択され、2 つ目のクエリでは同じテーブルの 1
パーセントがクラスタ・サンプリングで選択されるとします。クラスタ・サンプリングではこのテーブル
の約 1 パーセントだけを読み取って処理するのに対し、ロー・サンプリングではテーブル全体を読み取っ
て処理するため、クラスタ・サンプリングはランダム・ロー・サンプリングと比べて最大で 100 倍の速度
での処理が可能です。ただし、このパフォーマンスに対するトレードオフとして、ランダム・ロー・サン
プリングと比べると精度は低くなります。
3-6
523728-001J
第 3 章 統計情報の更新
これ以外に、PERIODIC のような他のサンプリング方法は、パフォーマンスあるいは精度の点でさらに
メリットがあるというわけではなく、特定の状況下で適したセマンティックスを提供します。PERIODIC
サンプリング (たとえば、10 ローごとに 1 ローを選択) が適しているのは、テーブルのあらゆる部分から統
計情報を計算することが重要である場合です。たとえば、テーブルがタイムスタンプの順に並んでいて、
カラムの値が時間の経過に伴って大きく変化するような場合には、PERIODIC サンプリングを使用するこ
とで、テーブル全体に均等に分布しているローから統計情報を計算することができます。
次のサンプリング・オプションでは、サンプル・セットの選択の前に、テーブル全体のスキャンを実行
します。
SAMPLE RANDOM x PERCENT
SAMPLE PERIODIC x ROWS EVERY y ROWS
次のサンプリング・オプションでは、サンプル・セットを決めるためにテーブル全体をスキャンするこ
とはありません。また、これらすべての例の精度は、SAMPLE RANDOM x PERCENT CLUSTER OF y
BLOCKS と同等です。
SAMPLE
SAMPLE r ROWS
SAMPLE SET ROWCOUNT c
SAMPLE r ROWS SET ROWCOUNT c
3.2.2 複数カラムの統計情報の収集
複数カラムのユニーク・エントリ・カウント (UEC) とは、カラムの組み合わせの UEC です。これは、カ
ラム集合のユニークな組み合わせの合計数です。複数カラムの UEC を使用するとオプティマイザはロー数
をより正確に予測することができるため、より適したプランが提供されます。特に、複数カラムの UEC を
使用すると、複数カラムをグループ化した結果のロー数と複数カラムのジョインした場合のロー数をオプ
ティマイザが予測します。
通常、グループ化に使用するカラム (JOBCODE と DEPTNUM など) の集合に複数カラムの統計情報が
ない場合、オプティマイザはそれらのカラムの UEC を掛け合わせて、結合した UEC を取得します。しか
し、この結果は実際の組み合わせ数よりはるかに大きな度数になります。ジョインと同様、2 つ以上のカ
ラムによってジョインされた 2 つのテーブルがある場合は、各テーブルのカラムをジョインした集合の複
数カラム・ヒストグラムは、よい結果がもたらします。
523728-001J
3-7
第 3 章 統計情報の更新
3.3
UPDATE STATISTICS の結果のテスト
統計情報を更新するとプランの質に大きな影響を与える可能性があるので、ヒストグラム・テーブルを
更新を決定する前に、この操作によってどのような利益があるのかを判別します。
3.3.1 SQL/MP テーブルの結果のテスト
次の手順に従って、統計情報の更新の結果を確認します。
1. アプリケーションからサンプル・クエリをプリペア (prepare) する (アプリケーションの中でよく使用さ
れるクエリを使用)。
2. EXPLAIN を使用して、クエリのコスト情報を取得する。
3. UPDATE STATISTICS ステートメントによる効果を判定して、必要に応じて生成されたヒストグラム
を取り消す。
a. 現行のヒストグラム・テーブルがあれば、SQLCI でバックアップを取得する。
SQLCI> DUP histogrm, myogrm;
SQLCI> DUP histints, myints;
b. MXCI から、必要とするカラム・グループに対して UPDATE STATISTICS コマンドを実行する。
c. MXCI で、クエリを再コンパイルする。
d. MXCI で、EXPLAIN を使用して、クエリのコスト情報を確認する。
e. 必要があれば、MXCI で UPDATE STATISTICS CLEAR オプションを使用して、不要なカラム・グ
ループのヒストグラムを削除する。
f. 必要があれば、バックアップしておいたヒストグラム・テーブルを MXCI でリストアする。
SQLCI> DROP TABLE histogrm;
SQLCI> DROP TABLE histints;
SQLCI> DUP myogrm, histogrm;
SQLCI> DUP myints, histints;
3.3.2 SQL/MX テーブルに対する結果のテスト
次の手順に従って、統計情報の更新の結果を確認します。
1. アプリケーションからサンプル・クエリをプリペア (prepare) する (アプリケーションの中でよく使用さ
れるクエリを使用)。
2. EXPLAIN を使用して、クエリのコスト情報を取得する。
3. UPDATE STATISTICS ステートメントによる効果を判定して、必要があれば生成されたヒストグラム
を取り消す。
3-8
523728-001J
第 3 章 統計情報の更新
a. 現行のヒストグラム・テーブルがあれば、MXCI でバックアップを取得する。
> CREATE TABLE myhist LIKE HISTOGRAMS;
> INSERT INTO myhist SELECT * FROM HISTOGRAMS;
> CREATE TABLE myhistint LIKE HISTOGRAM_INTERVALS;
> INSERT INTO myhistint SELECT * FROM HISTOGRAM_INTERVALS;
b. 必要とするカラム・グループに対して UPDATE STATISTICS コマンドを実行する。
c. クエリを再コンパイルする。
d. EXPLAIN を使用して、クエリのコスト情報を確認する。
e. 必要があれば、UPDATE STATISTICS CLEAR オプションを使用して、不要なカラム・グループの
ヒストグラムを削除する。
f. 必要があれば、バックアップしておいたヒストグラム・テーブルをリストアする。
> DELETE FROM HISTOGRAMS;
> INSERT INTO HISTOGRAMS SELECT * FROM myhist where table_uid in (select
object_uid from CAT.DEFINITION_SCHEMA_VERSION_1200.OBJECTS);
> DELETE FROM HISTOGRAM_INTERVALS;
> INSERT INTO HISTOGRAM_INTERVALS SELECT * FROM myhistint where
table_uid in (select object_uid from
CAT.DEFINITION_SCHEMA_VERSION_1200.OBJECTS);
523728-001J
3-9
第 3 章 統計情報の更新
3-10
523728-001J
第 4 章 クエリ実行プランの確認
この章では、クエリがどのように最適化されるのかを理解します。この知識は第 5 章「実行プランの強
制」で説明する実行プランの強制の決定にも利用します。
□ 4-2 ページの「EXPLAIN 関数の使用」
□ 4-5 ページの「実行プランの選択カラムの表示」
□ 4-8 ページの「実行プランの確認」
□ 4-10 ページの「最適化のヒント」
□ 4-13 ページの「DAM アクセスの検証」
□ 4-14 ページの「Visual Query Planner の使用」
□ 4-21 ページの「実行時統計情報の確認」
523728-001J
4-1
第 4 章 クエリ実行プランの確認
4.1
クエリ実行プランの表示
クエリ実行プランを表示するには、次のような方法があります。
□ EXPLAIN 関数を使用して、実行プランに関する情報の一部またはすべてのカラムを問い合わせ、表示
する。
□ DISPLAY_EXPLAIN ショートカットを使用して、実行プランに関する利用可能なすべての情報を表示
する。
□ Visual Query Planner グラフィカル・ユーザ・インタフェース (GUI) を使用して、SQL/MX オプティマ
イザが DML ステートメントに対して生成した実行プランを取得し、表示する。
EXPLAIN 関数または DISPLAY_EXPLAIN コマンドを使用して情報を表示すると、結果はマシン可読形
式で表示されます。これらの実行プランの結果をそのまま読んで理解することも可能ですが、Visual Query
Planner アプリケーションを使用すると、結果をより容易に確認することができます。
EXPLAIN 関数の使用
EXPLAIN 関数は、EXPLAIN テーブル値ストアド関数とも呼ばれ、SQL DML ステートメントに対する
実行プランについての情報を返します。EXPLAIN の出力情報を使用すると、次のような作業が可能にな
ります。
□ 選択された実行プランを確認する
□ 問題を特定し、クエリをチューニングする
□ オプティマイザが最適なプランを選択しているかどうかを判断する
EXPLAIN 関数を使用すると、実行プランに関する情報の一部またはすべてのカラムの問い合わせと表
示が可能です。
EXPLAIN 関数を使用すると、実行プランからカラムを選択して表示できます。
1. MXCI で、クエリをプリペア (prepare) する。
PREPARE FINDSAL FROM
SELECT FIRST_NAME, LAST_NAME FROM EMPLOYEE
WHERE SALARY > 40000.00;
2. EXPLAIN 関数を使用して、プリペアした FINDSAL ステートメントの実行プランからローを選択して
表示する。
SELECT SEQ_NUM, OPERATOR, TOTAL_COST
FROM TABLE (EXPLAIN (NULL, 'FINDSAL'));
このクエリの出力結果は以下のようになります。
4-2
523728-001J
第 4 章 クエリ実行プランの確認
SEQ_NUM
-----------
OPERATOR
---------------------------1 FILE_SCAN
2 PARTITION_ACCESS
3 ROOT
TOTAL_COST
-------------2.1645594E-002
2.1645594E-002
1.1964559E-001
--- 3 row(s) selected.
EXPLAIN 関数のすべてのカラムについては、4-4 ページの「EXPLAIN 関数の結果」を参照してください。
EXPLAIN 関数の詳細については、4-5 ページの「実行プランの選択カラムの表示」を参照してください。
4.1.1 DISPLAY_EXPLAIN ショートカットの使用
DISPLAY_EXPLAIN コマンドを使用すると、実行プランのすべてのカラムを表示できます。このコマ
ンドは EXPLAIN 関数のショートカットです。
MXCI で、DISPLAY_EXPLAIN と入力し、その後にクエリを続けて入力します。
DISPLAY_EXPLAIN
SELECT FIRST_NAME, LAST_NAME FROM EMPLOYEE
WHERE SALARY > 40000.00;
また、DISPLAY_EXPLAIN を使用して、プリペアしたクエリのプランを表示できます。
DISPLAY_EXPLAIN コマンドの詳細については、4-8 ページの「実行プランの確認」を参照してください。
4.1.2 Visual Query Planner の使用
1. 次のいずれかの手順を実行して、Visual Query Planner を開始します。
□ [スタート] - [プログラム] - [NonStop SQL-MX] - [Visual Query Planner] を選択する。
□ C:\Program Files\Hewlett Packard\NonStop SQL-MX フォルダを開き、[Visual Query Planner]を選
択する。
2. [Explain] - [Connect to ODBC] を選択して、ODBC Data Sourceに接続する。
SQL/MX 接続サービス (MXCS) への接続の詳細については、『SQL/MX Connectivity Services Manual』
を参照してください。
3. [Visual Query Planner] ウィンドウの上部ペインに、クエリを入力する。
4. [Explain] メニューから [Get Explain Plan] を選択して、クエリ実行プランを表示する。
クエリ実行プランの演算子ツリーが [Visual Query Planner] ウィンドウの左下のペインに表示されます。
演算子のサマリ詳細は、右下のペインに表示されます。各演算子の追加情報については、[Explain] メ
ニューから使用できる [Properties] ダイアログ・ボックスに表示されます。
Visual Query Planner の詳細については、4-14 ページの「Visual Query Planner の使用」を参照してくだ
さい。
523728-001J
4-3
第 4 章 クエリ実行プランの確認
4.1.3 オプティマイザとエグゼキュータ
オプティマイザは、クエリの演算子ツリーの各演算子に対して実行プランを作成します。コストとは、
あるプランの実行に必要となるリソースの予測値です。各演算子にはローカル・コストがあり、これは、
その演算子を実装するために選択されたアルゴリズムと、その演算子が入力として受け取る値に依存しま
す。ローカル・コストは、リーフ・ノード (葉ノード) に対するコストです。それ以降のローカル・コスト
は、そのノードのブランチ (枝) の累積コストになります。
実行プランは、最適なパフォーマンス・プランであると判別されるもの、つまり出力の最初のローまた
は最後のローを生成するための合計コストに基づき選択されます。合計コストは、ローカル・コストを累
計する多数の計算式を使って求められます。この計算式は、ツリーの各演算子の特性に依存します。
4.1.4 EXPLAIN 関数の結果
次の表は、EXPLAIN の結果テーブルのカラムと、そのカラムのデータ・タイプおよび説明をまとめた
ものです。
演算子ツリー は、クエリ実行プランで使用される演算子をノードとして表した構造体で、ツリーの各
ノードには最大で 1 つの親ノードがあり、また、ルート・ノードが 1 つだけあります。EXPLAIN 出力の
各ローは、ツリーの 1 ノードに対応します。演算子ツリーのノードは、プランの (演算子に関連する) イベ
ントを表します。各ノードには、従属ノードがある場合もあります。つまり、各イベントが、プランの中
に 1 つ以上の従属イベントを生成することがあります。演算子ツリーのグラフィカル表示については、4-
15 ページの図 4-2を参照してください。
4-4
カラム名
データ・
タイプ
MODULE_NAME
CHAR(60)
EXPLAIN 関数の引数で指定されたモジュール名。動的 SQL
ステートメント ( プリペアされたステートメント) の場合は
NULL。
STATEMENT_NAME
CHAR(60)
ワイルドカードを展開した後のステートメントの名前。60 文
字を超えると、右端が切り捨てられる。
PLAN_ID
LARGEINT
SQL により自動的に割り当てられたユニークなシステム生
成プラン ID。コンパイル時に生成される。
SEQ_NUM
INT
演算子ツリーの現在のノードのシーケンス番号。演算子ツ
リーでの生成順序を示す。
説明
523728-001J
第 4 章 クエリ実行プランの確認
カラム名
データ・
タイプ
OPERATOR
CHAR(30)
現在のノードのタイプ。すべての有効な演算子タイプの一覧
は、第 7 章「演算子と演算子グループ」を参照。
LEFT_CHILD_
SEQ_NUM
INT
現在のノード (すなわち演算子) の最初の子演算子のシーケン
ス番号。ノードに子演算子がない場合は NULL。
RIGHT_CHILD_
SEQ_NUM
INT
現在のノード (すなわち演算子) の 2 番目の子演算子のシーケ
ンス番号。ノードに 2 番目の子演算子がない場合は NULL。
TNAME
CHAR(60)
スキャン・グループの演算子に関する、実テーブルの完全な
名前。名前がカラムに対して長すぎると、右端が切り捨てら
れる。相関名がテーブル名と異なる場合は、単純な相関名と
カッコで囲まれたテーブル名。
CARDINALITY
REAL
現在のノードから返される予測ロー数。
OPERATOR_COST
REAL
現在のノードによる演算子の実行に関連する予測コスト。
説明
例: 6.8702000E+04
TOTAL_COST
REAL
現在のノードによる演算子の実行に関連する予測コストで、
演算子ツリーのすべてのサブツリーのコストを含む。
例: 6.8702000E+04
DETAIL_COST
VARCHAR
(200)
トークン化コスト・ベクトル。各コスト項目の説明は、下の
表を参照。
DESCRIPTION
VARCHAR
(3000)
トークン・ペアのストリーム形式で表示される操作に関する
追加情報。すべての演算子のトークンに関する詳細は、第 7
章「演算子と演算子グループ」を参照。
EXPLAIN 関数の結果の DETAIL_COST カラムには、次のコスト要因が含まれます。
523728-001J
CPU_TIME
このノードに対する命令の実行に要する予測 CPU 時間 (秒)。1.0 は 1 秒を表す。
IO_TIME
このノードに対する I/O (シーク時間 + データ転送) に要する予測 I/O 時間 (秒)。
MSG_TIME
このノードに対するメッセージングに要する予測秒数。ローカルとリモートの
メッセージ数とデータ送信量に関する時間を含む。
IDLETIME
イベント発生を待機する予測秒数。テーブルのオープンまたは ESP プロセスの
開始に要する時間を含む。
PROBES
演算子が実行される回数。この値は通常は 1 だが、たとえば nested loop join の
内部スキャンがある場合のように、1 より大きくなることがある。
4-5
第 4 章 クエリ実行プランの確認
4.1.5 実行プランの選択カラムの表示
次に示すクエリ実行プランは、PERSNL スキーマを使用して EMPLOYEE テーブルにクエリを発行する
簡単な例です。
PREPARE s1 FROM SELECT LAST_NAME, FIRST_NAME, SALARY
FROM EMPLOYEE ORDER BY SALARY;
次に示すクエリは、EXPLAIN 関数の結果から、カラム SEQ_NUM、OPERATOR、TOTAL_COST、お
よび DESCRIPTION を抽出します。
SELECT SEQ_NUM, OPERATOR, TOTAL_COST, DESCRIPTION
FROM TABLE (EXPLAIN (NULL, 'S1'));
次の出力は、実際の結果を見やすい形式に変更されています。EXPLAIN 関数と DISPLAY_EXPLAIN
は、アプリケーション・プログラムからのアクセスを考慮して、マシン可読形式を使用しています。
1 FILE_SCAN
2.1645594E-002
key_columns: indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.EMPNUM)
begin_key: (indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.EMPNUM) = 0)
end_key: (indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.EMPNUM) = 65535)
scan_type: file_scan SAMDBCAT.PERSNL.EMPLOYEE
scan_direction: forward
key_type: simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 6
fast_scan: used
fast_replydata_move: used
2 PARTITION_ACCESS
buffer_size: 31000
record_length: 44
2.1645594E-002
3 SORT
1.4924493E-001
sort_key: indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.SALARY)
4 ROOT
2.4726971E-001
select_list: indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.LAST_NAME),
indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.FIRST_NAME),
indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.SALARY)
order_by: indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.SALARY)
statement_index: 0
statement: select last_name, first_name, salary from employee order by
salary;
このプランには、FILE_SCAN、PARTITION_ACCESS、SORT、ROOT の 4 つのノード (演算子) が表示
されています。演算子の一覧は、第 7 章「演算子と演算子グループ」に掲載されています。
4-6
523728-001J
第 4 章 クエリ実行プランの確認
このクエリでは、フル・テーブル・スキャン (FILE_SCAN) が必要となります。これは、すべての
EMPLOYEE (従業員) を選択するためであり、従業員の名前を SALARY (給料) の順に並べるための SORT
が必要になるためです。
4 つのローが選択されています。EXPLAIN 関数はクエリの評価に使用する演算子ごとに 1 つのローを返
します。
Description フィールドに表示されている情報が演算子ごとに異なる点に注意してください。FILE_SCAN
ノードには、スキャン・タイプと入力ファイル名、開始キーと終了キー、スキャン方向、およびその他の
指定していないファイル・アクセス情報が表示されています。SORT ノードには、ソート・キーが表示さ
れています。ROOT ノードには、SELECT ステートメント・リストのすべてのカラム、出力カラムごとの
順序、SQL ステートメントが表示されています。各演算子の説明カラムの詳細については、第 7 章「演算
子と演算子グループ」を参照してください。
4.1.6 埋め込み SQL プログラムからの EXPLAIN 出力の抽出
EXPLAIN 出力は埋め込み SQL プログラムから簡単に抽出できます。モジュール名を必ず指定してくだ
さい。モジュール名は MODULE 句を使用してプログラム自身で指定できます。そうでない場合には、モ
ジュール定義ファイルでモジュール名を確認します。たとえば、埋め込みプログラムのモジュール名が
MYCAT.MYSCH.MYMOD であると仮定します。
プログラムに複数のステートメントが含まれている場合、次のクエリは、モジュールに含まれるすべて
のステートメントをモジュール内での出現順に表示します。
SELECT * FROM TABLE (EXPLAIN('MYCAT.MYSCH.MYMOD', '%'));
EXPLAIN 出力は、プログラムがコンパイルされていればいつでも確認でき、コンパイル時に実際に選
択されたプランが表示されます。この EXPLAIN の 2 番目の引数は STATEMENT-NAME カラムに対して
使用される LIKE パターンであることに注意してください。
523728-001J
4-7
第 4 章 クエリ実行プランの確認
4.2
実行プランの確認
4.2.1 DISPLAY_EXPLAIN コマンドの使用
次の DISPLAY_EXPLAIN コマンドの例は、述語を使用しているクエリの実行プランの情報を表示して
います。DISPLAY_EXPLAIN は、実行プランのカラムをすべて表示します。
>>DISPLAY_EXPLAIN
+>SELECT last_name, first_name, salary
+>FROM employee WHERE
+>salary > 40000.00 AND jobcode=450;
DISPLAY_EXPLAIN コマンドを使用する場合は、ページ送りをして出力全体を参照してください。
MODULE_NAME
STATEMENT_NAME
PLAN_ID
SEQ_NUM
OPERATOR
RIGHT_CHILD_SEQ_NUM TNAME
CARDINALITY
OPERATOR_COST
DESCRIPTION
LEFT_CHILD_SEQ_NUM
TOTAL_COST
DETAIL_COST
------------------------------------------------------------------------------- ----------- ------------------------?
EXPL_NAME__
211895497594099975
1 FILE_SCAN
?
? SAMDBCAT.PERSNL.EMPLOYEE
2.0000000E+000
2.1645594E-002
2.1645594E-002
CPU_TIME: 0.00097 IO_TIME: 0.021646 MSG_TIME: 0 IDLETIME: 0
PROBES: 1
key_columns: indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.EMPNUM)
executor_predicates: (indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.SALARY) >
40000.00) and (indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.JOBCODE) = 450)
begin_key: (indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.EMPNUM) = 0) end_key:
(indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.EMPNUM) = 65535) scan_type: file_scan
SAMDBCAT.PERSNL.EMPLOYEE
scan_direction: forward
key_type: simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 6
fast_scan: used
fast_replydata_move: used
?
EXPL_NAME__
211895497594099975
2 PARTITION_ACCESS
1
?
2.0000000E+000
2.0422223E-003
2.1645594E-002
CPU_TIME: 0.003012 IO_TIME: 0.021646 MSG_TIME: 0 IDLETIME: 0
PROBES: 1
4-8
523728-001J
第 4 章 クエリ実行プランの確認
buffer_size: 31000
record_length: 44
?
EXPL_NAME__
211895497594099975
3 ROOT
2
?
2.0000000E+000
9.8000794E-002
1.1964559E-001 CPU_TIME: 0.003013
CPU_TIME: 0.003013 IO_TIME: 0.021646 MSG_TIME: 0 IDLETIME: 0.098 PROBES: 1
select_list: indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.LAST_NAME),
indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.FIRST_NAME),
indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.SALARY)
statement_index: 0
statement: select last_name, first_name, salary from employee where salary >
40000.00 and jobcode=450;
--- SQL operation complete.
次に示す FILE_SCAN 演算子の出力は、見やすい形式に変換されています。
523728-001J
カラム名
DISPLAY_EXPLAIN 出力
MODULE_NAME
Null
STATEMENT_NAME
__EXPL_NAME
PLAN_ID
211860929109200668
SEQ_NUM
1
OPERATOR
FILE_SCAN
LEFT_CHILD_
SEQ_NUM
Null
RIGHT_CHILD_
SEQ_NUM
Null
TNAME
SAMDBCAT.PERSNL.EMPLOYEE
CARDINALITY
2.4783301E+000
OPERATOR_COST
2.0646531E-002
4-9
第 4 章 クエリ実行プランの確認
カラム名
DISPLAY_EXPLAIN 出力
TOTAL_COST
2.0646531E-002
DETAIL_COST
CPU_TIME: 0.000327 IO_TIME: 0.020647 MSG_TIME: 0
IDLETIME: 0 PROBES: 1
DESCRIPTION
key_columns: indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.
EMPNUM)
executor_predicates:
(indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.
SALARY) > 40000.00) and
(indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.
JOBCODE) = 450)
begin_key: (indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.
EMPNUM) = 0)
end_key: (indexcol(\MYSYS.$SAMDB.PERSNL.EMPLOYEE.
EMPNUM) = 65535)
scan_type: file_scan SAMDBCAT.PERSNL.EMPLOYEE
scan_direction: forward
key_type: simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 6
fast_scan: used
fast_replydata_move: used
最適化のヒント
SQL/MX は、数百の属性に対してシステム定義のデフォルト設定を使用しています。これらの設定のほ
とんどは、予め適切に調整されていますが、いくつかの属性は変更が可能です。
システム・カタログの DEFAULTS テーブルにある外部属性のデフォルト設定を変更することができま
す。これらのシステム・デフォルト設定は、
NONSTOP_SQLMX_<systemname>.SYSTEM_DEFAULTS_SCHEMA.SYSTEM_DEFAULTS テーブルに
格納されています。CONTROL QUERY DEFAULT コマンドを使用すると、プロセス単位にこれらの値を
変更できます。外部属性の一覧、およびコマンドの優先順序とデフォルト設定の指定方法については、
『NonStop SQL/MX リファレンス・マニュアル』を参照してください。
以下の節では、最適化関連のいくつかの外部属性を取り上げます。各属性に関する情報は、『NonStop
SQL/MX リファレンス・マニュアル』を参照してください。
□ JOIN_ORDER_BY_USER
FROM 句で最初に指定したテーブルが、クエリの外部テーブルとなります。この属性は、ジョインの
タイプではなくテーブルの順序を指定したい場合に、CONTROL QUERY SHAPE の簡単な代替手段と
して使用できます。
□ OPTIMIZATION_LEVEL
この属性は、SQL クエリの最適化レベルを設定します。
4-10
523728-001J
第 4 章 クエリ実行プランの確認
最適化レベル
説明
0
このレベルでは、コンパイラの最適化によるレベルは最小 ( 発見的方法を使用して、
可能な限り最短のコンパイル時間で 1-パスの最適化を実行する)。このレベルが適し
ているのは、テーブルが小さい場合やプランの質が重要ではない場合。
2
コンパイラは、発見的方法と限定的な検索スペース 列挙の組み合わせを使用する。
このレベルでは、全体的に見ると最適なプランとは言えない部分がある可能性はあ
るものの、一般的には質の高いプランが生成される。高い最適化レベル (3 と 5) と比
較すると、コンパイル時間は大幅に短縮される。
3 (デフォルト)
デフォルトの最適化レベルであり、一般的にはこのレベルを使用することを推奨。
コンパイラは、完全な 2- パス最適化を実行する。複雑なクエリ (5- ウェイを超える
ジョインの場合) では、発見的方法、検索スペース列挙、コンパイル時間制御アルゴ
リズムを組み合わせて使用し、妥当なコンパイル時間内で最適なプランを見つけ出
す。簡単なクエリ (5-ウェイ以下のジョインの場合) では、コンパイラは完全検索を
実行する。
コンパイラは、最大 40-ウェイのジョインのプランをコンパイルする。生成されるプ
ランは、最適化レベル 0 で生成されるプランと比較してはるかに優れ、通常は、レ
ベル 2 で生成されるプランよりも優れたプランになる。
クエリのコンパイル時間を短くするには、最適化レベル2 を使用することを検討す
る。
完全検索を実行するには、最適化レベル 5 を使用することを検討する。その場合は、
より優れたプランが生成されるものの、コンパイル時間は長くなる。
5
コンパイラは、完全検索アルゴリズムを使用してクエリの完全な最適化を実行する。
結果として得られるプランは全体的に見て最適なプランではあるものの、プランを
見つけ出すためのコンパイルに時間がかかるというトレード・オフがある。複雑な
クエリ (11-ウェイ以上のジョインの場合) では、コンパイル時間が極めて長くなる可
能性がある。このコンパイル時間のしきい値は、semi-join、outer join、またはサブ
クエリが含まれているクエリではさらに長くなる (9-ウェイのジョイン)。
注． 最適化レベルの値は、0、2、3、5 のいずれかにしてください。これ以外の値を指定すると、エラー
2055 (DEFAULTS 属性 OPTIMIZATION_LEVEL の値が無効) が返されます。値 1 と 4 は、現在は予
備であり、指定できません。これらの値を指定すると、コンパイラはその値に最も近い低い値に置き
換えます。たとえば、4 は 3 に、1 は 0 に置き換えられます。
互換性を維持するために、コンパイラは、前リリースの最適化設定である MINIMUM、MEDIUM、
MAXIMUM を受け付けます。これらの設定は、現行のリリースの設定に以下のように対応します。
523728-001J
NonStop SQL/MX リリース 1.8
NonStop SQL/MX リリース 2.0
MINIMUM
0
MEDIUM
3
MAXIMUM
5
4-11
第 4 章 クエリ実行プランの確認
□ OPTS_PUSH_DOWN_DAM
コンパウンド・ステートメントの場合、単一の DAM プロセスがコンパイラに識別されるように各ス
テートメントの述語は DAM プロセスを識別する必要があります。SQL/MX ではコンパウンド・ステー
トメント内に 2 つ以上のステートメントが必要なため、1 つの SELECT ステートメントを BEGIN ス
テートメントと END ステートメントの間に置き、その SELECT ステートメントを DAM プロセスに
プッシュ・ダウンさせることはできません。
コンパウンド・ステートメントに含まれる最初のステートメントに関する注意点は次のとおりです。
□ INSERT ステートメントに VALUE 句を使用することはできない。
□ ステートメントが SELECT または UPDATE のいずれかである場合は、ローセット・ホスト変数を
WHERE 句に指定することはできない。
コンパウンド・ステートメントに含まれる 2 番目以降のステートメント (最初のステートメントの後) に
関する注意点は次のとおりです。
□ ステートメントが INSERT の場合、VALUE 句内のパーティション・キー・カラムに対応するロー
セット・ホスト変数を指定することはできない。
□ ステートメントが SELECT または UPDATE のいずれかの場合、WHERE 句の中のパーティショ
ン・キー・カラムに対応するローセット・ホスト変数を指定することはできない。
コンパウンド・ステートメントに含まれるすべてのステートメントに関する注意点は次のとおりです。
□ すべてのパーティション・キー・カラムは、コンパイラが 1 つのパーティションだけに実行時にア
クセスできると判断できるように、スカラ ( 非ローセット) ホスト変数の同じ集合により処理され
る。
□ 集計 (aggregate) を含めることはできない。
3 つ以下のテーブルおよびインデックスの間での nested join で DAM へのプッシュ・ダウンを検討する
ことはありません。このオプションは、OLTP タイプのクエリで、対象テーブルの数ブロックだけにし
かアクセスしないクエリに使用できます。次の理由から、このオプションは複雑な DSS タイプのクエ
リには向いていません。
z
最適化の検索スペースが増えるため、コンパイル時間がかなり長くなる。
z 同じ物理ボリューム上でスキャンが同時に実行されると、期待しない不要なシークが多数発生し
て、クエリのパフォーマンスが悪化することがある。
プランを DAM にプッシュ・ダウンすることが可能な場合でも (述語で DAM プロセスを正しく特定し、
OPTS_PUSH_DOWN_DAM 属性値が 1 に設定されている) 、プラン・コストにより SQL/MX がプラン
をプッシュ・ダウンしないことがあります。システム定義のデフォルト値 (0) では、SQL/MX がプッ
シュ・ダウンを行ないません。
ステートメントが DAM にプッシュ・ダウンされたかどうかは、プランの EXPLAIN 出力で確認できま
す。プ ラ ン が PARTITION_ACCESS 演 算 子 を 示 し て い れ ば、DAM ア ク セ ス が 使 用 さ れ て お り、
PARTITION_ACCESS 演算子以下の演算子は DAM にプッシュ・ダウンされています。
コンパウンド・ステートメントについては、
『HP NonStop SQL/MX プログラミング・マニュアル C お
よび COBOL 言語用』を参照してください。
4-12
523728-001J
第 4 章 クエリ実行プランの確認
□ REMOTE_ESP_ALLOCATION
OFF に設定すると、SQL/MX に対してすべての ESP をローカル・システム上で起動するよう強制しま
す。この設定は、次のような状況に適しています。
□ ネットワーク接続が低速のため、ネットワーク・トラフィックを低下させたくない (クエリで使用
するテーブルのパーティションの分布によって異なる)
□ リモート・システムでのメモリ消費を低くしたい
□ ジョインによって、生成されるロー数が増える
さらにこの設定は、SQL/MX がネットワークをまたがる通信を使用せずに、最大限並列性を実現する
ように強制します。
アクティブなノードをすべて使用したい場合は、SYSTEM 設定を使用します。この設定は、次のよう
な状況に適しています。
□ 少なくとも 2 つのテーブルに、パーティションがあるノード
□ 1 つのテーブルの複数のパーティションが存在するノード
ON に設定すると、パーティションが置かれているすべてのノードを使用します。
□ ZIG_ZAG_TREES
左リニア・ツリーでは、右の子ノードは常に 1 つのテーブルまたはサブクエリで、左の子ノードは 1
つ以上のテーブルのサブツリーです。ジグザグ・ツリーでは、1 つの子ノードは常にテーブルであり、
それ以外の子ノードは通常ジグザグに形成される 1 つ以上のテーブルのサブツリーです。デフォルト値
を OFF (デフォルト設定) に設定すると、オプティマイザは左のリニア・ツリーと有効性を見込めるい
くつかのジグザグ・ツリーだけを検査します。デフォルト値を ON に設定すると、オプティマイザは、
最適なプランを検索するにあたって、より多くのジグザグ・ツリーを列挙します。
図 4-1 左リニア・ツリーとジグザグ・ツリー
T5
T5
T4
T4
T3
T1
T2
左リニア・ツリー
T3
T1
T2
ジグザグ・ツリー
VST041.vsd
4.2.2 DAM アクセスの検証
演算子が DAM で実行されているかどうかを検証するには、そのプランの EXPLAIN 出力で確認します。
プ ラ ン に P A R T I T I O N _ A C C E S S 演 算 子 が あ れ ば、D A M ア ク セ ス が 使 用 さ れ て い ま す。
523728-001J
4-13
第 4 章 クエリ実行プランの確認
PARTITION_ACCESS 演算子の下に表示される演算子は、DAM で実行されます。
4.2.3 Visual Query Planner の使用
Visual Query Planner は、Microsoft Windows NT のグラフィカル・ユーザ・インタフェース (GUI) アプ
リケーションです。DML ステートメントから SQL/MX オプティマイザが 生成したクエリ実行プランを抽
出し表示できます。Visual Query Planner は、内部的には EXPLAIN 関数を使用してクエリ・プランに関す
る情報を抽出しています。
生成したプランを保存して、後で解析に利用することができます。保存したプランはどこにでも送信可
能で、実際のデータベースにアクセスすることなく表示できます。さらに、問題が発生時には、そのプラ
ンを Global Customer Support Center (GCSC) に提供することもできます。Visual Query Planner には、自分
が設計したプランをオプティマイザが使用するように強制する機能もあります。詳しくは、第 5 章「実行
プランの強制」を参照してください。
Visual Query Planner の要件
Visual Query Planner を使用するには、SQL/MX の他に ODBC/MX も必要です。また、ODBC/MX に
データソースを定義する必要もあります。Windows NT 4.0 (以降) の PC またはワークステーションも必要
『 NonStopSQL/MX インストールと管理ガイド』を
です。Visual Query Planner のインストールについては、
参照してください。
注． 期待しない結果を回避するために、VQP セッション開始時にクエリ・キャッシングをオフにしておき
ます。
Visual Query Planner のヘルプ
Visual Query Planner のオンライン・ヘルプにアクセスするには、[Help] メニューから [Visual Query
Planner Help] を選択します。またコンテキスト依存のヘルプも、F1 を押すか [Properties] ダイアログ・
ボックスから使用できます。詳細については、4-16 ページの「演算子の追加情報へのアクセス」を参照し
てください。
4.2.4 実行プランのグラフィカル表示
1. 次のいずれかの方法で、Visual Query Planner を開始します。
□ [スタート] - [プログラム] - [NonStop SQL-MX] - [Visual Query Planner] を選択して Visual Query
Planner をオープンする。
□ C:\Program Files\Hewlett Packard\NonStop SQL-MX フォルダを開き、[Visual Query Planner]を選
択する。
プログラムが起動されると、デフォルトのファイル名である VQP1 がタイトル・バーに表示され、
ステータス・メッセージがウィンドウ下部に表示されます。
2. [Explain] メニュー から [Connect to ODBC] を選択して、ODBC Data Source に接続します。
注．Visual Query Planner を MXCS に接続するには、MXCS がサーバで実行されている必要があります。
4-14
523728-001J
第 4 章 クエリ実行プランの確認
MXCS への接続の詳細については、『SQL/MX Connectivity Services Manual』を参照してください。
データソースに接続すると、ウィンドウ下部のステータス・メッセージにそのデータソース名が表示さ
れます。また、ツールバーの [Connect to ODBC] アイコンがグレーに変わり、接続が確立されたこと
を表します。
3. [Visual Query Planner] ウィンドウの上部ペインにクエリを入力します。
プリペア (prepare) されたクエリを実行するのではなく、クエリを入力 ( またはコピー ) してください。
Visual Query Planner によって内部でそのクエリがプリペアされ、ステートメント名が割り当てられま
す。
4. [Explain] メニューから [Get Explain Plan] を選択して、EXPLAIN 関数で、クエリをプリペアして表示
します。
クエリ実行プランの演算子ツリーがウィンドウの左下ペイン (演算子ツリー・ペイン) に表示されます。
演算子のサマリ詳細がウィンドウの右下ペイン (サマリ詳細ペイン) に表示されます。カラム名をクリッ
クすれば、サマリ詳細をそのカラムでソートできます。
図 4-2 Visual Query Planner でクエリ・実行プランを表示
vst501.vsd
5. [File] メニューから [Save] を選択して、クエリ実行プランを保存します。セッションのデフォルト名が
[Save] ダイアログ・ボックスに表示されます。クエリ実行プランに異なる名前を使用すると、新しい名
前がタイトル・バーに表示されます。
523728-001J
4-15
第 4 章 クエリ実行プランの確認
ツールバーからのタスクの選択
ツールバーからタスクを選択することもできます。ツールバーはメニュー・バーのすぐ下にあります。
VST502.vsd
アイコン・ボタンの意味は次のとおりです。:
新規ファイルの作成
既存ファイルのオープン
ファイルの保存
編集ウィンドウ内のテキストの切り取り
編集ウィンドウ内のテキストのコピー
編集ウィンドウ内のテキストの貼り付け
ODBC ソースへの接続
ODBC データソースとの切断
クエリの実行
ヘルプを開く
これらのタスクはすべて、メニューからも使用できます。
演算子の追加情報へのアクセス
[Properties] ダイアログ・ボックスから各演算子の追加情報にアクセスするには、演算子を右クリックし
ます。すると、次の図のように、[Properties] と [Tree Depth] がダイアログ・ボックスに表示されます。演
算子をダブルクリックするか、[Explain] メニューから [Properties] を選択しても、[Properties] ダイアロ
グ・ボックスにアクセスできます。
4-16
523728-001J
第 4 章 クエリ実行プランの確認
VST503.vsd
注． [Tree depth] は、演算子ツリーに表示するレベル数を示します。[All Levels] を選択すると、完全に展
開された演算子ツリーが表示されます。
次の図に示すように、[Operator Properties] ダイアログ・ボックスには 3 つのタブがあります。
□ Node details
□ Cost details
□ Description
523728-001J
4-17
第 4 章 クエリ実行プランの確認
vst504.vsd
このダイアログ・ボックスの左上隅には、プッシュピン・アイコンと ? アイコンがあります。プッシュ
ピン・アイコンを選択すると、ダイアログを開いたままにできるため、[Properties] ダイアログ・ボックス
を再度開かずに別の演算子を選択できます。? アイコンを選択すると、演算子のコンテキスト依存ヘルプが
表示されます。[Operator Properties] ダイアログ・ボックスのタブについては、次の節で説明します。
Node Details
□ [Statement Name] は、プリペアされたクエリに割り当てられた名前。この例では、Statement Name は
Q2。
□ [Plan ID] は、コンパイル時に生成されたユニークな識別子。
□ [Node Name] は、演算子タイプ。この例では、INDEX_SCAN。
□ [Node Seq. Num.] は、最適化時の順序で、このノードが最初のノードであったことを示す。
□ [Left Child Seq. Num.] は 0 で、これは JOIN ではないことを示す。
□ [Right Child Seq. Num.] は 0 で、これは JOIN ではないことを示す。[Left Child Seq. Num.] と [Right
Child Seq. Num.] の両方に値が含まれている場合は、そのノードは JOIN。
4-18
523728-001J
第 4 章 クエリ実行プランの確認
□ [Table Name] は、スキャンされるテーブルのカタログ/スキーマ/テーブル名。
□ [Cardinality] は、INDEX_SCAN から返される予測ロー数。
□ [Operator Cost] は、現在のノードによる INDEX_SCAN の実行に関連する予測コスト。
□ [Total Cost] は、現在のノードによる INDEX_SCAN の実行に関連する予測コストで、演算子ツリーの
すべてのサブツリーのコストが含まれる。
Cost Details の確認
[Cost Details] タブに表示される情報は、EXPLAIN 関数の結果の DETAIL_COST カラムに表示されるも
のと同じです。これらの項目の詳細については、4-4 ページの「EXPLAIN 関数の結果」を参照してください。
vst505.vsd
523728-001J
4-19
第 4 章 クエリ実行プランの確認
追加テーブル情報
[Description] タブには、キー・カラム、スキャン・タイプ、スキャン方向などの、テーブルに関する追
加情報が表示されます。
vst506.vsd
各演算子に対するトークンの説明については、第 7 章「演算子と演算子グループ」を参照してください。
4-20
523728-001J
第 4 章 クエリ実行プランの確認
4.3
実行時統計情報の確認
SQL/MX は、実行されたクエリに関する統計情報を表示します。DETAILED_STATISTICS 属性を
DISPLAY STATISTICS コマンドと併用すると、統計情報を表示できます。DISPLAY STATISTICS は、現
在の MXCI セッションで最後に実行した DML ステートメントまたは PREPARE ステートメントに関する
統計情報を表示します。
DISPLAY STATISTICS コマンドと DETAILED_STATISTICS 属性については、『NonStop SQL/MX リ
ファレンス・マニュアル』を参照してください。
4.3.1 簡単なクエリの例
次のクエリは、EMPLOYEE テーブルのすべてのローとカラムを選択します。
>>prepare q1 from
+>select * from employee;
--- SQL command prepared.
>>execute Q1;
このクエリで、次の結果が返されます。
EMPNUM
------
FIRST_NAME
----------1 ROGER
.
568 JESSICA
LAST_NAME
---------GREEN
.
CRINER
DEPTNUM
------9000
.
3500
JOBCODE SALARY
-------- -----100
175500.00
.
.
300
39500.00
--- 62 row(s) selected.
このクエリに関する統計情報を取得するには、クエリを実行した後に次のように入力します。
>>DISPLAY STATISTICS;
統計情報を自動的に表示するには、セッションの任意の時点で SET STATISTICS ON を入力します。こ
うすると、各コマンドを実行した直後に統計情報が表示されます。PERTABLE オプションを指定したクエ
リに対する統計情報は、次のようになります。
Start Time
End Time
Elapsed Time
Compile Time
Execution Time
Table Name
2001/07/19 10:53:41.621
2001/07/19 10:53:41.881
00:00:00.260
00:00:00.000
00:00:00.260
Records
Records
Disk Message
Accessed
Message
Used
I/Os
Count
Bytes
62
0
2
14880
Lock
SDBCATMX.PERSNL.EMPLOYEE
62
0
収集される統計情報は、DETAILED_STATISTICS デフォルト設定によって異なります。同時にアクティ
ブにできるオプションは 1 つだけです。PERTABLE オプションを使用した場合に収集される情報は、
523728-001J
4-21
第 4 章 クエリ実行プランの確認
EXPLAIN 関数で収集される予測コスト (Estimated Cost) を除いて SQL/MP で収集される情報と同じです。
MEASURE 設定は、プロセスの実行と個々のステートメントの実行に関する統計情報を収集します。これ
らの統計情報については、Measure を使用して表示します。
PERTABLE 統計情報の収集
前出の例で DETAILED_STATISTICS 属性の PERTABLE オプションを使用すると、以下の情報が表示
されます。
□ 開始時間と終了時間
□ SQL 経過時間と実行時間
z 経過時間には、実行時間、I/O 時間、および結果表示のための時間が含まれる。
z 実行時間は、エグゼキュータが使用したプロセッサ時間の合計。
□ コンパイル時間
□ アクセスされたレコード数と使用されたレコード数
z アクセスされたレコード数とは、DAM が DAM のエグゼキュータに返したローの数。
z 使用されたレコード数とは、選択述語を満たし、エグゼキュータが使用したローの数。SELECT ク
エリの場合は、この数は DAM で選択述語を通過したローの数であり、JOIN のようなその後の操
作でのフィルタ処理で除外されれば、返されたロー数と同じにはならないこともある。UPDATE、
DELETE、INSERT のいずれかのクエリの場合は、この数は影響を受けたローの数になる。
□ ディスク I/O 数。これは、DAM が実行したディスクの読み取りと書き込みの数を示す。
□ メッセージ数。これは、ファイル・システムと DAM の間で送受信されたメッセージの数を示す。ファ
イル・システムと DAM の間でのメッセージの往復が 1 つのメッセージとしてカウントされる。
□ メッセージ・バイト数。これは、ファイル・システムと DAM の間で転送されたバイト数を示す。
□ ロック数。これは、ロック・エスカレーションに関する情報を示す。
Measure の使用
Measure を使用して、SQL/MX のデータベースとアプリケーション・プログラムに関する統計情報を収
集します。Measure は、プロセスの実行 (SQLPROC) と個々のステートメントの実行 (SQLSTMT) に関す
る統計情報を収集します。SQL/MX での Measure の使用については、
『NonStop SQL/MX インストールと管
理ガイド』を参照してください。Measure については、『Measure リファレンス・マニュアル』を参照して
ください。
プロセスの実行
Measure は、各プロセスに関する以下の統計情報を収集します。
□ 静的 SQL ステートメントが再コンパイルされた回数と、再コンパイルに要した経過時間
□ エグゼキュータ・サーバ・プロセスが起動された回数と、それに要した経過時間
□ SQL からのオープン要求の数と、それに要した経過時間
4-22
523728-001J
第 4 章 クエリ実行プランの確認
ステートメントの実行
SQLSTMT レポートは、SQL プロセスが実行したモジュールの特定のステートメントに関する情報を提
供します。Measure は、各ステートメントに関する以下の統計情報を収集します。
□ ステートメントが実行された回数
□ ステートメント実行における経過時間の合計
□ アクセスされ、返された、または変更されたローの数
□ 実行に要したディスク読み取り数
□ ステートメント実行のために送られたメッセージ数とメッセージ長
□ 実行されたソートの数とそれに要した経過時間
□ 再コンパイルの回数とそれに要した経過時間
□ タイムアウト、ロック・エスカレーション、ロック待ちの回数
SQLSTMT エンティティは、測定のために選択されたプロセスについてすべてのステートメントに関す
る統計情報を収集します。1 つのステートメントにつき 1 つの SQLSTMT エンティティが設定されます。
SQLSTMT レポートには、モジュール名とステートメント・インデックス別に各ステートメントに対する
SQLSTMT セクションが表示されます。測定される各 SQL ステートメントはステートメント・インデック
スによって識別されます。生成された SQL モジュール定義ファイルの中にこの数字が含まれるため、この
数字を使って対応する Measure の SQLSTMT カウンタを探すことができます。
注． Measure のレポートでの実行単位 (run unit) は、SQL/MP 用のプロシージャまたは COBOL 実行単位の
名前であり、SQL/MX では、この名前が SQL モジュールの名前になります。この名前の長さは 128
バイトです。
Measure データの評価
SQLSTMT レポートを使用すると、基本的なパフォーマンスの全体図を把握できるため、いくつかのバー
ジョンのクエリを比較して、クエリをチューニングできます。
注． ステートメント・インデックスを元の SQL ステートメントに戻すには、EXPLAIN 関数を使用します。
statement_index とステートメント・トークンについては、7-37 ページの「ROOT 演算子」を参照して
ください。
Measure は、オプションで各トランザクションまたはクエリを隔離します。隔離するよう設定しないと、
特定のトランザクションを明確に区別できません。パフォーマンスが悪いトランザクションがどれである
のかが分からない場合は、各トランザクションを別々に実行し、それを測定し、トランザクション・グルー
プ間で比較します。
パフォーマンスが悪いクエリの SQLSTMT を確認する場合は、I/O 操作の数、他のクエリの消費時間の
合計との相対比較、1 トランザクション内での実行頻度、およびその他のパフォーマンスに関する測定値
を基準にして、クエリを検査し、特定します。さらに、EXPLAIN 関数を使用してそのクエリのクエリ・プ
ランを生成して、パフォーマンスが悪い原因を特定する手掛かりにします。ある種のクエリには、特定の
タイプの問題が共通しているということもあります。
523728-001J
4-23
第 4 章 クエリ実行プランの確認
ストップウォッチ測定が役に立つ場合もあります。Measure の情報を比較する場合には、ストップウォッ
チ測定を使用すると、ネットワーク関連の問題やそれ以外の種類の遅延が明らかになることがあります。
特定のクエリにどの程度の応答時間を求めるかを明確にすることが重要な場合もあります。この方法を
採用すると、特定の目標やチューニング完了の基本的な指針を明確にできます。
クエリに対する変更を評価する場合は、その変更が他のトランザクションに悪影響を及ぼす可能性がな
いかどうかを考慮します。たとえば、インデックスを追加する場合には、追加する前後のINSERT や
UPDATE のトランザクションのパフォーマンスを比較します。インデックスを追加することで問題を解決
できるクエリの量と、UPDATE および DELETE のトランザクションの量を比較します。
4-24
523728-001J
第 5 章 実行プランの強制
この章では、実行プランの強制を決定するために使用できる情報を説明します。
□ 5-2 ページの「プラン強制の目的」
□ 5-3 ページの「プラン強制のチェックリスト」
□ 5-4 ページの「最適化プランの表示」
□ 5-5 ページの「最適化プランの確認」
□ 5-7 ページの「演算子ツリーをテキスト形式に変換」
□ 5-10 ページの「強制シェイプ・ステートメントの書き込み」
SQL/MX オプティマイザは最もコスト効率のよいプランを提供しますが、オプティマイザにより選択さ
れたプランを変更したい場合もあります。
注意． CONTROL QUERY SHAPE ステートメントを使用するとオプティマイザの標準コスト予測を上書
きするので、パフォーマンスが下がることがあります。また、無効なプランを強制しようとすると、
プランは返されません。CONTROL QUERY SHAPE は、オプティマイザが生成するプランが最適
ではない場合にだけ使用してください。
実行プランを強制するには、プランをどのように実行させたいのかをエグゼキュータに指示します。ク
エリの特定のプラン・シェイプを強制するには、CONTROL QUERY SHAPE ステートメントを使用しま
す。このステートメントは ANSI 標準に対する SQL/MX の拡張機能で、SQL 構文で記述します。プランを
強制するには、内部クエリ・ツリー構造を理解する必要があります。CONTROL QUERY SHAPE ステート
メントには任意の可能な構文を置くことができますが、その構文が有効であるとは限らず、有効性の検証
は行われません。
CONTROL QUERY SHAPE は、オプティマイザの内部設計に大きく依存します。オプティマイザの今後
の改善によって、CONTROL QUERY SHAPE ステートメントの変更が必要になる可能性もあります。
この章では、クエリ・プランの強制に関して説明します。CONTROL QUERY SHAPE ステートメントの
詳細は、『NonStop SQL/MX リファレンス・マニュアル』を参照してください。
523728-001J
5-1
第 5 章 実行プランの強制
5.1
プラン強制の目的
プランを強制する理由には次のようなものがあります。
□ テストのため。オプティマイザが提供する実行プランとは異なる実行シナリオを試すことができる。
□ オプティマイザが検出したプランが最適でないため。最新の統計情報とデータ更新が不足していたり、
データ・スキュー (data skew) や積極的なプルーニング (pruning) が原因で、このような状況が発生す
ることがある。
このような状況では、プランを強制することでプラン・シェイプを制御できます。オプティマイザは、
強制されたシェイプと一致する最適なプランを選択します。
5-2
523728-001J
第 5 章 実行プランの強制
5.2
プラン強制のチェックリスト
プランを強制するには、プランの内容を理解しておく必要があります。
1. プリペアされたステートメントの最適化プランを EXPLAIN 関数を使用して表示する。
2. 最適化プラン、および操作に関連するコストを確認する。
3. SHOWSHAPE ユーティリティまたはフォーマット規則を使用して、演算子ツリーをテキスト形式に変
換する。
4. CONTROL QUERY SHAPE ステートメントを使用して、指定したテキスト形式に基づいて演算子ツ
リーの再シェイプを行う。
これらの各手順については、以下の節で詳しく説明します。
523728-001J
5-3
第 5 章 実行プランの強制
5.3
最適化プランの表示
第 4 章「クエリ実行プランの確認」の手順に従って クエリ実行プランを表示し、オプティマイザが提供
する演算子ツリーを理解します。最適化プランを次の形式で表示できます。
□ EXPLAIN 関数を使用して、最適化プランを部分的に表示する。
□ DISPLAY_EXPLAIN 関数を使用して、最適化プラン全体を表示する。
□ Visual Query Planner (VQP) を使用して、最適化プラン全体をグラフィカルに表示する。
注． 期待しない結果を回避するために、VQP セッションの開始時にクエリ・キャッシングをオフにしてお
きます。
この章では、次のクエリを使用して、実行プランを強制する方法を説明します。
SELECT EMPLOYEE.LAST_NAME, EMPLOYEE.FIRST_NAME, DEPT.MANAGER,
EMPLOYEE.DEPTNUM, JOB.JOBCODE
FROM DEPT, EMPLOYEE, JOB
WHERE DEPT.DEPTNUM=3100 AND EMPLOYEE.DEPTNUM=3100 AND
JOB.JOBCODE=300;
5-4
523728-001J
第 5 章 実行プランの強制
5.4
最適化プランの確認
次の例は、最適化されたサンプル・クエリの EXPLAIN を示したものです。この出力では単に演算子と
シーケンス番号だけが示されていますが、コストをかけるカラムを選択して、各操作の予測コストを確認
することもできます。
>>SET SCHEMA samdbcat.persnl;
>>PREPARE s1 FROM SELECT employee.last_name, employee.first_name,
>+dept.manager, employee.deptnum, job.jobcode
>+FROM dept, employee, job
>+WHERE dept.deptnum=3100 AND employee.deptnum=3100
>+AND job.jobcode=300;
--- SQL command prepared.
>>SELECT seq_num, operator, left_child_seq_num, right_child_seq_num
>+FROM table (EXPLAIN(NULL, 'S1'));
SEQ_NUM
-------
OPERATOR
-----------
LEFT_CHILD_SEQ_NUM
------------------
1
2
3
4
5
6
7
8
9
FILE_SCAN_UNIQUE dept
PARTITION_ACCESS
FILE_SCAN employee
PARTITION_ACCESS
HYBRID_HASH_JOIN
FILE_SCAN_UNIQUE job
PARTITION_ACCESS
HYBRID_HASH_JOIN
ROOT
1
3
2
6
5
8
RIGHT_CHILD_SEQ_NUM
------------------4
7
-
--- 9 row(s) selected.
この出力には、このクエリ・プランは、アプリケーション・プロセスと DAM との通信を行う Exchange
(PARTITION_ACCESS) 演算子を持つ DAM の 3 つの SCAN 演算子、2 つの HYBRID_HASH_JOIN 演算
子、そして 1 つの ROOT ノードが示されています。
この出力を確認する場合に、ノードのシーケンス番号と左右の子ノードのシーケンス番号に注目します。
まず、ルート・ノードから読み始めます。この出力では、ROOT ノードには、1 つの子ノードである
H Y B R I D _ H A S H _ J O I N が あ り ま す。こ の ノ ー ド に は 2 つ の 子 ノ ー ド が あ り、そ の 1 つ は
HYPRID_HASH_JOIN、もう 1 つはファイル・スキャン操作付きの PARTITION_ACCESS です。さらに、
2 つ目の HYBRID_HASH_JOIN にもファイル・スキャン操作付きの 2 つの PARTITION_ACCESS ノード
があります。演算子の詳細については、第 7 章「演算子と演算子グループ」を参照してください。
ここで、親子関係をさらに見やすくするために、ツリー形式の出力を示します。ここには、シーケンス
番号とテーブル名も表示されています。
523728-001J
5-5
第 5 章 実行プランの強制
図 5-1 ビジュアルなツリー形式でのクエリ・プラン出力
ROOT 9
HYBRID_HASH_JOIN 8
HYBRID_HASH_JOIN 7
PARTITION_ACCESS 6
PARTITION_ACCESS 4
FILE_SCAN_UNIQUE 5
DEPT
FILE_SCAN_UNIQUE 3
JOB
PARTITION_ACCESS 2
FILE_SCAN 1
EMPLOYEE
VST062.vsd
演算子ツリーを実行プランの強制に使用できるテキスト形式に変換する前に、これらの親子関係と演算
子ツリーの左右でどのような操作が行われるのかを理解する必要があります。
Visual Query Planner アプリケーションを使用すれば、より簡単にクエリの演算子ツリーを確認できます。
Visual Query Planner はクエリ実行プランをグラフィカルに表示するので、演算子ツリーを簡単に参照でき
ます。
vst601.vsd
5-6
523728-001J
第 5 章 実行プランの強制
5.5
演算子ツリーをテキスト形式に変換
演算子ツリーは、必ずテキスト形式に変換します。CONTROL QUERY SHAPE ステートメントへの入力
として使用されるツリーのテキスト形式は、LISP に似た形式で作成されます (LISP とは、高水準のプログ
ラミング言語 List Processor のことです)。
5.5.1 SHOWSHAPE と SET SHOWSHAPE によるテキスト形式の表示
MXCI を使用してクエリを実行する場合は、SHOWSHAPE コマンドと SET SHOWSHAPE コマンドを
使用して、CONTROL QUERY SHAPE ステートメントのテキスト形式を表示できます。SHOWSHAPE コ
マンドでは、実行するステートメントのシェイプのテキスト形式が表示されるだけで、EXPLAIN 出力は
表示されません。
>>SHOWSHAPE SELECT last_name, first_name, manager,
+>employee.deptnum, job.jobcode FROM dept, employee, job
+>WHERE dept.deptnum=3100 AND employee.deptnum=3100 AND
+>job.jobcode=300;
control query shape hybrid_hash_join(hybrid_hash_join(partition_access(
scan(path '\MYSYS.$SAMDB.PERSNL.DEPT',
forward, blocks_per_access 1, mdam off)),partition_access(
scan(path '\MYSYS.$SAMDB.PERSNL.JOB',
forward, blocks_per_access 1 , mdam off))),partition_access(
scan(path '\MYSYS.$SAMDB.PERSNL.EMPLOYEE',
forward, blocks_per_access 1, mdam off)));
--- SQL operation complete.
さらに、SET SHOWSHAPE コマンドを使用すると、実行プランを実際に表示できます。シェイプのテ
キスト形式は、クエリ出力の直前に表示されます。サンプル・クエリを実行する前に SET SHOWSHAPE
コマンドを使用すると、次のような出力が表示されます。
control query shape hybrid_hash_join(hybrid_hash_join(partition_access(
scan(path '\MYSYS.$SAMDB.PERSNL.DEPT', forward, blocks_per_access 1,
mdam off)),partition_access(scan(path '\MYSYS.$SAMDB.PERSNL.JOB', forward,
blocks_per_access 1 , mdam off))),partition_access(scan(path
'\MYSYS.$SAMDB.PERSNL.EMPLOYEE', forward, blocks_per_access 1, mdam off)));
Last Name
--------------------
First Name
---------------
WINTER
Farley
Buskett
Buskett
STRICKER
WELLINGTON
TAYLOR
PAUL
Walt
Emmy
Paul
GEORGE
PETE
DONALD
Mgr
-----
Dept/Num
--------
Job/Code
--------
43
43
43
43
43
43
43
3100
3100
3100
3100
3100
3100
3100
300
300
300
300
300
300
300
--- 7 row(s) selected.
523728-001J
5-7
第 5 章 実行プランの強制
5.5.2 Visual Query Planner によるシェイプの取得
Visual Query Planner を使用したプランの実行で [Explain] メニューの [Show Query Shape] オプション
を選択すると、クエリをシェイプするためのテキスト形式を表示できます。次の図は、サンプル・クエリ
のシェイプです。
vst602.vsd
シェイプを変更したら、[Get Shape] アイコン ( 左上隅の真中のアイコン) を選択して新しいシェイプを
強制することができます。さらに、[Explain] メニューから [Get Explain Plan] を選択して変更後のプラン
を参照してください。
SHOWSHAPE コマンドと SET SHOWSHAPE コマンドの詳細については、『NonStop SQL/MX リファレ
ンス・マニュアル』を参照してください。Visual Query Planner の使用についての詳細は、第 4 章「クエリ
実行プランの確認」を参照してください。また、Visual Query Planner のオンライン・ヘルプでも役に立つ
さまざまな情報を提供しています。
5.5.3 シェイプの手動書き込み
以下の規則を適用することにより (ルートから) ツリーを繰り返し書き込み、ツリーを変換します。
TEXT (node) = node-identifier + '(' + TEXT(child1) + ',' +
TEXT(child2) + ... + ')'
node
変換される演算子ツリー・ノード
node-identifier
ノードの識別子
child i
5-8
（存在する場合） 左から右に数えて i 番目の子ノード
523728-001J
第 5 章 実行プランの強制
サンプル・クエリを使用して、演算子ツリーをテキスト形式に変換できます。
ROOT(HYBRID_HASH_JOIN (HYBRID_HASH_JOIN
(PARTITION_ACCESS (FILE_SCAN_UNIQUE),
PARTITION_ACCESS(FILE_SCAN)),
PARTITION_ACCESS (FILE_SCAN_UNIQUE)))
CONTROL QUERY SHAPE ステートメントを改良するには、次のような条件をテキスト形式に適用しま
す。
□ ROOT ノードを消去する。
□ EXPR ノードを消去する。
□ FILE_SCAN ノードと FILE_SCAN_UNIQUE ノードを SCAN として書き込む。
□ SPLIT_TOP(PARTITION_ACCESS(...)) を SPLIT_TOP_PA(...) に置き換える。
□ 演算子ツリーに操作の構文が存在しない場合 (たとえば、SORT_SCALAR_AGGR や
SHORTCUT_SCALAR_AGGR) 、SORT_GROUPBY または SHORTCUT_GROUPBY など、同様の演
算子を使用する。有効な演算子については、第 7 章「演算子と演算子グループ」を確認すること。
改良されたテキスト形式は、次のようになります。
HYBRID_HASH_JOIN (HYBRID_HASH_JOIN
(PARTITION_ACCESS (SCAN),
PARTITION_ACCESS (SCAN)),
PARTITION_ACCESS (SCAN))
523728-001J
5-9
第 5 章 実行プランの強制
5.6
強制シェイプ・ステートメントの書き込み
CONTROL QUERY SHAPE ステートメントを使用して、前の手順で作成したテキスト形式を使用して強
制シェイプ・ステートメントを書き込み、強制する演算子を置き換えます。CONTROL QUERY SHAPE ス
テートメントについては、
『NonStop SQL/MX リファレンス・マニュアル』を参照してください。プランで
特定の演算子が使用される理由については、第 7 章「演算子と演算子グループ」を参照してください。
多くの場合、実験に基づいてプランの強制を決定しますが、プランの公式化に役立つガイドラインをい
くつか示します。
5.6.1 CONTROL QUERY SHAPE の有効範囲
CONTROL QUERY SHAPE ステートメントの実行結果は、現在の MXCI セッションが終了するまで、ま
たは他の CONTROL QUERY SHAPE ステートメントにより変更されるかオフにされるまで有効です。
CONTROL QUERY SHAPE ステートメントを実行しても、CONTROL ステートメント、EXPLAIN コマン
ド、DISPLAY_EXPLAIN コマンド、LOCK ステートメント、UNLOCK ステートメント、DDL、およびト
ランザクション関連のステートメントには影響ありません。
警告． 特定のクエリのシェイプを強制した後、CONTROL QUERY SHAPE をオンにしたままにしてしま
うことがよくあります。このようにすると、他のクエリをコンパイルしようとしても、コンパイラ
は持続している強制シェイプに一致するプランを検出できません。シェイプの強制が終了したら、
必ず CONTROL QUERY SHAPE をオフにしてください。
CUT、ANYTHING、OFF のいずれかのオプションを使用して、シェイプをオフにします。
CONTROL QUERY SHAPE OFF;
5.6.2 演算子ツリーの部分的シェイプ
ANYTHING オプションを使用すると、演算子ツリーを部分的にシェイプできます。このオプションは、
特定の操作だけを対象とし、プランの残りの部分はどのように最適化されても構わないという場合に使用
します。ツリーの一部を指定する場合、ANYTHING によりオプティマイザで最適なソリューションを「継
承」および選択したいポイントをマークします。次の例では、演算子ツリーの部分的シェイプを示します。
CONTROL QUERY SHAPE join (anything, union (anything, scan));
5.6.3 論理指定と物理指定の使用
CONTROL QUERY SHAPE ステートメントで、論理演算子または物理演算子を使用できます。論理演算
子は実装を表さない比較演算子で、例としては join、group by、scan などがあります。物理演算子は実際
の実装またはランタイム・アルゴリズムを表す相関演算子で、例としては merge join、hash group by、file
scan などがあります。
5-10
523728-001J
第 5 章 実行プランの強制
論理演算子
物理演算子
scan
FILE_SCAN、INDEX_SCAN
hash_join
HYBRID_HASH_JOIN、ORDERED_HASH_JOIN
join
NESTED_JOIN、MERGE_JOIN、
HYBRID_HASH_JOIN、ORDERED_HASH_JOIN
groupby
SORT_GROUPBY、HASH_GROUPBY、
SHORTCUT_GROUPBY
union
UNION
sort
SORT
exchange
PARTITION_ACCESS (DAM と通信するファイル・シス
テム・インタフェース)
REPARTITION (データの再配布)
SPLIT_TOP_PA (複数のパーティションからデータをパラ
レルで読み取る。PARTITION_ACCESS ノードのパラレ
ル版)
materialize
MATERIALIZE (一時的なテーブルのマテリアライズ)
expr
EXPR (内部的に生成されるノード。指定する必要はない)
tuple
TUPLE
操作が行われるように指定したい、しかし実装のためにオプティマイザがどのアルゴリズムを選択する
のかは問題にしないという場合、論理指定を使用します。たとえば、テーブル EMPLOYEE がジョインの
最後のテーブルとしてスキャンされるように指定したいが、アルゴリズムの選択はオプティマイザにまか
せる場合などです。この場合、2 番目の引数として SCAN(EMPLOYEE) を指定して、論理ジョイン指定を
使用します。こうすると、オプティマイザは実装として nested join、merge join、hash join のいずれかを自
由に選択できます。
物 理 演 算 子 SHORT CUT_GROUPBY を 使 用 し て プ ラ ン を 強 制 す る と、EXPL AI N 出 力 に は
SHORTCUT_SCALAR_AGGR 演算子が表示されます。オプティマイザが SHORTCUT_SCALAR_AGGR
付きのプランを生成できない場合は、プランは返されません。
5.6.4 ビューでのシェイプの強制
クエリをプリペア (prepare) し、EXPLAIN 出力を使用してコンパイル統計情報を表示すると、コンパイ
ラによりビューが展開され、元となる実テーブルで操作が発生したことが示されます。ビューの新規シェ
イプに影響を与えるには、CONTROL QUERY SHAPE ステートメントで元となる実テーブルを参照しま
す。
5.6.5 プランが返されない場合
プランをシェイプしようとしたにもかかわらずオプティマイザからプランが返されなかった場合、次の
理由が考えられます。
523728-001J
5-11
第 5 章 実行プランの強制
□ 強制されたプランと発行されたクエリが一致しない。つまり、そのシェイプに対して、オプティマイ
ザ規則により定義されるオプティマイザ検索空間で一致するものがない。たとえば、2 つのテーブル
のジョイン・クエリにテーブル・スキャン・シェイプを強制しようとしても、プランは返されない。
□ 強制されたプランとクエリに互換性はあるが、一致するプランがオプティマイザの発見的手法により
削除される。このような場合、D A T A _ F L O W _ O P T I M I Z A T I O N
属性のデフォルト値と
CROSS_PRODUCT_CONTROL 属性のデフォルト値を OFF に変更し、結果が異なるかどうかプラン
を再び確認する。
5.6.6 SQL/MP からの強制シェイプの移行
CONTROL TABLE ステートメントを使用して SQL/MP でプランを強制した場合、CONTROL QUERY
SHAPE を使用してプランを再作成する必要があります。CONTROL QUERY SHAPE は、CONTROL
TABLE よりも強力にクエリを制御できます。CONTROL TABLE では 1 つの操作を強制するのに対して、
CONTROL QUERY SHAPE ではツリー構造全体を強制する必要があるので注意してください。
5.6.7 Data Access Manager に対する Group By 操作の強制
SQL コンパイラには、グループ化と集計を行うための 2 つの方法があります。
注． GROUP BY 句が指定されていない場合でも GROUP BY 演算子が使用されることがあります。
□ sort group by では group by の子ノードを group-by カラムで並べ替える必要があるので、並べ替え順序
は保持される。この方法では、入力が group-by カラムで予めソートされていない限り、追加のソート
操作が必要である。
□ hash group by ではハッシュ操作を使用してグループ化が実行される。また、子ノードに対して順序要
件はない。通常 hash group by は sort group by と比較してコストが効率的である。
コンパイラは、コストに基づいてアルゴリズムを使用して、hash または sort のどちらの group by を実行
するかを決定します。集計関数とは、AVG、COUNT、MAX、MIN、STDDEV、SUM、VARIANCE です。
集計関数の詳細については、
『NonStop SQL/MX リファレンス・マニュアル』のそれぞれの項を参照してく
ださい。
単一テーブルの操作は、常に Data Access Manager (DAM) レベルにプッシュ・ダウンできます。
5-12
523728-001J
第 5 章 実行プランの強制
図 5-2 DAM を使用しない group by 操作
ROOT
GROUPBY
エグゼキュータ
メッセージ
EXCHANGE
DAM
SCAN
VST067.vsd
メッセージは、EXCHANGE ノードを介して、DAM の SCAN 演算子からエグゼキュータの GROUP BY
演算子に渡されます。ローが何百万もあるテーブルでは、このようなメッセージ通信量は非効率です。次
の例に示すように group by 操作を DAM にプッシュ・ダウンして、DAM とエグゼキュータの間のメッセー
ジ通信量を削減できます。
ロー (従業員) が 50,000 あり、18 のパーティションがある EMPLOYEE テーブルに対して、次のクエリ
を実行します。
SELECT COUNT(*) FROM EMPLOYEE;
コンパイラが図のようなクエリ・プランを生成すると、SCAN 演算子は EXCHANGE ノードにブロック
単位でメッセージを渡します。次に、このメッセージは EXCHANGE ノードにより GROUP BY 演算子に
渡されます。
このメッセージ通信量を削減するには、GROUP BY 演算子を DAM にプッシュ・ダウンします。
図 5-3 DAM レベルでの group by 演算子
エグゼキュータ
Exchange
DAM
Groupby
Scan
VST060.vsd
523728-001J
5-13
第 5 章 実行プランの強制
メッセージ通信量は、次のような手順で削減されます。SCAN 操作では 50,000 ローがすべてスキャンさ
れますが、group by 操作ではテーブルのパーティション (18 個) ごとに 1 つの結果が生成されます。この結
果は、EXCHANGE ノードに渡されます。EXCHANGE ノードの上に GROUP BY 演算子をもう 1 つ追加
して、下位の group by 操作の結果と結合します。
図 5-4 2 つの group by 操作
Root
Groupby
パーティション・グループからの結
果を結合
Exchange
Groupby
パーティション・グループ化と集計操
作
Scan
VST061.vsd
group by 操作の一般例
パーティション分割されたテーブル (パーティションが 2 つ以上ある場合) および任意の hash group by 操
作をプッシュ・ダウンするには、追加の group by 操作が必要です。下位の group by ではパーティション単
位でグループ化と集計を行い、上位の group by ではすべてのグループを最終的に集計します。hash group
by の場合、上位の group by は DAM でオーバフローが発生すればそれを処理する必要があります。
sort group by 操作の特殊ケース
sort group by によってソートされた単一パーティションには、GROUP BY 演算子が 1 つだけ必要です。
sort group by 操作は、group by への入力が group by カラムですでに順序付けられている場合のみ実行でき
ます。この場合には、コンパイラはグループのインデックス・スキャンまたはファイル・スキャンを実行
可能で、ソートには追加コストがかかりません。DAM ではソートが実行されないので、sort group by への
入力を順序付けておく必要があります。
5.6.8 パラレル・プランの強制
オプティマイザは、利用可能な最もコスト効率のよいプランを生成します。しかし、オプティマイザは
常に希望のパラレル・プランを生成するとは限りません。CONTROL QUERY SHAPE を使用してパラレ
ル・プランを強制する場合、オプティマイザの標準コスト予測を無効にすると、パフォーマンスが下がる
こともあるので注意してください。
ESP 並列性の強制
ESP 並列性を行わせるには、パラレル実行を行わせたい演算子の前に ESP_EXCHANGE 演算子を置きま
す。
5-14
523728-001J
第 5 章 実行プランの強制
次のコマンドを使用しても、ESP 並列性を行わせることができます。
CONTROL QUERY SHAPE ESP_EXCHANGE(CUT);
注． ESP 並列性を使用するには、ATTEMPT_ESP_PARALLELISM を ON または SYSTEM に設定する必
要があります。また、システムに CPU が 2 つ以上必要です。
使用する ESP の数を強制できます。ジョインの場合、ジョインの指定時に ESP の数を指定します。ジョ
イン操作以外の場合は、ESP の数とともに EXCHANGE 論理演算子を指定します。子ノードに CUT キー
ワードを使用しないでください。使用すると、意図した結果が得られないことがあります。
警告．ESP の数を強制すると、オプティマイザの内部設定を完全に上書きします。このオプションは、オ
プティマイザが必要な ESP の数を選択しない場合に限って、注意して使用してください。
DAM 並列性の強制
DAM 並列性を行わせるには、DAM で実行させたい項目の上で SPLIT_TOP_PA を強制します。
CONTROL QUERY SHAPE SPLIT_TOP_PA (ANYTHING);
次のクエリを使用します。
SELECT JOBCODE, AVG(SALARY) FROM EMPLOYEE
WHERE JOBCODE > 55 AND SALARY <= 3000
GROUP BY JOBCODE
次のシェイプでは、ESP またはマスタ・エグゼキュータの統合グループ化を伴う DAM の部分グループ
化が強制されます。
CONTROL QUERY SHAPE
GROUPBY(
SPLIT_TOP_PA(
GROUPBY(SCAN))
);
523728-001J
5-15
第 5 章 実行プランの強制
図 5-5 強制されたプランのクエリ・ツリー
root
map_value_ids
マスタ・エグゼキュータ
hash_partial_groupby_root
split_top
partition_access
hash_partial_groupby_leaf
DAM フラグメント
VST614.vsd
file_scan
DAM 並列性を使用せずに DAM で演算子を実行するように強制するには、DAM で実行させたい演算子
の上位で PARTITION_ACCESS 演算子を強制します。ただし、演算子は要求できるものでなければなりま
せん。たとえば、ジョインは DAM への直接要求には使用できません。DAM に直接要求できる演算子に
は、scan や group by などがあります。
ジョインの強制
CONTROL QUERY SHAPE の構文を使用して、次に示すように、パラレル・プランで特定なタイプの
ジョインを強制できます。タイプ 1 とタイプ 2 のジョインについての詳細は、第 8 章「並列性」を参照し
てください。
タイプ 1 ジョインの強制
マッチング・パーティション・アルゴリズムは、ジョイン指定の中でタイプ 1 を指定することにより強
制できます。再パーティション化を行わずにタイプ 1 ジョインを強制するには、両方のテーブルですべて
の基準が一致している必要があります。テーブルの基準が一致していない場合にタイプ 1 ジョインを強制
す る に は、子 ノ ー ド で C U T
を 使 用 す る か、再 パ ー テ ィ シ ョ ン 化 が 必 要 な 子 ノ ー ド の 上 位 で
ESP_EXCHANGE を使用します。以下は、タイプ 1 ジョインの強制の例です。
CONTROL QUERY SHAPE
ESP_EXCHANGE(
MERGE_JOIN(
EXCHANGE(SCAN('DEPT')),
EXCHANGE(SCAN('EMP')),
TYPE1)
);
5-16
523728-001J
第 5 章 実行プランの強制
この例では、下位の Exchange 演算子で論理指定が使用されているので、オプティマイザはパラレル・ア
クセス (SPLIT_TOP_PA 演算子) またはシリアル・アクセス (PARTITION_ACCESS 演算子) を選択できま
す。
図 5-6 論理指定と下位の Exchange 演算子
root
esp exchange
merge_join
exchange
exchange
scan 'DEPT'
scan 'EMP'
VST650.vsd
タイプ 1 ジョインについての詳細は、8-1 ページの「並列性」を参照してください。
タイプ 2 ジョインの強制
内部テーブル・アルゴリズムへのパラレル・アクセス付きジョインは、ジョイン指定の中でタイプ 2 を
指定することにより強制できます。タイプ 2 nested join を強制するには、左の子ノードをパーティション
化します。タイプ 2 hash join を強制するには、左の子ノードをパーティション化し、さらに右の子ノード
の上位で CUT または ESP_EXCHANGE を指定してブロードキャスト複製を処理する必要があります。
次のステートメントでは、タイプ 2 hash join が強制されます。
CONTROL QUERY SHAPE
ESP_EXCHANGE(
HYBRID_HASH_JOIN (
EXCHANGE(SCAN('DEPT')),
ESP_EXCHANGE(EXCHANGE(SCAN('EMP'))),
TYPE2)
);
523728-001J
5-17
第 5 章 実行プランの強制
図 5-7 タイプ 2 hash join
root
esp_exchange
hybrid_hash_join
exchange
esp_exchange
scan 'DEPT'
exchange
scan 'EMP'
VST651.vsd
タイプ2 ジョインについての詳細は、8-1 ページの「並列性」を参照してください。
Exchange 演算子または Sort 演算子の選択をオプティマイザに任せる
前出のジョイン強制の例では、CONTROL QUERY SHAPE ステートメントの中で Exchange 演算子と
Sort 演算子のどちらかを選択する必要がありました。この手順を省略し有効な CONTROL QUERY SHAPE
ステートメントの記述過程を簡略化するには、以下に示す CONTROL QUERY SHAPE ステートメントの
オプションのいずれかを使用します。オプションを使用すると、Exchange 演算子と Sort 演算子の選択の判
断はオプティマイザにゆだねられ、ジョインの順序やジョインのタイプを始めとするプランのタイプの決
定にのみを行います。
□ IMPLICIT EXCHANGE を使用すると、オプティマイザは、CONTROL QUERY STATEMENT を有効
にするために必要な任意の位置に Exchange ノードを追加できます。Exchange ノードを追加する最適
な位置は、オプティマイザが決定します。ただし、この場合にも Exchange ノードの明示的な追加は可
能で、コンパイラによるノードの追加も行われます。
□ IMPLICIT SORT を使用すると、オプティマイザは、CONTROL QUERY STATEMENT を有効にする
ために必要な任意の位置に Sort ノードを追加できます。Sort ノードを追加する最適な位置は、
オプティ
マイザが決定します。ただし、この場合にも Sort ノードの明示的な追加は可能で、コンパイラによる
ノードの追加も行われます。
□ IMPLICIT
EXCHANGE_AND_SORT
を使用すると、オプティマイザは、CONTROL
QUERY
STATEMENT を有効にするために必要となる任意の位置に Exchange ノードと Sort ノードの両方を追
加できます。Exchange ノードと Sort ノードを追加する最適な位置は、オプティマイザが決定します。
ただし、この場合にも Exchange ノードや Sort ノードの明示的な追加は可能で、コンパイラによるノー
ドの追加も行われます。
次のステートメントにより、オプティマイザは Exchange ノードを追加できるようになります。
5-18
523728-001J
第 5 章 実行プランの強制
CONTROL QUERY SHAPE IMPLICIT EXCHANGE
HYBRID_HASH_JOIN (
SCAN('DEPT'),
SCAN('EMP'),
TYPE2);
構文と詳細情報については、『NonStop SQL/MX リファレンス・マニュアル』を参照してください。
523728-001J
5-19
第 5 章 実行プランの強制
5-20
523728-001J
第 6 章 クエリ・プラン・キャッシング
SQL/MX コンパイラには、特定のクエリのプランをキャッシュに格納できるクエリ・プラン・キャッシ
ングと呼ばれる機能があります。この機能によってプランを完全にコンパイルするかわりにキャッシュか
ら生成できる場合にパフォーマンスが向上します。単純な TP スタイルのクエリであれば、一般的に 60 ∼
80 % のパフォーマンス向上が達成できます。
CONTROL QUERY DEFAULT ステートメントで使用するいくつかのデフォルト設定が、クエリ・プラ
ン・キャッシングに適用されます。詳しくは、6-9 ページの「クエリ・プラン・キャッシング属性のデフォ
ルト・テーブル設定」を参照してください。
クエリ・プラン・キャッシングの機能は、自動的に実行されるように設計されています。SQL/MX アプ
リケーションのソース・コードを変更する必要はありません。SQL/MX は、同じクエリであればクエリ・
キャッシングの有無に関係なく、同じプランを生成します。SQL/MX コンパイラ (mxcmp) は、クエリ・
キャッシングがアクティブである状況においても、CONTROL QUERY DEFAULT ステートメントと
CONTROL TABLE ステートメントによる指示に従います。次の例を使って、クエリ・プラン・キャッシ
ングがどのように機能するのかを説明します。
□ テーブル T のテーブル・タイムアウト設定は無限 (-1) に設定されている。
□ SQL/MX コンパイラに “SELECT * FROM T” のコンパイルを要求する。
□ SQL/MX コンパイラは “SELECT * FROM T” に対するプランをコンパイルし、キャッシュに格納する。
□ CONTROL TABLE ステートメントによって、テーブル T のタイムアウト設定が 5 秒に変更される。
□ SQL/MX コンパイラに “SELECT * FROM T” のコンパイルを再度要求する。
SQL/MX コンパイラは、以前にキャッシュに格納した “SELECT * FROM T” のプランを使用することは
できません。これは、キャッシュに格納されているプランではテーブル T のタイムアウトを無限として設
定しているためです。キャッシュされているプランをコンパイラが使用したとすると、テーブル T のタイ
ムアウトを 5 秒に変更した CONTROL TABLE ステートメントは事実上無視されることになります。以上
のことから、コンパイラは、1 つのクエリに対して 1 つ以上のプランをコンパイルでき、それぞれのプラ
ンに異なる制御設定を関連付けています。
1 つのクエリを異なる制御設定で 繰り返しSQL/MX コンパイラでコンパイルすると、複数のプランを格
納できる十分な大きさにキャッシュが設定されていれば、コンパイラはキャッシュでヒットするものを返
すようになります。次のような順序で CONTROL ステートメントとクエリ・コンパイル要求が発生した場
合に、コンパイラがどのような処理を行うのかを考えてみます。
CONTROL TABLE T TIMEOUT 500;
SELECT * FROM T; -- mxcmp は "SELECT * FROM T; T TIMEOUT 500" をキャッシュに格納す
る
CONTROL TABLE T TIMEOUT -1;
SELECT * FROM T; -- mxcmp は "SELECT * FROM T; T TIMEOUT -1" をキャッシュに格納する
CONTROL TABLE T TIMEOUT 500;
SELECT * FROM T; -- mxcmp はキャッシュに格納されている "SELECT * FROM T; T TIMEOUT
500" にヒットする
CONTROL TABLE T TIMEOUT -1;
SELECT * FROM T; -- mxcmp はキャッシュに格納されている "SELECT * FROM T; T TIMEOUT
-1" にヒットする
523728-001J
6-1
第 6 章 クエリ・プラン・キャッシング
SQL/MX コンパイラは、これらの CONTROL QUERY DEFAULT ステートメントに同じように応答しま
す。
6-2
523728-001J
第 6 章 クエリ・プラン・キャッシング
6.1
キャッシュ可能なクエリのタイプ
クエリ・プラン・キャッシングの対象となるクエリには、単純な TP スタイルの INSERT、UPDATE、
DELETE、SELECT、および JOIN があります。2 つのクエリの正規形式が同じであれば、それらのクエリ
はキャッシングという観点から見れば等価であるとみなされます。クエリ・キャッシングを可能にするに
は、クエリの正規形式を次のようにします。
□ 意味のない余白文字の違いをなくす。
□ 意味のない大文字と小文字の違いをなくす。
□ SELECT リストで｢*｣表記を展開する。
□ すべてのオブジェクト名を解決して完全修飾名にする。
□ ほとんどの定数リテラルをパラメータに置き換える。
□ 現行の mxcmp セッションで以前に実行された CONTROL QUERY DEFAULT ステートメントと
CONTROL TABLE ステートメントをすべてエンコードする。
クエリ・キャッシングは、コンパイル済みプランとプランの質がリテラル定数の実際の値の影響を受け
ず、かつ再利用される可能性の高いクエリに限定されます。
SQL/MX コンパイラは、更新あるいは返すローの数が最大でも 1 つであることが確実であれば、TP ス
タイルの複数のクエリに対して同じプランを生成します。次の例でテーブル T のプライマリ・キー・カラ
ムが K であるとすると、いずれも最大で 1 つのローを返す、あるいは更新することが保証されます。これ
らはすべてキャッシュ可能なクエリです。
DELETE FROM T WHERE K=1;
UPDATE T SET C=1 WHERE K=2;
SELECT * FROM T WHERE K=1;
INSERT INTO T(K,C) VALUES(2,1);
6.1.1 キャッシュ可能な式の例
□ 動的パラメータ
UPDATE T SET C=? WHERE K=?;
□ 算術式
SELECT m + n - p * q / r FROM T WHERE K=?;
□ 集計関数 (MAX、MIN、SUM、AVG、COUNT はキャッシュ可能)
SELECT MAX(i), MIN(i), SUM(i), AVG(i), COUNT(DISTINCT i)
FROM T WHERE K=?;
□ 連結
UPDATE T SET D=D||'1', E=CONCAT(E,'z') WHERE K=?;
523728-001J
6-3
第 6 章 クエリ・プラン・キャッシング
□ ストリング関数 (CHAR LENGTH、OCTET LENGTH、LCASE、LOWER、UCASE、UPPER、UPSHIFT
はキャッシュ可能)
SELECT CHAR LENGTH(d), OCTET LENGTH(d), LCASE(d), LOWER('A'), UCASE(d),
UPPER('a'), UPSHIFT('b') FROM T;
□ 日付時刻関数 (CONVERTTIMESTAMP、JULIANTIMESTAMP、CURRENT TIMESTAMP、CURRENT
DATE、CURRENT TIME、CURRENT、NOW、DATEFORMAT、DAY、DAYNAME、DAYOFMONTH、
DAYOFWEEK、DAYOFYEAR、FIRSTDAYOFYEAR、HOUR、MINUTE、MONTH、MONTHNAME、
QUARTER、SECOND、WEEK、YEAR FUNCTIONS )
UPDATE T SET
TS=CONVERTTIMESTAMP(JULIANTIMESTAMP(CURRENT_TIMESTAMP))
WHERE K=?;
SELECT CURRENT_DATE, CURRENT_TIME, DATEFORMAT(NOW(),USA),
DATEFORMAT(NOW(),EUROPEAN), DAY(CURRENT), DAYNAME(NOW(), DAYOFMONTH(NOW()),
DAYOFWEEK(NOW()), DAYOFYEAR(NOW()), FIRSTDAYOFYEAR(NOW()), HOUR(NOW()),
MINUTE(NOW)), MONTH(NOW()), MONTHNAME(NOW()), QUARTER(NOW()), SECOND(NOW()),
WEEK(NOW()), YEAR(NOW()) FROM (VALUES(1)) AS T;
□ CASE 式
SELECT CASE i WHEN 3 THEN 'YES' ELSE 'NO' END FROM T;
□ 算術関数 (ABS、ATAN、ATAN2、CEILING、COS、COSH、DEGREES、EXP、FLOOR、LOG、LOG10、
PI、POWER、RADIANS、SIGN、SIN、SINH、SQRT、TAN、TANH )
SELECT ABS(i), ATAN(10), ATAN2(x,y), CEILING(r), COS(i), COSH(i),
DEGREES(i), EXP(i), FLOOR(i), LOG(i), LOG10(i), PI(), POWER(b,e),
RADIANS(i), SIGN(i), SIN(i), SINH(i), SQRT(i), TAN(i), TANH(i) FROM T;
□ 置換関数
UPDATE T SET job=replace(job, 'IM', 'IT') WHERE K=?;
□ 2 テーブル単一ロー・ジョインはキャッシュ可能。次の例で、テーブル T のプライマリ (パーティショ
ン)・キーが K、テーブル U のプライマリ (パーティション)・キーが J であれば、この 2 テーブル単一
ロー・ジョインはキャッシュ可能。
SELECT * FROM T, U WHERE (K,J)=(?,?) AND K=J;
ここに掲載されていないこれ以外の関数はすべてキャッシュできません。
リテラル値だけが異なる類似する複数の TP スタイルのクエリに対して、コンパイラは同じプランを生
成することが保証されています。次の 3 つの例に対して、同じプランが生成されます。
DELETE FROM T WHERE K=9999;
DELETE FROM T WHERE K=7;
DELETE FROM T WHERE K=?;
6-4
523728-001J
第 6 章 クエリ・プラン・キャッシング
次の 3 つの例にも同じプランが生成されます。
UPDATE T SET C=35 WHERE K=14;
UPDATE T SET C=7 WHERE K=31;
UPDATE T SET C=? WHERE K=?;
クエリ・プラン・キャッシングでは、あるクエリをキャッシュ内のクエリと比較するときに、TP スタイ
ルのクエリに含まれているほとんどのリテラル値を事実上ワイルド・カードとして扱います。ただし、す
べてのリテラル値をワイルド・カードとして扱うわけではありません。たとえば、次の例では、パターン
文字とエスケープ文字は比較時にワイルド・カードとして扱われません。
SELECT * FROM T WHERE K=1 AND S LIKE '\_C%' escape '\';
次のクエリは、クエリの比較時に上記のクエリと同等であるとはみなされません。
SELECT * FROM T WHERE K=1 AND S LIKE '\$C%' escape '\';
6.1.2 キャッシュ不可能なクエリの例
□ LIKE 述語だけが含まれているクエリ
SELECT * FROM T WHERE S LIKE 'c%'; -- キャッシュ不可能
ただし、キー等価述語と LIKE 述語の論理積はキャッシュ可能
SELECT * FROM T WHERE K=? AND S LIKE 'c%';
□ OR 述語だけが含まれているクエリ
SELECT * FROM T WHERE a=1 OR b=2; -- キャッシュ不可能
ただし、キー等価述語と OR 述語の論理積はキャッシュ可能
SELECT * FROM T WHERE K=? and (a=1 OR b=2);
□ BETWEEN 述語だけが含まれているクエリ
SELECT * FROM T WHERE a BETWEEN 1 AND 9; -- キャッシュ不可能
SELECT * FROM T WHERE K=? AND (a BETWEEN 1 AND 9); -- キャッシュ不可能
□ IN 述語だけが含まれているクエリ
SELECT * FROM T WHERE i IN (1,2); -- キャッシュ不可能
ただし、キー等価述語と IN 述語の論理積はキャッシュ可能
SELECT * FROM T WHERE K=? AND i IN (1,2); -- キャッシュ可能
また、単一値キー IN 述語もキャッシュ可能
SELECT * FROM T WHERE K IN (1);
523728-001J
6-5
第 6 章 クエリ・プラン・キャッシング
□ NOT 述語だけが含まれているクエリ
SELECT * FROM T WHERE NOT(i IN (1,2)); -- キャッシュ不可能
SELECT * FROM T WHERE NOT (K<>1); -- キャッシュ不可能
ただし、キー等価述語と NOT 述語の論理積はキャッシュ可能
SELECT * FROM T WHERE K=? AND NOT (i IN (1,2));
□ 6-3 ページの「キャッシュ可能な式の例」のリストに掲載されている以外の関数コールが含まれている
クエリ
SELECT * FROM T WHERE K=? AND SUBSTRING(c,1,1)='z'; -- キャッシュ不可能
□ サブクエリが含まれているクエリ
SELECT * FROM T WHERE K=? AND N=(SELECT MAX (b) FROM t); -- キャッシュ不可能
□ 和 (UNION)、共通 (INTERSECTION)、差 (DIFFERENCE)、商 (DIVISION)、およびテーブル値ストア
ド・プロシージャが含まれているクエリ
SELECT a FROM t UNION SELECT b FROM s; -- キャッシュ不可能
□ 複合ステートメントまたはローセットが含まれているクエリ
□ TRANSPOSE、SAMPLE、SEQUENCE、OFFSET、あるいはそれ以外のデータ・マイニング述語が含
まれているクエリ
□ データ定義言語 (DDL) ステートメント
□ データ制御言語 (DCL) ステートメント
6-6
523728-001J
第 6 章 クエリ・プラン・キャッシング
6.2
クエリ・キャッシュの適切サイズ
クエリ・キャッシュの適切なサイズを選択するには、まずアプリケーションを調べます。
開発の段階でクエリをコンパイルしていて、それ以降の開発や運用の段階ではそれらのクエリをほとん
ど再コンパイルすることがない静的なアプリケーションの場合には、QUERY_CACHE にデフォルト設定
である 0 を指定して、プラン・キャッシングを無効にしてください。
事前に確定していない文字を使ったクエリを多数処理するブック・サーチ・エンジンのような動的アプ
リケーションでは、頻繁に処理されるクエリのほとんどを保持できるサイズを QUERY_CACHE サイズと
して指定できます。たとえば、あるアプリケーションでは 40 種類のクエリを処理し、1 つのクエリのプラ
ンの平均サイズが 100 KB であるとすると、QUERY_CACHE の最適なサイズは 4000 KB になります。
アプリケーションでは、CONTROL QUERY DEFAULT コマンドを使用して QUERY_CACHE のサイズ
を動作中に変更できます。たとえば、トランザクション処理 (TP) と意思決定支援システム (DSS) の両方の
クエリを実行する混在モードのアプリケーションでは、TP モードに切り替わる直前に QUERY_CACHE サ
イズを増やすことで、より多くの TP クエリを保持し、キャッシュできます。同様に、DSS モードに切り
替わる直前に QUERY_CACHE サイズを減らすこともできます。
クエリのコンパイルと実行に多くの時間を費やす動的アプリケーションでは、GENERATE_EXPLAIN を
デフォルト設定である OFF にすることで設定された QUERY_CACHE サイズでより多くのクエリを保持
し、キャッシュに格納できます。GENERATE_EXPLAIN を OFF にすると、TP スタイルのクエリではプ
ランの平均サイズが約 15% 小さくなるので、クエリ・プラン・キャッシュにクエリを約 15% 多く保持で
きます。
523728-001J
6-7
第 6 章 クエリ・プラン・キャッシング
6.3
クエリ・プラン・キャッシングの統計情報
SQL/MX には、キャッシングに関する情報を取り出すための便利な方法が用意されており、保存された
プランの現在の状態に加えて、キャッシング処理に関する重要な情報を確認することができます。これら
の情報は 2 つの仮想テーブルに格納されていて、物理テーブルと同様、SELECT ステートメントを使用し
て参照できます。クエリ・キャッシングの関数である QUERYCACHE と QUERYCACHEENTRIES は、
MXCI プロンプトから、パラメータなしで実行できます。
クエリ・プランがキャッシュされていないと、ローは返されません。
構文については、『NonStop SQL/MX リファレンス・マニュアル』を参照してください。
6-8
523728-001J
第 6 章 クエリ・プラン・キャッシング
6.4
クエリ・プラン・キャッシング属性のデフォルト・テーブル設定
この節では、クエリ・プラン・キャッシングの外部属性の追加情報を説明します。これら属性の設定に
ついては、
『NonStop SQL/MX リファレンス・マニュアル』の｢デフォルト・テーブル｣の項を参照してくだ
さい。
□ QUERY_CACHE
システム定義のデフォルト設定: 1024 KB
設定可能な値: 0 ∼ 4194303
QUERY_CACHE の値は、キャッシュをどのサイズまで拡張できるかを KB 単位で設定します。デフォ
ルト設定は 1024 で、これは、現在のセッションで 1024 KB まで拡張できるクエリ・キャッシュを有効
にします。
QUERY_CACHE の最大値は 4194303 ですが、QUERY_CACHE をホスト・マシンの物理メモリの何分
の 1 かにあたる大きさ以上の値に設定しないでください。そのように設定すると、HP NonStop Kernel
オペレーティング・システムが SQL/MX コンパイラをホスト・マシンの物理メモリに何回もスワップ・
イン/スワップ・アウトするため、パフォーマンスが低下する恐れがあります。QUERY_CACHE に、ホ
スト・マシンの物理メモリの 10% を超える値を設定しないのが賢明な方法です。
新しいエントリによってクエリ・キャッシュのサイズが QUERY_CACHE のデフォルト値を超えると、
現在あるエントリが削除されます。削除されるエントリは、LRU (least recently used) ベース、すなわ
ち最も長い間使用されていないエントリから順に選択され、また、固定エントリであるかどうかと、デ
QUERY_CACHE_MAX_VICTIMS
も 考 慮 さ れ ま す。6 - 1 0
「QUERY_CACHE_STATEMENT_PINNING」を参照してください。
フォルトの
ページの
現在のセッションでクエリ・キャッシュを無効にするには、QUERY_CACHE を 0 に設定します。その
段階でクエリ・キャッシュが割り当てられていると、この設定によって解放されます。
□ QUERY_CACHE_MAX_VICTIMS
システム定義のデフォルト設定: 10 キャッシュ・エントリ
設定可能な値: 0 ∼ 4194303
この属性は、新しいエントリをキャッシュに格納し、しかもキャッシュ・サイズの制限を超えないよう
にするために、現在格納されているエントリのうちの最大でいくつを解放できるのかを指定します。
キャッシュ・エントリの解放にあたっては、コンパイラは、解放するエントリのサイズの合計が新しい
エントリのサイズより大きく、かつ最も長い間使用されていない非固定エントリを探します。この条件
に当てはまるエントリだけでは足りない場合には、コンパイラは、最も長い間使用されていない固定エ
ントリを探して解放します。この属性に非常に大きな値を設定すると、キャッシュ・エントリをすべて
解放して 1 つの非常に大きなクエリを格納できます。
この属性を 0 に設定すると、キャッシュがいっぱいになってもキャッシュ・エントリ (固定、非固定の
いずれも) を解放できないため、新しいエントリをキャッシュに格納できません。初めに格納した n 個
のクエリがキャッシュを占領してしまいます (n はキャッシュをいっぱいにするのに必要なエントリの
数 )。キャッシュがいっぱいになった状態で新しいエントリが発生した場合、その新しいエントリは
キャッシュに追加されず、すでにキャッシュに置かれているエントリは解放されません。クエリ・プラ
ン・キャッシング機能は透過的なので、エラー・メッセージは発行されません。
523728-001J
6-9
第 6 章 クエリ・プラン・キャッシング
後で QUERY_CACHE_MAX_VICTIMS を 0 以外の値に設定すれば、通常通りの入れ換えが再開しま
す。キャッシュに保持できるエントリの数は、キャッシュ・サイズとキャッシュに格納されるプランの
サイズによって異なります。システム定義のデフォルト設定では、解放できるキャッシュ・エントリの
数は 10 に制限されます。
□ QUERY_CACHE_REQUIRED_PREFIX_KEYS
システム定義のデフォルト設定: 255
設定可能な値: 0 ∼ 255
この属性は、等価述語をキャッシュ可能にするために必要となる、複合プライマリ・キーまたは複合
パーティション・キーのカラムとその数を指定します。この属性に複合キー内のカラムの数より大きい
値を設定すると、そのキーのすべてのカラムが必要になります。システム定義のデフォルト値は 255
で、これは、プライマリ・キーまたはパーティション・キー全体に対する等価述語だけがキャッシュ可
能になるという意味です。クエリ・プランの質を落としたくないのであれば、システム定義のデフォル
ト設定である 255 のままにしておくことをお奨めします。
値 0 は、等価キー述語内に複合プライマリ・キーまたはパーティション・キーのカラムが 1 つでもあれ
ばその述語をキャッシュ可能にできることを表します。0 より大きく、ただしキー内のカラム数より小
さい値 n を指定すると、そのキーの最初の n 個分のカラムがキー述語に存在すればその述語をキャッ
シュ可能にできます。
QUERY_CACHE_REQUIRED_PREFIX_KEYS が 1 で、T テーブルの複合プライマリ・キーはカラム
a、b、c から構成されているとします。QUERY_CACHE_REQUIRED_PREFIX_KEYS が 1 に設定され
て いる の で、キー の 最初 の カラム (a) が等価述語であれば、そのクエリはキャッシュ可能です。
QUERY_CACHE_REQUIRED_PREFIX_KEYS の設定が 2 の場合は、(a, b, c) の有効なプリフィックス
は (a, b) と (a, b, c) です。つまり、次のクエリがキャッシュ可能です。
SELECT * FROM T WHERE a=1 AND b = 20;
DELETE FROM T WHERE (a,b,c)=(9,909,10);
ただし、次のクエリはキャッシュ不可能です。
SELECT * FROM T WHERE a=77;
DELETE FROM T WHERE (b,c)=(1,23);
□ QUERY_CACHE_STATEMENT_PINNING
システム定義のデフォルト設定: OFF
設定可能な値: ON、OFF、CLEAR
この属性は、クエリをキャッシュに格納するときに、そのクエリを固定とするか、あるいは非固定とす
るかを制御します。重要なクエリやコンパイル時間に関する要件が厳しいクエリは、必要なときにキャッ
シュ内に確実に格納されているようにしたい場合があります。クエリをキャッシュ内に固定しておけ
ば、通常はそのクエリがキャッシュから削除されることはありません。ただし、固定クエリだけでキャッ
シュがいっぱいになった場合は例外です。その場合は、最も長い間使用されていない固定エントリが削
除されることになります。
システム定義のデフォルト設定である OFF に設定すると、それ以降のクエリ・キャッシュ・エントリ
はすべて非固定になります。
値を CLEAR に設定すると、それ以降のクエリ・キャッシュ・エントリはすべて非固定になり、キャッ
シュ内の固定エントリもすべて非固定になります。
値 ON は、それ以降のすべてのクエリ・キャッシュ・エントリを固定にすることを意味します。
6-10
523728-001J
第 6 章 クエリ・プラン・キャッシング
6.4.1 QUERYCACHE 関数
クエリ・プラン・キャッシングでは、利用状況に関する統計情報が自動的に収集されます。テーブル値
ストアド関数である QUERYCACHE テーブル値ストアド関数を呼び出すと、1 ローだけが含まれるテーブ
ルからこれらの統計情報の現在の状態が収集され、返されます。これらの統計情報は mxcmp セッションの
開始時に初期化され、各 mxcmp セッションは独立した統計情報のセットを保持します。
次の表は、QUERYCACHE テーブルの統計情報です。
523728-001J
カラム名
データ・タイプ
説明
AVG_PLAN_SIZE
INT UNSIGNED
すべてのキャッシュ・エントリの合計サ
イズ (KB 単位) をエントリ数で割った値
CURRENT_SIZE
INT UNSIGNED
クエリ・キャッシュの現在のサイズ (KB
単位)
MAX_CACHE_SIZE
INT UNSIGNED
最大キャッシュ・サイズ (KB 単位)
MAX_NUM_VICTIMS
INT UNSIGNED
新しいエントリのための空きを作るため
に削除できるプランの最大数
NUM_ENTRIES
INT UNSIGNED
キャッシュ内のクエリ・エントリの合計数
NUM_PINNED
INT UNSIGNED
固定エントリの合計数
NUM_COMPILES
INT UNSIGNED
完 全 コ ン パ イ ル 要 求 の 合 計 数
(DESCRIBE と SHOWSHAPE を除く)
NUM_RECOMPILES
INT UNSIGNED
再コンパイルの合計回数。キャッシュされ
たプランの再コンパイルが発生するのは、
参照しているテーブルが作成しなおされ
たか、テーブル定義が変更されたとき。
NUM_RETRIES
INT UNSIGNED
最初はキャッシュがオンになっていたた
めに失敗し (mxcmp での問題が原因)、そ
の後にキャッシュがオフになったことで
成功したコンパイルの数
NUM_CACHEABLE_PARSING
INT UNSIGNED
mxcmp がそのクエリの構文解析 (parsing)
の後、かつ結合 (binding) の前の段階で処
キャッ
理したSQL ステートメントの中で、
シング条件を満たした総数
NUM_CACHEABLE_BINDING
INT UNSIGNED
mxcmp がクエリの結合 (binding) の後、か
つ変換 (transformation) の前の段階で処理
した SQL ステートメントの中で、キャッ
シング条件を満たした総数
NUM_CACHE_HITS_PARSING
INT UNSIGNED
mxcmp が構文解析 (parsing) の後、かつ結
合 (binding) の前の段階で処理した SQL
ステートメントの中で、ヒットしたもの
の総数
6-11
第 6 章 クエリ・プラン・キャッシング
カラム名
データ・タイプ
説明
NUM_CACHE_HITS_BINDING
INT UNSIGNED
mxcmp がクエリの結合 (binding) の後、か
つ変換 (transformation) の前の段階で処理
した SQL ステートメントの中で、ヒット
したものの総数
NUM_PIN_HITS_PARSING
INT UNSIGNED
構 文 解 析 ( p a r s i n g ) の 後、か つ 結 合
(binding) の前に発生した固定エントリに
対するヒットの合計数
NUM_PIN_HITS_BINDING
INT UNSIGNED
結合
(binding)
の 後、か つ 変 換
(transformation) の前に発生した固定エン
トリに対するヒットの合計数
NUM_CACHEABLE_TOO_LARGE
INT UNSIGNED
mxcmp が処理した SQL ステートメント
の中で、キャッシュ可能な条件を満足し
たものの、プランが長過ぎてキャッシュ
に収まりきれなかったものの数
NUM_DISPLACED
INT UNSIGNED
新しいエントリのための空きを作るため、
またはキャッシュのサイズ変更か再コン
パイルが発生したために、キャッシュか
ら削除されたエントリの数
OPTIMIZATION_LEVEL
CHAR(10)
現 行 の ク エ リ 最 適 化 の 要 求 レ ベ ル。
MINIMUM、MEDIUM、HIGH のいずれ
か。
PINNING_STATE
CHAR(4)
現在、固定エントリになっているかどう
かを示す。ON または OFF。
6.4.2 QUERYCACHEENTRIES 関数
クエリ・プラン・キャッシングでは、キャッシュの各エントリに関する統計情報を自動的に収集します。
QUERYCACHEENTRIES テーブル値ストアド関数を呼び出すと、この関数は、キャッシュの中の各エン
トリに対して 1 ローが含まれているテーブルから統計情報を収集し、返します。この統計情報は mxcmp
セッションの開始時に初期化され、各 mxcmp セッションが独立した統計情報のセットを保持します。
次の表は、QUERYCACHEENTRIES テーブルの統計情報です。
6-12
523728-001J
第 6 章 クエリ・プラン・キャッシング
523728-001J
カラム名
データ・タイプ
説明
ROW_ID
INT UNSIGNED
0 を起点とするシーケンシャル番号。エン
トリ番号 0 が、最後に使用された (MRU:
most recently used) エントリ。新しいエン
トリがキャッシュに保存された場合、ま
たはクエリが一致した場合には、そのク
エリが 0 に入れ替わり、それ以外のエン
トリはキャッシュから削除されるか、今
までの番号に 1 が加算される。エントリ
番号 1 は、現状の MRU の次に最近使用さ
れたエントリということになる。
ROW_ID
が最も大きいエントリが最も長い間使用
されていない (LRU: least recently used) エ
ントリであり、新しいエントリと入れ替
えに削除されることになる。
PLAN_ID
LARGEINT
プライマリ・キー。プランをユニークに
識別するために各プランに格納されてい
るシステム生成のタイムスタンプ。この
カラムは Explain テーブルには表示され、
このカラムを使用して 2 つのテーブルを
ジョインできる。
TEXT
CHAR(1024)
オリジナルの SQL ステートメントのテキ
スト。
ENTRY_SIZE
INT UNSIGNED
このエントリのサイズ (バイト単位)
NUM_HITS
INT UNSIGNED
このエントリの合計ヒット数
PHASE
CHAR(10)
このエントリに関連付けられているプラ
ンがキャッシュされた後の mxcmp フェー
ズが含まれる (parsing または binding)
OPTIMIZATION_LEVEL
CHAR(10)
このクエリがコンパイルされたときに指
定されていたコード最適化レベルを示す。
MINIMUM、MEDIUM、HIGH のいずれか
CATALOG_NAME
CHAR(40)
クエリのコンパイル時のデフォルト・カ
タログの名前
SCHEMA_NAME
CHAR(40)
クエリのコンパイル時のデフォルト・ス
キーマの名前
NUM_PARAMS
INT UNSIGNED
クエリの中で、コンパイル時に内部的に
パラメータに変更された定数の数
PARAM_TYPES
CHAR(1024)
パラメータに変更された定数のタイプ (
カンマ区切りリスト)。該当するものがな
ければ空白。
PLAN_LENGTH
INT UNSIGNED
このエントリに関連付けられているコン
パイル済みプランのサイズ (バイト単位)
IS_PINNED
CHAR(6)
このエントリが固定エントリであるかど
うかを示す。ON または OFF。
6-13
第 6 章 クエリ・プラン・キャッシング
カラム名
データ・タイプ
説明
COMPILATION_TIME
INT UNSIGNED
このエントリに関連付けられたクエリの
コンパイルにかかった時間 (ミリ秒単位)
AVERAGE_HIT_TIME
INT UNSIGNED
このエントリに対するキャッシュ・ヒッ
トの平均処理時間 (ミリ秒単位)
SHAPE
CHAR (1024)
このエントリに関連付けられたクエリに
要求された CONTROL QUERY SHAPE。
シェイプが要求されていなければ空白。
ISOLATION_LEVEL
CHAR(20)
クエリに関連付けられたトランザクショ
ン隔離レベル。READ_UNCOMMITTED、
R E A D _ C O M M I T T E D 、
REPEATABLE_READ、SERIALIZABLE、
NOT_SPECIFIED のいずれか。
ACCESS_MODE
CHAR(20)
このクエリに関連付けられたトランザク
シ ョ ン・ア ク セ ス・モ ー ド 値。
R E A D _ O N L Y 、R E A D _ W R I T E 、
NOT_SPECIFIED のいずれか。
AUTO_COMMIT
CHAR(15)
このクエリに関連付けられたトランザク
シ ョ ン 自 動 コ ミ ッ ト 値。O N 、O F F 、
NOT_SPECIFIED のいずれか。
ROLLBACK_MODE
CHAR(15)
このクエリに関連付けられたトランザク
シ ョ ン・ロ ー ル バ ッ ク・モ ー ド 値。
W A I T E D 、N O W A I T E D 、
NOT_SPECIFIED のいずれか。
6.4.3 クエリ・プラン・キャッシング仮想テーブルに対するクエリ
クエリ・プラン・キャッシング仮想テーブルに対して SELECT ステートメントを使用すると、このテー
ブルの一部あるいはすべてのカラムのクエリと表示が可能です。SELECT ステートメントでは、キーワー
ド table の後に、この仮想テーブルをカッコで囲んで指定します。さらに、そのカッコの中の仮想テーブル
名の後に、カッコをもう 1 組記述します。情報は、マシン可読形式で返されます。
クエリ・プラン・キャッシュにプランが 1 つも格納されていない場合には、ローは返されません。
たとえば、次のクエリでは、QUERYCACHE 仮想テーブルからすべてのカラムを選択しています。
NUM_ENTRIES の値が 1 になっていることから、キャッシュにはプランが 1 つだけ格納されていることが
分かります。
SELECT * FROM TABLE(QUERYCACHE());
AVG_PLAN_SIZE
31
CURRENT_SIZE
35
MAX_CACHE_SIZE
1024
MAX_NUM_VICTIMS
10
NUM_ENTRIES
1
NUM_PINNED
0
NUM_COMPILES
21
NUM_RECOMPILES
0
6-14
523728-001J
第 6 章 クエリ・プラン・キャッシング
NUM_RETRIES
NUM_CACHEABLE_PARSING
NUM_CACHEABLE_BINDING
NUM_CACHE_HITS_PARSING
NUM_CACHE_HITS_BINDING
NUM_PIN_HITS_PARSING
NUM_PIN_HITS_BINDING
NUM_CACHEABLE_TOO_LARGE
NUM_DISPLACED
OPTIMIZATION_LEVEL
PINNING_STATE
0
0
1
0
0
0
0
0
0
MEDIUM
OFF
--- 1 row(s) selected.
QUERYCACHE 関数は 1 ローだけのテーブルですが、この出力は読みやすい形式に変更されています。
次のクエリでは、QUERYCACHEENTRIES 仮想テーブルからすべてのカラムを選択しています (読みや
すい形式に変更されています)。
SELECT * FROM TABLE(QUERYCACHEENTRIES());
ROW_ID
-----0
1
2
PLAN_ID
-----------------211894097543468116
211894097552547493
211894097548497817
NUM_HITS
-------1
0
0
NUM_PARAMS
---------0
0
0
PHASE
---------BINDING
BINDING
BINDING
OPTIMIZATION_LEVEL
---------------------MEDIUM
MEDIUM
MEDIUM
PARAM_TYPES
-----------
AVERAGE_HIT_TIME
---------------41
0
0
TEXT
-------------------------select * from employee;
select * from job;
select * from dept;
SHAPE
------Cut (0)
Cut (0)
Cut (0)
PLAN_LENGTH
----------31752
24504
29144
CATALOG_NAME
-----------SAMDBCAT
SAMDBCAT
SAMDBCAT
IS_PINNED
--------OFF
OFF
OFF
ISOLATION_LEVEL
--------------READ COMMITTED
READ COMMITTED
READ COMMITTED
ENTRY_SIZE
---------32410
24968
29730
SCHEMA_NAME
----------PERSNL
PERSNL
PERSNL
COMPILATION_TIME
----------------334
54
96
ACCESS_MODE
-----------READ/WRITE
READ/WRITE
READ/WRITE
AUTO_COMMIT
----------ON
ON
ON
ROLLBACK_MODE
-------------NOT SPECIFIED
NOT SPECIFIED
NOT SPECIFIED
--- 3 row(s) selected.
523728-001J
6-15
第 6 章 クエリ・プラン・キャッシング
6.4.4 DISPLAY_QC コマンドと DISPLAY_QC_ENTRIES コマンドを使用した、クエリ・プラ
ン・キャッシング統計情報の確認
DISPLAY_QC コマンドと DISPLAY_QC_ENTRIES コマンドを使用すると、クエリ・プラン・キャッシ
ング統計情報の中で最もよく利用されるカラムを手軽に確認できます。これらのコマンドは MXCI プロン
プトから入力し、パラメータはありません。クエリ・プラン・キャッシュにプランが 1 つも格納されてい
ない場合には、ローは返されません。
DISPLAY_QC コマンド
DISPLAY_QC コマンドは、QUERYCACHE 関数の情報にアクセスし次のカラムを表示します。
カラム名
タイプ
QUERYCACHE 関数のソース・カラム
AVGSIZE
CHAR(8)
AVG_PLAN_SIZE
CURSIZE
CHAR(8)
CURRENT_SIZE
MAXSIZE
CHAR(8)
MAX_CACHE_SIZE
NPINNED
CHAR(8)
NUM_PINNED
NRECOM
CHAR(8)
NUM_RECOMPILES
NRETR
CHAR(8)
NUM_RETRIES
NCACHE
CHAR(8)
NUM_CACHEABLE_PARSING +
NUM_CACHEABLE_BINDING
NHITS
CHAR(8)
NUM_CACHE_HITS_PARSING +
NUM_CACHE_HITS_BINDING
>>DISPLAY_QC;
AVGSIZE
CURSIZE
MAXSIZE
NPINNED
NRECOM
NRETR
NCACHE
NHITS
------- -------- -------- -------- -------- -------- -------- -------31
35
1024
0
0
0
1
0
--- SQL operation complete.
6-16
523728-001J
第 6 章 クエリ・プラン・キャッシング
DISPLAY_QC_ENTRIES コマンド
DISPLAY_QC_ENTRIES コマンドは、QUERYCACHEENTRIES 関数の情報にアクセスし次のカラムを
表示します。
カラム名
タイプ
QUERYCACHEENTRIES 関数のソース・カラム
ROWID
CHAR(8)
ROW_ID
TEXT
CHAR(36)
TEXT
NUMHITS
CHAR(8)
NUM_HITS
PH
CHAR(1)
PHASE
COMPTIME
CHAR(8)
COMPILATION_TIME
AVGHITTIME
CHAR(8)
AVERAGE_HIT_TIME
DISPLAY_QC_ENTRIES;
ROWID
TEXT
NUMHITS
PH COMPTIME AVGHTIME
-------- ------------------------------------ -------- - -------- -------0
1
2
select * from job;
select * from dept;
select * from employee;
0
0
0
B 88
B 115
B 1605
0
0
0
--- SQL operation complete.
523728-001J
6-17
第 6 章 クエリ・プラン・キャッシング
6-18
523728-001J
第 7 章 演算子と演算子グループ
この章では、EXPLAIN 関数を使用するとき、および Visual Query Planner によるクエリ実行プランを表
示するときの Description カラムを理解します。SQL/MX 関連のマニュアルでは、演算子をノードまたは
ノード・タイプと呼ぶ場合があります。
この章では、すべての演算子とその属する演算子グループを、アルファベット順に説明します。
ほとんどの演算子については例をともない、参照演算子を含むクエリの一部に対応する EXPLAIN 出力
を示しています。場合によっては、特定の演算子を示すためクエリが強制されていることもあります。
EXPLAIN 出力の読み方については、第 4 章「クエリ実行プランの確認」を参照してください。
演算子グループは、同じタイプの演算子を簡単にグループ化するために使用されます。たとえば、Join
グループには、ジョインを使用するすべての演算子が含まれます。
523728-001J
7-1
第 7 章 演算子と演算子グループ
7.1
7-2
演算子グループと演算子の一覧
グループ
演算子
ユーザ定義ルーチン
(UDR: User-Defined
Routine)
CALL 演算子
DAM Subset
FILE_SCAN 演算子
INDEX_SCAN 演算子
SUBSET_DELETE 演算子
SUBSET_UPDATE 演算子
DAM Unique
CURSOR_DELETE 演算子
CURSOR_UPDATE 演算子
FILE_SCAN_UNIQUE 演算子
INDEX_SCAN_UNIQUE 演算子
UNIQUE_DELETE 演算子
UNIQUE_UPDATE 演算子
Data Mining
SAMPLE 演算子
SEQUENCE 演算子
TRANSPOSE 演算子
Exchange
ESP_EXCHANGE 演算子
PARTITION_ACCESS 演算子
SPLIT_TOP 演算子
Groupby
HASH_GROUPBY 演算子
HASH_PARTIAL_GROUPBY_LEAF 演算子
HASH_PARTIAL_GROUPBY_ROOT 演算子
SHORTCUT_SCALAR_AGGR 演算子
SORT_GROUPBY 演算子
SORT_PARTIAL_AGGR_LEAF 演算子
SORT_PARTIAL_AGGR_ROOT 演算子
SORT_PARTIAL_GROUPBY_LEAF 演算子
SORT_PARTIAL_GROUPBY_ROOT 演算子
SORT_SCALAR_AGGR 演算子
Insert
INSERT 演算子
INSERT_VSBB 演算子
523728-001J
第 7 章 演算子と演算子グループ
グループ
演算子
Join
HYBRID_HASH_ANTI_SEMI_JOIN 演算子
HYBRID_HASH_JOIN 演算子
HYBRID_HASH_SEMI_JOIN 演算子
LEFT_HYBRID_HASH_JOIN 演算子
LEFT_MERGE_JOIN 演算子
LEFT_NESTED_JOIN 演算子
LEFT_HYBRID_HASH_JOIN 演算子
LEFT_ORDERED_HASH_JOIN 演算子
MERGE_ANTI_SEMI_JOIN 演算子
MERGE_JOIN 演算子
MERGE_SEMI_JOIN 演算子
NESTED_ANTI_SEMI_JOIN 演算子
NESTED_JOIN 演算子
NESTED_SEMI_JOIN 演算子
ORDERED_HASH_ANTI_SEMI_JOIN
ORDERED_HASH_JOIN 演算子
ORDERED_HASH_SEMI_JOIN 演算子
TUPLE_FLOW 演算子
Materialize
MATERIALIZE 演算子
MATERIALIZE 演算子
Merge_Union
MERGE_UNION 演算子
Root
ROOT 演算子
Rowset
PACK 演算子
UNPACK 演算子
Sort
SORT 演算子
Stored Function
EXPLAIN 演算子
Tuple
EXPR 演算子
TUPLELIST 演算子
VALUES 演算子
7.1.1 CALL 演算子
ユーザ定義ルーチン (UDR)
CALL 演算子は、UDR の使用を示します。
CALL 演算子には子ノードがありません。この演算子の Description フィールドには次の情報があります。
523728-001J
7-3
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
input_values
CALL ステートメントへの入力値。IN パラ
メータまたは INOUT 各パラメータに対して
1 つの SQL/MX 式が返される。OUT パラ
メータに対しては何も返されない。
expr(text)
parameter_modes
プロシージャの SQL パラメータ・モードを
指定する文字列。IN パラメータは I、OUT
パラメータは O、INOUT パラメータは N で
表される。キャラクタは、1 つのスペースで
区切られる。SQL パラメータがないと、none
という値が返される。
text
routine_name
プロシージャの ANSI 名
text
routine_label
ストアド・プロシージャ・ラベルの Guardian
名
text
sql_access_mode
プロシージャの SQL アクセス・モード
text
external_name
Java メソッド名
text
external_path
Java クラス・ファイルが含まれる OSS ディ
レクトリまたは JAR ファイル・パス
text
external_file
Java クラス名。SPJ メソッドが含まれるパッ
ケージ名が接頭辞として付くことがある。
text
signature
内部 Java 仮想マシン (JVM) フォーマットの
SPJ メソッドの Java 署名
text
language
SPJ メソッドの言語。常に Java。
text
runtime_options
CALL ステートメントがコンパイルされた
ときの UDR_JAVA_OPTIONS の設定
text
runtime_option_delimiters
UDR_JAVA_OPTIONS ス ト リ ン グ で オ プ
ションの区切り文字となるストリング (一重
引用符で囲まれている)。この区切り文字は、
常に 1 文字分の空白。
text
CALL 演算子の例を次のクエリで示します。
create procedure mx_proc2(in a int, in b int, inout c int)
external name 'myClass.myMethod'
external path '/usr/spj/classes'
language java parameter style java no sql;
input_values: cast(1), cast(2), cast(?c)
parameter_modes: I I N
routine_name: CAT.SCH.MX_PROC2
routine_label: \BINGO.$DATA10.ZSDL2M3C.NCT8VS00
sql_access_mode: NO SQL
external_name: myMethod
7-4
523728-001J
第 7 章 演算子と演算子グループ
external_path: /usr/spj/classes
external_file: myClass
signature: (II[I)V
language: Java
runtime_options: OFF
runtime_option_delimiters: ' '
7.1.2 CURSOR_DELETE 演算子
DAM Unique グループ
CURSOR_DELETE 演 算 子 は、実 行 プ ラ ン の 中 で 1 ロ ー だ け で 機 能 す る 部 分 を 記 述 し ま す。
CURSOR_DELETE 操作は、まずテーブルからローを読み取り、次に条件に該当する各ローを要求に応じ
て削除します。この操作は、読み取りと削除を 1 つの結合された操作として実行する SUBSET_DELETE
演算子とは異なります。
CURSOR_DELETE 演算子には子ノードがありません。この演算子の Description フィールドには次の情
報があります。
トークン
内容
データ・タイプ
begin_key
開始キー述語の式
expr(text)
CURSOR_DELETE 演算子の例を示します。
DELETE FROM
bbase WHERE
unique1 < 32000;
.
.
8
cursor_delete
part_key_predicates: (indexcol(\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3) =
indexcol(\TESTSYS.$BIG18A.WISC32M.BBASE.UNIQUE3))
begin_key: (indexcol(\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3) =
indexcol(\TESTSYS.$BIG18A.WISC32M.BBASE.UNIQUE3))
7.1.3 CURSOR_UPDATE 演算子
DAM Unique グループ
CURSOR_UPDATE 演 算 子 は、実 行 プ ラ ン の 中 で 1 ロ ー だ け で 機 能 す る 部 分 を 記 述 し ま す。
CURSOR_UPDATE 操作は、まずテーブルからローを読み取り、次に条件に該当する各ローを要求に応じ
て更新します。この操作は、読み取りと更新を 1 つの結合された操作として実行する SUBSET_UPDATE
演算子とは異なります。
CURSOR_UPDATE 演算子には子ノードがありません。この演算子の Description フィールドには次の情
報があります。
523728-001J
トークン
内容
データ・タイプ
new_rec_expr
更新されるローの計算
expr(text)
begin_key
開始キー述語の式
expr(text)
7-5
第 7 章 演算子と演算子グループ
CURSOR_UPDATE 演算子の例を次のクエリで示します。
UPDATE abase SET two = two + 1 WHERE
.
.
4
unique3
<
32000;
cursor_update
new_rec_expr: (\TESTSYS.$BIG18A.WISC32M.ABASE.TWO assign
(cast(indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.TWO)) + cast(1)))
part_key_predicates: (\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2 =
indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2))
begin_key: (\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2 =
indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2))
7.1.4 ESP_EXCHANGE 演算子
Exchange グループ
ESP_EXCHANGE 演算子は、実行プランの中で入力データ・ストリームを再配布する部分を記述します。
この演算子は、複数の ESP 間、マスタ・エグゼキュータと 1 つ以上の ESP の間 、または 1 つの ESP プロ
セスと 1 つの DAM プロセスの間のインタフェースを表します。Exchange 演算子の詳細については、第 8
章「並列性」を参照してください。
ESP_EXCHANGE 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情
報があります。
7-6
トークン
内容
データ・タイプ
buffer_size
メッセージ・バッファのサイズ
integer
record_length
送信レコードのバイト数
integer
top_degree_parallelism
最上位 ESP の数
integer
bottom_degree_parallelism
最下位 ESP の数
integer
top_num_data_streams
最上位パーティションの数
integer
bottom_num__data_streams
最下位パーティションの数
integer
top_partitioning_function
top_partitioning_function のサマリ・
パーテション情報
text
bottom_partitioning_function
パーティション化タイプの説明と、
パラレル・プランのサマリ情報
text
bottom_partition_input_values
ESP が機能するデータ部分を識別す
る内部値
integer
partitioning_expression
データのパーティション化に使用さ
れる式
expr(text)
merged_order
ソート・キーを記述する式
expr(text)
523728-001J
第 7 章 演算子と演算子グループ
ESP_EXCHANGE 演算子の例を次のクエリで示します。
SELECT supp_nation, cust_nation, yr, sum(volume) as revenue
FROM
(SELECT n1.n_name as supp_nation, n2.n_name as
cust_nation, extract(year from l_shipdate) as yr,
CAST(l_extendedprice*(1-l_discount) AS NUMERIC(18,2))
as volume
FROM supplier,lineitem,orders,customer, nation n1,
nation n2
WHERE s_suppkey = l_suppkey
AND o_orderkey = l_orderkey
AND c_custkey = o_custkey
AND s_nationkey = n1.n_nationkey
AND c_nationkey = n2.n_nationkey
AND ((n1.n_name = 'FRANCE' AND
n2.n_name = 'GERMANY')
OR (n1.n_name = 'GERMANY' AND
n2.n_name = 'FRANCE'))
AND l_shipdate BETWEEN DATE '1995-01-01'
AND DATE '1996-12-31') as shipping
GROUP BY supp_nation, cust_nation, yr
ORDER BY supp_nation, cust_nation, yr;
211862597572632956
16 ESP_EXCHANGE
15
?
1.1108888E+001
1.9247573E-001
2.2068891E+000 CPU_TIME: 0.966086
0.966086 IO_TIME: 0.101359 MSG_TIME: 0.071711 IDLETIME: 1.2408
PROBES: 1
bottom_partition_input_values: \:_sys_HostVarLo0, \:_sys_HostVarHi0,
\:_sys_hostVarExclRange
buffer_size: 4166
record_length: 24
top_degree_parallelism: 1
bottom_degree_parallelism: 3
top_num_data_streams: 1
bottom_num_data_streams: 3
bottom_partitioning_function: range partitioned 3 ways on
(([1583]equiv(LINEITEM.L_ORDERKEY) ))
7.1.5 EXPLAIN 演算子
Stored Function グループ
EXPLAIN 演算子は、ストアド関数を実行します。EXPLAIN 演算子の演算子は常に EXPLAIN です。
523728-001J
7-7
第 7 章 演算子と演算子グループ
EXPLAINには子ノードがありません。この演算子の Description フィールドには次の情報があります。
トークン
内容
データ・タイプ
procedure_parameters
EXPLAIN 関数呼び出しのパラメータ
expr(text)
7.1.6 EXPR 演算子
Tuple グループ
EXPR 演算子は、子ノードから受け取る各ローの式を計算し、その式を親ノードに返します。
EXPR 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報がありま
す。
トークン
内容
データ・タイプ
tuple_expr
このノードによって生成されるタプル
expr(text)
7.1.7 FILE_SCAN 演算子
DAM Subset グループ
FILE_SCAN 演算子には、lock_mode や scan_direction といった、特定のアクセス・パスがどのようにス
キャンされるかについての詳細情報が含まれます。
FILE_SCAN 演算子には子ノードがありません。この演算子の Description フィールドには次の情報があ
ります。
7-8
トークン
内容
データ・タイプ
begin_key
開始キー述語の式
expr(text)
end_key
終了キー述語の式
expr(text)
scan_type
FILE_SCAN と、テーブル名
text
scan_direction
forward または reverse
text
lock_mode
no lock、share lock、exclusive
lock のいずれか
text
access_mode
read committed、
read uncommitted、serializable の
いずれか
text
executor_predicates
キー述語でない任意の述語式
expr(text)
key_columns
プライマリ・キーとして使用され
るカラム
expr(text)
key_type
simple または MDAM
text
523728-001J
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
columns_retrieved
返されるカラムの予測数
integer
fast_replydata_move
DAM からのデータ返却に最適化
が使用されているかどうかを示す
識別子。最適化が使用されている
場合は、usedという値が返される。
text
fast_scan
単純スキャン操作に最適化が使用
されているかどうかを示す識別
子。最適化が使用されている場合
は、used という値が返される。
text
FILE_SCAN 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
AND p_size = 15
AND p_type like '%BRASS'
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'EUROPE'
AND ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
211862597476194167
1 FILE_SCAN
?
? PART (\TESTSYS.$DATA14.SPTPCD.PART)
1.0000000E+001
1.1565582E+000
1.1565582E+000 CPU_TIME: 0.001258
0.001258 IO_TIME: 0.054058 MSG_TIME: 0 IDLETIME: 1.1025
PROBES: 1
key_columns: indexcol(\TESTSYS.$DATA14.SPTPCD.PART.P_PARTKEY)
executor_predicates: (cast(indexcol(\TESTSYS.$DATA14.SPTPCD.PART.P_TYPE))
like '%BRASS') and (indexcol(\TESTSYS.$DATA14.SPTPCD.PART.P_SIZE) = 15)
begin_key: (indexcol(\TESTSYS.$DATA14.SPTPCD.PART.P_PARTKEY) = -2147483648)
end_key: (indexcol(\TESTSYS.$DATA14.SPTPCD.PART.P_PARTKEY) = 2147483647)
scan_type: file_scan \TESTSYS.$DATA14.SPTPCD.PART PART scan_direction:
forward
key_type: simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 9
fast_scan: used
fast_replydata_move: used
523728-001J
7-9
第 7 章 演算子と演算子グループ
7.1.8 FILE_SCAN_UNIQUE 演算子
DAM Unique グループ
FILE_SCAN_UNIQUE 演算子は、実行プランの中でユニークなキー値をスキャンしている部分を記述し
ます。この演算子は、0 または 1 個のローを選択します。
FILE_SCAN_UNIQUE 演算子には子ノードがありません。この演算子の Description フィールドには次
の情報があります。
トークン
内容
データ・タイプ
key_columns
プライマリ・キーとして使用される
カラム
expr(text)
begin_key
開始キー述語の式 (終了キー述語と
同じ)
expr(text)
end_key
終了キー述語の式 (開始キー述語と
同じ)
expr(text)
scan_type
FILE_SCAN_UNIQUE とテーブル
名
text
key_type
simple または MDAM
text
lock_mode
no lock、share lock、exclusive lock の
いずれか
text
access_mode
read committed、read uncommitted、
serializable のいずれか
text
columns_retrieved
返されるカラムの予測数
integer
executor_predicates
非キー述語の式
expr(text)
fast_replydata_move
DAM からのデータ返却に最適化が
使用されているかどうかを示す識
別子。最適化が使用されている場合
は、usedという値が返される。
text
fast_scan
単純スキャン操作に最適化が使用
されているかどうかを示す識別子。
最適化が使用されている場合は、
used という値が返される。
text
olt_optimization
短い単純 な操作に最適化が使用さ
れているかどうかを示す識別子。最
適化が使用されている場合は、used
という値が返される。
text
FILE_SCAN_UNIQUE 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
7-10
523728-001J
第 7 章 演算子と演算子グループ
AND
AND
AND
AND
AND
AND
AND
s_suppkey = ps_suppkey
p_size = 15
p_type like '%BRASS'
s_nationkey = n_nationkey
n_regionkey = r_regionkey
r_name = 'EUROPE'
ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
?
XX
211862597476194167
8 FILE_SCAN_UNIQUE
?
? SUPPLIER (\TESTSYS.$DATA14.SPTPCD.SUPPLIER)
1.0000000E+000
2.8289675E-001
2.8289675E-001 CPU_TIME: 0.001129
0.001129 IO_TIME: 0.020397 MSG_TIME: 0 IDLETIME: 0.2625
PROBES: 10
key_columns: indexcol(\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_SUPPKEY)
part_key_predicates:
VEGPred_1297(VEG{SUPPLIER.S_SUPPKEY(828),\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_S
UPPKEY(835),\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY(853),\TESTSYS.$DATA14.SPTPC
D.SX1.S_SUPPKEY(854),PARTSUPP.PS_SUPPKEY(1069),\TESTSYS.$DATA14.SPTPCD.PARTSU
PP.PS_SUPPKEY(1074),\TESTSYS.$DATA14.SPTPCD.PSX1.PS_SUPPKEY(1088),\TESTSYS.$D
ATA14.SPTPCD.PSX1.PS_SUPPKEY(1092),\TESTSYS.$DATA14.SPTPCD.PSX2.PS_SUPPKEY(11
04),\TESTSYS.$DATA14.SPTPCD.PSX2.PS_SUPPKEY(1108)})
begin_key: (indexcol(\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_SUPPKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPKEY))
end_key: (indexcol(\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_SUPPKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPKEY))
scan_type: file_scan_unique \TESTSYS.$DATA14.SPTPCD.SUPPLIER SUPPLIER
key_type: simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 7
fast_replydata_move: used
7.1.9 HASH_GROUPBY 演算子
Groupby グループ
HASH_GROUPBY 演算子は、実行プランの中でグループに影響を与える部分を記述します。グループ値
は個々のローを 1 つのハッシュ・テーブルにハッシュすることで計算されます。新規ローを受け取ると、
エグゼキュータはハッシュ・テーブルにハッシュし、そのハッシュ・テーブルで集計を実行します。
HASH_GROUPBY 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の
情報があります。
523728-001J
7-11
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
selection_predicates
having 句の式
expr(text)
grouping_columns
グループ化しているカラムの式
expr(text)
HASH_GROUPBY 演算子の例を次のクエリで示します。
SELECT l_orderkey,
CAST(SUM(l_extendedprice*(1-l_discount))AS
NUMERIC(18,2)), o_orderdate, o_shippriority
FROM customer,orders,lineitem
WHERE c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1995-03-15'
AND l_shipdate > DATE '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
HAVING sum(l_extendedprice)> 100
ORDER BY 2 DESC,3 ASC;
?
XX
211862597497309538
13 HASH_GROUPBY
12
?
3.3329999E-001
7.2278591E-005
2.2941484E+000
CPU_TIME: 3.70538e-07
IO_TIME: 0
MSG_TIME: 0
IDLETIME: 0
PROBES: 1
grouping_columns: indexcol(\TESTSYS.$DATA14.SPTPCD.ORDERS.O_ORDERKEY),
indexcol(\TESTSYS.$DATA14.SPTPCD.ORDERS.O_ORDERDATE),
indexcol(\TESTSYS.$DATA14.SPTPCD.ORDERS.O_SHIPPRIORITY) aggregates:
sum((cast(indexcol(\TESTSYS.$DATA14.SPTPCD.LINEITEM.L_EXTENDEDPRICE)) *
cast((cast((1 * 100)) indexcol(\TESTSYS.$DATA14.SPTPCD.LINEITEM.L_DISCOUNT)))))
7.1.10 HASH_PARTIAL_GROUPBY_LEAF 演算子
Groupby グループ
HASH_PARTIAL_GROUPBY_LEAF 演算子は、できるだけコスト効率がよくなるデータの読み取り位
置でグループ化操作を (group by) 実行します。この方法により、1 つのクエリのために再配置しなければ
ならないデータ量が削減されます。DAM で実行される場合、HASH_PARTIAL_GROUPBY_LEAF のメモ
リ は 少 量 に 限 定 さ れ ま す。メ モ リ に 入 り き ら な い 任 意 の グ ル ー プ は グ ル ー プ 化 さ れ ず に 渡 さ れ、
HASH_PARTIAL_GROUPBY_ROOT で完全にグループ化されます。HASH_PARTIAL_GROUPBY_LEAF
が DAM で実行されない場合、より多くのメモリを利用できるため、すべてのローがグループ化されます。
複数のプロセスのグループは HASH_PARTIAL_GROUPBY_ROOT で収集されます。
この演算子は、常にツリーの上位に HASH_PARTIAL_GROUPBY_ROOT 演算子を伴う必要があり、そ
こでクエリは完了します。
7-12
523728-001J
第 7 章 演算子と演算子グループ
HASH_PARTIAL_GROUPBY_LEAF 演算子 には子ノードが 1 つあります。この演算子の Description
フィールドには次の情報があります。
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
selection_predicates
having 句の式
expr(text)
grouping_columns
グループ化しているカラムの式
expr(text)
HASH_PARTIAL_GROUPBY_LEAF 演算子の例を次のクエリで示します。
SELECT a.ten, MAX(a.unique2)
FROM $big18a.wisc32m.abase a, $big18a.wisc32m.bbase b
WHERE a.unique2=b.unique3 AND a.onepercent = 90
GROUP BY a.ten;
? 7
.
8
hash_partial_groupby_leaf
grouping_columns: indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.TEN) aggregates:
max(indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2))
7.1.11 HASH_PARTIAL_GROUPBY_ROOT 演算子
Groupby グループ
HASH_PARTIAL_GROUPBY_ROOT 演算子は、HASH_PARTIAL_GROUPBY_LEAF 演算子とペアで
機能します。HASH_PARTIAL_GROUPBY_ROOT 演算子は、ESP レベルでグループ化 (group by) を完了
します。7-12 ページの「HASH_PARTIAL_GROUPBY_LEAF 演算子」を参照してください。
HASH_PARTIAL_GROUPBY_ROOT 演算子には子ノードが 1 つあります。この演算子の Description
フィールドには次の情報があります。
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
selection_predicates
having 句の式
expr(text)
grouping_columns
グループ化しているカラムの式
expr(text)
HASH_PARTIAL_GROUPBY_ROOT 演算子の例を次のクエリで示します。
SELECT a.ten, MAX(a.unique2)
FROM $big18a.wisc32m.abase a, $big18a.wisc32m.bbase b
WHERE a.unique2=b.unique3 AND a.onepercent = 90
GROUP BY a.ten;
9
.
10 hash_partial_groupby_root
grouping_columns: indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.TEN) aggregates:
max(max(indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2)))
523728-001J
7-13
第 7 章 演算子と演算子グループ
7.1.12 HYBRID_HASH_ANTI_SEMI_JOIN 演算子
Join グループ
HYBRID_HASH_ANTI_SEMI_JOIN 演算子は、マッチするものがない外部テーブルのローを返します。
7-15 ページの「HYBRID_HASH_JOIN 演算子」と7-16 ページの「HYBRID_HASH_SEMI_JOIN 演算子」
も参照してください。
HYBRID_HASH_ANTI_SEMI_JOIN には子ノードが 2 つあります。この演算子の Description フィール
ドには次の情報があります。
トークン
内容
データ・タイプ
join_type
inner、natural、left、inner semi、inner antisemi のいずれか
text
join_method
ジョイン方法の名前
text
join_predicate
join 述語の式
expr(text)
hash_join_predicate
join 述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョ
イン・アルゴリズムによって異なる。
text
selection_predicates
選択述語の式
expr(text)
join_predicate トークンと hash_join_predicate トークンの違いは、join_predicate トークンが非等価結合述
語であるのに対して、hash_join_predicate トークンは等価結合述語であるという点です。等価結合述語は、
ハッシュ・テーブルの生成と精査に利用できます。
HYBRID_HASH_ANTI_SEMI_JOIN 演算子の例を次のクエリで示します。
SELECT * FROM partsupp, part
WHERE p_brand <>'Brand#45'
AND ps_suppkey
NOT IN (SELECT s_suppkey FROM supplier
WHERE
s_comment LIKE '%Better BusinessBureauComplaints%');
?
XX
211932228834415605
11 HYBRID_HASH_ANTI_SEMI_JOIN
10
3
1.3823995E+015
8.185757
6E+010
8.1857626E+010 CPU_TIME: 8.18576e+10 IO_TIME: 0 MSG_TIME: 0
IDLETIME:
0 PROBES: 1
hash_join_predicate:
(indexcol(TPCDF.SF100F.PARTSUPP.PS_SUPPKEY) =
indexcol(TPCDF.SF100F.SUPPLIER.S_SUPPKEY))
join_type: inner anti-semi
join_method: hash
7-14
523728-001J
第 7 章 演算子と演算子グループ
7.1.13 HYBRID_HASH_JOIN 演算子
Join グループ
HYBRID_HASH_JOIN 演算子は、2 つの子テーブルのデータを結合します。この演算子は、内部テーブ
ルのハッシュ・テーブルを作成し、外部ローをハッシュし、ハッシュ・テーブルでマッチするものを検索
することにより、外部テーブルを結合します。内部テーブルが大きすぎてメモリに入りきらないと、この
演算子はディスクにオーバフローします。この演算子は、等価結合とクロス積をサポートしています。
HYBRID_HASH_JOIN には子ノードが 2 つあります。この演算子の Description フィールドには次の情
報があります。
トークン
内容
データ・タイプ
join_type
inner、natural、left、inner semi、inner antisemi のいずれか
text
join_method
ジョイン方法の名前
text
hash_join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョ
イン・アルゴリズムによって異なる。
text
selection_predicates
選択述語の式
expr(text)
HYBRID_HASH_JOIN 演算子の例を次のクエリで示します。
SELECT n_name, CAST(SUM(l_extendedprice*(1-l_discount))
AS NUMERIC(18,2)) AS revenue
FROM customer,orders,lineitem,supplier,nation, region
WHERE c_custkey = o_custkey
AND o_orderkey = l_orderkey
AND l_suppkey = s_suppkey
AND c_nationkey= s_nationkey
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'ASIA'
AND o_orderdate >= DATE '1994-01-01'
AND o_orderdate < DATE '1994-01-01' + INTERVAL '1' YEAR
GROUP BY n_name
ORDER BY revenue desc;
?
XX
211862597542574407
13 HYBRID_HASH_JOIN
12
10
1.1108888E+001
2.4975137E-003
1.8145949E+000
CPU_TIME: 0.002874
IO_TIME: 0
MSG_TIME: 0
IDLETIME: 0
PROBES:
1
hash_join_predicate: (indexcol(\TESTSYS.$DATA14.SPTPCD.NATION.N_REGIONKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.REGION.R_REGIONKEY))
join_type: inner
join_method: hash
523728-001J
7-15
第 7 章 演算子と演算子グループ
7.1.14 HYBRID_HASH_SEMI_JOIN 演算子
Join グループ
HYBRID_HASH_SEMI_JOIN は、マッチした数に関係なく、すべての外部ローに対して 1 ローだけを返
します。HYBRID_HASH_SEMI_JOIN 演算子と HYBRID_HASH_JOIN 演算子が異なるのは、内部テーブ
ルでのマッチを複数検出するかどうかという点だけです。HYBRID_HASH_JOIN は、内部テーブルでマッ
チしたものに対して個々に結果ローを返します。7-15 ページの「HYBRID_HASH_JOIN 演算子」を参照し
てください。
HYBRID_HASH_SEMI_JOIN 演算子 には子ノードが 2 つあります。この演算子の Description フィール
ドには次の情報があります。
データ・タイ
プ
トークン
内容
join_type
inner、left、natural、inner semi、inner
anti-semi のいずれか
text
join_method
ジョイン方法の名前
text
hash_join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレ
ル・ジョイン・アルゴリズムによっ
て異なる。
text
selection_predicates
選択述語の式
expr(text)
HYBRID_HASH_SEMI_JOIN 演算子の例を次のクエリで示します。
SELECT o_orderpriority, COUNT(*)
FROM $big18a.tpcd2x.orders
WHERE o_orderdate >= DATE '1993-07-01'
AND o_orderdate < DATE '1993-10-01'
AND EXISTS (SELECT *
FROM $big18a.tpcd2x.lineitem
WHERE l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate)
GROUP BY o_orderpriority
ORDER BY o_orderpriority;
3
6
7
hybrid_hash_semi_join
hash_join_predicate: (indexcol(\TESTSYS.$BIG18A.TPCD2X.ORDERS.O_ORDERKEY) =
indexcol(\TESTSYS.$BIG18A.TPCD2X.LINEITEM.L_ORDERKEY))
join_type: inner semi
join_method: hash
parallel_join_type: 1
7-16
523728-001J
第 7 章 演算子と演算子グループ
7.1.15 INDEX_SCAN 演算子
DAM Subset グループ
INDEX_SCAN 演算子は、キー・カラムで作成されたインデックスをスキャンします。ノード記述には、
lock_mode や scan_direction といった、特定のアクセス・パスがどのようにスキャンされるかについての詳
細情報が含まれます。
INDEX_SCAN 演算子には子ノードがありません。この演算子の Description フィールドには次の情報が
あります。
トークン
内容
データ・タイプ
key_columns
プライマリ・キーとして使用
されるカラム
expr(text)
begin_key
開始キー述語の式
expr(text)
end_key
終了キー述語の式
expr(text)
scan_type
INDEX_SCAN とテーブル名
text
scan_direction
forward または reverse
text
lock_mode
no lock、share lock、exclusive
lock のいずれか
text
access_mode
r e a d u n c o m m i t t e d 、r e a d
committed、serializable のいず
れか
text
key_type
simple または MDAM
text
executor_predicates
キー述語でない任意の述語式
expr(text)
columns_retrieved
返されるカラムの予測数
integer
fast_replydata_move
DAM からのデータ返却に最
適化が使用されているかどう
かを示す識別子。最適化が使
用されている場合は、used と
いう値が返される。
text
fast_scan
単純なスキャン操作に最適化
が使用されているかどうかを
示す識別子。最適化が使用さ
れている場合は、used という
値が返される。
text
INDEX_SCAN 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
523728-001J
7-17
第 7 章 演算子と演算子グループ
AND
AND
AND
AND
AND
AND
p_size = 15
p_type like '%BRASS'
s_nationkey = n_nationkey
n_regionkey = r_regionkey
r_name = 'EUROPE'
ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
?
XX
211862597476194167
22 INDEX_SCAN
?
? SUPPLIER (\TESTSYS.$DATA14.SPTPCD.SUPPLIER)
1.0000000E+002
2.1277186E-001
2.1277186E-001
CPU_TIME: 0.001533 IO_TIME: 0.020272 MSG_TIME: 0
IDLETIME: 0.1925
PROBES: 1
key_columns: indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_NATIONKEY),
indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY) executor_predicates:
(indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY))
begin_key: (indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_NATIONKEY) = -2147483648),
(indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY) = -2147483648)
end_key: (indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_NATIONKEY) = 2147483647),
(indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY) = 2147483647)
scan_type: index_scan
\TESTSYS.$DATA14.SPTPCD.SX1(\TESTSYS.$DATA14.SPTPCD.SUPPLIER SUPPLIER)
scan_direction: forward
key_type: simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 4
fast_scan: used
fast_replydata_move: used
7.1.16 INDEX_SCAN_UNIQUE 演算子
DAM Unique グループ
INDEX_SCAN_UNIQUE 演算子は、インデックス付きプライマリ・キー・カラムのスキャンを記述します。
INDEX_SCAN_UNIQUE 演算子には子ノードがありません。この演算子の Description フィールドには
次の情報があります。
7-18
523728-001J
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
key_columns
プライマリ・キーとして使用され
るカラム
expr(text)
begin_key
開始キー述語の式
expr(text)
end_key
終了キー述語の式
expr(text)
scan_type
INDEX_SCAN_UNIQUE とテーブ
ル名
text
lock_mode
no lock、share lock、exclusive lock
のいずれか
text
key_type
simple または MDAM
text
access_mode
read uncommitted、read committed、
serializable のいずれか
text
executor_predicates
キー述語でない任意の述語式
expr(text)
columns_retrieved
返されるカラムの予測数
integer
fast_replydata_move
DAM からのデータ返却に最適化
が使用されているかどうかを示す
識別子。最適化が使用されている
場合は、usedという値が返される。
text
fast_scan
単純 (simple) スキャン操作に最適
化が使用されているかどうかを示
す識別子。最適化が使用されてい
る場合は、used という値が返され
る。
text
olt_optimization
短い単純な操作に最適化が使用さ
れているかどうかを示す識別子。最
used
適化が使用されている場合は、
という値が返される。
text
INDEX_SCAN_UNIQUE 演算子の例を次のクエリで示します。
SELECT a.ten, max(a.unique2)
FROM $big18a.wisc32m.abase a, $big18a.wisc32m.bbase b
WHERE a.unique2=b.unique3 AND a.onepercent = 90
GROUP BY a.ten;
.
.
4
index_scan_unique
key_columns: indexcol(\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3)
part_key_predicates:
VEGPred_170(VEG{A.UNIQUE2(32),\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2(48),\TES
TSYS.$BIG18A.WISC32M.IXA4.UNIQUE2(73),B.UNIQUE3(121),\TESTSYS.$BIG18A.WISC32M
.BBASE.UNIQUE3(137),\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3(152)})
begin_key: (indexcol(\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3) =
indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2))
end_key: (indexcol(\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3) =
523728-001J
7-19
第 7 章 演算子と演算子グループ
indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2))
scan_type: index_scan_unique
\TESTSYS.$BIG18A.WISC32M.IXB4(\TESTSYS.$BIG18A.WISC32M.BBASE B) key_type:
simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 3
7.1.17 INSERT 演算子
INSERT グループ
INSERT 演算子は、実行プランの中でテーブルに新規ローを追加する部分について記述します。INSERT
演算子に対する演算子は常に INSERT です。
INSERT 演算子には子ノードがありません。この演算子の Description フィールドには次の情報がありま
す。
トークン
内容
データ・タイプ
new_rec_expr
挿入されるローの計算
expr(text)
olt_optimization
短い単純な操作に最適化が使用さ
れているかどうかを示す識別子。最
適化が使用されている場合は、used
という値が返される。
text
INSERT 演算子の例を次のクエリで示します。
INSERT INTO $big18a.sch.custss SELECT *
FROM $big18a.tpcd2x.customer
WHERE c_nationkey IN (1,3,7,8,10,15,18,20,22,44);
?
XX
211862676932112060
4 INSERT
?
? \TESTSYS.$BIG18A.SCH.CUSTSS
1.0000000E+000
2.2347903E+000
2.2347903E+000
CPU_TIME: 0.031273 IO_TIME: 0.659791 MSG_TIME: 0 IDLETIME: 1.575
PROBES: 6213
new_rec_expr: ("\TESTSYS.$BIG18A".SCH.CUSTSS.C_CUSTKEY assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_CUSTKEY)),
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_NAME assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_NAME)),
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_ADDRESS assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_ADDRESS)),
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_NATIONKEY assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_NATIONKEY)),
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_PHONE assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_PHONE)),
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_ACCTBAL assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_ACCTBAL)),
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_MKTSEGMENT assign
7-20
523728-001J
第 7 章 演算子と演算子グループ
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_MKTSEGMENT)),
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_COMMENT assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_COMMENT)) part_key_predicates:
("\TESTSYS.$BIG18A".SCH.CUSTSS.C_CUSTKEY assign
indexcol(\TESTSYS.$BIG18A.TPCD2X.CUSTOMER.C_CUSTKEY))
7.1.18 INSERT_VSBB 演算子
INSERT グループ
INSERT_VSBB 演算子は、実行プランの中で、DAM で複数のローを 1 つのテーブルに挿入する部分を
記述します。INSERV_VSBB 演算子に対する演算子は常に INSERT_VSBB です。
INSERT_VSBB での CONTROL QUERY DEFAULT 属性の設定については、『 NonStop SQL/MX リファ
レンス・マニュアル』を参照してください。
INSERT_VSBB 演算子には子ノードがありません。この演算子の Description フィールドには次の情報が
あります。
トークン
内容
データ・タイプ
new_rec_expr
挿入されるローの計算
expr(text)
7.1.19 LEFT_HYBRID_HASH_JOIN 演算子
Join グループ
LEFT_HYBRID_HASH_JOIN 演算子は、内部テーブルでマッチするものが検出されなくても、マッチし
な い 外 部 ロ ー を 返 し ま す。内 部 ロ ー で 値 が な い カ ラ ム に は ヌ ル 値 が 設 定 さ れ ま す。
LEFT_HYBRID_HASH_JOIN 演算子が HYBRID_HASH_JOIN と異なるのは、内部テーブルにマッチする
ものが検出されなかった場合だけです。7-15 ページの「HYBRID_HASH_JOIN 演算子」を参照してくださ
い。
LEFT_HYBRID_HASH_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィール
ドには次の情報があります。
523728-001J
トークン
内容
データ・タイプ
join_type
inner、left、natural、inner semi、inner
anti-semi のいずれか
text
join_method
ジョイン方法の名前
text
hash_join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレ
ル・ジョイン・アルゴリズムによっ
て異なる。
text
selection_predicates
選択述語の式
expr(text)
7-21
第 7 章 演算子と演算子グループ
LEFT_HYBRID_HASH_JOIN 演算子の例を次のクエリで示します。
SELECT a.ten, max(a.unique2)
FROM abase a left join bbase b
ON a.unique2=b.unique3 WHERE a.tenpercent = 9
GROUP BY a.ten FOR READ UNCOMMITTED ACCESS;
3
5
6
left_hybrid_hash_join
hash_join_predicate: (indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2) =
indexcol(\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3))
join_type: left
join_method: hash
parallel_join_type: 1
7.1.20 LEFT_MERGE_JOIN 演算子
Join グループ
LEFT_MERGE_JOIN 演 算 子 は、実 行 プ ラ ン の 中 で merge join を と も な う 部 分 を 記 述 し ま す。
LEFT_MERGE_JOIN が MERGE_JOIN と異なるのは、内部テーブルにマッチするものが検出されなかっ
た場合だけです。LEFT_MERGE_JOIN では、マッチするものが検出されない場合でも左のローは返され、
右のテーブルのデータはヌルに設定されます。7-26 ページの「MERGE_JOIN 演算子」を参照してください。
LEFT_MERGE_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィールドには次
の情報があります。
トークン
内容
データ・タイプ
join_type
inner、left、natural、inner semi、inner
anti-semi のいずれか
text
join_method
ジョイン方法の名前
text
merge_join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレ
ル・ジョイン・アルゴリズムによっ
て異なる。
text
selection_predicates
選択述語の式
expr(text)
LEFT_MERGE_JOIN 演算子の例を次のクエリで示します。
SELECT a.ten, MAX(a.unique2) FROM abase a LEFT JOIN bbase b
ON a.unique2=b.unique3 WHERE a.tenpercent = 9
GROUP BY a.ten FOR READ UNCOMMITTED ACCESS;
2
4
5
left_merge_join
merge_join_predicate: (indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2) =
indexcol(\TESTSYS.$BIG18A.WISC32M.IXB4.UNIQUE3))
join_type: left
join_method: merge
parallel_join_type: 1
7-22
523728-001J
第 7 章 演算子と演算子グループ
7.1.21 LEFT_NESTED_JOIN 演算子
Join グループ
LEFT_NESTED_JOIN 演 算 子 は、実 行 プ ラ ン の 中 で nested join を と も な う 部 分 を 記 述 し ま す。
LEFT_NESTED_JOIN は、各外部 (左) ローを内部 (右) の子ノードに送ります。右の子ノードは、あるロー
とマッチするものをすべて検出し、それらをすべて返します。内部テーブルにおいて外部ローでマッチす
るものが検出されなければ、その外部ローが返され、内部テーブルの値にはヌルが設定されます。7-30 ペー
ジの「NESTED_JOIN 演算子」を参照してください。
LEFT_NESTED_JOIN には子ノードが 2 つあります。この演算子の Description フィールドには次の情報
があります。
トークン
内容
データ・タイプ
join_type
inner、left、natural、inner semi、inner
anti-semi のいずれか
text
join_method
ジョイン方法の名前
text
join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・
ジョイン・アルゴリズムによって異
なる。
text
selection_predicates
選択述語の式
expr(text)
LEFT_NESTED_JOIN 演算子の例を次のクエリで示します。
SELECT a.ten, MAX(a.unique2)
FROM abase a LEFT JOIN bbase b ON a.unique2=b.unique3
WHERE a.onepercent = 90 by a.ten FOR READ UNCOMMITTED ACCESS;
3
6
7
left_nested_join
join_type: left
join_method: nested
parallel_join_type: 2
7.1.22 LEFT_ORDERED_HASH_JOIN 演算子
Join グループ
LEFT_ORDERED_HASH_JOIN 演算子は、内部テーブルにマッチするものが検出できなかった場合でも、
マ ッ チ し な い 外 部 ロ ー を 返 し ま す。見 つ か ら な か っ た 内 部 ロ ー に は ヌ ル が 設 定 さ れ ま す。
L E F T _ O R D E R E D _ H A S H _ J O I N 演 算 子 と L E F T _ H Y B R I D _ H A S H _ J O I N 演 算 子 の 違 い は、
LEFT_ORDERED_HASH_JOIN 演算子は外部テーブルの順序を保持し、ディスクにオーバフローしない点
です。再利用の機能があり、同じクエリの後続の要求にこのハッシュ・テーブルを使用できます。外部テー
ブルの順序を保持する必要がある場合や再利用の機能が必要な場合に、この演算子を選択します。内部テー
ブルのサイズが十分に小さく、メモリに収まる場合にのみこの演算子を選択してください。
LEFT_ORDERED_HASH_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィー
ルドには次の情報があります。
523728-001J
7-23
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
hash_join_predicate
ジョイン述語の式
expr(text)
join_type
Inner、left、natural、inner semi、inner
anti-semi のいずれか
text
join_method
ジョイン方法の名前
text
join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・
ジョイン・アルゴリズムによって異
なる。
text
reuse_comparison_values
変更するとハッシュ・テーブルが再
構築されることになる値のリスト
expr(text)
selection_predicates
選択述語の式
expr(text)
LEFT_ORDERED_HASH_JOIN 演算子の例を次のクエリで示します。
SELECT *
FROM customer LEFT JOIN nation ON c_nationkey = n_nationkey
WHERE c_custkey > 1000 AND c_custkey < 1010
ORDER BY order by c_custkey
?
XX
211932229677605958
6 LEFT_ORDERED_HASH_JOIN
5
2
1.1000000E+001
2.5856664E-003
8.3582334E-002 CPU_TIME: 0.001746 IO_TIME:
0.000999 MSG_TIME: 0 IDLETIME: 0 PROBES: 1
hash_join_predicate: (indexcol(TPCDF.SF100F.CUSTOMER.C_NATIONKEY) =
indexcol(TPCDF.SF100F.NATION.N_NATIONKEY))
join_type: left
join_method: hash
7.1.23 MATERIALIZE 演算子
Materialize グループ
MATERIALIZE 演算子は、初回の実行時にこの演算子の下位のクエリを一度評価し、評価の結果を一時
テーブルに保存し、結果を親ノードに返します。以降の MATERIALIZE 演算子への要求では、その子ノー
ドを再度評価する代わりに、格納されている一時テーブルを返します。MATERIALIZE 演算子は、相関す
るサブクエリを使用する場合や、外部テーブルの順序を維持する必要がある場合に HYBRID_HASH_JOIN
の代わりに使用します。
SQL/MX リリース2 においては、デフォルトでは MATERIALIZE ノードが使用されません。使用する場
合は、MATERIALIZE のデフォルトを ON に設定してください。SQL/MX リリース 2 では、MATERIALIZE
ノードの機能は ORDERED_HASH_JOIN 演算子 に移行しています。
7-24
523728-001J
第 7 章 演算子と演算子グループ
MATERIALIZE 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報
があります。
トークン
内容
データ・タイプ
operation_type
ハッシュ・テーブル
text
values_given_to_child
変更されるとテーブルのマテリア
ライズが発生する値
expr(text)
temp_table_key
一時テーブルのキー
expr(text)
begin_key
開始キー述語
expr(text)
end_key
終了キー述語
expr(text)
scan_direction
forward または reverse
text
check_input_values
入力値が変わったかどうかを
チェックするために使用される式
expr(text)
MATERIALIZE 演算子の例を次のクエリで示します。
SELECT [FIRST 100] s_acctbal, s_name, n_name, p_partkey, p_mfgr,
s_address, s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
AND p_size = 15
AND p_type like '%BRASS'
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'EUROPE'
AND ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp, supplier, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'EUROPE')
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
?
XX
211862597476194167
26 MATERIALIZE
24
?
1.0000000E+000
3.6709364E-003
2.6314377E-001 CPU_TIME: 0.001469
IO_TIME: 0
MSG_TIME: 0
IDLETIME: 0
PROBES: 10
values_given_to_child: execution_count
temp_table_key: indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY) begin_key:
(indexcol(\TESTSYS.$DATA14.SPTPCD.SX1.S_SUPPKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPKEY)) check_input_values:
(execution_count = convert(execution_count)) operation_type: hash
scan_direction: forward
523728-001J
7-25
第 7 章 演算子と演算子グループ
7.1.24 MERGE_ANTI_SEMI_JOIN 演算子
Join グループ
MERGE_ANTI_SEMI_JOIN 演算子は、内部テーブルにマッチするものが検出されない場合だけローを返
します。この演算子は、マッチするものがあるローをすべて破棄します。7-26 ページの「MERGE_JOIN
演算子」と7-27 ページの「MERGE_SEMI_JOIN 演算子」も参照してください。
MERGE_ANTI_SEMI_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィールド
には次の情報があります。
トークン
内容
データ・タイプ
merge_join_predicate
ジョイン述語の式
expr(text)
join_type
inner、left、natural、inner semi、inner anti-semi の
いずれか
text
join_method
ジョイン方法の名前
text
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョイン・
アルゴリズムによって異なる。
text
MERGE_ANTI_SEMI_JOIN の例を次のクエリで示します。
INSERT INTO $sql06.sch184.d2pwl24
(SELECT* FROM $big18a.sqldpops.b2pwl24
WHERE sdec9_uniq NOT IN (SELECT DISTINCT(sdec2_500)
FROM $big18a.sqldpops.b2pwl10));
4
8
9
merge_anti_semi_join
merge_join_predicate: (indexcol(\TESTSYS.$BIG18A.SQLDPOPS.B2PWL24.SDEC9_UNIQ)
= cast(indexcol(\TESTSYS.$BIG18A.SQLDPOPS.B2PWL10.SDEC2_500))) join_type:
inner anti-semi
join_method: merge
parallel_join_type: 1
7.1.25 MERGE_JOIN 演算子
Join グループ
MERGE_JOIN 演算子は、実行プランの中で merge join を呼び出す部分を記述します。この演算子は 2 つ
の子ノードのデータを結合します。両方の子ノードのデータ・ストリームは同じ順序である必要がありま
す。この演算子は、各データ・ストリームでマッチするローをすべて結合します。MERGE_JOIN 演算子は
等価結合でのみ機能します。
MERGE_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィールドには次の情報
があります。
7-26
523728-001J
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
join_type
inner、left、natural、inner semi、inner antisemi のいずれか
text
join_method
ジョイン方法の名前
text
merge_join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョ
イン・アルゴリズムによって異なる。
text
selection_predicates
選択述語の式
expr(text)
MERGE_JOIN 演算子の例を次のクエリで示します。
SELECT l_orderkey,
CAST(SUM(l_extendedprice*(1-l_discount))AS
NUMERIC(18,2)), o_orderdate, o_shippriority
FROM customer,orders,lineitem
WHERE c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1995-03-15'
AND l_shipdate > DATE '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY 2 DESC,3 ASC;
?
XX
211862597497309538
12 MERGE_JOIN
8
11
3.3329999E-001
1.4655510E-004
2.2940764E+000 CPU_TIME: 0.345902 IO_TIME:
0.033786 MSG_TIME: 0.067074 IDLETIME: 0
PROBES: 1
merge_join_predicate: (indexcol(\TESTSYS.$DATA14.SPTPCD.ORDERS.O_CUSTKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.CUSTOMER.C_CUSTKEY))
join_type: inner
join_method: merge
7.1.26 MERGE_SEMI_JOIN 演算子
Join グループ
MERGE_SEMI_JOIN 演算子は、内部テーブルで最初にマッチした 1 ローを返します。これに対して、
MERGE_JOIN は、内部テーブルでマッチしたローをすべて返します。7-26 ページの「MERGE_JOIN 演算
子」を参照してください。
MERGE_SEMI_JOIN 演算子 には子ノードが 2 つあります。この演算子の Description フィールドには次
の情報があります。
523728-001J
7-27
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
merge_join_predicate
ジョイン述語の式
expr(text)
join_type
inner、left、natural、inner semi、inner antisemi のいずれか
text
join_method
ジョイン方法の名前
text
parallel_join_type
タイプ 1 または タイプ 2。パラレル・
ジョイン・アルゴリズムによって異なる。
text
MERGE_SEMI_JOIN 演算子の例を次のクエリで示します。
INSERT INTO $sql06.sch184.d2pwl24
(SELECT* FROM $big18a.sqldpops.b2pwl24
WHERE sdec9_uniq IN (SELECT DISTINCT(sdec2_500)
FROM $big18a.sqldpops.b2pwl10));
4
8
9
merge_semi_join
merge_join_predicate: (indexcol(\TESTSYS.$BIG18A.SQLDPOPS.B2PWL24.SDEC9_UNIQ)
= cast(indexcol(\TESTSYS.$BIG18A.SQLDPOPS.B2PWL10.SDEC2_500))) join_type:
inner semi
join_method: merge
parallel_join_type: 1
7.1.27 MERGE_UNION 演算子
MERGE_UNION グループ
MERGE_UNION 演算子は、実行プランの中で 2 つの子ノードのローをマージする部分を記述します。
MERGE_UNION 演算子に対する演算子は常に MERGE_UNION です。
MERGE_UNION 演算子には子ノードが 2 つあります。この演算子の Description フィールドには次の情
報があります。
トークン
内容
データ・タイプ
union_type
merge
text
sort_order
union の結果のソート順
text
merge_expr
子演算子をどちらから読み取るかを判別するときに使用さ
れる式。true であれば左から、false なら右から読み取る
expr(text)
MERGE_UNION 演算子の例を次のクエリで示します。
SELECT x.c_name, x.c_phone
FROM $sql07.tpcdtab.customer x, $big18a.sch1810.cclone y
WHERE x.c_phone = y.c_phone
UNION SELECT s.c_name, s.c_phone
FROM $sql07.tpcdtab.customer s,
$big18a.sch1810.cclone t
WHERE s.c_name = t.c_name ORDER BY x.c_name;
7-28
523728-001J
第 7 章 演算子と演算子グループ
10 21 22 merge_union
sort_order: ValueIdUnion(\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_NAME,
\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_NAME),
ValueIdUnion(\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_PHONE,
\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_PHONE)
merge_expr: ((indexcol(\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_NAME),
indexcol(\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_PHONE)) <=
(indexcol(\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_NAME),
indexcol(\TESTSYS.$SQL07.TPCDTAB.CUSTOMER.C_PHONE)))
union_type: merge
7.1.28 NESTED_ANTI_SEMI_JOIN 演算子
Join グループ
NESTED_ANTI_SEMI_JOIN 演算子は、実行プランの中で nested join を呼び出す部分を記述します。こ
の演算子は述語を満たさない内部テーブルのローをすべて返します。7-30 ページの「NESTED_JOIN 演算
子」を参照してください。
NESTED_ANTI_SEMI_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィールド
には次の情報があります。
トークン
内容
データ・タイプ
join_type
Inner、left、natural、inner semi、inner anti-semi のい
ずれか
text
join_method
ジョイン方法の名前
text
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョイン・アル
ゴリズムによって異なる。
text
NESTED_ANTI_SEMI_JOIN 演算子の例を次のクエリで示します。
SELECT p_brand, p_type, p_size, COUNT(DISTINCT ps_suppkey)
FROM partsupp, part
WHERE p_partkey = ps_partkey
AND p_brand <> 'Brand#45'
AND p_type NOT LIKE 'MEDIUM POLISHED%'
AND p_size IN (49, 14, 23, 45, 19, 3, 36, 9)
AND ps_suppkey NOT IN (SELECT s_suppkey
FROM supplier
WHERE s_comment LIKE
'%Better Business
Bureau%Complaints%')
GROUP BY p_brand, p_type, p_size
ORDER BY 4 DESC, 1, 2, 3;
?
XX
211862597679263939
11 NESTED_ANTI_SEMI_JOIN
7
10
0.0000000E+000
2.8552881E-006
1.9244983E+000 CPU_TIME: 0.821998 IO_TIME:
523728-001J
7-29
第 7 章 演算子と演算子グループ
0.091286 MSG_TIME: 0.115813 IDLETIME: 1.1025
PROBES: 1
join_type: inner anti-semi
join_method: nested
7.1.29 NESTED_JOIN 演算子
Join グループ
NESTED_JOIN 演算子は、実行プランの中で nested join を呼び出す部分を記述します。この演算子は各
外部ローを内部の子ノードに送り、最終的にスキャン操作に送られます。通常、内部スキャン・アクセス
はキー順で行われ外部のプローブ (probe) 数が少なくなるため、ジョインが効率的になります。実際のジョ
インは、NESTED_JOIN 演算子ではなく、内部スキャンで行われます。nested join は、範囲演算 (>=, >, <,
<=) と等結合がサポートされます。
NESTED_JOIN には子ノードが 2 つあります。この演算子の Description フィールドには次の情報があり
ます。
トークン
内容
データ・タイプ
join_type
Inner、left、natural、inner semi、inner anti-semi の
いずれか
text
join_method
ジョイン方法の名前。nested または in-order nested
text
join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョイン・
アルゴリズムによって異なる。
text
selection_predicates
選択述語の式
expr(text)
NESTED_JOIN 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
AND p_size = 15
AND p_type like '%BRASS'
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'EUROPE'
AND ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
7-30
523728-001J
第 7 章 演算子と演算子グループ
?
XX
211862597476194167
11 NESTED_JOIN
7
10
1.0000000E+001
6.9649995E-006
1.8949854E+000
0.091286 MSG_TIME: 0.111842 IDLETIME: 1.1025
PROBES: 1
join_type: inner
join_method: nested
CPU_TIME: 0.792485 IO_TIME:
7.1.30 NESTED_SEMI_JOIN 演算子
Join グループ
NESTED_SEMI_JOIN 演算子は、マッチしたローを 1 つだけ内部テーブルから返し、重複してマッチし
ているローは無視します。7-30 ページの「NESTED_JOIN 演算子」を参照してください。
NESTED_SEMI_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィールドには次
の情報があります。
トークン
内容
データ・タイプ
join_type
Inner、left、natural、inner semi、inner anti-semi のい
ずれか
text
join_method
ジョイン方法の名前
text
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョイン・ア
ルゴリズムによって異なる。
text
NESTED_SEMI_JOIN 演算子の例を次のクエリで示します。
DELETE FROM $big18b.sch183.d2pns03
WHERE ts1_n100 in
(SELECT ts1_n100 FROM $big18a.sqldpops.b2pns03
WHERE ts1_n100 BETWEEN
(TIMESTAMP '1900-01-01:00:10:00.000000') AND
(TIMESTAMP '2100-01-01:00:20:00.000000'));
2
6
7
nested_semi_join
join_type: inner semi
join_method: nested
7.1.31 ORDERED_HASH_ANTI_SEMI_JOIN
Join グループ
ORDERED_HASH_ANTI_SEMI_JOIN 演算子は、一致するものがない場合に、各外部ローにつき 1 ロー
を返します。この演算子は外部テーブルの順序を保持し、ディスクにオーバフローすることはありません。
再利用の機能があり、同じクエリの後続の要求にこのハッシュ・テーブルを使用できます。外部テーブル
の順序を保持する必要がある場合や、再利用の機能が必要な場合に、この演算子を選択します。内部テー
ブルのサイズが十分に小さくメモリに収まる場合にのみこの演算子を選択してください。
523728-001J
7-31
第 7 章 演算子と演算子グループ
ORDERED_HASH_ANTI_SEMI_JOIN 演算子には子ノードが 2 つあります。この演算子の Description
フィールドには次の情報があります。
トークン
内容
データ・タイプ
hash_join_predicate
ジョイン述語の式
expr(text)
join_type
inner、left、natural、inner semi、inner antisemi のいずれか
text
join_method
ジョイン方法の名前
text
join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョ
イン・アルゴリズムによって異なる。
text
reuse_comparison_values
変更によりハッシュ・テーブルが再構築さ
れることになる値のリスト
expr(text)
selection_predicates
選択述語の式
expr(text)
ORDERED_HASH_ANTI_SEMI_JOIN 演算子の例を次のクエリで示します。
SELECT *
FROM customer, nation
WHERE c_custkey > 10000 AND c_custkey < 10010
AND c_nationkey NOT IN
(select n_nationkey from nation where n_regionkey = 10)
ORDER BY c_custkey
?
XX
211932229593011348
9 ORDERED_HASH_ANTI_SEMI_JOIN
8
2
8.7000000E+001
1.4744397E-002
1.1843304E-001 CPU_TIME: 0.015609 IO_TIME:
0.000908 MSG_TIME: 0 IDLETIME: 0 PROBES: 1
hash_join_predicate: (indexcol(TPCDF.SF100F.CUSTOMER.C_NATIONKEY) =
indexcol(TPCDF.SF100F.NATION.N_NATIONKEY))
join_type: inner
anti-semi join_method: hash
7.1.32 ORDERED_HASH_JOIN 演算子
Join グループ
ORDERED_HASH_JOIN 演算子は、2 つの子テーブルのデータを結合します。この演算子は、外部テーブ
ルの順序を保持し、ディスクにオーバフローすることはありません。内部テーブルからハッシュ・テーブ
ルを作成し、外部ローをハッシュし、ハッシュ・テーブルでマッチするものを検索することにより、外部
テーブルを結合します。再利用の機能により、同じクエリの後続の要求にこのハッシュ・テーブルを使用
できます。外部テーブルの順序を保持する必要がある場合や再利用の機能が必要な場合に、この演算子を
選択します。内部テーブルのサイズが十分に小さくメモリに収まる場合にのみ、この演算子を選択してく
ださい。
7-32
523728-001J
第 7 章 演算子と演算子グループ
この演算子は、等価結合とクロス積をサポートしています。
ORDERED_HASH_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィールドには
次の情報があります。
トークン
内容
データ・タイプ
hash_join_predicate
ジョイン述語の式
expr(text)
join_type
inner、left、natural、inner semi、inner antisemi のいずれか
text
join_method
ジョイン方法の名前
text
join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョ
イン・アルゴリズムによって異なる。
text
reuse_comparison_values
変更によりハッシュ・テーブルが再構築さ
れることになる値のリスト
expr(text)
selection_predicates
選択述語の式
expr(text)
join_predicate トークンと hash_join_predicate トークンの違いは、join_predicate トークンが非等価結合述
語であるのに対して、hash_join_predicate トークンは等価結合述語であるという点です。等価結合述語は、
ハッシュ・テーブルの生成と精査に利用できます。
ORDERED_HASH_JOIN 演算子の例を次のクエリで示します。
SELECT * FROM customer JOIN nation on c_nationkey = n_nationkey
WHERE c_custkey > 10000
AND c_custkey < 10010 ORDER BY c_custkey>
?
XX
211932229204655082
6 ORDERED_HASH_JOIN
5
2
1.1000000E+001
2.5856664E-003
8.3582334E-002 CPU_TIME: 0.001746 IO_TIME: 0.000999 MSG_TIME: 0 IDLETIME: 0
PROBES: 1
hash_join_predicate: (indexcol(TPCDF.SF100F.CUSTOMER.C_NATIONKEY) =
indexcol(TPCDF.SF100F.NATION.N_NATIONKEY))
join_type: inner
join_method: hash
7.1.33 ORDERED_HASH_SEMI_JOIN 演算子
Join グループ
ORDERED_HASH_SEMI_JOIN 演算子は、マッチするものすべてに対して外部ローを返します。この演
算子と HYBRID_HASH_SEMI_JOIN 演算子の違いは、ORDERED_HASH_SEMI_JOIN 演算子は外部テー
ブルの順序を保持し、ディスクにオーバフローすることはないという点です。再利用の機能によって、同
523728-001J
7-33
第 7 章 演算子と演算子グループ
じクエリの後続の要求にハッシュ・テーブルを使用できます。外部テーブルの順序を保持する必要がある
場合や、再利用の機能が必要な場合に、この演算子を選択します。内部テーブルのサイズが十分に小さく
メモリに収まる場合にのみこの演算子を選択してください。
7-15 ページの「HYBRID_HASH_JOIN 演算子」も参照してください。
ORDERED_HASH_SEMI_JOIN 演算子には子ノードが 2 つあります。この演算子の Description フィー
ルドには次の情報があります。
トークン
内容
データ・タイプ
hash_join_predicate
ジョイン述語の式
expr(text)
join_type
Inner、left、natural、inner semi、inner antisemi のいずれか
text
join_method
ジョイン方法の名前
text
join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・
ジョイン・アルゴリズムによって異な
る。
text
reuse_comparison_values
変更によりハッシュ・テーブルが再構築
されることになる値のリスト
expr(text)
selection_predicates
選択述語の式
expr(text)
join_predicate トークンと hash_join_predicate トークンの違いは、join_predicate トークンが非等価結合述
語であるのに対して、hash_join_predicate トークンは等価結合述語であるという点です。等価結合述語は、
ハッシュ・テーブルの生成と精査に利用できます。
ORDERED_HASH_SEMI_JOIN 演算子の例を次のクエリで示します。
SELECT *
FROM customer ,nation
WHERE c_custkey > 10000
AND c_custkey < 10010
AND c_nationkey IN(select n_nationkey from nation)
ORDER BY c_custkey
?
XX
211932229506956715
8 ORDERED_HASH_SEMI_JOIN
7
4
1.1000000E+001
2.3594854E-003
8.3467796E-002
CPU_TIME: 0.001631 IO_TIME: 0.000999 MSG_TIME: 0 IDLETIME: 0 PROBES: 1
hash_join_predicate: (indexcol(TPCDF.SF100F.CUSTOMER.C_NATIONKEY) =
indexcol(TPCDF.SF100F.NATION.N_NATIONKEY))
join_type: inner semi
join_method: hash
7-34
523728-001J
第 7 章 演算子と演算子グループ
7.1.34 PACK 演算子
Rowset グループ
ローを選択してローセット配列に入れる場合に、PACK 演算子をクエリ・プランで使用します。
SELECT <list> INTO <list of arrays> <body of query>
PACK 演算子は、クエリ本体のローをすべて収集し、<list of arrays> の配列に入れます。ローセッ
トと配列については、『HP NonStop SQL/MX プログラミング・マニュアル C および COBOL 言語用』を参
照してください。
PACK 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報がありま
す。
トークン
内容
データ・タイプ
pack_expr
ローの値を、パックされた 1 つのローに入れるために
使用する式
expr(text)
PACK 演算子の例は、次のローセットを基にしています。出力は読みやすい形式に変更されています。
Output from MDF file:
PROCEDURE SQLMX_DEFAULT_STATEMENT_3 ("staff_num" ROWSET 5 CHARACTER(3),
"staff_name" ROWSET 5 CHARACTER(20),"staff_grade" ROWSET 5 INTEGER,
"staff_city" ROWSET 5 ANSIVARCHAR(15))
SELECT * into :"staff_num",:"staff_name",:"staff_grade",:"staff_city"
FROM RSSTAFF;
Command in MXCI:
>>SELECT OPERATOR, CARDINALITY, OPERATOR_COST, DESCRIPTION FROM
TABLE(EXPLAIN(('CAT.SCH.TESTE051M','SQLMX_DEFAULT_STATEMENT_3')));
OPERATOR
CARDINALITY
OPERATOR_COST
DESCRIPTION
FILE_SCAN
1.9067585E+002
2.2145127E-002
key_columns:
indexcol(CAT.SCH.RSSTAFF.SYSKEY)
begin_key: (indexcol(CAT.SCH.RSSTAFF.SYSKEY) = -9223372036854775808)
end_key: (indexcol(CAT.SCH.RSSTAFF.SYSKEY) = 9223372036854775807)
scan_type: file_scan CAT.SCH.RSSTAFF
scan_direction: forward
key_type: simple
lock_mode: not specified
access_mode: not specified
columns_retrieved: 5
fast_replydata_move: used
PARTITION_ACCESS 1.9067585E+002
buffer_size: 31000 record_length: 44
2.5107495E-003
PACK
3.8135169E+001
0.0000000E+000
pack_expr: (cast(indexcol(CAT.SCH.RSSTAFF.EMPNUM)) RowsetArrayInto 5 ),
(cast(indexcol(CAT.SCH.RSSTAFF.EMPNAME)) RowsetArrayInto 5 ),
(cast(indexcol(CAT.SCH.RSSTAFF.GRADE)) RowsetArrayInto 5 ),
(cast(cast(indexcol(CAT.SCH.RSSTAFF.CITY))) RowsetArrayInto 5 )
ROOT
3.8135169E+001
9.8091781E-002
select_list: (cast(indexcol(CAT.SCH.RSSTAFF.EMPNUM)) RowsetArrayInto 5 ),
(cast(indexcol(CAT.SCH.RSSTAFF.EMPNAME)) RowsetArrayInto 5 ),
(cast(indexcol(CAT.SCH.RSSTAFF.GRADE)) RowsetArrayInto 5 ),
523728-001J
7-35
第 7 章 演算子と演算子グループ
(cast(cast(indexcol(CAT.SCH.RSSTAFF.CITY))) RowsetArrayInto 5 )
statement_index: 1 statement: PROCEDURE SQLMX_DEFAULT_STATEMENT_3 ("staff_num"
ROWSET 5 CHARACTER(3),"staff_name" ROWSET 5 CHARACTER(20),"staff_grade"
ROWSET 5 INTEGER,"staff_city" ROWSET 5 ANSIVARCHAR(15)) SELECT * into
:"staff_num",:"staff_name",:"staff_grade",:"staff_city"
FROM RSSTAFF;
--- 4 row(s) selected.
7.1.35 PARTITION_ACCESS 演算子
Exchange グループ
PARTITION_ACCESS 演算子は、ファイル・システム・インタフェースの実行プランにおいて、DAM に
要求がある部分を記述するときに使用されます。DAM プロセスは、PARTITION_ACCESS (待ちなしイン
タフェース) とパラレルで実行します。Exchange 演算子の詳細情報は、第 8 章「並列性」を参照してください。
PARTITION_ACCESS 演算子には子ノードが 1 つあります。この演算子の Description フィールドにには
次の情報があります。
トークン
内容
データ・タイプ
buffer_size
PARTITION_ACCESS 演 算 子 と DAM 間 の メ ッ
セージのバッファ・サイズ
integer
record_length
DAM から返されるレコードの長さ
integer
begin_key_preds
(incl | excl)
開始キーが指定キーを含むかどうかを決める述語
expr(text)
end_key_preds
(incl | excl)
終了キーが指定キーを含むかどうかを決める述語
expr(text)
begin_key_exclusion_expr
開始キーがキー範囲から除外されるかどうかを示
すブール式 (動的に判断される)
expr(text)
end_key_exclusion_expr
終了キーがキー範囲から除外されるかどうかを示
すブール式 (動的に判断される)
expr(text)
begin_part_no_expr
開始パーティション番号を計算する式
(begin_key_preds と begin_key_exclusion_expr の
代わりに表示される)
expr(text)
end_part_no_expr
終 了 パ ー テ ィ シ ョ ン 数 を 計 算 す る 式
(end_key_preds と end_key_exclusion_expr の代わ
りに表示される)
expr(text)
olt_optimization
短い単純な操作に最適化が使用されているかどう
かを示す識別子。最適化が使用されている場合は、
used という値が返される。
text
PARTITION_ACCESS 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
7-36
523728-001J
第 7 章 演算子と演算子グループ
AND
AND
AND
AND
AND
AND
AND
s_suppkey = ps_suppkey
p_size = 15
p_type like '%BRASS'
s_nationkey = n_nationkey
n_regionkey = r_regionkey
r_name = 'EUROPE'
ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
?
XX
211862597476194167
9 PARTITION_ACCESS
8
?
1.0000000E+000
8.9073047E-002
3.5270255E-001 CPU_TIME: 0.090203 IO_TIME:
0.020397 MSG_TIME: 0.017591 IDLETIME: 0.2625
PROBES: 10 begin_key_preds_(incl):
(indexcol(\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_SUPPKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPKEY)) end_key_preds_(incl):
(indexcol(\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_SUPPKEY) =
indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPKEY)) begin_part_no_expr:
\:_sys_hostVarPAPartNo_1283843904 end_part_no_expr:
\:_sys_hostVarPAPartNo_1283843904 buffer_size: 31000
record_length: 199
7.1.36 ROOT 演算子
Root グループ
ROOT 演算子は、実行プランのルート、つまり最上位のノードであり、SQL クエリを記述します。ルー
トに対する演算子は常に ROOT です。
ROOT 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報がありま
す。
523728-001J
トークン
内容
データ・タイプ
statement
オリジナルの SQL ステートメント
text
select_list
SELECT リストの式
expr(text)
input_variables
入力変数のリストが含まれている式
expr(text)
order_by
ソート・キーのリストが含まれている式
expr(text)
must_match
CONTROL QUERY SHAPE が使用されている場
合、強制されたクエリ・ツリーの説明
expr(text)
7-37
第 7 章 演算子と演算子グループ
update_col
カーソル宣言の更新カラムを指定
expr(text)
olt_optimization
短い単純な操作に最適化が使用されているかどう
かを示す識別子。最適化が使用されている場合は
used という値が返される。
text
statement_index
Measure によって通知されるこのステートメント
のステートメント・インデックス。
integer
upd_action_on_error
XN_ROLLBACK: エラー発生で、トランザクショ
ンはロールバックされる。
text
Return: クエリの実行は停止し、制御が戻る。ス
テートメントのロールバックは不要。
Savepoint: エラー発生で、DAM のセーブポイント
を使用してステートメントをロールバックする。
PARTIAL_UPD: [SQL/MP スタイル] 一部の結果が
更新され、エラーが返される。
ROOT 演算子の例を次のクエリで示します。
SELECT CAST(SUM(l_extendedprice*l_discount) AS NUMERIC(18,2))
AS revenue
FROM lineitem
WHERE l_shipdate >= DATE '1994-01-01'
AND l_shipdate < DATE '1994-01-01' + INTERVAL '1' YEAR
AND l_discount BETWEEN .06 - 0.01 AND .06 + 0.01
AND l_quantity < 24;
211862597551536523
5 ROOT
4
?
1.0000000E+000
9.8000094E-002
1.5509755E+000 CPU_TIME: 0.350476 IO_TIME:
0.054058 MSG_TIME: 0.068671 IDLETIME: 1.2005
PROBES: 1
select_list: cast(sum((cast(indexcol
(\TESTSYS.$DATA14.SPTPCD.LINEITEM.L_EXTENDEDPRICE)) *
cast(indexcol(\TESTSYS.$DATA14.SPTPCD.LINEITEM.L_DISCOUNT)))))
statement_index: 0
statement: SELECT CAST(SUM(l_extendedprice*l_discount) AS NUMERIC(18,2)) AS
revenue FROM lineitem WHERE l_shipdate >= DATE '1994-01-01'AND l_shipdate <
DATE '1994-01-01' + INTERVAL '1' YEAR AND l_discount BETWEEN .06 - 0.01 AND
.06 + 0.01 AND l_quantity < 24;
7-38
523728-001J
第 7 章 演算子と演算子グループ
7.1.37 SAMPLE 演算子
Data Mining グループ
SAMPLE 演算子は、クエリの sample 句の結果として発生します。
SAMPLE 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報があり
ます。
トークン
内容
データ・タイプ
sampled_columns
SAMPLE 演算子の出力を表すカラム参照リスト。カ
ラムがサンプリングされていることを示す。
expr(text)
balance_expression
サンプリング式を表す式。単純なランダム選択だが、
sample 句に balance 句が含まれている場合はより複
雑になる。
expr(text)
sample_type
実行されるサンプリングのタイプを示す。
RANDAM、
PERIODIC、FIRST、CLUSTER のいずれかの値
text
required_order
サンプリング操作のための指定順序キー
expr(text)
データ・マイニングの詳細は、『HP NonStop SQL/MX Data Mining Guide』を参照してください。
SAMPLE 演算子の例を次のクエリで示します。
SELECT * FROM starter SAMPLE RANDOM 10 PERCENT;
sampled_columns: Sampled_column(indexcol(CAT.SCH.STARTER.A))
balance_expression: randomSelection
sample_type: RANDOM
7.1.38 SEQUENCE 演算子
Data Mining グループ
SEQUENCE 演算子は、クエリの SEQUENCE BY 句の結果として発生します。
SEQUENCE 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報が
あります。
523728-001J
トークン
内容
データ・タイプ
required_order
SEQUENCE 演算子で必要な順序を指定するカラム参照
リスト。SEQUENCE BY 句で指定されたカラムのリス
トから取得される。
expr(text)
sequence_functions
この SEQUENCE 演算子によって評価される必要がある
sequence 関数のリストを表す。.
ItemExpr tree
7-39
第 7 章 演算子と演算子グループ
num_history_rows
ヒストリ・バッファのサイズ (ロー単位)。この数のロー
が 1 つのバッファに保持され、sequence 関数でアクセス
できる。このバッファの外のローにアクセスすると、ヌ
ル値が返される。このパラメータのデフォルト値は、デ
フォルトの DEF_MAX_HISTORY_ROWS の初期設定値
で、最初は 1024 に設定されている。
integer
history_row_size
ヒストリ・バッファの各ヒストリ・ローのサイズ
integer
データ・マイニングの詳細は、『HP NonStop SQL/MX Data Mining Guide』を参照してください。
SEQUENCE 演算子の例を次のクエリで示します。
SELECT RUNNINGCOUNT(*) FROM mining_data
SEQUENCE BY age, gender DESC;
required_order: indexcol(CAT.SCH.MINING_DATA.AGE), inverse(indexcol
CAT.SCH.MINING_DATA.GENDER)) sequence_functions: (replace
null(offset(\:_sys_Result), cast(offset(\:_sys_Result)), cast(0 )) + replace
null(1 , cast(1 ), cast(0 )))
num_history_rows: 1024
history_row_size: 16
7.1.39 SHORTCUT_SCALAR_AGGR 演算子
Groupby グループ
SHORTCUT_SCALAR_AGGR 演算子は、GROUP BY 句のない集計に対して発生し、ローを 1 つ返しま
す。この演算子の Description フィールドには次の情報があります。
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
SHORTCUT_SCALAR_AGGR 演算子の例を次のクエリで示します。
SELECT MIN( NO_O_ID )
FROM norders
WHERE (NO_W_ID, NO_D_ID) = (?W_ID, ?D_ID)
FOR REPEATABLE ACCESS IN EXCLUSIVE MODE;
3
.
4
shortcut_scalar_aggr
aggregates: min(indexcol(\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_O_ID))
7.1.40 SORT 演算子
Sort グループ
SORT 演算子は、ソートを実行する実行プランの部分を記述します。SORT 演算子の演算子は常に SORT
です。
SORT 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報があります。
7-40
523728-001J
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
sort_key
ソート・キーを記述する式
expr(text)
SORT 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
AND p_size = 15
AND p_type like '%BRASS'
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'EUROPE'
AND ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
?
XX
211862597476194167
18 SORT
17
?
1.0000000E+001
1.4229869E-001
2.0431513E+000 CPU_TIME: 0.000463
IO_TIME: 0
MSG_TIME: 0
IDLETIME: 0
PROBES: 1
sort_key: inverse(indexcol(\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_ACCTBAL)),
indexcol(\TESTSYS.$DATA14.SPTPCD.NATION.N_NAME),
indexcol(\TESTSYS.$DATA14.SPTPCD.SUPPLIER.S_NAME),
indexcol(\TESTSYS.$DATA14.SPTPCD.PART.P_PARTKEY)
7.1.41 SORT_GROUPBY 演算子
Groupby グループ
SORT_GROUPBY 演算子は、実行プランの中でグループに影響を与える部分を記述します。
SORT_GROUPBY 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の
情報があります。
523728-001J
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
selection_predicate
having 句の式
expr(text)
grouping_columns
グループ化しているカラムの式
expr(text)
7-41
第 7 章 演算子と演算子グループ
SORT_GROUPBY 演算子の例を次のクエリで示します。
SELECT o_orderpriority, COUNT(*) as order_count
FROM orders
WHERE o_orderdate >= DATE '1993-07-01'
AND o_orderdate < DATE '1993-07-01' + INTERVAL '3' MONTH
AND EXISTS (SELECT *
FROM lineitem
WHERE l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate)
GROUP BY o_orderpriority
ORDER BY o_orderpriority;
?
XX
211862597502233318
9 SORT_GROUPBY
8
?
3.7025923E+000
7.7009797E-005
1.9430620E+000 CPU_TIME: 9.52407e-05
IO_TIME: 0
MSG_TIME: 0
IDLETIME: 0
PROBES: 1
grouping_columns: indexcol(\TESTSYS.$DATA14.SPTPCD.ORDERS.O_ORDERPRIORITY)
aggregates: count(1 )
7.1.42 SORT_PARTIAL_AGGR_LEAF 演算子
Groupby グループ
SORT_PARTIAL_AGGR_LEAF 演算子は、できるだけコスト効率がよくなるデータの読み取り位置で部
分的なグループ化操作 (group by) を実行します。この方法は、1 つのクエリのために再配布しなければな
ら な い デ ー タ 量 を 削 減 し ま す。ツ リ ー の 中 で こ の 演 算 子 の 上 位 に は 必 ず、ク エ リ を 終 了 さ せ る
SORT_PARTIAL_AGGR_ROOT 演算子があります。
この演算子は、標準的な集計関数 (SUM、MIN、MAX など) のない 1 ロー集計で構成されます。リーフ
(葉) の部分は、DAM のエグゼキュータ部分で発生します。この演算子の Description フィールドには次の
情報があります。
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
SORT_PARTIAL_AGGR_LEAF 演算子の例を次のクエリで示します。
SELECT CAST(SUM(l_extendedprice*l_discount) AS NUMERIC(18,2))
FROM $big18a.tpcd2x.lineitem
WHERE l_shipdate >= DATE '1994-01-01'
AND l_shipdate < DATE '1995-01-01'
AND l_discount BETWEEN .06 - 0.01 AND .06 + 0.01
AND l_quantity < 24;
1
.
2
sort_partial_aggr_leaf
aggregates: sum((cast(indexcol(\TESTSYS.$BIG18A.TPCD2X.LX1.L_EXTENDEDPRICE))
* cast(indexcol(\TESTSYS.$BIG18A.TPCD2X.LX1.L_DISCOUNT))))
7-42
523728-001J
第 7 章 演算子と演算子グループ
7.1.43 SORT_PARTIAL_AGGR_ROOT 演算子
Groupby グループ
SORT_PARTIAL_AGGR_ROOT 演算子は、SORT_PARTIAL_AGGR_LEAF 演算子とペアで機能します。
SORT_PARTIAL_AGGR_ROOT 演算子は ESP レベルでのグループ化 (group by) を完了させます。この演
算子は、標準的な集計関数 (SUM、MIN、MAX など) のない 1 ロー集計から構成されます。ルートの部分
は、ルートで発生します。この演算子の Description フィールドには次の情報があります。
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
SORT_PARTIAL_AGGR_ROOT 演算子の例を次のクエリで示します。
SELECT CAST(SUM(l_extendedprice*l_discount) AS NUMERIC(18,2))
FROM $big18a.tpcd2x.lineitem
WHERE l_shipdate >= DATE '1994-01-01'
AND l_shipdate < DATE '1995-01-01'
AND l_discount BETWEEN .06 - 0.01 AND .06 + 0.01
AND l_quantity < 24;
4
.
5
sort_partial_aggr_root
aggregates:
sum(sum((cast(indexcol(\TESTSYS.$BIG18A.TPCD2X.LX1.L_EXTENDEDPRICE)) *
cast(indexcol(\TESTSYS.$BIG18A.TPCD2X.LX1.L_DISCOUNT)))))
7.1.44 SORT_PARTIAL_GROUPBY_LEAF 演算子
Groupby グループ
SORT_PARTIAL_GROUPBY_LEAF 演算子は、できるだけコスト効率がよくなるデータの読み取り位置
で部分的なグループ化操作 (group by) を実行します。この方法は、1 つのクエリのために再配布しなけれ
ばならないデータ量を削減します。ツリーの中で、この演算子の上位には必ず、クエリを完了させる
SORT_PARTIAL_GROUPBY_ROOT 演算子があります。
SORT_PARTIAL_GROUPBY_LEAF 演算子には子ノードが 1 つあります。この演算子の Description
フィールドには次の情報があります。
トークン
内容
データ・タイプ
grouping_columns
グループ化カラムの式
expr(text)
aggregates
集計関数の式
expr(text)
SORT_PARTIAL_GROUPBY_LEAF 演算子の例を次のクエリで示します。
SELECT a.ten, MAX(a.unique2)
FROM $big18a.wisc32m.abase a, $big18a.wisc32m.bbase b
WHERE a.unique2=b.unique2 AND a.fiftypercent = 1
GROUP BY a.ten ORDER BY a.ten;
523728-001J
7-43
第 7 章 演算子と演算子グループ
6
.
7
sort_partial_groupby_leaf
grouping_columns: indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.TEN) aggregates:
max(indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2)
7.1.45 SORT_PARTIAL_GROUPBY_ROOT 演算子
Groupby グループ
SORT_PARTIAL_GROUPBY_ROOT 演算子は、SORT_PARTIAL_GROUPBY_LEAF 演算子とペアで機
能します。SORT_PARTIAL_GROUPBY_ROOT 演算子は ESP レベルでグループ化 (group by) を完了させ
ます。
SORT_PARTIAL_GROUPBY_ROOT 演算子 には子ノードが 1 つあります。この演算子の Description
フィールドには次の情報があります。
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
selection_predicate
having 句の式
expr(text)
grouping_columns
グループ化カラムの式
expr(text)
SORT_PARTIAL_GROUPBY_ROOT 演算子の例を次のクエリで示します。
SELECT o_orderpriority, COUNT(*)
FROM $big18a.tpcd2x.orders
WHERE o_orderdate >= DATE '1993-07-01'
AND o_orderdate < DATE '1993-10-01'
AND EXISTS (SELECT *
FROM $big18a.tpcd2x.lineitem
WHERE l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate)
GROUP BY o_orderpriority
ORDER BY o_orderpriority;
10 .
11 sort_partial_groupby_root grouping_columns:
indexcol(\TESTSYS.$BIG18A.TPCD2X.ORDERS.O_ORDERPRIORITY) aggregates:
sum(count(1 ))
7.1.46 SORT_SCALAR_AGGR 演算子
Groupby グループ
SORT_SCALAR_AGGR 演算子は、GROUP BY 句のない集計に対して発生し、ローを 1 つ返します。こ
の演算子の Description フィールドには次の情報があります。
7-44
トークン
内容
データ・タイプ
aggregates
集計関数の式
expr(text)
selection_predicates
having 句の式
expr(text)
523728-001J
第 7 章 演算子と演算子グループ
SORT_SCALAR_AGGR 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
AND p_size = 15
AND p_type like '%BRASS'
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'EUROPE'
AND ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
?
XX
211862597476194167
34 SORT_SCALAR_AGGR
33
?
9.9999997E-003
3.0513660E-004
1.7417581E+000 CPU_TIME: 0.357311 IO_TIME:
0.056431 MSG_TIME: 0.067074 IDLETIME: 0
PROBES: 10
aggregates: min(indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPLYCOST))
selection_predicates:
(indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPLYCOST) =
min(indexcol(\TESTSYS.$DATA14.SPTPCD.PARTSUPP.PS_SUPPLYCOST)))
7.1.47 SPLIT_TOP 演算子
Exchange グループ
SPLIT_TOP 演算子は、実行プランの中で DAM への要求が複数のパラレル処理レベルで発生するファイ
ル・システム・インタフェースに対する部分を記述します。SPLIT_TOP 演算子に対する演算子は常に
SPLIT_TOP です。Exchange 演算子の詳細は、第 8 章「並列性」を参照してください。
SPLIT_TOP 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報が
あります。
523728-001J
トークン
内容
データ・タイプ
top_degree_parallelism
存在する SPLIT_TOP ノードを含むフラグメ
ントのインスタンスの数
integer
bottom_degree_parallelism
パーティションの数
integer
top_num_data_streams
パーティションの数
integer
7-45
第 7 章 演算子と演算子グループ
bottom_num_data_streams
パーティションの数
integer
bottom_partitioning_function
パーティション化のタイプの詳細と、パラレ
ル・プランのサマリ情報
text
SPLIT_TOP 演算子の例を次のクエリで示します。
SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address,
s_phone, s_comment
FROM part,supplier,partsupp, nation, region
WHERE p_partkey = ps_partkey
AND s_suppkey = ps_suppkey
AND p_size = 15
AND p_type like '%BRASS'
AND s_nationkey = n_nationkey
AND n_regionkey = r_regionkey
AND r_name = 'EUROPE'
AND ps_supplycost = (SELECT MIN(ps_supplycost)
FROM partsupp ps1,supplier s1, nation n1,region r1
WHERE p_partkey = ps1.ps_partkey
AND s1.s_suppkey = ps1.ps_suppkey
AND s1.s_nationkey = n1.n_nationkey
AND n1.n_regionkey = r1.r_regionkey
AND r1.r_name = 'EUROPE’
ORDER BY s_acctbal desc, n_name, s_name, p_partkey;
?
XX
211862597476194167
24 SPLIT_TOP
23
?
1.0000000E+002
6.5439477E-002
2.5947284E-001
CPU_TIME: 0.066973 IO_TIME: 0.020272 MSG_TIME: 0.012804
IDLETIME: 0.1925
PROBES: 1
top_degree_parallelism: 1
bottom_degree_parallelism: 12
top_num_data_streams: 1
bottom_num_data_streams: 12
bottom_partitioning_function: logphys partitioned(grouping, PAPA with 12
PA(s), log=exactly 1 partition, phys=range partitioned 12 ways on
(([1377]equiv(SUPPLIER.S_NATIONKEY) )))
7.1.48 SUBSET_DELETE 演算子
DAM Subset グループ
SUBSET_DELETE 演算子は、実行プランの中で特定のアクセス・パスのスキャン方法を説明する部分を
記述します。この演算子は複数のローを削除します。サブセット操作は、読み取りと削除を結合された 1
つの演算子で実行します。この操作は、読み取りと削除を別々に実行する CURSOR_DELETE 演算子とは
異なります。CURSOR_DELETE 操作には、より多くのメッセージが関係します。
この演算子には子ノードがありません。この演算子の Description フィールドには次の情報があります。
7-46
523728-001J
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
begin_key
開始キー述語の式
expr(text)
end_key
終了キー述語の式
expr(text)
scan_type
インデックスの情報
text
scan_direction
forward または reverse
text
lock_mode
no lock、share lock、exclusive lock のいずれか
text
access_mode
read committed、read uncommitted、serializable の
いずれか
text
columns_retrieved
返されるカラムの予測数
integer
SUBSET_DELETE 演算子の例を次のクエリで示します。
DELETE FROM $big18a.wisc32m.bbase WHERE unique2 < 32000;
.
.
1
subset_delete
part_key_predicates: (equiv(BBASE.UNIQUE2) < 32000)
begin_key: (indexcol(\TESTSYS.$BIG18A.WISC32M.BBASE.UNIQUE2) = -2147483648)
end_key: (indexcol(\TESTSYS.$BIG18A.WISC32M.BBASE.UNIQUE2) = 32000)
7.1.49 SUBSET_UPDATE 演算子
DAM Subset グループ
SUBSET_UPDATE 演算子は、実行プランの中で特定のアクセス・パスのスキャン方法を説明する部分
を記述します。この演算子は複数のローを更新します。サブセット操作は、読み取りと更新を結合された
1 つの演算子で実行します。この操作は、読み取りと更新を別々に実行する CURSOR_UPDATE 演算子と
は異なります。CURSOR_UPDATE 操作には、より多くのメッセージが関係します。
この演算子には子ノードがありません。この演算子の Description フィールドには次の情報があります。
523728-001J
トークン
内容
データ・タイプ
begin_key
開始キー述語の式
expr(text)
end_key
終了キー述語の式
expr(text)
scan_type
インデックスの情報
text
scan_direction
forward または reverse
text
lock_mode
no lock、share lock、exclusive lock
のいずれか
text
access_mode
read committed、read uncommitted、
serializable のいずれか
text
new_rec_expr
更新されるローの計算
expr(text)
columns_retrieved
返されるカラムの予測数
integer
7-47
第 7 章 演算子と演算子グループ
SUBSET_UPDATE 演算子の例を次のクエリで示します。
UPDATE $big18a.wisc32m.abase SET two = two + 1 WHERE unique3 < 320000;
.
.
1
subset_update
new_rec_expr: (\TESTSYS.$BIG18A.WISC32M.ABASE.TWO assign
(cast(indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.TWO)) + cast(1))) predicate:
(indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE3) < 320000)
begin_key: (indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2) = -2147483648)
end_key: (indexcol(\TESTSYS.$BIG18A.WISC32M.ABASE.UNIQUE2) = 2147483647)
7.1.50 TRANSPOSE 演算子
Data Mining グループ
TRANSPOSE 演算子は、TRANSPOSE 句の結果として発生します。
TRANSPOSE 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報
があります。
トークン
内容
データ・タイプ
transpose_union_vector
transpose 句の 転置集合を表す。複数の転置集合
がある場合、トークンの複数インスタンス。
ItemExpr tree
データ・マイニングの詳細は、『HP NonStop SQL/MX Data Mining Guide』を参照してください。
TRANSPOSE 演算子の例を次のクエリで示します。
INSERT INTO test1
SELECT x1, x1/2, x1/4, x1/8 FROM t TRANSPOSE
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
15 as x1;
211862648363811363
3 TRANSPOSE
2
?
1.5999999E+003
3.0645998E-003
2.0646531E-002
CPU_TIME: 0.009267 IO_TIME: 0.020647 MSG_TIME: 0
IDLETIME: 0
PROBES: 1
transpose_union_vector: ValueIdUnion(0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15)
7.1.51 TUPLE_FLOW 演算子
Join グループ
TUPLE_FLOW 演算子は、実行プランの中で nested join をともなう部分を記述します。この演算子では、
子ノード間でデータの受け渡しが可能になります。
TUPLE_FLOW 演算子には子ノードが 2 つあります。この演算子の Description フィールドには次の情報
があります。
7-48
523728-001J
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
join_type
inner、left、natural、inner semi、inner anti-semi
のいずれか
text
join_method
ジョイン方法の名前
text
join_predicate
ジョイン述語の式
expr(text)
parallel_join_type
タイプ 1 または タイプ 2。パラレル・ジョイ
ン・アルゴリズムによって異なる。
text
selection_predicate
選択述語の式
expr(text)
TUPLE_FLOW 演算子の例を次のクエリで示します。
UPDATE abase SET two = two + 1 WHERE unique3
<
32000;
3
6
7
tuple_flow
join_type: inner
join_method: in-order nested
parallel_join_type: 1
7.1.52 TUPLELIST 演算子
Tuple グループ
TUPLELIST 演算子は、VALUE 句が使用されている場合にクエリに入れる値を示します。この演算子の
Description フィールドには次の情報があります。
トークン
内容
データ・タイプ
tuple_expr
このノードによって生成されるタプル
expr(text)
TUPLELIST 演算子の例を次のクエリで示します。
INSERT INTO $big18a.tpcd2x.nation
VALUES (43, 'botswana', 16, 'african country'),
(44, 'france', 23, 'european country'),
(45, 'nepal', 88, 'asian country');
.
.
1
tuplelist
tuple_expr: cast(45), cast('nepal'), cast(88), cast('asian country'
7.1.53 UNIQUE_DELETE 演算子
DAM Unique グループ
UNIQUE_DELETE 演算子は、実行プランの中で 1 ローだけで機能する部分を記述します。この演算子
は、0 または 1 個のローを削除します。
UNIQUE_DELETE 演算子には子ノードがありません。この演算子の Description フィールドには次の情
報があります。
523728-001J
7-49
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
begin_key
キー述語の式
expr(text)
end_key
キー述語の式
expr(text)
olt_optimization
短い単純な操作に最適化が使用されているかどうかを
示す識別子。最適化が使用されている場合は、used と
いう値が返される。
text
UNIQUE_DELETE 演算子の例を次のクエリで示します。
DELETE FROM norders
WHERE (NO_W_ID, NO_D_ID, NO_O_ID) = (?W_ID, ?D_ID, ?O_ID);
?
XX
211862680693186511
1 UNIQUE_DELETE
?
? \TESTSYS.$BIG18B.OEQA8.NORDERS
2.4750000E+001
2.0646531E-002
2.0646531E-002
CPU_TIME: 0.001712 IO_TIME: 0.020647 MSG_TIME: 0 IDLETIME: 0
PROBES: 1
part_key_predicates: VEGPred_49(VEG{NORDERS.NO_W_ID(8),
\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_W_ID(11),?W_ID(24),
"\TESTSYS.$SQL09".OEQA8.NORDERS.NO_W_ID(30),
\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_W_ID(33)}) and
VEGPred_52(VEG{NORDERS.NO_D_ID(9),
\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_D_ID(12),?D_ID(25),
"\TESTSYS.$SQL09".OEQA8.NORDERS.NO_D_ID(31),
\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_D_ID(34)}) and
VEGPred_55(VEG{NORDERS.NO_O_ID(10),
\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_O_ID(13),?O_ID(26),
"\TESTSYS.$SQL09".OEQA8.NORDERS.NO_O_ID(32),
\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_O_ID(35)})
begin_key: (indexcol(\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_W_ID) = ?W_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_D_ID) = ?D_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_O_ID) = ?O_ID) end_key:
(indexcol(\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_W_ID) = ?W_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_D_ID) = ?D_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.NORDERS.NO_O_ID) = ?O_ID)
olt_optimization: used
7.1.54 UNIQUE_UPDATE 演算子
DAM Unique グループ
UNIQUE_UPDATE 演算子は、実行プランの中で 1 ローだけで機能する部分を記述します。この演算子
は、0 または 1 個のローを更新します。
UNIQUE_UPDATE 演算子には子ノードがありません。この演算子の Description フィールドには次の情
報があります。
7-50
523728-001J
第 7 章 演算子と演算子グループ
トークン
内容
データ・タイプ
new_rec_expr
更新されるローの計算
expr(text)
begin_key
キー述語の式
expr(text)
end_key
キー述語の式
expr(text)
olt_optimization
短い単純な操作に最適化が使用されているかどうかを
示す識別子。最適化が使用されている場合は、used と
いう値が返される。
text
UNIQUE_UPDATE 演算子の例を次のクエリで示します。
UPDATE ORDERS SET O_CARRIER_ID = ?Carrier_ID
WHERE (O_W_ID, O_D_ID, O_ID) = (?W_ID, ?D_ID, ?O_ID);
?
XX
211862680734184570
1 UNIQUE_UPDATE
?
? \TESTSYS.$BIG18B.OEQA8.ORDERS
2.4857715E+001
4.1293062E-002
4.1293062E-002
CPU_TIME: 0.000819 IO_TIME: 0.041293 MSG_TIME: 0 IDLETIME: 0
PROBES: 1
new_rec_expr: ("\TESTSYS.$SQL09".OEQA8.ORDERS.O_CARRIER_ID assign
?Carrier_ID)
part_key_predicates: VEGPred_118(VEG{ORDERS.O_W_ID(15),
\TESTSYS.$BIG18B.OEQA8.ORDERS.O_W_ID(23),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_W_ID(41),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_W_ID(45),?W_ID(61),
"\TESTSYS.$SQL09".OEQA8.ORDERS.O_W_ID(67),
\TESTSYS.$BIG18B.OEQA8.ORDERS.O_W_ID(75),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_W_ID(93),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_W_ID(97)}) and
VEGPred_121(VEG{ORDERS.O_D_ID(16),
\TESTSYS.$BIG18B.OEQA8.ORDERS.O_D_ID(24),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_D_ID(42),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_D_ID(46),?D_ID(62),
"\TESTSYS.$SQL09".OEQA8.ORDERS.O_D_ID(68),
\TESTSYS.$BIG18B.OEQA8.ORDERS.O_D_ID(76),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_D_ID(94),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_D_ID(98)}) and
VEGPred_124(VEG{ORDERS.O_ID(17),
\TESTSYS.$BIG18B.OEQA8.ORDERS.O_ID(25),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_ID(44),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_ID(47),?O_ID(63),
"\TESTSYS.$SQL09".OEQA8.ORDERS.O_ID(69),
\TESTSYS.$BIG18B.OEQA8.ORDERS.O_ID(77),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_ID(96),
\TESTSYS.$BIG18B.OEQA8.ORDER1.O_ID(99)})
begin_key: (indexcol(\TESTSYS.$BIG18B.OEQA8.ORDERS.O_W_ID) = ?W_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.ORDERS.O_D_ID) = ?D_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.ORDERS.O_ID) = ?O_ID) end_key:
523728-001J
7-51
第 7 章 演算子と演算子グループ
(indexcol(\TESTSYS.$BIG18B.OEQA8.ORDERS.O_W_ID) = ?W_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.ORDERS.O_D_ID) = ?D_ID) and
(indexcol(\TESTSYS.$BIG18B.OEQA8.ORDERS.O_ID) = ?O_ID) olt_optimization:
used
7.1.55 UNPACK 演算子
Rowset グループ
クエリの入力に配列を使用する場合に、クエリ・プランの中で UNPACK 演算子を使用します (たとえば、
ローセット配列からローを挿入する場合)。UNPACK 演算子は、配列から要素を抽出しクエリの中で使用
します。ローセットと配列については、
『HP NonStop SQL/MX プログラミング・マニュアル C および
COBOL 言語用』を参照してください。
UNPACK 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報があ
ります。
トークン
内容
データ・タイプ
unpack_expression
パックされたローから値を抽出するために使用する
式
expr(text)
index_value
パックされたローへのアクセスに使用する、システ
ム生成インデックス
integer
packing_factor
パックされたローから、パック化要素を抽出するた
めに使用。パック化要素とは、1 つのパックされた
ローに含まれる論理ローの数。
expr(text)
UNPACK 演算子は、次の配列を基にしたものです。出力は、読みやすい形式に変更されています。
MDF ファイルの出力 :
PROCEDURE SQLMX_DEFAULT_STATEMENT_26 ("arrayA"
ROWSET 50 INTEGER)
ROWSET 50 INTEGER,"arrayB"
INSERT INTO t071T VALUES(:"arrayA",:"arrayB");
MXCI のコマンド :
>>select operator, cardinality, operator_cost, description from
table(explain(('CAT.SCH.CURSOMEM','SQLMX_DEFAULT_STATEMENT_26')));
OPERATOR
CARDINALITY
OPERATOR_COST
DESCRIPTION
----------------
---------------
---------------
---------------
VALUES
:arrayB
1.0000000E+000
1.4082240E-006
tuple_expr: :arrayA,
UNPACK
1.0000000E+000
7.6120221E-007 unpack_expression: (:arrayA
RowsetArrayScan \:_sys_rowset_index1), (:arrayB RowsetArrayScan
\:_sys_rowset_index1)
packing_factor: 50
index_value: \:_sys_rowset_index1
INSERT
1.0000000E+000
8.1587061E-002 new_rec_expr:
(CAT.SCH.T071T.T1 assign (:arrayA RowsetArrayScan \:_sys_rowset_index1)),
7-52
523728-001J
第 7 章 演算子と演算子グループ
(CAT.SCH.T071T.T2 assign (:arrayBRowsetArrayScan \:_sys_rowset_index1)),
(CAT.SCH.T071T.SYSKEY assign 0)
PARTITION_ACCESS
record_length: 0
1.0000000E+000
1.8542949E-003
TUPLE_FLOW
1.0000000E+000
2.5373407E-007
buffer_size: 31000
join_type: inner
join_method: nested
ROOT
1.0000000E+000
9.8000004E-002 select_list: :arrayA,
:arrayB statement_index: 9 statement: PROCEDURE SQLMX_DEFAULT_STATEMENT_26
("arrayA" ROWSET 50 INTEGER,"arrayB" ROWSET 50 INTEGER)
INSERT INTO t071T VALUES(:"arrayA",:"arrayB");
--- 6 row(s) selected.
7.1.56 VALUES 演算子
Tuple グループ
VALUES 演算子は、子ノードから受け取る各ローの式を計算し、その式を親ノードに返します。
VALUES 演算子には子ノードが 1 つあります。この演算子の Description フィールドには次の情報があ
ります。
トークン
内容
データ・タイプ
tuple_expr
このノードによって生成されるタプル
expr(text)
VALUES 演算子の例を次のクエリで示します。
INSERT INTO NORDERS VALUES (?W_ID,?D_ID,?O_ID);
.
.
1
values
tuple_expr: ?W_ID, ?D_ID, ?O_ID
523728-001J
7-53
第 7 章 演算子と演算子グループ
7-54
523728-001J
第 8 章 並列性
SQL/MX では、大規模なクエリを実行できます。SQL/MX は大規模なクエリ、特に分散サポート・シス
テム (DSS) アプリケーションを効率的に実行できるように設計されています。DSS ビジネスのアナリスト
は、ビジネスにおける複雑な決定を下すために大量のデータを検査しなければならない場合があります。
大規模クエリにおける SQL/MX パラレル処理は、そのようなクエリの効率とパフォーマンスを最大限に高
めます。
SQL/MX オプティマイザは、パラレル実行プランと非パラレル実行プランの両方を検証し、合計コスト
が最も低ければ、たとえそれが非パラレル実行プランであってもそのプランを選択します。
並列性の有効性を示す例としては、大量データ上で完全な処理を実行してから少数のローを返す演算子
を用いる場合、テーブルがパーティション化されているほうが良いという点が挙げられます。また、SELECT
COUNT(*) FROM T1,T2 WHERE T1.A=T2.B というようなクエリも、パラレル・プランの候補となるよ
い例です。この例では、大量のデータを取り出して集計する必要がありますが、クエリの終了時に返され
るのは 1 ローだけです。
パラレル実行にはいくつかの形式があります。データとクエリ実行のいずれかあるいは両方を分割すれ
ば、それらの複数のパーティションをパラレルで処理できます。この章では、SQL/MX がサポートしてい
る並列性タイプを説明します。
523728-001J
8-1
第 8 章 並列性
8.1
SQL/MX での並列性タイプ
□ パーティション化並列性 (partitioned parallelism)
□ パイプライン並列性 (pipelined parallelism)
□ 独立並列性 (independent parallelism)
SQL/MX アーキテクチャは、特別な処理を必要としないパイプライン並列性と独立並列性をサポートし
ています。SQL/MX が生成する個々のクエリ・プランには、パイプライン並列性、独立並列性、パーティ
ション化並列性が任意に組み合わされ、利用されます。
8.1.1 パーティション化並列性
パーティション化並列性は、SQL/MX の主要な並列性タイプであり、処理されるデータをパーティショ
ン ( フラクション) に分割し、各パーティションをパラレルに処理します。分割化パラレル・プランでは、
複数の演算子がすべて同じプランで処理されます。結果は、複数のパイプラインを使用してマージされる
ため、SQL/MX は入力パーティションのソート順を維持できます。また、そのデータは個別に実行できる
フラクションにパーティション化される単位のため、パーティション化並列性はデータ並列性 (data
parallelism) とも呼ばれます。パーティション化並列性は、DAM プロセスで使用される場合もあり (DAM
並列性)、ESP プロセスで使用される場合もあります (ESP 並列性)。8-5 ページの「DAM と ESP 並列性」
を参照してください。
8.1.2 パイプライン並列性
パイプライン並列性は、SQL/MX の データ・フロー・アーキテクチャとして、SQL/MX が独自に備えて
いる機能です。このアーキテクチャではすべての演算子をパイプを使って相互接続し、1 つの演算子の出
力が次の演算子に入力として送られるという処理が繰り返されます。これにより、各演算子は他の演算子
と独立して機能し、入力が可能になりしだい出力を生成することができます。パイプライン処理はほとん
どすべてのクエリ・プランで使用されます。パイプライン並列性を強制することはできません。この並列
性は、SQL/MX 検索エンジン本来の機能として備わっています。
8.1.3 独立並列性
独立実行も、SQL/MX のアーキテクチャ固有の機能です。独立並列性とは、2 つ以上の演算子を同時に
実行できるということです。特定の同期化条件を除いて、UNION クエリの一部などの演算子は独立して実
行します。通常、それぞれの独立した演算子は共通の親プロセスにパイプラインを使って接続されます。
独立並列性はパラレルで実行するデータ上の演算子であるため、演算子並列性 (operator parallelism) とも
呼ばれます。独立並列性は多くのプランで使用されます。パイプラインと同様、独立並列性も強制できま
せん。
8-2
523728-001J
第 8 章 並列性
8.2
パラレル実行の原理
8.2.1 データ・フロー・ツリーとしてのクエリ・プラン
クエリ・プランは、次の 3 種類のノードからなるデータ・フロー・ツリーで表わされます。
リーフ・ノード
各リーフ・ノードはデータ・ソース。通常は実テーブル・スキャンまたはインデッ
クス・スキャンのいずれか。
内部ノード
各内部ノードは現行クエリ内の演算子に対応する。演算子自体と同様、内部ノード
は単項、2 項、N 項が可能。Exchange ノードは、プロセス境界を表す特別な内部
ノードである。
ルート・ノード
(root ノード)
各プランにはルート・ノードが 1 つある。クエリの結果は、ルート・ノードの出力
である。
次の図は、基本的なクエリ・プランにデータ・フロー要素の説明を付加しています。
root [7]
ルート・ノード
esp exchange [6]
プロセス境界
内部ノード
merge_join [5]
partition access [2]
partition access [4]
リーフ・ノード
file_scan ORDERS [1]
プロセス境界
file_scan LINEITEM [3]
VST820.vsd
8.2.2 Exchange ノードとプラン・フラグメント
プラン・フラグメントとは、クエリ・プランの中で 1 つのプロセス内で実行される部分のことです。プ
ラン・フラグメント境界は Exchange ノードにより識別されます。次に示す演算子は、Exchange ノードと
して認識されます。
□ PARTITION_ACCESS (EXPLAIN 出力の PA としても識別される)。PARTITION_ACCESS ノードは、
一度に 1 つのパーティションへのアクセスを提供する単項ノード。PARTITION_ACCESS ノード内の
ディスク・アクセスはすべてシリアル、すなわち一度に 1 つの要求である。このノードは、DAM プロ
セス境界を決定する。
□ SPLIT_TOP (EXPLAIN 出力では PAPA として識別される)。SPLIT_TOP ノードは、2 つ以上の
PARTITION_ACCESS ノードへの同時アクセスを行う N 項演算子。結果として、SPLIT_TOP ノード
は DAM 並列性を促進する。他の 2 つの Exchange ノードとは異なり、SPLIT_TOP ノードはプロセス
境界を識別しない。
523728-001J
8-3
第 8 章 並列性
□ ESP_EXCHANGE。ESP_EXCHANGE ノードは、出力ローを生成する下位プロセスと、下位プロセス
が生成したローを受け取る上位プロセスの 2 つのプロセス間でのデータ転送を表す。
z ハッシュ再パーティション化 (hash repartitioning) では、ハッシュ関数をローのパーティション化
キーに適用することで、
下位プロセスが生成したローは上位プロセスにランダムに割り当てられる。
z 範囲再パーティション化 (range repartitioning) では、各上位プロセスに関連するパーティション化
キー値の連続範囲があり、ローのパーティション化キーが一致する範囲を判別することによって、
下位プロセスが生成したローは上位プロセスに割り当てられる。
z 複製 (replication) では、任意の下位プロセスにより生成される各ローのコピーは、すべての上位プ
ロセスに送信される。また、ESP_EXCHANGE ノードは、パラレル・データ・ストリームを 1 つ
のプロセスに集めることで、入力データ・ストリームを再配布する。
パーティション化関数のこれらのタイプについては、8-6 ページの「マッチング・パーティションによ
るジョイン」を参照してください。
プラン・フラグメントは、次のいずれかのプロセスで実行されます。
□ DAM。プラン・フラグメントは、ルート・ノードが PARTITION_ACCESS ノードの場合に限り、DAM
プロセス内で実行される。
□ ESP。プラン・フラグメントは、ルート・ノードが ESP_EXCHANGE ノードの場合に限り、ESP プロ
セス内で実行される。
□ マスタ・エグゼキュータ、またはルート。プラン・フラグメントは、ROOT 演算子を含む場合に限り、
マスタ・エグゼキュータ・プロセス内で実行される。
プラン・フラグメントの複数インスタンスは、異なるプロセッサでパラレルに実行できます。同じプラ
ン・セグメント内の各インスタンスは、それぞれのパーティション境界など、非常に細かい部分だけが異
なります。各インスタンスは通常、データの一部分 (パーティション) だけを処理します。
次の図は、DAM (index_scan から partition_access )、ESP (split_top から esp_exchange ) およびマスタ・
エグゼキュータ (sort から root ) の 3 種類のプラン・フラグメントを示したものです。実行時にプランは、
12 の DAM (DAM プラン・フラグメントの 12 のインスタンスを実行)、4 つの ESP (ESP フラグメントの 4
つのインスタンスを実行) および 1 つのマスタ・エグゼキュータ・プロセス (マスタ・エグゼキュータ・プ
ラン・フラグメントの 1 つのインスタンスを実行) から構成されるプロセス集合として実行されます。
8-4
523728-001J
第 8 章 並列性
root [14]
ルート・フラグメント
(マスタ・エグゼキュータ )
sort [13]
hash_groupby [12]
hybrid_hash_join [11]
1
split_top [3]
hybrid_hash_join [10]
1
2(logphys)
partition access [2]
1
top_degree_parallelism
split_top [6]
split_top [9]
2(logphys)
2(logphys)
bottom_degree_parallelism
file_scan [1] - LINEITEM
partition access [5]
partition access [8]
file_scan [4] - CUSTOMER
index_scan [7] - ORDERX1
DAM プラン・フラグメント
VST810.vsd
プラン・フラグメント、プラン・フラグメント境界、および EXPLAIN 出力の見方についての詳細は、812 ページの「パラレル・プランの Explain」を参照してください。
8.2.3 DAM と ESP 並列性
パーティション化並列性では、処理される演算子のタイプに基づいて、データ・アクセス・マネージャ
(DAM) プロセスとエグゼキュータ・サーバ・プロセス (ESP) という異なるプロセスが使用されます。
□ DAM 並列性は、複数の DAM フラグメント・インスタンスでのパラレル実行を表す。インスタンス
は、join または union クエリのように、異なるテーブルにアクセスしたり、SPLIT_TOP ノードの調整
下で 1 テーブルの異なるパーティションにアクセスしたりする。DAM 並列性は、待ちなし通信 (非同
期アクセス) を特徴とする。この形式の並列性は、既存のディスク・プロセスが使用されるのでコスト
は低いが、使用面での制限がある。たとえば、DAM プロセスは再パーティション化できず、他からの
要求にサービスを提供する必要がある場合がある。
□ ESP 並列性は、少なくとも 1 つの ESPプラン・フラグメントを持つ任意のパラレル・プランを表す。
ESP 並列性は、プラン・フラグメントをエグゼキュータ・サーバ・プロセス (ESP) と呼ばれる特別な
プロセス内で実行するときに発生する。ESP 並列性は、デフォルト ATTEMPT_ESP_PARALLELISM
により制御される。
コストは ESP プロセスの起動に関連します。オプティマイザは、コストと、並列性の増加によるパフォー
マンスの向上とのバランスをとり、パフォーマンスの向上が ESP 起動のコストを上回る場合にだけ、ESP
並列性を選択します。
523728-001J
8-5
第 8 章 並列性
8.3
パラレル・プラン生成
SQL/MX オプティマイザは、次に説明するように、演算子タイプの一般カテゴリに応じて異なる方法で
演算子を処理します。
8.3.1 スキャン、更新、削除
DAM 並列性では、複数の PARTITION_ACCESS 演算子が非同期アクセスを使用することで、データに
同時にアクセスできます。データは SPLIT_TOP ノードで統合されます。
8.3.2 マッチング・パーティションによるジョイン
オプティマイザは、ジョインに関連するテーブルにおいてマッチング・パーティションを検出すると、
マッチング・パーティション・アルゴリズムを使用してテーブルをジョインしようとします。このタイプ
のプランは、タイプ 1 ジョインとも呼ばれます。
注． タイプ 1 ジョインは、CONTROL QUERY SHAPE ステートメントを使用して強制できます。詳しく
は、8-24 ページの「パラレル・プランに影響を与える」を参照してください。
マッチング・パーティション・パラレル・ジョインでは、ジョインに関連する両方のテーブルの対応す
るパーティション化キー・カラムがジョイン述語で結び付けられる必要があります。また、最初のキー値
(つまり、パーティション境界) が一致していなければなりません。ハッシュ・パーティション化では、各
テーブルのパーティション数が一致している必要があり、両方のテーブルの対応するパーティション化
キー・カラムのデータ・タイプは一致していなければなりません。
分断キー
分断されたテーブル、あるいは分断されたインデックスでは、パーティション化キーはクラスタ化キー
とは異なり、また、クラスタ化キーの接頭辞も形成しません。分断キーにはパーティション化キーと同じ
規則が適用されます。クラスタ化キーに互換性があれば、ジョインはより効率的に行えます。
範囲パーティション化とハッシュ・パーティション化
パーティション境界だけが不一致の場合、異なる境界値を調整するために再パーティションまたは論理
サブパーティション化すれば、オプティマイザはマッチング・パーティション・アルゴリズムを使用する
ことができます。
オプティマイザは、ジョインに関連する両方のテーブル (外部テーブル、内部テーブル) の対応するパー
ティション化キー・カラムがジョイン述語でリンクされていない場合、または、十分な並列性を実現する
ためにより多くのパーティションが必要である場合、ジョインする前に、1 つの入力、両方の入力、また
は入力なしで、再パーティション化できます ( この場合の入力とは、外部テーブルと内部テーブルに対す
るものです) 。
ジョインに関連する両方のテーブルで対応するパーティション化キー・カラム同士がジョイン述語で結
び付けられていないと、オプティマイザはジョインのどちらかあるいは両方のテーブルを再パーティショ
ン化する必要があります。
8-6
523728-001J
第 8 章 並列性
次の図で示す簡単な例の場合、テーブル A の最初のパーティションがテーブル B の最初のパーティショ
ンとジョインされ、以降、テーブル A の 2 番目のパーティションがテーブル B の 2 番目のパーティション
というようにジョインされます。このジョイン方法はテーブル A のパーティション 1 のローと一致する
ローが必ずテーブル B のパーティション 1 に格納されている場合にだけ機能します。テーブル A とテーブ
ル B の両方が、同じキー範囲またはハッシュ関数を持つジョイン属性でパーティション化されている場合
には、オプティマイザがこのアルゴリズムを選択することがあります。
組み合わせ
ジョイン
ジョイン
テーブル A
パーティシ
ョン 1
テーブル A
パーティシ
ョン ２
テーブル A
パーティシ
ョン ３
テーブル Ｂ
パーティシ
ョン 1
テーブル Ｂ
パーティシ
ョン ２
ジョイン
ジョイン
テーブル Ｂ
パーティシ
ョン ３
SERIAL PLAN
テーブル A
パーティシ
ョン 1
テーブル Ｂ
パーティシ
ョン 1
テーブル A
パーティシ
ョン ２
テーブル Ｂ
パーティシ
ョン ２
テーブル A
パーティシ
ョン ３
テーブル Ｂ
パーティシ
ョン ３
PARTITIONED PARALLEL PLAN
前述のとおり、マッチング・パーティションによるジョインは、タイプ 1 ジョインとも呼ばれます。こ
の図に示した例は一般的なタイプ 1 ジョインです。タイプ 1 ジョインの種類については、以下で説明します。
範囲再パーティション (range repartitioning) によるジョイン
範囲再パーティションでは、1 つのテーブルだけがジョイン・カラムでパーティション化されている2 つ
のテーブル間でのマッチング・パーティション・ジョインが可能です。またこのようなプランは、最初の
キー値が一致しない場合、または2 つのテーブルのパーティション数が一致せず、他方のテーブルがジョ
イン・カラムでクラスタ化されていない場合でも生成することができます。このタイプのプランでは、1 つ
のテーブルだけが再パーティション化されます。
ハッシュ再パーティション (hash repartitioning) によるジョイン
両方のテーブルがクエリのパラレル実行を促進しない方法でパーティション化されている場合、オプティ
マイザは両方のテーブルを実行時に再パーティション化 (再編成) するようエグゼキュータに要求できます。
再編成されたテーブルには、マッチング・パーティション・ジョイン・アルゴリズムが使用されます。
オプティマイザによるジョインの再パーティション化の回避方法
再パーティション化ではかなり多くのデータ移動をともなうので、オプティマイザは、論理パーティショ
ン化と呼ばれるより効率的な方法を使用してこれを回避しようとします。オプティマイザは次のいずれか
の方法を選択します。
523728-001J
8-7
第 8 章 並列性
□ 論理パーティション・グループ化
論理パーティション・グループ化では、再パーティションを行わずに、ESP の数をパーティションの数
より少なくできます。SQL/MX 内の ESP の数は、テーブルのパーティション数よりも、使用可能な CPU
数によって決まります。あるテーブルのパーティション数が使用可能な CPU 数よりも多い場合には、オプ
ティマイザがそれらのパーティションをグループ化するため、各 ESP は複数のパーティションをあたかも
1 つのパーティションであるかのように処理します。各 ESP は、隣接するパーティションをグループにま
とめます。
ハッシュ・パーティション化テーブルにおける論理パーティション・グループ化では、ハッシュ・パー
ティション化テーブルが論理パーティションより少なくなるようにグループ化されますが、マッチングで
きるのは、元のパーティション数と同じ数のパーティションがある別のテーブルだけです。たとえば、あ
るテーブルが 15 個のパーティションに分割され、4 個の論理パーティションにグループ化される場合があ
ります。3 個の論理パーティションにはそれぞれ 4 個のパーティションがあって、1 個の論理パーティショ
ンには 3 個のパーティションがあるとします。この場合にこのテーブルとマッチングできるのは、パーティ
ションが 15 個あって論理パーティションが 4 個ある別のテーブルだけです。パーティションが 16 個あっ
て論理パーティションが 4 個あるハッシュ・パーティション化テーブルとのマッチングはできません。
次の図は、論理パーティション・グループ化 (範囲パーティション) を示しています。ジョインの左の子
ノードには 2 個のパーティションがあり、右の子ノードには 4 個のパーティションがあります。ただし、
左の子ノードのパーティション化キー境界値は、右の子ノードのパーティション化キー境界値の一部分集
合に一致しています (左の子ノードのパーティション化キー境界値 は 100 で、右の子ノードのパーティショ
ン化キー境界値は 50、100、150 です)。左の子ノードは右の子ノードをグループ化したもので、右の子ノー
ドは左の子ノードを改良したものです。このような場合には、ESP は連続する物理パーティションを 1 つ
の論理パーティションにまとめることができます。
次の図では、右の子ノードの物理パーティション 1 と 2 から論理パーティション 1 が、また、物理パー
ティション 3 と 4 から論理パーティション 2 が形成されています。右の子ノードの論理パーティションは、
左の子ノードのパーティション化スキーマと一致しています。
テーブル A
パーティシ
ョン 1
0 - 100
テーブル A
パーティシ
ョン ２
101 -
0 - 100
101 -
テーブル1
テーブル ２
テーブル B
パーティシ
ョン 1
テーブル B
パーティシ
ョン ２
テーブル B
パーティシ
ョン ３
0 - 50
51 - 100
101 - 150
左の子ノード
テーブル B
パーティシ
ョン ４
151 -
右の子ノード
VST083.vsd
□ 論理サブパーティション・アライメントによるジョイン
論理サブパーティション化は通常、ジョイン・テーブル間での相違がパーティション境界またはパーティ
ション数だけである場合に使用されます。ハッシュ・パーティション化テーブルには論理サブパーティショ
ン化を使用できません。
両方のテーブルがジョイン・カラムでパーティション化されているのに、最初のキー値または 2 番目の
テーブルのパーティション数が最初のテーブルのものと一致せず、2 番目のテーブルがジョイン・カラム
8-8
523728-001J
第 8 章 並列性
でクラスタ化されている場合、オプティマイザはこの機能を選択できます。2 番目のテーブルのパーティ
ション化キーとクラスタ化キー・カラムは、同じでなければなりません。
論理サブパーティション化では、オプティマイザは、他のテーブルが最初のテーブル (論理パーティショ
ン) と同じ方法でパーティション化されているかのように処理します 。そのため、ジョイン演算子 (ESP)
の各インスタンスは、2 つ以上のパーティション、または 2 番目のテーブルのパーティション ( サブパー
ティション) のフラクションにアクセスできます。
次の図は、論理サブパーティション化の例です。最初のテーブルには 3 つのパーティションがあります。
2 番目のテーブルには 4 つのパーティションがありますが、パーティション化キーとクラスタ化キー・カ
ラムが最初のテーブルと一致しているので、オプティマイザは 2 番目のテーブルのパーティション化キー
境界値を調整し、最初のテーブルと一致する 3 つの論理パーティションにします。
テーブル A
パーティシ
ョン 1
テーブル A
パーティシ
ョン ２
0 - 100
101 - 200
テーブル A
パーティシ
ョン ３
201 -
ﾃｰﾌﾞﾙ1
ﾃｰﾌﾞﾙ2
ﾃｰﾌﾞﾙ3
0 - 100
101 - 200
201 -
テーブル Ｂ
パーティシ
ョン 1
テーブル Ｂ
パーティシ
ョン ２
テーブル Ｂ
パーティシ
ョン ３
0 - 75
76 - 150
151 - 225
左の子ﾉード
右の子ノード
テーブル Ｂ
パーティシ
ョン ４
226 VST084.vsd
8.3.3 内部テーブルへのパラレル ・アクセスによるジョイン
内部テーブルと外部テーブルが一致せず、再パーティションが不適当または不可能であるジョインであっ
ても、オプティマイザは、内部テーブルへのパラレル・アクセスを使用することで、並列性を実現できま
す。このタイプのプランは、タイプ 2 ジョインとも呼ばれます。
注． タイプ 2 ジョインは、CONTROL QUERY SHAPE ステートメントを使用して強制できます。詳しく
は、8-24 ページの「パラレル・プランに影響を与える」を参照してください。
パラレル・アクセス・ジョインでは、外部テーブルの各パーティションは、パーティション化されてい
る、あるいはされていない内部テーブル全体とジョインされます。この方法により、テーブルがどのよう
にパーティション化されているか、また、ジョイン述語に何が指定されているのかに関係なく、正確な結
果が保証されます。これは、外部テーブル・パーティションの任意のローが、常に内部テーブルでマッチ
するローを検出することができるからです。
nested join アルゴリズムは、述語の選択性に基づいてオプティマイザにより選択されることがあります。
選択性が低く、内部テーブルに必要なプローブ数が少ない場合、nested join アルゴリズムにより最適なプ
ランを生成されます。ただし、内部テーブルのプローブ数が多数必要な場合 (ジョイン ESP から内部テー
ブルへの同時アクセスが多く発生する)、nested join アルゴリズムがパフォーマンス低下の原因となること
があります。このタイプのジョインは、ブロードキャストなしの複製 (replicate no broadcast) とも呼ばれま
す。
注． ブロードキャストなしの複製は、ソース ESP がないことを意味します。ターゲット ESP は、必要な
データを独立して読み取ります。
523728-001J
8-9
第 8 章 並列性
パラレル・アクセスをハッシュ・ジョインと組み合わせると、内部テーブルがジョイン・プロセスのメ
モリに実体化されるので、パフォーマンス低下を回避できます。各ジョイン・プロセスは内部テーブルを
ランダムに検査するのではなく、内部テーブルの内容をブロードキャストする ESP 集合から内部テーブル
の完全なコピーを受け取ります。ジョイン・プロセスが内部テーブルの完全なコピーを受け取る場合、そ
のジョインは、ブロードキャストによる複製 (replicate by broadcast) と呼ばれます。
注． ブロードキャストによる複製は、ESP が実際に複数のメッセージを各受信者に送ることを意味します。
次の図は、内部テーブルへのパラレル・アクセスを伴う nested join を示したものです。
SELECT * FROM A,B
WHERE A.COL1=B.COL2;
組み合わせ
ジョイン
ジョイン
Join
Join
テーブル A
パーティシ
ョン 1
テーブル A
パーティシ
ョン ２
テーブル A
パーティシ
ョン ３
テーブル B
外部
内部
VST890.vsd
8.3.4 UNION
MERGE_UNION の上に group by のような別の演算子が存在すると、オプティマイザはユニオン (union)
をパラレルで実行することができます。この方法には、パラレルでデータ・ストリームを受け取れるとい
うメリットがあります。MERGE_UNION 演算子をパラレル処理するために、オプティマイザは matching
partition union (マッチング・パーティション・ジョインのアルゴリズムに基づく) をサポートしています。
ユニオンの入力は同様にパーティション化されている必要があり、そうでない場合、オプティマイザはテー
ブルを再パーティション化する必要があります。
ユニオンは、次の 3 つの方法でパラレルに実行できます。
□ データの並べ替えが必要ない場合、オプティマイザは両方のテーブルをパラレルに読み取る。
□ データの並べ替えが必要な場合には、オプティマイザは、それぞれのテーブルに対しソート操作また
はインデックス操作を行い、その後、それぞれのストリームをパラレルでマージする。
□ 場合によっては、テーブルの各パーティションを別々に読み取る ESP を使用して、ユニオンがパラレ
ルで実行されることがある。
8-10
523728-001J
第 8 章 並列性
8.3.5 Group By
SQL/MX は、スカラ集計操作 (group by 演算子を伴わない group by 操作) に加えて、hash group by 操作
と sort group by 操作をサポートしています。これらのグループ化は、DAM プロセス、ESP、またはマス
タ・エグゼキュータの中で行われます。
完全な group by は、データが group by カラムでパーティション化されていればパラレルに実行できま
す。完全なスカラ集計は、パラレルで実行できません。
部分的な group by 演算子は、パーティション化スキームに関係なくパラレルに実行できますが、グルー
プが重複することがあります。そのため、部分的な group by の結果は、クエリの結果が使用される前に一
連の最終ステップで結合される必要があります。部分的なスカラ集計は、パーティション化スキームに関
係なくパラレルに実行できますが、部分的な集計は一連の最終ステップで結合される必要があります。
8.3.6 ソート
SQL/MX では、複数の ESP によるパラレルのソートと、マスタ・エグゼキュータによるシリアルのソー
トを実行できます。パラレル・ソートには、マスタ・エグゼキュータまたは他の ESP によりソートされた
ストリームのマージが必要です。
8.3.7 挿入、選択
オプティマイザは、パラレルとシリアルの両方の挿入 (insert) と選択 (select) で、できるだけ連続して
(ランダムでなく) ローを挿入しようとします。パフォーマンス上の理由から、オプティマイザは、選択さ
れたローをターゲット・テーブルと同じ並び順で同じようにパーティション化するようなプランを生成し
ます。この機能では、挿入前にソートを含むことができます。デフォルト設定 UPD_ORDERED を OFF に
設定することで、この機能を無効にできます (オプティマイザがローの挿入前にソートを実行しないように
するため)。詳細は、8-24 ページの「並列性に影響を与えるデフォルト設定」と『NonStop SQL/MX リファ
レンス・マニュアル』のデフォルト・テーブルの項を参照してください。
8.3.8 異なるタイプの並列性を結合する
複数レベルの並列性とは、各演算子が並列性がない場合も含めて、異なるレベルのパーティション化並
列性を使用できることを表します。複数レベルの並列性の例としては、ルートに最も近い複数の演算子が
パラレルで実行していないためにマスタ・エグゼキュータで実行されていて、その一方で、より低いレベ
ルの演算子はパラレルで実行しているような場合が挙げられます。また、異なる演算子がパラレルで実行
されているものの、使用する ESP の数が異なるという例もあります。
SQL/MX は、いくつかの演算子は本来の並列性レベルを使用し、その一方で、他の演算子は利用可能な
CPU の数をベースにして最大パーティション数を使用するという考え方を採用しています。DAM レベル
では、パーティション化は固定です。
523728-001J
8-11
第 8 章 並列性
8.4
パラレル・プランの Explain
最適化されたパラレル・プランを確認するには、EXPLAIN 関数を使用します。EXPLAIN 関数の使用方
法およびその読み方の詳細については、第 4 章「クエリ実行プランの確認」を参照してください。
8.4.1 パラレル・プランが使用されているかどうかの確認方法
並列性を使用可能にするデフォルト設定がオンになっていることを確認してください。詳細は、8-24 ペー
ジの「並列性に影響を与えるデフォルト設定」を参照してください。
クエリをコンパイルし、EXPLAIN 関数を使用してクエリ・プランを確認します。
クエリ・プランのパーティション化並列性は、Exchange グループの演算子、ESP_EXCHANGE と
SPLIT_TOP で表されます。クエリ・プランにこれらの演算子が含まれていなければ、そのプランではパラ
レル処理が使用されていません。
これ以外にも、Exchange 演算子 PARTITION_ACCESS がパラレル・プランに表示されますが、これは
ESP 並列性、DAM 並列性のどちらも意味しません。PARTITION_ACCESS 演算子は、実行プランの中で
パーティション化並列性のない DAM への要求がある部分を記述するために使用されます。一度に要求を
送れるのは、1 つの DAM プロセスです。
Exchange 演算子については、第 7 章「演算子と演算子グループ」を参照してください。
オプティマイザによる ESP 数の選択方法
ESP_EXCHANGE 演算子は、クエリ・プランにおける ESP 並列性を表します。パラレル・プランのため
に選択される ESP 数の決定要因は、次のとおりです。
□ 次の数値から求められる、クラスタ内の合計 CPU 数。
z クラスタ内のノードごとの CPU 数
z クラスタ内のノード数
□ 1 つの演算子に対する最大 ESP 数は、CPU 数にデフォルト設定値 MAX_ESPS_PER_CPU_PER_OP を
かけた値。デフォルト値は 1。
デフォルト MAX_ESPS_PER_CPU_PER_OP を再セットしていない限り、CPU 数を超える数の ESP を
使用することはできません。クエリが I/O 制約 (I/O bound) の場合や、CPU が十分に使用されていない
場合には、デフォルト MAX_ESPS_PER_CPU_PER_OP を増やすことがあります。たとえば、あるノー
ド (16 CPU) で実行し、64 のパーティションにアクセスするプランでは、通常 16 の ESP (各 CPU に 1
つの ESP) を使用します。MAX_ESPS_PER_CPU_PER_OP のデフォルト値を 2 に変更すると、ESP は
32 になります。詳細は、8-24 ページの「並列性に影響を与えるデフォルト設定」を参照してください。
8-12
523728-001J
第 8 章 並列性
例
ここでは、クエリに対するクエリ・ツリーでの ESP 並列性を紹介します。
SELECT * FROM ORDERS O, LINEITEM L
WHERE O.O_ORDERKEY=L.L_ORDERKEY
AND O.O_TOTALPRICE < 25000 AND L.L_QUANTITY < 5;
このクエリは、合計金額が $25,000 未満で、発注された量が 5 個未満の小口注文の情報を抽出します。図
8-1 にクエリ・ツリーを示します。EXPLAIN 出力を見ると、ESP プロセスで並列性が行われていることが
わかります ( 並列性に関連するトークンが強調表示されています)。このテーブルは、O_ORDERKEY と
L_ORDERKEY でパーティション化されています。
図 8-1 ESP 並列性を使用したマッチング・パーティション・ジョイン
root [7]
esp exchange [6]
merge_join [5]
partition access [2]
partition access [4]
file_scan ORDERS [1]
file_scan LINEITEM [3]
VST085.vsd
このクエリ・プランは、パラレル・マッチング・パーティション merge join を表しています。2 つの ESP
が起動され、パラレルで merge join を実行します (ESP_EXCHANGE の bottom_degree_parallelism トー
クン)。また、bottom_partitioning_function トークンは、マッチング・パーティション・ジョインが指定
カラムでの 2 ウェイの範囲パーティションであることを示しています。これらの並列性に関連するトーク
ンについては、8-16 ページの「EXPLAIN 出力の並列性トークン」を参照してください。
EXPLAIN 出力の一部を次に示します。
Seq_Num: 6
Operator: ESP_EXCHANGE
Left_Child_Seq_Num: 5
Right_Child_Seq_Num: ?
Cardinality: 1.7563164E+004
Operator Cost: 1.0772745E+000
Total Cost: 6.0278694E+001
Detail Cost: CPU_TIME: 43.9642 IO_TIME: 59.8779
MSG_TIME: 1.30885 IDLETIME: 0.400804 PROBES: 1
bottom_partition_input_values: \:_sys_HostVarLo0, \:_sys_HostVarHi0,
\:_sys_hostVarExclRange
buffer_size: 3951
record_length: 288
523728-001J
8-13
第 8 章 並列性
top_degree_parallelism: 1
bottom_degree_parallelism: 2
top_num_data_streams: 1
bottom_num_data_streams: 2
bottom_partitioning_function: range partitioned 2 ways on
(([150]equiv(O.O_ORDERKEY)))
図 8-2に、DAM 並列性を使用してパーティション化テーブルにアクセスする同じクエリを示します。こ
のクエリ・プランは、ESP のないシリアル hybrid hash join を示しています。ただし、もととなるパーティ
シ ョ ン 化 テ ー ブ ル へ の ア ク セ ス を 行 う SPLIT_TOP 演 算 子 で、DAM 並 列 性 が 示 さ れ て い ま す。
bottom_partitioning_function トークンは、2 つの PARTITION_ACCESS ノードが起動され、2 ウェイの範
囲パーティション化テーブルのデータにパラレルでアクセスすることを示しています。
図 8-2 DAM 並列性を使用したシリアル・ハイブリッド・ハッシュ・ジョイン
root [8]
hybrid_hash_join [7]
split_top [3]
split_top [6]
partition access [2]
partition access [5]
file_scan ORDERS [1]
file_scan LINEITEM [4]
VST086.vsd
EXPLAIN 出力の一部を次に示します。この出力は 2 つの SPLIT_TOP 演算子の詳細を示しています。
Seq_Num: 3
Operator: SPLIT_TOP
Left_Child_Seq_Num: 2
Right_Child_Seq_Num: ?
Cardinality: 5.9717000E+004
Operator Cost: 3.2347381E+000
Total Cost: 2.1504770E+001
Detail Cost: CPU_TIME: 5.697804 IO_TIME: 9.2084682 MSG_TIME: 0 IDLETIME:
0.7 PROBES: 1
top_degree_parallelism: 1
bottom_degree_parallelism: 2
top_num_data_streams: 1
bottom_num_data_streams: 2
bottom_partitioning_function: logphys partitioned(grouping, PAPA with 2
PA(s), log=exactly 1 partition, phys=range partitioned 2 ways on
(([150]equiv(O.O_ORDERKEY))))
Seq_Num: 6
Operator: SPLIT_TOP
8-14
523728-001J
第 8 章 並列性
Left_Child_Seq_Num: 5
Right_Child_Seq_Num: ?
Cardinality: 9.3210889E+003
Operator Cost: 5.0158596E-001
Total Cost: 5.4755492E+000
Detail Cost: CPU_TIME: 1.2585902 IO_TIME: 2.1397587 MSG_TIME: 0
IDLETIME: 0.7 PROBES: 1
top_degree_parallelism: 1
bottom_degree_parallelism: 2
top_num_data_streams: 1
bottom_num_data_streams: 2
bottom_partitioning_function: logphys partitioned(grouping, PAPA with 2
PA(s), log=exactly 1 partition, phys=range partitioned 2 ways on
(([150]equiv(O.O_ORDERKEY))))
8.4.2 プラン・フラグメント
プランの基礎となる並列性を理解するには、クエリ・プランをプラン・フラグメントに分割すると便利
です。8-3 ページの「Exchange ノードとプラン・フラグメント」で説明したように、プラン・フラグメン
トはプランの一部分であり、同じプロセスで実行するもので、そのノードのルートは以下のいずれかとな
ります。
□ ROOT: このフラグメントはルート・フラグメントまたはマスタ・エグゼキュータと呼ばれ、クエリ・
プランごとに一度だけ発生する。
□ ESP_EXCHANGE: これらのフラグメントは ESP プラン・フラグメントと呼ばれ、クエリ・プランで
何度も発生することがある。
□ PARTITION_ACCESS: これらのフラグメントは DAM プラン・フラグメントと呼ばれ、DAM プロセ
スとパーティション間の境界を表す。
1 つのクエリ・プランは、1 つ以上のプラン・フラグメントで構成されます。プラン・フラグメントは、
クエリをコンパイルしてから EXPLAIN 出力を表示して確認します。フラグメント境界は、Exchange ノー
ドである ESP_CEXCHANGE と PARTITION_ACCESS で表されます。図 8-5 に、クエリ・プランで識別
されるプラン・フラグメントを示します。各 Exchange ノードは、2 つのフラグメントの一部です。
EXPLAIN 出力を基にクエリ・ツリーを示すと、図 8-5 に示すようなプラン・フラグメントを識別できま
す。
実行時には、各プラン・フラグメントに対して 1 つ以上のパラレル・インスタンスが作成されます。ルー
ト・フラグメントには常に 1 つのインスタンスがあり、マスタ・エグゼキュータで実行されます。
ESP フラグメント(最上位ルートとしての ESP_EXCHANGE) は、エグゼキュータ・サーバ・プロセスで
実行されます。ESP_EXCHANGE ノードの EXPLAIN 出力は、次の「EXPLAIN 出力の並列性トークン」
で示すように、作成されるインスタンスの数を示します。
DAM フラグメント (最上位ルートとしての PARTITION_ACCESS) は、DAM で実行されます。DAM フ
ラグメントのアクティブ・インスタンスは、SPLIT_TOP ノードが PARTITION_ACCESS ノードの上にな
い限り、1 つだけ存在します。SPLIT_TOP ノードの EXPLAIN 出力は、次に説明するように DAM フラグ
メントに対して作成されるインスタンスの数を示します。
523728-001J
8-15
第 8 章 並列性
EXPLAIN 出力の並列性トークン
Exchange 演算子である ESP_EXCHANGE と SPLIT_TOP には、各プラン・フラグメントの最高と最低
の並列度を表す、EXPLAIN 出力の Descriptionカラムのトークンが含まれます。
ESP_EXCHANGE 演算子の場合には、top_degree_parallelism トークンは、そのノード上にフラグメン
トのインスタンスがいくつあるかを示します。マスタ・エグゼキュータと通信する ESP_EXCHANGE ノー
ドの場合、この値は常に 1 です。bottom_degree_parallelism トークンは、このノードをルートとするフラ
グメントのインスタンスがいくつあるかを示します。bottom_partitioning_function トークンは、プランがど
のように並列化されるかについての情報を示します。
SPLIT_TOP 演算子の場合、top_degree_parallelism トークンは、SPLIT_TOP ノードを含むフラグメント
のインスタンスがいくつあるかを示します。bottom_degree_parallelism トークンは、パーティションがい
くつあるかを示します。bottom_partitioning_function トークンは、パラレル・プランに関する論理情報と物
理情報の両方を示します。物理情報は並列性と最も関連性が高い情報で、フラグメントがどのようにパー
ティション化されるかを示します。
プラン・フラグメントの認識
以下の一連の図 (図 8-3 ∼ 図 8-6) は、DISPLAY_EXPLAIN OPTIONS 'f' SQLQUERY コマンドで取得
した出力と、次のクエリで識別されるプラン・フラグメントのクエリ・ツリーです。
PREPARE SQLQUERY FROM
SELECT l_orderkey, CAST(SUM(l_extendedprice*(1-l_discount))
AS NUMERIC(18,2)), o_orderdate, o_shippriority
FROM customer,orders,lineitem
WHERE c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1995-03-15'
AND l_shipdate > DATE '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY 2 DESC,3 ASC;
注． このクエリは、TPC-D 意思決定支援ベンチマークから抽出し、DIAPLAY_EXPLAIN コマンドで
OPTIONS ‘f’ オプションを指定して実行し取得した DISPLAY_EXPLAIN 出力です。この出力部分に
『NonStop SQL/MX リファレンス・
は OPT カラムは含まれていません。OPTIONS ‘f’ 句については、
マニュアル』の¢DISPLAY_EXPLAIN コマンド£を参照してください。
8-16
523728-001J
第 8 章 並列性
例 8-1 ESP 並列性を使用したサンプル・クエリの DISPLAY_EXPLAIN OPTIONS 'f' SQLQUERY 出力
LC
-12
11
10
9
2
7
4
5
.
3
.
1
.
RC
-.
.
.
.
8
.
6
.
.
.
.
.
.
OP
-13
12
11
10
9
8
7
6
5
4
3
2
1
OPERATOR
------------------------root
esp_exchange
sort
hash_groupby
hybrid_hash_join
esp_exchange
merge_join
partition_access
index_scan
partition_access
file_scan
partition_access
file_scan
DESCRIPTION
-------------------1:2(range)
2(range):2(range)
ORDERX1 (s)
CUSTOMER (s)
LINEITEM (s)
CARDINALITY
---------1.23E+4
1.23E+4
1.23E+4
1.23E+4
3.26E+4
1.51E+4
1.51E+4
7.27E+4
7.27E+4
3.11E+3
3.11E+3
3.24E+5
3.24E+5
この出力には、シーケンス番号、演算子、並列性の情報、および演算子の基数 (cardinality) が表示されて
います。シーケンス番号を使用すると、クエリ・プランをビジュアルに表示するクエリ・ツリーを作成で
きます。
注． 図 8-3 ∼ 図 8-6 のプランは、デフォルトの左線リニア・ツリーではなく、デフォルト設定を使用して
ジグザグ・ツリー・シェイプを生成しています。ジグザグ・ツリーの詳細は、第 4 章「クエリ実行プ
ランの確認」を参照してください。
523728-001J
8-17
第 8 章 並列性
図 8-3 ESP 並列性によるクエリ・ツリー
root [13]
esp exchange [12]
sort [11]
hash_groupby [10]
hybrid_hash_join [9]
partition access [2]
esp exchange [8]
file_scan [1] - LINEITEM
merge_join [7]
partition access [4]
file_scan [3] - CUSTOMER
partition access [6]
index_scan [5] - ORDERX1
VST087.vsd
図 8-4 に、ルート・フラグメント (マスタ・エグゼキュータ) と最初の ESP フラグメント間の 境界を形
成する ESP_EXCHANGE ノードを示します。
図 8-4 プラン・フラグメント境界
root [13]
ルート・フラグメント
(マスタ・エグゼキュ
ータ)
プラン・フラグメント境界
esp exchange [12]
ESP フラグメント
sort [11]
VST088.vsd
ESP_EXCHANGE 演算子の EXPLAIN 出力には、最大並列性 (この場合 1 で、ルート・フラグメントの
並列性を表す) と最低並列性 (この場合は 2 で、ESP フラグメントでの並列性を表す) に関連する記述のトー
クンを示します。bottom_partitioning_function トークンは、パラレル・プランのタイプについての情報を提
供します。並列性に関するトークンは (見やすいように) 太字で表示されています。
8-18
523728-001J
第 8 章 並列性
Seq_Num: 12
Operator: ESP_EXCHANGE
Left_Child_Seq_Num: 11
Right_Child_Seq_Num: ?
Cardinality: 1.2347501E+004
Operator Cost: 5.5621022E-001
Total Cost: 2.7717787E+001
Detail Cost: CPU_TIME: 0.0821787 IO_TIME: 0 MSG_TIME: 0
IDLETIME: 0.262715 PROBES: 1
merged_order: inverse(cast(cast((cast(sum((cast(indexcol
(TPCD.XMPS.LINEITEM.L_EXTENDEDPRICE)) * cast((cast((1 * 100)) indexcol(TPCD.XMPS.LINEITEM.L_DISCOUNT)))))) / cast(100))))),
indexcol(TPCD.XMPS.ORDERX1.O_ORDERDATE)
bottom_partition_input_values: \:_sys_HostVarLo0, \:_sys_HostVarHi0,
\:_sys_hostVarExclRange
buffer_size: 6250
record_length: 24
top_degree_parallelism: 1
bottom_degree_parallelism: 2
top_num_data_streams: 1
bottom_num_data_streams: 2
bottom_partitioning_function: range partitioned 2 ways on
(([260]equiv(TPCD.XMPS.ORDERS.O_ORDERKEY)))
図 8-5 は、プラン・フラグメントを含むクエリ・プラン全体を示します。演算子のシーケンス番号は、演
算子名の横に示されています。
523728-001J
8-19
第 8 章 並列性
図 8-5 プラン・フラグメントを表すサンプル・クエリ・プラン
root [13]
ルート・フラグメント
top_degree_parallelism
1
(マスタ・エグゼキュータ)
esp exchange [12]
2(range)
bottom_degree_parallelism
sort [11]
hash_groupby [10]
ESP プラン・フラグメント
hybrid_hash_join [9]
top_degree_parallelism
2(range)
partition access [2]
esp exchange [8]
2(range)
file_scan [1] - LINEITEM
bottom_degree_parallelism
merge_join [7]
partition access [4]
partition access [6]
file_scan [3] - CUSTOMER
index_scan [5] - ORDERX1
DAM プラン・フラグメント
VST089.vsd
8.4.3 並列度
各プラン・フラグメント には、EXPLAIN 出力の演算子説明フィールドにある Exchange 演算子のトーク
ンで示されるように、その演算子固有の並列度があります。図 8-5 のクエリ・プランには、1 つのルート・
フラグメント、2 つの ESP フラグメント、3 つの DAM フラグメントがあります。このクエリ・プランに
は、並 列 度 に 関 す る 情 報 が 各 E S P _ E X C H A N G E 演 算 子 の 説 明 フ ィ ー ル ド に 含 ま れ て い ま す。
PARTITION_ACCESS ノードは、開始キー述語と終了キー述語についての情報を提供し、処理されるパー
ティションの開始位置と終了位置を各 DAM フラグメントに指示します。
並 列 度 の 詳 細 を さ ら に 理 解 で き る よ う に、D A M 並 列 性 ( E S P 並 列 性 で は な い) を 使 用 し、
DISPLAY_EXPLAIN OPTIONS ‘f’ SQLQUERY コマンドで出力した例を次に示します。
PREPARE SQLQUERY FROM
SELECT l_orderkey, CAST(SUM(l_extendedprice*(1-l_discount))
AS NUMERIC(18,2)), o_orderdate, o_shippriority
8-20
523728-001J
第 8 章 並列性
FROM customer,orders,lineitem
WHERE c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1995-03-15'
AND l_shipdate > DATE '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY 2 DESC,3 ASC;
例 8-2 DAM 並列性を使用したサンプル・クエリの
DISPLAY_EXPLAIN_OPTIONS ‘f’ SQLQUERY 出力
LC
-13
12
11
3
6
8
7
.
5
4
.
2
1
.
RC
-.
.
.
10
9
.
.
.
.
.
.
.
.
.
OP
-14
13
12
11
10
9
8
7
6
5
4
3
2
1
OPERATOR
------------------------root
sort
hash_groupby
hybrid_hash_join
hybrid_hash_join
split_top
partition_access
file_scan
split_top
partition_access
file_scan
split_top
partition_access
file_scan
DESCRIPTION
-----------------
1:2(logph)
CUSTOMER (s)
1:2(logph)
ORDERS (s)
1:2(logph)
LINEITEM (s)
CARDINALITY
----------1.23E+4
1.23E+4
1.23E+4
3.26E+4
1.51E+4
3.11E+3
3.11E+3
3.11E+3
7.27E+4
7.27E+4
7.27E+4
3.24E+5
3.24E+5
3.24E+5
図 8-6は、プラン・フラグメントを含むプランのクエリ・ツリーを示します。
注． SPLIT_TOP 演算子が DAM 並列性を表すので、なぜ SPLIT_TOP 演算子ではなく PARTITION_TOP
演算子で DAM プラン・フラグメントが表されているのか疑問を持つかもしれません。SPLIT_TOP 演
算 子 は、ESP ま た は マ ス タ・エ グ ゼ キ ュ ー タ と DAM 間 の 機 能 を 分 割 す る 役 割 を 果 た し ま す。
SPLIT_TOP 演算子は、パーティションごとに PARTITON_ACCESS ノードを介して DAM に作業を
割り当てます。
523728-001J
8-21
第 8 章 並列性
図 8-6 DAM 並列性を使用したサンプル・クエリのクエリ・ツリー
root [14]
ルート・フラグメント
sort [13]
(マスタ・エグゼキュータ )
hash_groupby [12]
hybrid_hash_join [11]
1
split_top [3]
hybrid_hash_join [10]
1
2(logphys)
partition access [2]
top_degree_parallelism
1
split_top [6]
split_top [9]
2(logphys)
2(logphys)
bottom_degree_parallelism
file_scan [1] - LINEITEM
partition access [5]
partition access [8]
file_scan [4] - CUSTOMER
index_scan [7] - ORDERX1
DAM プラン・フラグメント
VST810.vsd
各 SPLIT_TOP 演算子は、最高と最低の並列度を提示します。EXPLAIN 出力は、クエリ・プランからの
3 つの SPLIT_TOP 演算子を示しています。並列性に関連するトークンは太字で表示されています。
Seq_Num: 3
Operator: SPLIT_TOP
Left_Child_Seq_Num: 2
Right_Child_Seq_Num: ?
Cardinality: 3.2441872E+005
Operator Cost: 3.4873798E+000
Total Cost: 1.7911737E+001
Detail Cost: CPU_TIME: 3.843434 IO_TIME: 7.6177573495 MSG_TIME: 0 IDLETIME:
0.7 PROBES: 1
top_degree_parallelism: 1
bottom_degree_parallelism: 2
top_num_data_streams: 1
bottom_num_data_streams: 2
bottom_partitioning_function: logphys partitioned(grouping, PAPA with 2
PA(s), log=exactly 1 partition, phys=range partitioned 2 ways on
(([260]equiv(TPCD.XMPS.ORDERS.O_ORDERKEY) )))
8-22
523728-001J
第 8 章 並列性
Seq_Num: 6
Operator: SPLIT_TOP
Left_Child_Seq_Num: 5
Right_Child_Seq_Num: ?
Cardinality: 7.2738547E+004
Operator Cost: 5.6920946E-001
Total Cost: 4.6269255E+000
Detail Cost: CPU_TIME: 0.9101162 IO_TIME: 1.7542597
MSG_TIME: 0 IDLETIME: 0.7 PROBES: 1
top_degree_parallelism: 1
bottom_degree_parallelism: 2
top_num_data_streams: 1
bottom_num_data_streams: 2
bottom_partitioning_function: logphys partitioned(grouping, PAPA with 2
PA(s), log=exactly 1 partition, phys=range partitioned 2 ways on
(([260]equiv(TPCD.XMPS.ORDERS.O_ORDERKEY) )))
Seq_Num: 9
Operator: SPLIT_TOP
Left_Child_Seq_Num: 8
Right_Child_Seq_Num: ?
Cardinality: 3.1110000E+003
Operator Cost: 4.4777110E-002
Total Cost: 1.9319278E+000
Detail Cost: CPU_TIME: 0.1957998 IO_TIME: 0.5657918
MSG_TIME: 0 IDLETIME: 0.7 PROBES: 1
top_degree_parallelism: 1
bottom_degree_parallelism: 2
top_num_data_streams: 1
bottom_num_data_streams: 2
bottom_partitioning_function: logphys partitioned(grouping, PAPA with 2
PA(s), log=exactly 1 partition, phys=range partitioned 2 ways on
(([209]equiv(TPCD.XMPS.CUSTOMER.C_CUSTKEY) )))
523728-001J
8-23
第 8 章 並列性
8.5
パラレル・プランに影響を与える
オプティマイザによるプランの選択やプランで並列性が使用されるかどうかの決定に影響を与える要因
としては、次のようなものがあります。
□ 関連するカラムに関する更新済み統計情報。クエリに記述されているすべてのカラムの統計情報を更
新する必要がある。また、サブクエリの統計情報も更新する必要があるので注意すること。統計情報
の更新の詳細については、第 3 章「統計情報の更新」を参照。
□ パーティションの数。パーティションの数は、オプティマイザがパラレル・プランを選択するかどう
かに大きな影響を与える。パラレル・プランを選択させるには 2 つ以上のパーティションが必要。オ
プティマイザは、パーティション化スキーマを使用してパーティション化並列性をどのように実行す
るかを認識する。
□ CPU の数。ESP 並列性では、可能な ESP 数はクラスタごとの CPU 数により異なる。パラレル・プラ
ンには 2 つ以上の CPU が必要。
□ コンパイルと実行。クエリを同じクラスタでコンパイルし、実行すること。
□ テーブル・パーティション。クエリがパラレルに実行されるように、テーブル・パーティションを物
理ディスク上に均等に分散させる。
□ 返されるローの複雑さと量。集計の計算など、大量のデータに対して複雑な処理をした後に少数のロー
だけを返すような場合には、オプティマイザはパラレル・プランを選択する。
□ CONTROL QUERY SHAPE による並列性の強制。このステートメントを使用すると、特定のパラレ
ル・プランを強制できる。第 5 章「実行プランの強制」を参照。
□ デフォルト。次の項で説明するように、いくつかのデフォルトはパラレル・プランに影響を与えるこ
とがある。
8.5.1 並列性に影響を与えるデフォルト設定
次のデフォルト設定は並列性に影響を与えます。デフォルト設定、およびシステム定義のデフォルト設
定の変更方法に関する詳細は、『NonStop SQL/MX リファレンス・マニュアル』を参照してください。
□ ATTEMPT_ESP_PARALLELISM
ON に設定すると、オプティマイザは可能であれば最高の並列度を使用しようとする。テーブルが小さ
すぎる場合には、ON に設定されていても、いくつかの演算子では ESP並列性が選択されないことがあ
る。OFF に設定すると、オプティマイザは ESP 並列性を使用するプランを生成しない。SYSTEM ( シ
ステム定義のデフォルト値) を設定すると、オプティマイザは、各演算子ごとに ESP 並列性を使用する
プランを生成しコストを算出すべきかどうかを判断する。オプティマイザが ESP を使用することを選
択した場合、SYSTEM に設定されていれば、並列性のレベルもオプティマイザが決定できる。オプティ
マイザは、各演算子に対して、ロー選択率やメモリ使用率といった演算子の論理的/物理的プロパティ
に基づくさまざまな発見的方法を使用して、パラレル・プランを生成を判断する。
□ ATTEMPT_ASYNCHRONOUS_ACCESS
パーティションの同時アクセス (DAM 並列性) における待ちなしアクセスを有効または無効にする。シ
ステム定義のデフォルト設定は ON。ESP を使用するパラレル実行と比較するとコストが低いので、こ
8-24
523728-001J
第 8 章 並列性
のオプションによって SQL/MX クエリのパフォーマンスが大幅に向上する可能性がある。この設定を
ON にすることを推奨。
□ MAX_ESPS_PER_CPU_PER_OP
1 つの演算子に対して、オプティマイザが各 CPU で起動しようとする ESP の最大数。システム定義の
デフォルト値は 1。1 より大きい値を指定すると、オプティマイザは 1 つの CPU で複数の ESP を使用
す る プ ラ ン を 生 成 す る こ と を 検 討 す る。た と え ば、利 用 可 能 な C P U
が 4
つあって
MAX_ESPS_PER_CPU_PER_OP が 2 に設定されている場合、オプティマイザは 1 つの演算子に 8 つの
ESP を使用するプランを検討する (パラレル実行が ON になっている場合)。この方法は、クエリに対す
る CPU の負荷は軽いが I/O の負荷が重い場合に効果を発揮する。たとえば、I/O を多用するクエリで、
CPU を他の目的に使用することがない場合など。
□ PARALLEL_NUM_ESPS
1 つの演算子が使用できる ESP の最大数 (演算子あたりの CPU が少ない場合)。演算子あたりの ESP の
最大数を、クラスタ内の CPU 数より小さい値に制限する。ただし、数は制限するが、どの CPU を使用
するのかの選択は行わない。システム定義のデフォルト設定はクラスタ内のプロセッサ数。
ユーザがこの属性を設定しないと (SYSTEM に設定される)、オプティマイザが並列度を計算する。オ
プティマイザは、クラスタ内の CPU 数に 1 つの CPU あたりの ESP 数を掛けた数を並列度として選択
する。デフォルトでは 1 つの CPU あたりの ESP 数は 1 のため、オプティマイザはクラスタ内の CPU
数と等しい並列度を選択する。
PARALLEL_NUM_ESPS 属性に値を設定すると、オプティマイザはその値を並列度として選択する。
指定された値がクラスタ内の CPU 数を超えている場合には、クラスタ内の CPU 数を並列度として使用
する。指定可能な値は、符号なしの正の整数か、SYSTEM。
R E M O T E _ E S P _ A L L O C A T I O N 属 性 も 並 列 性 に 影 響 を 与 え ま す。詳 細 は、4 - 1 3 ペ ー ジ の
「REMOTE_ESP_ALLOCATION」を参照してください。
523728-001J
8-25
第 8 章 並列性
8-26
523728-001J
索引
索 引
LEFT_CHILD_SEQ_ NUM 4-5
MODULE_NAME 4-4
OPERATOR 4-5
OPERATOR_COST 4-5
PLAN_ID 4-4
RIGHT_CHILD_ SEQ_NUM 4-5
SEQ_NUM 4-4
STATEMENT_NAME 4-4
TNAME 4-5
TOTAL_COST 4-5
A
ATTEMPT_ASYNCHRONOUS_ACCESS システムデ
フォルト設定 8-25
ATTEMPT_ESP_PARALLELISM システムデフォルト
設定 8-24
C
CALL 演算子 7-3
CAST を使った式
パフォーマンス 1-6
CONTROL QUERY SHAPE ステートメント
exchange 演算子か sort 演算子か任せる 5-18
MDAM OFF 2-10
アクセス・パスの強制 2-8
依存 5-1
オフにする 5-10
有効範囲 5-10
CURSOR_DELETE 演算子 7-5
CURSOR_UPDATE 演算子 7-5
D
EXPLAIN 出力情報
演算子ツリー 4-4
説明 4-2
EXPLAIN 出力における DETAIL_COST
CPU_TIME 4-5
IDLETIME 4-5
IO_TIME 4-5
MSG_TIME 4-5
PROBES 4-5
EXPR 演算子 7-8
DAM
F
プラン・フラグメント 8-15
並列性 5-15
DENSE アルゴリズム、MDAM 2-15
FILE_SCAN 演算子 7-8
DETAILED_STATISTICS デフォルト設定 4-21
Group by
FILE_SCAN_UNIQUE 演算子 7-10
G
DISPLAY_EXPLAIN コマンド 4-8
パラレル・プラン 8-11
H
E
ESP (executor server process)
Halloween 更新問題 2-7
演算子 8-12
関連するコスト 8-5
選択方法 8-12
プラン・フラグメント 8-15
並列性 5-14
ESP_EXCHANGE 演算子 7-6, 8-16
HASH_GROUPBY 演算子 7-11
Exchange ノード 8-3
HYBRID_HASH_SEMI_JOIN 演算子 7-16
EXPLAIN 演算子 7-7
I
EXPLAIN 出力
IMPLICIT EXCHANGE 5-18
カラム 4-4
生成 5-4
並列性トークン 8-16
EXPLAIN 出力カラム
IMPLICIT EXCHANGE_AND_SORT 5-18
CARDINALITY 4-5
DESCRIPTION 4-5
DETAIL_COST 4-5
523728-001J
HASH_PARTIAL_GROUPBY_LEAF 演算子 7-12
HASH_PARTIAL_GROUPBY_ROOT 演算子 7-13
HYBRID_HASH_ANTI_SEMI_JOIN 演算子 7-14
HYBRID_HASH_JOIN 演算子 7-15
IMPLICIT SORT 5-18
INDEX_SCAN_UNIQUE 演算子 7-18
INDEX_SCAN 演算子 7-17
INSERT_VSBB 演算子 7-21
INSERT 演算子 7-20
索引 -1
索引
L
OLT 最適化
LEFT_HYBRID_HASH_JOIN 演算子 7-21
表示 1-8
有効化 1-8
有効なクエリと演算子 1-8
ORDERED_HASH_ANTI_SEMI_JOIN 演算子 7-31
LEFT_MERGE_JOIN 演算子 7-22
LEFT_NESTED_JOIN 演算子 7-23
LEFT_ORDERED_HASH_JOIN 演算子 7-23
LISP フォーマット 5-7
ORDERED_HASH_JOIN 演算子 7-32
ORDERED_HASH_SEMI_JOIN 演算子 7-33
M
MATERIALIZE 演算子 7-24
OR 演算子
最適化 1-10
パフォーマンス向上のためのインデックスの特定
1-10
MAX_ESPS_PER_CPU_PER_OP システムデフォルト
設定 8-25
MDAM (MultiDimensional Access Method)
OR 最適化 1-9
1 つのクエリで複数テーブル 1-10
CONTROL QUERY SHAPE で強制 2-10
DENSE アルゴリズム 2-15
DENSE または SPARSE の強制 2-15
IN リスト 2-13
OR 述語 2-13
SPARSE アルゴリズム 2-15
キー・カラム数の制御 2-15
キー述語 2-13
コスト 2-12
ジョイン 1-10
冗長で矛盾する述語 2-14
説明 2-10
選択しやすくする方法 2-14
ソート順序 2-14
単一サブセット・アクセスの比較 2-10
重複ロー 2-14
範囲述語の介入 2-13
Measure 4-22
OR 述語、MDAM の処理方法 2-13
Measure の構成要素
SHORTCUT_SCALAR_AGGR 演算子 5-11, 7-40
SQLPROC 4-22
SQLSTMT 4-23
MERGE_ANTI_SEMI_JOIN 演算子 7-26
MERGE_JOIN 演算子 7-26
MERGE_SEMI_JOIN 演算子 7-27
MERGE_UNION 演算子 7-28
N
Nested join、複製、ブロードキャストなし 8-9
NESTED_ANTI_SEMI_JOIN 演算子 7-29
NESTED_JOIN 演算子 7-30
NESTED_SEMI_JOIN 演算子 7-31
NonStop Data Access Manager (DAM)
DAM を参照
O
ODBC データソース 4-14
索引 -2
P
PACK 演算子 7-35
PARALLEL_NUM_ESPS システムデフォルト設定 8-25
PARTITION_ACCESS 演算子 7-36
R
ROOT 演算子 7-37
S
SAMPLE 演算子 7-39
SCAN 演算子
パラレル・プラン 8-6
SELECT
パラレル・プラン 8-11
SEQUENCE 演算子 7-39
SET SHOWSHAPE コマンド 5-7
SHORTCUT_GROUPBY 論理演算子 5-11
SHOWSHAPE コマンド 5-7
SORT_GROUPBY 演算子 7-41
SORT_PARTIAL_AGGR_LEAF 演算子 7-42
SORT_PARTIAL_AGGR_ROOT 演算子 7-43
SORT_PARTIAL_GROUPBY_LEAF 演算子 7-43
SORT_PARTIAL_GROUPBY_ROOT 演算子 7-44
SORT_SCALAR_AGGR 演算子 7-44
SORT 演算子 7-40
SPARSE アルゴリズム
MDAM 2-15
SPLIT_TOP 演算子 7-45, 8-16
SQL/MP からの移行、強制プラン 5-12
SQL/MP、強制プランの移行 5-12
SQL コンパイラ
523728-001J
索引
オプティマイザ 1-2
クエリをコンパイルする手順 1-2
コードジェン 1-2
説明 1-1
ノーマライザ 1-2
パーサ 1-2
バインダ 1-2
メタデータと統計情報 1-2
SUBSET_DELETE 演算子 7-46
SUBSET_UPDATE 演算子 7-47
T
TRANSPOSE 演算子 7-48
TUPLE_FLOW 演算子 7-48
TUPLELIST 演算子 7-49
い
インデックス
パフォーマンス向上 1-10
インデックス・オンリ・アクセス
概算コスト 2-4
使用 2-3
説明 2-3
え
エグゼキュータ
キュー 1-15
スケジューラ指向タスク・モデル 1-15
データ・フロー・タスク・モデル 1-15
プランの処理方法 1-15
演算子 7-1
演算子グループ 7-2, 7-3
U
UNIQUE_DELETE 演算子 7-49
UNIQUE_UPDATE 演算子 7-50
UNPACK 演算子 7-52
V
VALUES 演算子 7-53
Visual Query Planner
ODBC への接続 4-14
アクセス 4-14
オンライン・ヘルプ 4-14
ツールバー 4-16
目的 4-14
要件 4-14
要約 4-15
演算子ツリー
コンパイラ 1-2
説明 4-4
テキスト形式に変換 5-7
部分的シェイプ 5-10
演算子並列性 8-2
お
オプティマイザ
検索スペース 1-3
検索メモリ 1-3
最適化の方法 1-3
実行プラン 5-1
実装ルール 1-4
説明 1-2
トップダウン・アプローチ 1-3
分岐と境界プログラミング 1-3
変換ルール 1-4
マルチパス最適化 1-4
あ
アクセス・コスト
MDAM 2-12
インデックス・オンリ・アクセス 2-4
ストレージ・キー・アクセス 2-3
代替インデックス・アクセス 2-5
単一サブセット・アクセス 2-11
テーブル・スキャン 2-6
アクセス・パス
MDAM 2-10
強制 2-8
説明 2-1
予期しない 2-6
アクセス方法
インデックス・オンリ 2-3
キーシーケンス・アクセスの代替 2-5
ストレージキー 2-2
代替インデックス 2-4
523728-001J
き
キー述語、MDAM の処理方法 2-13
キュー 1-15
強制パラレル・プラン
DAM 並列性 5-15
ESP 並列性 5-14
ジョイン 5-16
説明 5-14
強制プラン
CONTROL QUERY SHAPE ステートメントの書
き込み 5-10
MDAM DENSE または SPARSE 2-15
SET SHOWSHAPE を使用してプランを実際に表
示する 5-7
SHOWSHAPE を使用して形式を表示 5-7
索引 -3
索引
SQL/MP からの移行 5-12
Visual Query Planner を使用 5-8
トラブルシューティング 5-11
ビュー 5-11
部分的シェイプ 5-10
強制並列プラン
し
システムのデフォルト設定
および並列性 8-24
実行プラン
クエリのコンパイル 1-1
新しいシェイプを強制 5-1
確認 5-5
コスト要因 4-5
表示 5-4
例 4-5
実装ルール 1-4
クエリの実行プラン、例 4-8, 4-14
重複ロー、MDAM の処理方法 2-14
クエリ・プラン 8-3
述語
タイプ 1 ジョインの強制 5-16
タイプ 2 ジョインの強制 5-17
く
OR 2-13
クエリ・プラン・キャッシング
概要 6-1
キャッシュ可能なクエリ 6-3
キャッシュ不可能なクエリ 6-5
サイズ選択 6-7
説明 6-1
け
検索スペース 1-3
検索メモリ 1-3
こ
更新、Halloween 問題 2-7
コードジェン 1-2
コスト、アクセス
MDAM 2-12
インデックス・オンリ・アクセス 2-4
ストレージ・キー・アクセス 2-3
代替インデックス・アクセス 2-5
単一サブセット・アクセス 2-11
テーブル・スキャン 2-6
コスト、プラン 4-5
OR 演算子 1-10
欠如キー 2-13
冗長で矛盾 2-14
範囲 2-13
ジョイン
代替インデックス・アクセス 2-4
タイプ 1 ジョイン 8-6
内部テーブルへのパラレル・アクセス 8-9
パーティション境界が一致しない場合 8-8
範囲再パーティションによる 8-7
ブロードキャストなしの複製 8-9
ブロードキャストによる複製 8-10
マッチング・パーティション 8-6
論理サブパーティション・アライメント 8-8
論理パーティション・グループ 8-8
冗長な述語
MDAM の処理方法 2-14
す
スケジューラ指向タスク・モデル 1-15
ストレージ・キー・アクセス
概算コスト 2-3
説明 2-2
コンパイラ
SQL コンパイラを参照
そ
さ
最適化
ルール 1-3
最適化の原則 1-3
挿入、パラレル・プラン 8-11
ソート、パラレル・プラン 8-11
た
再パーティション 8-7
代替インデックス・アクセス
サンプリング
概算コスト 2-5
更新問題 2-7
説明 2-4
タイプ 1 ジョイン、強制 5-16
periodic 3-7
クラスタ 3-6
精度 3-6
統計情報の更新 3-6
ランダム・ロー 3-6
索引 -4
タイプ 2 ジョイン
強制 5-17
複製、ブロードキャストなし 8-9
523728-001J
索引
ブロードキャストによる複製 8-10
単一サブセット・アクセス
コスト 2-11
説明 2-11
て
データ・フロー・タスク・モデル 1-15, 8-2
データ並列性 8-2
テーブル・スキャン
概算コスト 2-6
回避 2-6
説明 2-5
テキスト
LISP のような形式 5-7
デフォルトの統計情報 3-2
と
統計情報
DETAILED_STATISTICS 属性 4-21
DISPLAY STATISTICS 4-21
Measure 4-22
更新の結果のテスト 3-8
更新、影響 3-5
サンプリング 3-6
実行時 4-21
デフォルト 3-2
パフォーマンス、効果 3-5
ヒストグラムの更新 3-2, 3-3
複数カラムの統計情報 3-7
統計情報の表示 4-21
独立並列性 8-2
トップダウン・アプローチ 1-3
CONTROL QUERY SHAPE のマイナス影響 5-1,
5-14
MDAM 2-10
Measure データの使用 4-23
nested join アルゴリズム 8-9
OLTP 情報 1-6
OLT 最適化 1-8
OR 最適化 1-10
インデックスの効果 2-3
クエリ・プラン・キャッシング 1-5, 6-1
サンプリング手法 3-6
サンプリングのトレードオフ 3-6
短縮した応答時間 3-5
ハッシュ・ジョイン 8-10
フル・テーブル・スキャン 2-5
ロー対クラスタ・サンプリング 3-6
パラレル
プランの確認 8-12
プランの強制 5-14
パラレル・プラン
EXPLAIN 出力を理解する 8-12
group by 8-11
SCAN 演算子 8-6
SELECT 8-11
影響 8-24
強制 5-14
挿入 8-11
ソート 8-11
プラン・フラグメント 8-15, 8-16
並列性、確認 8-12
ユニオン 8-10
範囲述語
介入、MDAM の処理方法 2-13
トラブルシューティング、強制プラン 5-11
ひ
の
ノーマライザ 1-2
は
パーサ 1-2
パーティション化並列性 8-2
パーティション、並列性に影響を与える 8-24
ヒストグラム
キャッシュに格納 3-4
統計情報 3-3
ビュー、強制プラン 5-11
ふ
複数カラムの統計情報 3-7
パイプライン並列性 8-2
複製
バインダ 1-2
ブロードキャストなし、nested join 8-9
物理演算子 1-3, 1-4, 5-10
ハッシュ・ジョイン、ブロードキャストによる複製 810
パフォーパンス
UPDATE STATISTICS 3-5
パフォーマンス
CAST 1-6
523728-001J
プラン
新しいシェイプを強制 5-1
確認 5-5
コスト要因 4-5
トラブルシューティング 5-11
索引 -5
索引
表示 5-4
例 4-5
プラン強制
手順要旨 5-3
プラン・フラグメント
EXPLAIN 出力 8-15
説明 8-3
認識 8-16
複数インスタンス 8-4
プロセス境界 8-3, 8-18
並列度 8-20
フル・テーブル・スキャン
む
矛盾する述語、MDAM の処理方法 2-14
ゆ
ユニオン
パラレル・プラン 8-10
ろ
ロー、重複 2-14
論理演算子 5-10
論理式 1-3, 1-4
テーブル・スキャンを参照
ブロードキャストによる複製
ハッシュジョイン 8-10
分岐と境界プログラミング 1-3
分断キー
マッチング・パーティション・ジョイン 8-6
へ
並列性
CPU 数と ESP 数の関係 8-24
EXPLAIN 出力 8-12
EXPLAIN 出力におけるトークン 8-16
group by 8-11
SELECT 8-11
影響を与える 8-24
演算子 8-2
オプティマイザによる再パーティション化の回避
方法 8-7
異なるタイプを結合 8-11
スキャン 8-6
挿入 8-11
ソート 8-11
デフォルト設定 8-24
独立 8-2
内部テーブルへのパラレル・アクセス 8-9
パーティション化 8-2
パイプライン 8-2
パラレル・ジョイン 8-7
複数レベル 8-11
プラン・フラグメント 8-15, 8-20
並列度 8-20
マッチング・パーティション・アルゴリズム 8-6
ユニオン 8-10
変換ルール 1-4
ま
マッチング・パーティション・ジョイン 8-6
分断キー 8-6
索引 -6
523728-001J