17.00 - 17.05 - キュー テーブルのパフォーマンスに関する事項 - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQLデータ定義言語 詳細トピック

Product
Advanced SQL Engine
Teradata Database
Release Number
17.00
17.05
Release Date
2020年6月
Content Type
プログラミング リファレンス
Publication ID
B035-1184-170K-JPN
Language
日本語 (日本)
以下のリストは、キュー テーブルのパフォーマンス関連事項に適用されます。
  • キュー テーブルの一般的な目的は、いくつかのアプリケーションがデータベースの外部で生じる非同期タスクとのインターフェースを提供する機能を実現することです。

    キュー テーブルで想定されている動作は、キュー テーブルの行の消費側がその生成側とほぼ同じ速度で作業することです。その結果、行がテーブルに挿入されると、すぐにその行が消費されます。

    キュー テーブルに何百万もの行を入れた後に行を消費するというアプリケーションには、非キュー テーブルの使用に比べてパフォーマンス上のメリットがないので、この機能を使用するための優れた候補とはなりません。

    データベース内の非同期イベントも、キュー テーブルを使用できます。例えば、品目の数量が特定のしきい値よりも小さくなったかどうかを調べるトリガーを在庫テーブルに定義したとします。そのしきい値に到達すると、トリガーが起動してキュー テーブルに行を挿入します。その後、キュー テーブルは少量品目を再配列するアプリケーションによって処理されます。

  • CONSUMEモードのSELECT操作のパフォーマンスは、USIを使用して非キュー テーブルから単一の行を選択する場合とほぼ同じです。

    このパフォーマンスは、プライマリ インデックスを使用して非キュー テーブルから単一の行を選択する場合よりも低くなります。

  • 他のデータベース リソースとの競合を避けるために、SELECT AND CONSUME TOP 1文をトランザクション内のできるだけ早い位置に指定してください。これにより、他のリクエストによって必要とされることのあるリソースをロックしたままでSELECT AND CONSUME TOP 1文が遅延状態に入る可能性が最小になります。
  • SELECT AND CONSUME文を発行するときは、以下のプログラミング手法を避けてください。
    • 明示的なトランザクション内で、いずれのデータベース オブジェクトに対する多数のロックを使用して維持するSELECT AND CONSUME文をコーディングすること。
    • トランザクション内で多数のSELECT AND CONSUME文をコーディングすること。SELECT AND CONSUME文と同じキュー テーブルでDELETE操作およびUPDATE操作も行なう場合には特に避けてください。

      システムがキュー テーブルでDELETE、MERGE、またはUPDATE操作を実行するたびに、そのテーブルのFIFOキャッシュは破壊されます。そのテーブルで次に実行されるINSERTまたはSELECT AND CONSUME文により、テーブルのフル テーブル スキャンが開始されてFIFOキャッシュが再構築されます。これはパフォーマンスに影響を与えます。

  • 単一のPEにあるキュー テーブルの行数がキュー テーブル キャッシュのサイズ(テーブルあたり約2,000行項目またはPEあたり20,000行項目。厳密な制限は1MBの項目)を頻繁に超過すると、システムはキャッシュをリフレッシュするためにテーブルの全テーブル スキャンを頻繁に実行する必要が生じます。そのような状態により、ロックに由来するトランザクション アボートおよびキュー テーブル キャッシュのオーバーフローのエラーがリクエスト元に返される可能性も大きくなります。
  • キュー テーブルへのINSERT操作は、システムがCPUバウンドでなければ、応答時間に影響を与えません。
  • キュー テーブルへのINSERT操作は、影響を受けるPE上にあるFIFOキャッシュの更新を強制するので、非キュー テーブルへの挿入よりも負荷が大きくなります。
  • キュー テーブルでのDELETE、MERGE、またはUPDATE操作は、パフォーマンスを低下させるため、例外的な状況に限定してください。重要な要素はそのような操作をコーディングする数ではなく、そのような操作が実行される頻度です。たとえば、ほとんど発生しない例外的な状況の場合にだけ多数のDELETE、MERGE、またはUPDATE操作が実行されるアプリケーションを実行する場合には、この指針を無視できます。

    それ以外の場合には、結果としてパフォーマンスが低下する可能性があるために、DELETE、MERGE、およびUPDATEは控えめに、そして頻繁に実行しない操作に限定してコーディングしてください。

    クエリー テーブルに対するUPDATE、MERGE、およびDELETE操作は、非キュー テーブルに対して実行する同じ操作よりも負荷が大きくなります。それぞれの操作のたびに、影響を受けるPE上にFIFOキャッシュを再構築するためにフル テーブル スキャンが強制実行されるためです。

  • Teradata DatabaseはTeradata Dynamic Workload Managerソフトウェアを使用して、キュー テーブルに対するすべての延期したリクエスト(遅延状態のトランザクション)を管理します。Teradata Dynamic Workload Managerクライアント アプリケーション ソフトウェアを、遅延したCONSUMEモードのリクエストをシステムが管理できるように使用可能に設定する必要はありません。

    そのため、キュー テーブルに対して多数の延期したリクエストがあると、遅延したCONSUMEモードのクエリーだけではなくすべてクエリーを最適に管理するTeradata Dynamic Workload Managerソフトウェアに悪影響があるので、この2つの機能の使用方法を最適化する必要があります。

  • 各PEにあるキュー テーブルのFIFOキャッシュは、最大100のキュー テーブルをサポートします。

    キャッシュ内のアクティブなキュー テーブルの数が100を超えると、システムはキャッシュ内のすべてのテーブルに対してテーブル全体のスキャンを実行し、以下のアクションの1つを実行してキャッシュの除去を試行します。除去を開始するにあたり、まずリストされた最初の方法でキャッシュの除去を試行してから、その最初の方法が適用不可または効果なしの場合に2番目の方法に進みます。

    破損したキュー テーブルをスワップ アウトする。たとえば、キュー テーブルに対して削除操作が実行された場合、これはFIFOキャッシュから除去する候補となります。

    アクティブでないキュー テーブルをFIFOキャッシュから除去する。

    詳細は、キュー テーブル キャッシュを参照してください。

  • 各PEにあるキュー テーブルのFIFOキャッシュは、約20,000のキュー テーブルの行項目をサポートします。

    FIFOキュー テーブル キャッシュにある行項目の数が約20,000行項目の限度を超過すると、システムは最長のキューから最新の項目を除去して空きを作ります。

    システム決定のデフォルトQITS値(キュー テーブルの行の配列を参照)の代わりにユーザー選択のQITS値を使用して行を挿入することによりキュー項目の順序を制御できるため、フラッシュされる項目は実際には最も新しくキューに追加された項目ではないことがあります。

    詳細については、<キュー テーブル キャッシュ>を参照してください。

  • 同じPE FIFOキャッシュにハッシュするキュー テーブルは、行項目の同じプールを共有します。
  • PEあたりのアクティブなキュー テーブルの理想的な数は1です。

    最適な方法で複数のPEにキュー テーブルを分散するには、そのすべてを同時に作成することを検討してください。

  • 行をキュー テーブルに挿入するための反復リクエスト処理が使用可能なクライアント アプリケーションを使用する場合、SQLリクエストを入れて送信するUSINGデータ バッファ内に格納するレコード数を少なくするようにしてください。

    たとえば、BTEQ .IMPORTコマンドを使用して行をキュー テーブルに挿入する場合、BTEQ .SET PACKコマンドを使用して、トランザクションごとのSQL操作の格納濃度を5未満にします。<Basic Teradata®Queryリファレンス、B035-2414>を参照してください。これにより、デッドロックおよびそれによる再試行可能エラーの数が最小になり、最適なパフォーマンスが保証されます。.SET PACKコマンド引数を1より大きい値に設定すると、反復リクエスト処理が可能になります。これにより、DML USING句で複数の制約が生じます。これらの制約については、<Teradata Vantage™ - SQLデータ操作言語、B035-1146>を参照してください。

    トランザクションあたりのSQL操作の数を少なく保つことにより、.IMPORTコマンドで実行される挿入操作の際に、テーブルに対する行ハッシュ レベルのWRITEロック数が最少になります。キュー テーブル キャッシュを参照してください。

    キュー テーブルに行を挿入する際に、そのテーブルに対して更新または削除操作を実行しない場合、キュー テーブル キャッシュが最後にリセットされてからそのテーブルに対する消費または挿入が行なわれたことがあれば、格納濃度は問題とはなりません。