PLAN_TABLE インスタンスにおけるアクセス・パスの指定

PLAN_TABLE アクセス・パスを作成すると、1 つの特定の許可 ID によって発行される SQL ステートメントに特定のアクセス・パスを施行できます。

始める前に

以下の前提条件が満たされています。

アクセス経路の管理に備えましょう。
PLAN_TABLE 表のインスタンスが、SQL ステートメントを発行した許可 ID で作成されている。
索引は、PLAN_TABLE の以下の列に作成されます。
- QUERYNO
- APPLNAME
- PROGNAME
- バージョン
- COLLID
- OPTHINT
索引を作成するサンプル・ステートメントは、SDSNSAMP ライブラリーのメンバー DSNTESC に組み込まれています。

このタスクについて

PLAN_TABLE アクセス・パスを指定すると、それは特定の指定された SQL 文にのみ適用され、指定されたアクセス・パスを含む PLAN_TABLE インスタンスを所有する認証 ID によって発行されたその文のインスタンスのみに適用されます。Db2 他の認証IDによって発行された同じステートメントのインスタンスに対して、指定されたアクセスパスを使用しない。

また、他のメソッドを使用して、ステートメントを発行した許可 ID に関係なく、ステートメントの複数のインスタンスのアクセス・パス選択に影響を与えることができます。ステートメントレベルでアクセスパスを指定する方法の詳細については、「ステートメントレベルでのアクセスパスの指定」を参照してください。

PLAN_TABLEアクセス・パスを使用して、Db2が既存のアクセス・パスを強制しようとすることを指定することもできますが、静的SQLステートメントの再バインド時にアクセス・パスの変更を防止するための優先される方法は、APREUSEバインド・オプションを指定することです。同様に、動的 SQL ステートメントの準備時にアクセス・パスの変更を防止するための望ましい方法は、プラン管理ポリシーを指定することです。アクセスパスの再利用に関する詳細は、「バインドおよび再バインド時のアクセスパスの再利用と比較」を参照してください。

プロシージャー

PLAN_TABLE インスタンスでアクセス・パスを指定するには、次のようにします。

オプション： SQLステートメントにQUERYNO句を含めます
以下の照会には QUERYNO 文節の例が含まれています。
```
SELECT * FROM T1
  WHERE C1 = 10 AND
        C2 BETWEEN 10 AND 20 AND
        C3 NOT LIKE 'A%'
  QUERYNO 100;
```
このステップは、PLAN_TABLE インスタンスでアクセス・パスを指定するために必要なわけではありません。ただし、各 SQL ステートメントを識別するために照会番号を指定することで、PLAN_TABLE の行と対応する SQL ステートメントの間の関係におけるあいまいさを解消することができます。
例えば、動的アプリケーションのステートメント番号は、アプリケーションでステートメントを準備するステートメントの番号です。 DSNTEP2 などの一部のアプリケーションでは、アプリケーション内の同一ステートメントがそれぞれの動的ステートメントを準備しています。これは、それぞれの動的ステートメントに同一のステートメント番号が付いていることを意味します。

同様に、静的ステートメントが含まれるアプリケーションを変更する場合は、ステートメント番号が変更される恐れがあり、その結果、PLAN_TABLE の行が変更されたアプリケーションと同期しなくなります。 QUERYNO 文節を使用したステートメントは、ステートメント番号には依存していません。 PLAN_TABLE の行とアプリケーションで対応するステートメントの間の関係に影響を与えることなく、これらのステートメントを近辺に移動させることができます。

そのようなあいまいさがあると、Db2が指定されたアクセス・パスを強制的に実行するのを防ぐことが出来ます。
SQL ステートメントの PLAN_TABLE 行の OPTHINT 列に指定されたアクセス・パスの名前を挿入します。
このステップにより、Db2は、アクセス・パスを指定したPLAN_TABLE行を識別することができます。
```
UPDATE PLAN_TABLE
  SET OPTHINT = 'NOHYB'
  WHERE QUERYNO = 200 AND
        APPLNAME = ' ' AND
        PROGNAME = 'DSNTEP2' AND
        VERSION = ' ' AND
        COLLID = 'DSNTEP2';
```
オプション： PLAN_TABLEの行を修正して、 Db2 に別のアクセス経路を試行するよう指示します
また、PLAN_TABLE アクセス・パスは、再バインドまたは準備後に同じアクセス・パスの施行を試みる場合にのみ使用できます。この場合は、このステップを省略できます。ただし、PLAN_TABLE アクセス・パスは、再バインドまたは準備の後に既存のアクセス・パスを施行するための推奨される方法ではないことを覚えておいてください。再バインド時に APREUSE オプションを使用するか、プラン管理ポリシーを代わりに指定してください。
例えば、 Db2 がハイブリッド結合（METHOD = 4 ）を選択したとします。しかし、ソートマージ結合（METHOD = 2 ）の方がパフォーマンスが向上する可能性があることをあなたが知っているとします。以下のステートメントを発行できます。
```
UPDATE PLAN_TABLE
  SET METHOD = 2 
  WHERE QUERYNO = 200 AND
        APPLNAME = ' ' AND
        PROGNAME = 'DSNTEP2' AND
        VERSION = '' AND
        COLLID = 'DSNTEP2' AND
        OPTHINT = 'NOHYB' AND
        METHOD = 4;
```

Db2 に、指定されたアクセス経路の適用を開始するよう指示します。

オプション	説明
動的ステートメントの場合	SET CURRENT OPTIMIZATION HINT = '`hint-name`' ステートメントを発行します。 SET CURRENT OPTIMIZATION HINT ステートメントが静的 SQL ステートメントである場合は、プランまたはパッケージを再バインドしてください。アクセス・パスを使用するステートメントの EXPLAIN ステートメントを発行します。 Db2 ステートメントの計画テーブルに行を追加し、HINT_USED列に `「hint-name」の値`を挿入します。動的ステートメント・キャッシュが有効になっている場合、Db2は、動的ステートメント・キャッシュ内のステートメントに一致するものが見つからない場合にのみヒントを使用しようとします。それ以外の場合、Db2はキャッシュされたプランを使用し、ステートメントを準備したり、指定されたアクセス・パスを考慮したりしません。
静的ステートメントの場合	ステートメントが含まれるプランまたはパッケージを再バインドして、EXPLAIN(YES) オプションと OPTHINT('`hint-name`') オプションを指定します。

オプション

説明

動的ステートメントの場合

SET CURRENT OPTIMIZATION HINT = 'hint-name' ステートメントを発行します。
SET CURRENT OPTIMIZATION HINT ステートメントが静的 SQL ステートメントである場合は、プランまたはパッケージを再バインドしてください。
アクセス・パスを使用するステートメントの EXPLAIN ステートメントを発行します。 Db2 ステートメントの計画テーブルに行を追加し、HINT_USED列に 「hint-name」の値を挿入します。

動的ステートメント・キャッシュが有効になっている場合、Db2は、動的ステートメント・キャッシュ内のステートメントに一致するものが見つからない場合にのみヒントを使用しようとします。それ以外の場合、Db2はキャッシュされたプランを使用し、ステートメントを準備したり、指定されたアクセス・パスを考慮したりしません。

静的ステートメントの場合

ステートメントが含まれるプランまたはパッケージを再バインドして、EXPLAIN(YES) オプションと OPTHINT('hint-name') オプションを指定します。

Db2は、SQLステートメントへのアクセス・パスを指定する行を突き合わせるときに、次のPLAN_TABLE列を使用します。

QUERYNO
APPLNAME
PROGNAME
バージョン
COLLID
OPTHINT

PLAN_TABLE インスタンスでアクセス・パスを指定する場合は、PLAN_TABLE のこれらの列に索引を作成することが最善です。

Db2 は、指定されたすべてのアクセス・パスを使用する場合、EXPLAIN ステートメントの PREPARE、および指定されたアクセス・パスを使用する SQL ステートメントの PREPARE から SQLCODE +394 を戻します。指定されたいずれかのアクセス・パスが無効である場合、または、重複が検出された場合は、Db2はSQLCODE +395を発行します。サブシステムパラメータSUPPRESS_HINT_SQLCODE_DYNの値を設定することで、動的SQL文におけるSQLCODES +394および+395を抑制することができます。

Db2は、アクセス・パスが指定されていることを検出しない場合、別のSQLCODEを戻します。通常、この SQLCODE は 0 です。Db2 は、バインド操作の完了時に、ヒントが完全に適用されたステートメントの数、適用されなかったステートメントの数、部分的に適用されたステートメントの数、見つからなかったステートメントの数を識別するメッセージも返します。

PLAN_TABLEから選択し、 Db2 が指定されたアクセス経路を使用したかどうかを確認します。

例えば、以下のステートメントを発行できます。

SELECT *
  FROM PLAN_TABLE
   WHERE QUERYNO = 200
  ORDER BY TIMESTAMP, QUERYNO, QBLOCKNO, PLANNO, MIXOPSEQ;

以下の表に、PLAN_TABLE データの例を示します。指定されたアクセス・パスが使用された場合、OPTHINT 列に NOHYB 値が入っています。また、HINT_USED列のNOHYB値によって示されるアクセス・パスにDb2が使用されていることを確認することもできます。

表 1. NOHYB アクセス・パスが使用されることを示す PLAN_TABLE
QUERYNO	METHOD	TNAME	OPTHINTS	HINT_USED
200	0	EMP	NOHYB
200	2	EMPPROJACT	NOHYB
200	3		NOHYB
200	0	EMP		NOHYB
200	2	EMPPROJECT		NOHYB
200	3			NOHYB