16.20 - 分類基準 - Teradata Workload Management

Teradata Vantage™ ワークロード管理 ユーザー ガイド

prodname
Teradata Vantage NewSQL Engine
Teradata Workload Management
vrm_release
16.20
category
ユーザー ガイド
管理
featnum
B035-1197-162K-JPN
ワークロード、フィルタ、スロットル ルールで使用される共通の分類基準セットがあります。
分類基準 説明
リクエスト元 リクエスト元は次のいずれかより取得されます。
  • ユーザー名
  • アカウント名(アカウント文字列から最初の4文字を除外)
  • アカウント文字列
  • プロファイル
  • アプリケーション
  • クライアントIPアドレス
  • クライアント ログオンID
TASMルールに同じリクエスト元タイプの複数の基準(複数のユーザーや複数のアカウントなど)が含まれている場合、リクエストがルールを満たすためには、ルールで定義した1つのタイプのみが、現在のリクエストの属性と一致する必要があります。ルールにさまざまなリクエスト元タイプの基準が含まれている場合、リクエストがルールを満たすためには、現在のリクエストの属性がルールで定義されている各タイプの1つと一致しなければなりません。
ユーザーとプロファイルが定義されている場合、プロファイルはユーザーの集合であるため、ルールに対するユーザーとプロファイルの基準をANDまたはORから選択できます。
リクエスト先 リクエストが動作するデータベース オブジェクトとそのオブジェクトに適用されるステップのタイプ
  • データベース
  • テーブル(揮発テーブルを除く)
  • ビュー
  • マクロ
  • ストアド プロシージャ
  • ユーザー定義関数(この選択にはテーブル演算子が含まれる)
  • ユーザー定義メソッド
  • QueryGridサーバー
    • 構文がアクセスするHadoopサーバーなどの外部サーバー名。例: SELECT * FROM Table1@Hadoopserver1;
    • サーバー オブジェクトは参照先の外部テーブル(上記の例ではTable1)から抽出されます。
  • ターゲット基準を選択した後、必要に応じて“テーブルXYZに対して制約のないプロダクト ジョイン”など、より具体的な基準を選択できます。次のリクエスト先に対するより詳細な基準の追加を参照してください。
ストアド プロシージャ リクエストを任意のルールに適用するには、ルールにストアド プロシージャの包含基準が必要です。ルールにストアド プロシージャの包含基準がない場合、ストアド プロシージャはそのルールを満たしません。
分類目的ですべてのターゲット オブジェクトは同じ種類とであると見なされ、論理的ORで結合されます(固有のDBSオブジェクト タイプとして扱われるQueryGridサーバーを除く)。
クエリー特性 処理の詳細:
  • 文のタイプ(DDL、DML、SELECT、COLLECT STATISTICSなど)
  • 複文リクエストについては、複文リクエストを参照してください。
  • AMP制限(単一AMPまたは少数AMPリクエストのみまたは全AMPリクエストを含む)
  • ステップ予測行数
  • 最終予測行数
  • 予想処理時間
  • 予測ステップ処理時間
  • 推定メモリ使用量(推定メモリ使用量を参照)
  • フル テーブル スキャン(この基準はビューで使用できません)
    指定したターゲット オブジェクトのより具体的な二次基準として、代わりにフル テーブル スキャンを使用することをお勧めします。次のリクエスト先に対するより詳細な基準の追加を参照してください。
  • 結合タイプ(すべてまたは結合なし、すべてまたはプロダクト ジョインなし、すべてまたは制約のないプロダクト ジョインなし)
    指定したターゲット オブジェクトのより具体的な基準として、代わりに結合タイプを使用することをお勧めします。次のリクエスト先に対するより詳細な基準の追加を参照してください。
  • 増分計画および実行(IPE)属性(増分計画および実行を参照)
ユーティリティ基準 どのユーティリティがリクエストを発行するか。この基準はシステム スロットルには使用できません。
クエリー バンド 元のアプリケーションにより、リクエストにクエリー バンド名/値のペアが割り当てられる場合があります。クエリー バンドを使用すると、共通のログオンから取得されるリクエストを異なるワークロードに分類できます。
複数の分類基準を指定すると、TDWMは指定したすべての基準をAND条件として扱います。この例外として、同じ種類のDBSオブジェクトや同じ名前のクエリー バンドがあります。

リクエスト先に対するより詳細な基準の追加

ターゲット分類基準を作成した後、オプションで、Viewpointワークロード管理で以下を行なうことにより、ほとんどのデータベースについてより具体的な分類基準を選択できます。
  • ターゲット基準の選択または編集。ターゲット基準の編集ダイアログ ボックスが表示されます。
  • 選択済み:領域にある鉛筆アイコンの選択。基準の編集ダイアログ ボックスが表示され、より詳細な分類基準を追加できます。
具体的な分類基準を追加すると、ルールを満たすリクエストの特性を正確に特定することができます。例えば、リクエストが指定したテーブルで動作し、そのテーブルでプロダクト ジョインを必要とする場合にリクエストがルールを満たすように指定できます。具体的な分類基準を追加することで、目的のルールがTDWMで確実に適用されるようになります。次のリクエストについて考えてみます。
  • 特定のステップでは、小さなテーブルで結合が必要になります。
  • 別のステップでは、結合はありませんが、大きなテーブルで多数の行が生成されます。
この状況で、次の項目に分類基準を指定します。
  • 大きなテーブル
  • すべての結合
  • ステップ行数

大きなテーブルから多くのステップ行が返されて結合された場合にTASMで検出するには、直前のリクエストがこのルールを満たさないようにする必要がありますが、誤検出である可能性もあります。必要な機能を取得する唯一の方法は、大きなテーブルのより具体的な基準としてすべての結合予測ステップ行数を指定することです。つまり、大きなテーブルで動作するリクエストのいずれかのステップで、結合とステップ行数の両方が発生する必要があることを意味します。

次のより具体的な基準は、リクエスト ターゲットであるほとんどのDBSオブジェクトに適用できます。
  • フル テーブル スキャン(含めるまたは除外)
  • 結合タイプ(すべてまたは結合なし、すべてまたはプロダクト ジョインなし、すべてまたは制約のないプロダクト ジョインなし)
  • 予測ステップ行数(指定した番号より上または下)
  • 予測ステップ処理時間(指定した番号より上または下)
UDFおよびUDMに対してより詳細な分類基準を作成することはできません。
次のより具体的な分類基準をテーブルに指定できます。
  • クエリーの実行中にアクセスされるテーブル ブロックの推定パーセント(指定した比率より大きいまたは等しい)。これはリクエストがアクセスすることが予想されるテーブルの割合です。
  • 次のタイプの文のみ:(DML、DDL、Select)

次の図は、ターゲット基準の編集画面の例です。具体的な分類基準を在庫テーブルに追加するには、lumber.inventoryの横にある選択済み:領域で鉛筆アイコンを選択します。