105 ハッシュ表サイズの指定で一括ハッシュジョイン処理（内表から作成したハッシュ表を、すべて作業

表バッファ領域に展開しハッシュジョインする）か、バケット分割ハッシュジョイン処理（内表、外表をバケットに分割し、内表の一部を作業表用バッファ領域に展開し、残りを作業表用ファイルに退避する）かが決まり、性能も大きく異なります。

一括ハッシュジョインにするためには、ハッシュ表サイズを、内表の条件評価後のヒットデータをすべて載せるために十分な大きさにします。

ハッシュ表に内表データをすべて載せるには、以下のシステム定義、クライアント環境変数のオペ

ランドを変更します。

① システム定義の

pd_hash_table_size

またはクライアント環境変数の

PDHASHTBLSIZE

を大きくする。

② システム定義のpd_work_buff_sizeまたはpd_work_buff_expand_limitを大きくする。

（注）一括ハッシュジョインかバケット分割ハッシュジョインかどうか、および一括ハッシュジョインするために必要なハッシュ表サイズは、

UAP

に関する統計情報または

UAP

統計レポート機能で確認できます。

内表の条件評価後のヒットデータが、ハッシュ表に載りやすくするために、条件評価後のヒットデータの少ない表を内表とします。

外表と内表を入れ替えは、結合表構文

(INNER JOIN)

を指定することにより行います。

ハッシュジョインを一括ハッシュジョインにする場合

付録Ｃ-２グループ分け高速化処理

SQL

最適化オプションの指定を省略した場合、

"RAPID_GROUPING"

（グループ分け高速化処理）は省略値であるため、GROUP BYを指定したSQLに対して、ハッシュ表を使用したグループ分け高速化処理が適用されます。

ハッシュ表のサイズは、クライアント環境定義

PDAGGR

（省略値は

1024

）に基づいて決定されます。ハッシュ表の領域不足を起こさないためには、クライアント環境定義

PDAGGR

にグループ化での最大グループ数を指定します。ただし、メモリの使用量との

トレードオフであるため、実メモリの空きサイズより適切な値を検討してください。

グループ分け高速化処理は、グループ化前の行数に対して、グループ数が十分小さい場合に大きな効果を発揮します。

Point

グループ分け高速化処理に対しては、PDAGGRをチューニングする

付録Ｃ-３無排他条件判定の指定（１）

107

インデクスが適切に定義されていないため、効率よくインデクスを利用した検索できない場合や、テーブルスキャンになる場合、検索する行に排他が一時的にかかるため、条件に該当しないものにも排他がかかってしまいます。このようなとき、無排他条件判定で探索条件を判定して満たした行にだけ排他を掛けます。

無排他条件判定は、検索処理時には排他を掛けないで、探索条件を判定して満たした

行にだけ排他を掛けます。探索条件を満たさない行、またはキー値に対して排他を掛けないため、通常の検索と比べて、検索時間が短縮でき、同時実行性を向上させます。

Point

厳密な条件判定が要求されない場合は、無排他条件判定の適用を検討する

図Ｃ.３-１通常の検索処理と排他の例次に検索する行の有無の判定

検索する行に排他を掛ける

探索条件の判定

条件に該当しない

条件に該当する

そのままの状態

排他を解除する

付録Ｃ-３ -１無排他条件判定の指定（２）

無排他条件判定を指定する場合は、余分な範囲を検索しないように、検索するキーは探索範囲絞

り込めるようにインデクスのチューニングを行っておきます。

インデクスのキーによって、探索範囲をある程度絞り込んだ状態から、条件を切り出して検索した

場合、条件を満たすものだけに排他を掛けます。このため、探索範囲の件数に比べて、条件を満たす件数が少ないと、通常の検索処理に比べて（条件を満たす件数／探索範囲の件数）の割合で排他処理を削減できます。

無排他条件判定は、クライアント環境定義の

PDLOCKSKIP

で

YES

を指定します。

排他を掛けないで条件判定をするため、

COMMIT

していないデータを検索して条件判定するおそれがあります。例えば、更新トランザクションと同時に条件判定するとき、条件判定での検索結果と、

更新トランザクションの処理結果との間に差異(ROLLBACKによる読み飛ばし)が発生することがあるので注意が必要です。

図Ｃ.３-２無排他条件判定を使用した検索処理の排他の例次に検索する行の有無の判定

探索条件の判定

条件に該当しない

条件に該当する

検索する行に排他を掛ける

そのままの状態

付録Ｄ. チューニングに関する記述

109 付録Ｄ-１インデクスを有効に使用するための考慮

以下にインデクスを有効に使用するために考慮する点について示します。

A)

大量データのランダム参照とI/Oの増加

大量データをアクセスすると、ランダムにデータを参照したり、アクセスする表の全データページ数を大きく超える

I/O

が発生したりする場合がある。

I/O

を削減するために、絞り込める列にインデクスを定義する。またインデクスを定義した列に絞り込みできるようにすること。

B)

更新列のインデクスメンテナンスによる更新オーバヘッドの増加インデクス定義時、更新の多い列に対する考慮すること。

C)

重複の多いキー値は、インデクスメンテナンスオーバヘッド大

ナル値の重複が多い場合は、インデクス定義でナル値の除外を指定すること。

D)

絞り込める条件を指定している検索においてテーブルスキャン

絞り込める条件の列にインデクスを定義することによって、表のデータのアクセス量を削減し、検索性能を改善できる。（表の行数が少なく、現時点で性能が悪くなくても、

将来、行数が増加する場合や、本番環境で行数が多いという場合に、インデクスを利用すると性能が安定する。）

Point

インデクス定義時は、メリット／デメリットを考慮する

付録Ｄ-２集合関数 MAX/MIN でのインデクス利用（１）

111

集合関数

MAX

、

MIN

は、引数の列にインデクスの構成列を指定します。探索条件がない場合は、MAX、 MINの引数に、第1構成列を指定します。また、探索条件がある場合は、条件を満たすインデクス構成列を指定することで、インデクスを利用して最小値・最大値を求める性能が向上します。

Point

集合関数MAX、 MINの引数にする列は、インデクスを定義する

探索条件がある場合、次の条件を満たすインデクスが利用される。



=条件列(またはIS NULL条件列)を、第１～第n構成列として連続して含む n≧1



MAX、 MINの引数の列に、第n+1構成列に含む



その他の条件列を第n+2構成列以降に含む

SQL文中にC1～Cmまで使用する。

m：定義したインデクスの最大構成列数

SELECT MAX(Cn+1 ), MIN(Cn+1 ) FROM T1

WHERE C1=10 AND …AND Cn=20 AND Cn+2 <30 AND Cm >40

INDEX ON T1(C1, ･･･ , Cn, Cn+1, Cn+2, ･･･, Cm)

図Ｄ.２-１集合関数MIN／MAXでのインデクスの利用