パラメータ化されたリクエスト - Advanced SQL Engine - Teradata Database

Vantageには、CLIv2データ パーセル内のリクエストに含まれるパラメータ化された値(ユーザーが供給する定数データのUSINGリクエスト修飾子の値など)をピーク処理し、それらの変数を意味解釈ルーチンで解釈する機能があります。この機能により、キャッシュされた汎用計画を常に生成するよりも特定のキャッシュされない計画をリクエストに対して生成するほうがリクエストを処理する上でよいと判断された際に、最適化ルーチンで特定のキャッシュされない計画を生成することができます。

データ パーセル ピーク操作の用語

以下は、パラメータ値ピーク操作サブシステムに特有の用語です。

リクエスト内にパラメータ化されたデータが存在している場合でも、最適化ルーチンが特定のリクエスト計画を生成するとは限りません。最適化ルーチンによって生成されるクエリー計画がパラメータ化された値に依存していない、パラメータ化されたクエリーが複数あります。このような問合わせでは、パラメータ化された値ピーク処理操作の結果として特定の問合わせ計画を生成することによる、付加的なパフォーマンスの向上は得られません。さらに、リクエストの実行時間が短い場合、計画をキャッシュしないことによるパフォーマンス低下の影響が大きくなることがあります。

例として、USINGリクエスト修飾子を指定する次の問合わせを検討します。そのUSINGリクエスト修飾子の単一の変数xは、WHERE句でパラメータ化された述部条件 :xを指定する際にも使用されます。

USING (x INTEGER)
SELECT *
FROM table_1
WHERE column_1 = :x;

table_1.column_1で定義されるUPI (Unique Primary Index: 固有プライマリ インデックス)がある場合、最適化ルーチンによって選択されるアクセス パスは、xの値に依存しません。これは、値に関係なく、その値が有効なプライマリ インデックスを指定し、プライマリ インデックスのアクセス パスが最良のアクセス パスであると仮定されているためです。

パラメータ値ピーク処理サブシステムについては、次の定義が適用されます。

パラメータ化された値ピーク操作はパラメータ化されたPKリクエストの処理方法に影響しません。このため、この場合、最適化ルーチンは特定計画を生成しません。

次のテーブルは、さまざまなタイプのパラメータ化されたリクエストが、パラメータ化に依存するかどうかを示しています。

CREATE TABLE emp (
  emp_id INTEGER,
  dept_id INTEGER)
UNIQUE PRIMARY INDEX (emp_id);

USING (x INTEGER)
SELECT *
FROM emp
WHERE dept_id = 10
;SELECT *
FROM emp
WHERE emp_id = :x
AND   dept_id = 12;

パラメータ化された値ピーク操作

ピーク処理は、他の方法よりもリクエスト処理の早い段階で、問合わせに特定のデータ値を構文解析ツリーに挿入することによって、特定のカテゴリの問合わせを簡単に最適化することができます。キャッシュにあるクエリー計画を再使用すると構文解析と最適化の時間が短縮されるため、汎用計画は常にキャッシュされます。ただし、キャッシュにある汎用クエリー計画を再使用することは、特定リクエストに合わせて特定計画を生成する定数リテラルを提供するクエリーを実行するための常に最適な手法ではありません。

システムは、パラメータ化に依存するリクエストについての特定計画をキャッシュしません。これは、異なるセットのパラメータ化定数値または組み込み関数供給定数値を持つ他の同等のクエリーには、これらの計画を再使用できないためです。ただし、システムは、特定計画について生成される他の情報をキャッシュします。この情報には、そのSQLテキスト ハッシュ、ホスト文字セット、実行の見積もりコスト、構文解析時間、および実行時間が含まれます。

システムがリクエストの計画をキャッシュすべきでないと判断した場合は、そのデータを未知の値があるパラメータとして扱う代わりに、パラメータ化されたリクエストとDATE、CURRENT_DATE、TEMPORAL_DATE、CURRENT_TIMESTAMP、USER、および場合によってはTEMPORAL_TIMESTAMP組み込み関数値を使用して、リクエストを最適化することができます。つまり、パラメータ化された値ピーク操作により、パラメータ化されたリクエストと日付関連の組み込み関数、またはそれら両方からのリテラル データ値を使用して、最適化ルーチンが、汎用計画を生成して将来の再使用のためにキャッシュするのではなく、その特定のリクエストに関する最適かつキャッシュされない計画を生成することを確実にします。

最適化ルーチンによって生成される特定計画は最適な計画であり、その実行時パフォーマンスは、同等の汎用計画の実行時間よりも大幅に短縮されます。 ただし、特定計画とその同等の汎用計画の実行時コストにあまり差がない場合があります。 この場合、構文解析コストが高い場合は特に影響が大きくなります。 これらの問題を防ぐには、システムは構文解析と実行時間においてのこのようなリクエストをすべて監視し、リクエスト キャッシュ内に情報を保持します。 システムでは、この情報を使用して、リクエストに対する特定計画または汎用計画の生成の間で決定します。 このプロセスの詳細については、リクエスト キャッシュ ロジックを参照してください。

パラメータ化された値のピーク操作の有効化と無効化

デフォルトでは、パラメータ化された値ピーク操作が有効です。この機能を無効にするには、DBS制御ユーティリティを使用してDisablePeekUsingフィールドの値を変更します。 DBS制御の詳細については、<Teradata Vantage™ - データベース ユーティリティ、B035-1102>を参照してください。

パラメータ化された値ピーク操作についてのさまざまな検討事項

リクエスト キャッシュ ロジック

リクエスト キャッシュは正常に構文解析されたSQL DMLリクエストの計画を保存します。これらは、同じリクエストが再び実行依頼されるときに再利用できます。リクエスト キャッシュにはSQLリクエストのテキストとそのプラスチック ステップが含まれています。プラスチック ステップはリクエスト計画または単に計画と呼ばれます。

• パラメータ化された値ピーク操作が有効な場合、次のテーブルに示すように、リクエストがキャッシュされる場合とされない場合があります。

それ以外の場合は、データベースがリクエストを再度構文解析して、それについて特定計画を生成します。

その他のすべての場合、最適化ルーチンはキャッシュが除去されるまですべてのリクエストについて特定計画を生成します。これには汎用計画の実行が失敗する場合、例えば実行中に異常終了したり致命的なエラーを返す場合が含まれます。

システムで対象のリクエストに関してその後の実行依頼すべてについて特定計画を生成する場合は、パフォーマンスの向上が期待できます。システムで対象のリクエストに関してその後の実行依頼すべてについてキャッシュに入っている計画を使用する場合は、パフォーマンスの向上が期待できます。

MONITOR SESSIONリクエストを実行依頼して、セッションでのリクエスト キャッシュのヒットの数を確認できます。この情報を使用して、汎用計画がキャッシュおよび使用されているかどうかを確認できます。

特定計画は、そのパラメータ化された値がリテラルの代用となっているため、一般に同等の汎用計画よりも適しています。ただし、特定計画のコストが、同等の汎用計画のコストと同じであるリクエストが一部存在します。特定計画を生成するために、パラメータ化された値を置き換えるロジックでは、見積もられている特定計画の時間と汎用計画の時間が同じである問合わせを区別することはできません。

次の2つのリクエストのリクエスト計画は同等であり、パラメータ化された値をピーク処理しても、これらのリクエストに最適な計画を生成することはできません。ただし、次のような結合インデックスがクエリーについてのターゲット基本テーブルで定義される場合、以前のSELECTの例などのリクエストは、パラメータ化された値ピーク操作によるメリットがあります。

例えば、次のテーブル定義があるとします。

CREATE SET TABLE MYDB.t2, NO FALLBACK,NO BEFORE JOURNAL,
  NO AFTER JOURNAL,CHECKSUM = DEFAULT (
  i INTEGER,
  j INTEGER,
  k INTEGER,
  l INTEGER,
  c CHARACTER(400) CHARACTER SET LATIN NOT CASESPECIFIC
                   DEFAULT 'a')
PRIMARY INDEX (i)
INDEX (j);

テーブルに示されている統計は、NUSI (非固有セカンダリ インデックス)列jおよびNUPI (非固有プライマリ インデックス)列iの固有の値の数を示しています。

Date     Time     Unique Values      Column Names
-------- -------- ------------------ --------------------------
06/02/17 12:51:22              1,537 j
06/02/17 12:56:10                 60 k

関連するステップを示しながら、テーブルt2に対する次のクエリーについて考えてみます。

EXPLAIN USING (a INTEGER) SELECT *
                          FROM t2
                          WHERE j = 58
                          AND   k = 100000+i;

...
3) We do an all-AMPs RETRIEVE step from MYDB.t2 by way of an all-rows
   scan with a condition of ("(MYDB.t2.k = (100000 + MYDB.t2.i )) AND
   (MYDB.t2.j = 58)") into Spool 1 (group_amps), which is built
   locally on the AMPs. The size of Spool 1 is estimated with high
   confidence to be 10 rows. The estimated time for this step is
   0.17 seconds.
...

次に、関連するステップを示しながら、テーブルt2に対する次のクエリーについても考えてみます。

EXPLAIN USING (a INTEGER) SELECT *
                          FROM t2
                          WHERE j = 58
                          AND   k =:a + i;

...
3) We do an all-AMPs RETRIEVE step from MYDB.t2 by way of an all-rows
   scan with a condition of ("(MYDB.t2.k = (:a + MYDB.t2.i )) AND
   (MYDB.t2.j = 58)") into Spool 1 (group_amps), which is built
   locally on the AMPs. The size of Spool 1 is estimated with high
   confidence to be 10 rows. The estimated time for this step is
   0.17 seconds.
...

テーブルt3を、テーブルt2のデータを含むコピーとして作成し、次の結合インデックス定義について考えてみます。

CREATE JOIN INDEX j1 AS
  SELECT *
  FROM t3
  WHERE j > 58
  AND k > i+3;

次のクエリーについて考えてみます。ここでは、a1USING値は4であると仮定します。

EXPLAIN USING (a1 INTEGER)
        SELECT *
        FROM t3
        WHERE j = 80
        AND   k = i+:a1;

値の4がステップ3のテキストに明示的に挿入されていることを確認できます。該当箇所は太字で強調表示されています。

...
3) We do an all-AMPs RETRIEVE step from MYDB.J1 by way of an 
   all-rows scan with a condition of 
   ("(MYDB.J1.k = (MYDB.J1.i +  4  )) AND
   (MYDB.J1.j = 80)") into Spool 1 (group_amps), which is built
   locally on the AMPs. The size of Spool 1 is estimated with no
   confidence to be 126 rows. The estimated time for this step is
   0.14 seconds.
...