ALTER WORKLOAD GROUP (Transact-SQL)

構文

ALTER WORKLOAD GROUP { group_name | "default" }
[ WITH
    ([ IMPORTANCE = { LOW | MEDIUM | HIGH } ]
           [ [ , ] REQUEST_MAX_MEMORY_GRANT_PERCENT = value ]
           [ [ , ] REQUEST_MAX_CPU_TIME_SEC = value ]
           [ [ , ] REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value ]
           [ [ , ] MAX_DOP = value ]
           [ [ , ] GROUP_MAX_REQUESTS = value ] )
 ]
[ USING { pool_name | "default" } ]
[ ; ]

引数

• group_name | "default"
  既存のユーザー定義のワークロード グループの名前か、リソース ガバナーの既定のワークロード グループを指定します。

  注
  SQL Server のインストール時に、リソース ガバナーにより "既定の" グループと内部のグループが作成されます。

  オプションの "default" を ALTER WORKLOAD GROUP で使用する場合は、システム予約語の DEFAULT と競合しないように引用符 ("") または角かっこ ([]) で囲む必要があります。詳細については、「区切られた識別子 (データベース エンジン)」を参照してください。

  注
  定義済みのワークロード グループおよびリソース プールはすべて、"default" などの小文字の名前を使用しています。大文字と小文字を区別する照合順序を使用するサーバーでは、これを考慮する必要があります。SQL_Latin1_General_CP1_CI_AS など、大文字と小文字を区別しない照合順序を使用するサーバーでは、"default" と "Default" が同じものと見なされます。

• IMPORTANCE = { LOW | MEDIUM | HIGH }
  ワークロード グループでの要求の相対的な重要度を指定します。次のいずれかの値を指定します。

  • LOW

  • MEDIUM (既定)

  • HIGH

  注
  内部的には、各重要度の設定は計算に使用される数値として格納されます。

  IMPORTANCE は、リソース プールに対してローカルです。同じリソース プール内の異なる重要度のワークロード グループは互いに影響しますが、別のリソース プールのワークロード グループには影響しません。

• REQUEST_MAX_MEMORY_GRANT_PERCENT = value
  1 つの要求にプールから割り当てられる最大メモリ量を指定します。このパーセンテージは、MAX_MEMORY_PERCENT で指定したリソース プールのサイズが基準になります。

  注
  指定した量だけがクエリ実行許可メモリに割り当てられます。

  value には、0 または正の整数を指定する必要があります。value の許容範囲は 0 ～ 100 です。value の既定の設定は 25 です。

  次の点に注意してください。

  • value を 0 に設定すると、ユーザー定義のワークロード グループでは SORT と HASH JOIN 操作を含むクエリが実行されなくなります。

  • 同時に他のクエリが実行されているとサーバーが空きメモリを十分に確保できない可能性があるため、value を 70 より大きな値に設定することはお勧めしません。空きメモリを十分に確保できないと、クエリの時間切れエラー 8645 が発生します。

  注
  クエリのメモリ要求がこのパラメーターによって指定されている制限を超えると、サーバーは次のように対応します。 ユーザー定義のワークロード グループでは、サーバーはクエリの並列処理の次数を下げます。これはメモリ要求が制限より低くなるか、並列処理の次数が 1 になるまで続きます。それでもクエリのメモリ要求が制限を超える場合は、エラー 8657 が発生します。 内部および既定のワークロード グループでは、そのクエリに必要なメモリの確保がサーバーによって許可されます。 サーバーに十分な物理メモリがない場合は、どちらの場合も時間切れエラー 8645 が発生する可能性があります。

  リソース ガバナーのエラー メッセージの詳細については、「リソース ガバナーのトラブルシューティング」を参照してください。

• REQUEST_MAX_CPU_TIME_SEC = value
  クエリが失敗する前に、リソースが使用可能になるのをそのクエリが待機できる最大時間を秒単位で指定します。value には、0 または正の整数を指定する必要があります。value の既定の設定は 0 で、クエリ コストに基づく内部の計算を使用して最大時間を決定します。

  注
  リソース ガバナーでは、最大時間を超過しても、要求は継続されます。ただし、イベントが生成されます。詳細については、「CPU Threshold Exceeded イベント クラス」を参照してください。

• REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value
  メモリ許可 (作業バッファー メモリ) が使用可能になるのをクエリが待機できる最大時間を秒単位で指定します。

  注
  メモリ許可のタイムアウトに達しても、常にクエリが失敗するとは限りません。クエリが失敗するのは、同時実行クエリ数が多すぎる場合だけです。それ以外の場合、クエリは最小限のメモリ許可を取得するため、クエリのパフォーマンスが低下します。

  value は正の整数にする必要があります。value の既定の設定は 0 で、クエリ コストに基づく内部の計算を使用して最大時間を決定します。

• MAX_DOP = value
  並列要求の最大 DOP (並列処理の次数) を指定します。value には、0 または正の整数 (1 ～ 255) を指定する必要があります。value が 0 の場合、サーバーでは最大限の並列処理が実行されます。この値は既定値であり、推奨の設定です。

  注
  データベース エンジンによって MAX_DOP に設定される実際の値は、指定された値よりも小さくなる場合があります。最終的な値は、min(255, number_of_CPUs) という式で決定されます。

  注意
  MAX_DOP を変更すると、サーバーのパフォーマンスが低下することがあります。MAX_DOP を変更する必要がある場合には、1 つの NUMA ノードで示されているハードウェア スケジューラの最大数以下の値に設定することをお勧めします。MAX_DOP に 8 よりも大きな値を設定することはお勧めできません。

  MAX_DOP は次のように処理されます。

  • ワークロード グループの MAX_DOP を超えない限り、クエリ ヒントとしての MAX_DOP が有効です。

  • クエリ ヒントとしての MAX_DOP は、sp_configure の 'max degree of parallelism' より常に優先されます。

  • ワークロード グループの MAX_DOP は、sp_configure の 'max degree of parallelism' より優先されます。

  • コンパイル時にクエリが直列 (MAX_DOP = 1 ) としてマークされている場合は、ワークロード グループまたは sp_configure の設定にかかわらず、実行時に並列に変更することはできません。

  DOP は、構成した後、許可メモリの不足時にのみ低くすることができます。ワークロード グループの再構成は、許可メモリ キューで待機している間は表示されません。

• GROUP_MAX_REQUESTS = value
  ワークロード グループで実行を許可する同時要求の最大数を指定します。value には、0 または正の整数を指定する必要があります。value の既定の設定は 0 で、無制限に要求が許可されます。

• USING { pool_name | "default" }
  ワークロード グループを pool_name で識別されるユーザー定義のリソース プールに関連付けます。実質的には、これによってワークロード グループがリソース プールに配置されます。pool_name を指定していない場合、または USING 引数を使用していない場合、ワークロード グループは事前に定義されたリソース ガバナーの既定のプールに配置されます。

  オプションの "default" を ALTER WORKLOAD GROUP で使用する場合は、システム予約語の DEFAULT と競合しないように引用符 ("") または角かっこ ([]) で囲む必要があります。詳細については、「区切られた識別子 (データベース エンジン)」を参照してください。

  注
  オプションの "default" は、大文字と小文字が区別されます。

説明

ALTER WORKLOAD GROUP は、既定のグループに対して使用できます。

ワークロード グループの構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE を実行しないと有効になりません。

DDL ステートメントを実行する場合、リソース ガバナーの状態について詳しく理解しておくことをお勧めします。詳細については、「リソース ガバナの状態」を参照してください。

REQUEST_MEMORY_GRANT_PERCENT: SQL Server 2005 のインデックス作成では、パフォーマンスを向上させるため、最初に許可されたメモリ量を超えるワークスペース メモリの使用が許可されます。この特別な処理は、SQL Server 2008 のリソース ガバナーでサポートされています。ただし、最初のメモリ許可も追加のメモリ許可も、リソース プール設定およびワークロード グループ設定によって制限されます。

パーティション テーブルのインデックス作成

非固定パーティション テーブルのインデックス作成によって消費されるメモリは、含まれるパーティションの数に比例します。必要なメモリの合計が、リソース ガバナーのワークロード グループの設定によって課せられているクエリごとの制限 (REQUEST_MAX_MEMORY_GRANT_PERCENT) を超えると、インデックス作成の実行に失敗します。"default" ワークロード グループでは、SQL Server 2005 との互換性のために、クエリごとの制限を超えてもクエリの開始に必要な最低限のメモリを使用できるようになっているので、そのようなクエリを実行するのに十分な量のメモリが "default" リソース プールに対して構成されていれば、同じインデックス作成を "default" ワークロード グループで実行できる可能性があります。

権限

CONTROL SERVER 権限が必要です。

例

次の例は、既定のグループの要求の重要度を MEDIUM から LOW に変更する方法を示しています。

ALTER WORKLOAD GROUP "default"
WITH (IMPORTANCE = LOW)
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

次の例は、ワークロード グループを現在のプールから既定のプールに移動する方法を示しています。

ALTER WORKLOAD GROUP adHoc
USING [default];
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

関連項目

参照

概念