ALTER WORKLOAD GROUP (Transact-SQL)

製品を選択する

次の行で、興味のある製品の名前を選択します。その製品の情報だけが表示されます。

* SQL Server *  

 

SQL Server と SQL Managed Instance

既存の Resource Governor ワークロード グループの構成を変更します。必要に応じて、そのワークロード グループを Resource Governor リソース プールに割り当てることもできます。

Topic link iconTransact-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"

既存のユーザー定義のワークロード グループの名前か、リソース ガバナーの既定のワークロード グループを指定します。 Resource Governorのインストール時に、"default" グループと internal 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 つの要求にプールから割り当てられる最大メモリ量を指定します。 value は、MAX_MEMORY_PERCENT で指定したリソース プールのサイズが基準になります。 既定値は 25 です。 指定した量のみがクエリの実行時に許可されるメモリとして割り当てられます。

value は 2017 年SQL Server (14.x) までの整数で、使用できる範囲は 1 ~ 100 です。 2019 SQL Server (15.xfloat) から、値はデータ型で、使用できる範囲は 0 から 100 です。

重要

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

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

クエリのメモリ要求がこのパラメーターによって指定されている制限を超えると、サーバーは次のように対応します。

  • ユーザー定義のワークロード グループでは、メモリ要求が制限より低くなるか、並列処理の次数が 1 になるまで、サーバーはクエリの並列処理の次数を下げます。 それでもクエリのメモリ要求が制限を超える場合は、エラー 8657 が発生します。
  • 内部および既定のワークロード グループでは、そのクエリに必要なメモリの確保がサーバーによって許可されます。

どちらの場合も、サーバーに十分な物理メモリがない場合はタイムアウト エラー 8645 が発生する可能性があることに注意してください。

REQUEST_MAX_CPU_TIME_SEC = value

要求が使用できる最大 CPU 時間を秒単位で指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定が 0 の場合は、無制限を示します。 既定では、リソース ガバナーでは最大時間を超過しても、要求は継続されます。 ただし、イベントが生成されます。 詳細については、「CPU Threshold Exceeded イベント クラス」を参照してください。

SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) CU3 より、トレース フラグ 2422 を使用すると、Resource Governor は最大時間を超えたときに要求を中止します。

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 と競合しないように引用符 ("") または角かっこ ([]) で囲む必要があります。 詳細については、「データベース識別子」を参照してください。

注釈

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

ワークロード グループの構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE を実行しないと有効になりません。 DBCC FREEPROCCACHE (*pool_name*)設定に影響を与えるプランを変更する場合、新しい設定は、 の実行後に以前にキャッシュされたプランでのみ有効になります。DBCC FREEPROCCACHE (*pool_name*) は、ワークロード グループが関連付けられている Resource Governor リソース プールの名前です。

  • MAX_DOP を 1 に変更する場合、並列プランは直列モードで実行できるため、DBCC FREEPROCCACHE を実行する必要はありません。 ただし、直列プランとしてコンパイルされたプランほど効率的ではない可能性があります。

  • MAX_DOP を 1 から 0、または 1 より大きい値に変更する場合、DBCC FREEPROCCACHE を実行する必要はありません。 ただし、直列プランは並列で実行できません。そのため、個々のキャッシュを消去すると、場合によっては、新しいプランを並列処理でコンパイルできます。

注意事項

複数のワークロード グループに関連付けられているリソース プールからキャッシュされているプランを消去すると、ユーザー定義のリソース プールが pool_name で識別されているすべてのワークロード グループに影響します。

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

REQUEST_MEMORY_GRANT_PERCENT: SQL Server 2005 (1.x) では、インデックスの作成では、パフォーマンスの向上のために最初に許可されたよりも多くのワークスペースメモリを使用できます。 この特別な処理は、今後のバージョンのリソース ガバナーでもサポートされますが、最初のメモリ許可も追加のメモリ許可もリソース プール設定とワークロード グループ設定によって制限されます。

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

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

アクセス許可

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  

参照

リソース ガバナー
CREATE WORKLOAD GROUP (Transact-SQL)
DROP WORKLOAD GROUP (Transact-SQL)
CREATE RESOURCE POOL (Transact-SQL)
ALTER RESOURCE POOL (Transact-SQL)
DROP RESOURCE POOL (Transact-SQL)
ALTER RESOURCE GOVERNOR (Transact-SQL)

* SQL Managed Instance *  

 

SQL Server と SQL Managed Instance

既存の Resource Governor ワークロード グループの構成を変更します。必要に応じて、そのワークロード グループを Resource Governor リソース プールに割り当てることもできます。

Topic link icontransact-sql 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 をインストールすると、Resource Governor によって "既定" と内部グループが作成されます。

オプションの "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 つの要求にプールから割り当てられる最大メモリ量を指定します。 value は、MAX_MEMORY_PERCENT で指定したリソース プールのサイズが基準になります。 既定値は 25 です。 指定した量のみがクエリの実行時に許可されるメモリとして割り当てられます。

は SQL Server 2017 (14. x) までの整数で、許容範囲は 1 ~ 100 です。 SQL Server 2019 (15. x) 以降では、値は float データ型であり、許容範囲は 0 ~ 100 です。

重要

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

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

クエリのメモリ要求がこのパラメーターによって指定されている制限を超えると、サーバーは次のように対応します。

  • ユーザー定義のワークロード グループでは、メモリ要求が制限より低くなるか、並列処理の次数が 1 になるまで、サーバーはクエリの並列処理の次数を下げます。 それでもクエリのメモリ要求が制限を超える場合は、エラー 8657 が発生します。
  • 内部および既定のワークロード グループでは、そのクエリに必要なメモリの確保がサーバーによって許可されます。

どちらの場合も、サーバーに十分な物理メモリがない場合はタイムアウト エラー 8645 が発生する可能性があることに注意してください。

REQUEST_MAX_CPU_TIME_SEC = value

要求が使用できる最大 CPU 時間を秒単位で指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定が 0 の場合は、無制限を示します。 既定では、リソース ガバナーでは最大時間を超過しても、要求は継続されます。 ただし、イベントが生成されます。 詳細については、「CPU Threshold Exceeded イベント クラス」を参照してください。

SQL Server 2016 (13. x) SP2 および SQL Server 2017 (14. x) CU3 から、トレースフラグ 2422を使用すると、最大時間を超過した場合に Resource Governor が要求を中止します。

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 と競合しないように引用符 ("") または角かっこ ([]) で囲む必要があります。 詳細については、「データベース識別子」を参照してください。

注釈

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

ワークロード グループの構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE を実行しないと有効になりません。 DBCC FREEPROCCACHE (*pool_name*)設定に影響を与えるプランを変更する場合、新しい設定は、 の実行後に以前にキャッシュされたプランでのみ有効になります。DBCC FREEPROCCACHE (*pool_name*) は、ワークロード グループが関連付けられている Resource Governor リソース プールの名前です。

  • MAX_DOP を 1 に変更する場合、並列プランは直列モードで実行できるため、DBCC FREEPROCCACHE を実行する必要はありません。 ただし、直列プランとしてコンパイルされたプランほど効率的ではない可能性があります。

  • MAX_DOP を 1 から 0、または 1 より大きい値に変更する場合、DBCC FREEPROCCACHE を実行する必要はありません。 ただし、直列プランは並列で実行できません。そのため、個々のキャッシュを消去すると、場合によっては、新しいプランを並列処理でコンパイルできます。

注意事項

複数のワークロード グループに関連付けられているリソース プールからキャッシュされているプランを消去すると、ユーザー定義のリソース プールが pool_name で識別されているすべてのワークロード グループに影響します。

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

REQUEST_MEMORY_GRANT_PERCENT: SQL Server 2005 (9.x) では、インデックスの作成では、パフォーマンスを向上するために、最初に付与されたよりも多くのワークスペース メモリを使用できます。 この特別な処理は、今後のバージョンのリソース ガバナーでもサポートされますが、最初のメモリ許可も追加のメモリ許可もリソース プール設定とワークロード グループ設定によって制限されます。

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

非固定パーティション テーブルのインデックス作成によって消費されるメモリは、含まれるパーティションの数に比例します。 必要なメモリの合計が、リソース ガバナーのワークロード グループの設定によって課せられているクエリごとの制限 (REQUEST_MAX_MEMORY_GRANT_PERCENT) を超えると、インデックス作成の実行に失敗します。 "既定" ワークロード グループでは、クエリがクエリごとの制限を超え、SQL Server 2005 (9.x) の互換性のために必要な最小メモリを使用できます。このため、"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  

参照

リソース ガバナー
CREATE WORKLOAD GROUP (Transact-SQL)
DROP WORKLOAD GROUP (Transact-SQL)
CREATE RESOURCE POOL (Transact-SQL)
ALTER RESOURCE POOL (Transact-SQL)
DROP RESOURCE POOL (Transact-SQL)
ALTER RESOURCE GOVERNOR (Transact-SQL)

* Azure Synapse
分析 *
 

 

Azure Synapse Analytics

既存のワークロード グループを変更します。

実行中の要求とキューに置かれた要求を含むシステムで ALTER WORKLOAD GROUP がどのように動作するかの詳細については、以下の「ALTER WORKLOAD GROUP の動作」のセクションを参照してください。

CREATE WORKLOAD GROUP に適用される制限は にも適用されます。 パラメーターを変更する前に、クエリ sys.workload_management_workload_groups を使用して、値が許容範囲内にあることを確認してください。

構文

ALTER WORKLOAD GROUP group_name
 WITH
 ([       MIN_PERCENTAGE_RESOURCE = value ]
  [ [ , ] CAP_PERCENTAGE_RESOURCE = value ]
  [ [ , ] REQUEST_MIN_RESOURCE_GRANT_PERCENT = value ]
  [ [ , ] REQUEST_MAX_RESOURCE_GRANT_PERCENT = value ] 
  [ [ , ] IMPORTANCE = { LOW | BELOW_NORMAL | NORMAL | ABOVE_NORMAL | HIGH }]
  [ [ , ] QUERY_EXECUTION_TIMEOUT_SEC = value ] )
  [ ; ]

引数

group_name

変更されている、既存のユーザー定義のワークロード グループの名前です。 group_name は変更できません。

MIN_PERCENTAGE_RESOURCE = value

Value は 0 から 100 の範囲の整数です。 min_percentage_resource を変更するときは、min_percentage_resource の合計がすべてのワークロード グループ全体で 100 を超えてはいけません。 min_percentage_resource を変更するには、コマンドが完了する前に、実行中のすべてのクエリがワークロードグループ内で完了する必要があります。 詳細については、このドキュメントの「ALTER WORKLOAD GROUP の動作」のセクションを参照してください。

CAP_PERCENTAGE_RESOURCE = value

Value は 1 から 100 の範囲の整数です。 cap_percentage_resource の値は、min_percentage_resource よりも大きくする必要があります。 cap_percentage_resource を変更するには、コマンドが完了する前に、実行中のすべてのクエリがワークロードグループ内で完了する必要があります。 詳細については、このドキュメントの「ALTER WORKLOAD GROUP の動作」のセクションを参照してください。

REQUEST_MIN_RESOURCE_GRANT_PERCENT = value

Value は、0.75 から 100.00 の範囲の 10 進数です。 request_min_resource_grant_percent の値は、min_percentage_resource の係数である必要があり、cap_percentage_resource よりも小さくする必要があります。

REQUEST_MAX_RESOURCE_GRANT_PERCENT = value

Value は 10 進数で request_min_resource_grant_percent 以上である必要があります。

IMPORTANCE = { LOW |BELOW_NORMAL |NORMAL |ABOVE_NORMAL |HIGH }

ワークロード グループに対する要求の既定の重要度を変更します。

QUERY_EXECUTION_TIMEOUT_SEC = value

クエリが取り消されるまでに実行できる最大時間を秒単位で変更します。 Value は、0 または正の整数にする必要があります。 value の既定の設定が 0 の場合は、無制限を示します。

アクセス許可

CONTROL DATABASE アクセス許可が必要です。

次の例では、wgDataLoads という名前のワークロード グループのカタログ ビューの値を調べて、その値を変更しています。

SELECT *
FROM sys.workload_management_workload_groups  
WHERE [name] = 'wgDataLoads'

ALTER WORKLOAD GROUP wgDataLoads WITH
( MIN_PERCENTAGE_RESOURCE            = 40
 ,CAP_PERCENTAGE_RESOURCE            = 80
 ,REQUEST_MIN_RESOURCE_GRANT_PERCENT = 10 )

ALTER WORKLOAD GROUP の動作

どの時点でも、システムには 3 種類の要求があります。

  • まだ分類されていない要求。
  • オブジェクトのロックまたはシステム リソースのために分類され、待機している要求。
  • 分類され、実行中の要求。

変更するワークロード グループのプロパティによって、設定が有効になるタイミングは異なります。

重要度または query_execution_timeout 重要度と query_execution_timeout のプロパティの場合、分類されていない要求は、新しい構成値を取得します。 待機中および実行中の要求は、古い構成で実行されます。 ALTER WORKLOAD GROUP の要求は、ワークロード グループでクエリが実行されているかどうかに関係なく、直ちに実行されます。

Request_min_resource_grant_percent または request_max_resource_grant_percent request_min_resource_grant_percent または request_max_resource_grant_percent の場合、実行中の要求は古い構成で実行されます。 待機中の要求と分類されていない要求は、新しい構成値を取得します。 ALTER WORKLOAD GROUP の要求は、ワークロード グループでクエリが実行されているかどうかに関係なく、直ちに実行されます。

Min_percentage_resource または cap_percentage_resource min_percentage_resource および cap_percentage_resource の場合、実行中の要求は古い構成で実行されます。 待機中の要求と分類されていない要求は、新しい構成値を取得します。

min_percentage_resource と cap_percentage_resource を変更するには、変更されているワークロード グループ内で実行中の要求をドレインする必要があります。 min_percentage_resource を減らすと、解放されたリソースが共有プールに返され、他のワークロード グループからの要求で使用できるようになります。 逆に、min_percentage_resource を増やすと、共有プールから必要なリソースのみを使用する要求が完了するまで待機します。 ALTER WORKLOAD GROUP 操作では、共有プールで実行されるのを待機している他の要求よりも、共有リソースへのアクセスが優先されます。 min_percentage_resource の合計が 100% を超えた場合、ALTER WORKLOAD GROUP 要求はすぐに失敗します。

ロック動作 ワークロード グループを変更するには、すべてのワークロード グループに対するグローバルなロックが必要です。 ワークロード グループを変更する要求は、既に送信済みのワークロード グループの作成/ドロップ要求の後ろのキューに格納されます。 変更ステートメントのバッチを一度に送信すると、そのバッチは、送信された順序で処理されます。

関連項目