次の方法で共有

ALTER WORKLOAD GROUP (Transact-SQL)

  • [アーティクル]

製品を選択する

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

* SQL Server *  

SQL Managed Instance

Azure Synapse
分析

 

SQL Server と SQL Managed Instance

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

Note

Azure SQL Managed Instance の場合、Resource Governor の構成を変更するには、データベースの master コンテキストにある必要があります。

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"

既存のユーザー定義のワークロード グループまたは Resource Governor の既定のワークロード グループの名前。 SQL Server のインストール時に、Resource Governor により "default" グループと内部のグループが作成されます。

オプションの "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) までは、value は int で、許容範囲は 1 から 100 です。 SQL Server 2019 (15.x) 以降、value は 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 の場合は、無制限を示します。 既定では、最大時間を超過しても、要求の継続は Resource Governor によって妨げられません。 ただし、イベントが生成されます。 詳細については、「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 引数を使用しない場合、ワークロード グループは事前に定義された Resource Governor の既定のプールに配置されます。

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

注釈

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

ワークロード グループの構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE が実行されるまで有効になりません。 プランに影響する設定を変更した場合、新しい設定は、DBCC FREEPROCCACHE (*pool_name*) の実行後にのみ、前にキャッシュされたプランに反映されます。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) では、インデックスの作成では、パフォーマンスの改善のために最初に付与されたのよりも多くのワークスペース メモリを使用することが許可されています。 この特別な処理は、今後のバージョンのリソース ガバナーでもサポートされますが、最初のメモリ許可も追加のメモリ許可もリソース プール設定とワークロード グループ設定によって制限されます。

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

非固定パーティション テーブルのインデックス作成によって消費されるメモリは、含まれるパーティションの数に比例します。 必要なメモリの合計が、Resource Governor のワークロード グループの設定によって課せられているクエリごとの制限 (REQUEST_MAX_MEMORY_GRANT_PERCENT) を超えると、このインデックス作成の実行に失敗する場合があります。 "default" ワークロード グループでは、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

関連項目

SQL Server

* SQL Managed Instance *  

Azure Synapse
分析

 

SQL Server と SQL Managed Instance

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

Note

Azure SQL Managed Instance の場合、Resource Governor の構成を変更するには、データベースの master コンテキストにある必要があります。

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"

既存のユーザー定義のワークロード グループまたは Resource Governor の既定のワークロード グループの名前。 SQL Server のインストール時に、Resource Governor により "default" グループと内部のグループが作成されます。

オプションの "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) までは、value は int で、許容範囲は 1 から 100 です。 SQL Server 2019 (15.x) 以降、value は 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 の場合は、無制限を示します。 既定では、最大時間を超過しても、要求の継続は Resource Governor によって妨げられません。 ただし、イベントが生成されます。 詳細については、「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 引数を使用しない場合、ワークロード グループは事前に定義された Resource Governor の既定のプールに配置されます。

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

注釈

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

ワークロード グループの構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE が実行されるまで有効になりません。 プランに影響する設定を変更した場合、新しい設定は、DBCC FREEPROCCACHE (*pool_name*) の実行後にのみ、前にキャッシュされたプランに反映されます。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) では、インデックスの作成では、パフォーマンスの改善のために最初に付与されたのよりも多くのワークスペース メモリを使用することが許可されています。 この特別な処理は、今後のバージョンのリソース ガバナーでもサポートされますが、最初のメモリ許可も追加のメモリ許可もリソース プール設定とワークロード グループ設定によって制限されます。

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

非固定パーティション テーブルのインデックス作成によって消費されるメモリは、含まれるパーティションの数に比例します。 必要なメモリの合計が、Resource Governor のワークロード グループの設定によって課せられているクエリごとの制限 (REQUEST_MAX_MEMORY_GRANT_PERCENT) を超えると、このインデックス作成の実行に失敗する場合があります。 "default" ワークロード グループでは、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

関連項目

SQL Server

SQL Managed Instance

* Azure Synapse
Analytics *  

 

Azure Synapse Analytics

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

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

CREATE WORKLOAD GROUP に適用される制限は ALTER 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 要求はすぐに失敗します。

ロック動作

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

関連項目