ALTER WORKLOAD GROUP (Transact-SQL)
製品を選択する
次の行で、関心のある製品名を選択すると、その製品の情報のみが表示されます。
* SQL Server *
SQL Managed Instance の
Azure Synapse の
分析
SQL Server と SQL Managed Instance
既存のリソース ガバナー ワークロード グループ構成を変更し、必要に応じて別のリソース ガバナー リソース プールに割り当てます。
手記
Azure SQL Managed Instance の場合、リソース ガバナーの構成を変更するには、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 ワークロード グループの名前。
default システム予約語である DEFAULTとの競合を回避するために、ALTER WORKLOAD GROUP で使用する場合は、角かっこ ([]) または引用符 ("") にする必要があります。 詳細については、「データベース識別子の」を参照してください。
組み込みのリソース プールとワークロード グループでは、defaultなど、すべての小文字の名前が使用されます。 大文字と小文字を区別する照合順序を使用するサーバーでは、小文字の default を使用します。 大文字と小文字を区別しない照合順序を持つサーバーは、default、Default、および DEFAULT を同じ値として扱います。
IMPORTANCE = { LOW |MEDIUM |HIGH }
ワークロード グループ内の要求の相対的な重要度を指定します。 既定値は MEDIUMです。
IMPORTANCE は、ワークロード グループを含むリソース プールに対してローカルです。 同じリソース プール内の重要度が異なるワークロード グループは相互に影響しますが、他のリソース プールのワークロード グループには影響しません。
REQUEST_MAX_MEMORY_GRANT_PERCENT = 値
1 つの要求がプールから取得できるクエリ ワークスペース メモリの最大量を指定します。
値 は、MAX_MEMORY_PERCENTによって定義されたリソース プール サイズに対する割合です。 既定値は 25 です。
SQL Server 2017 (14.x) 以前では、値 は整数で、使用できる範囲は 1 から 100 です。
SQL Server 2019 (15.x) 以降では、float データ型を使用して値を小数にすることができます。 使用できる範囲は 0 ~ 100 です。
大事な
指定された量は、クエリ メモリ許可によって取得されたクエリ ワークスペース メモリのみを指します。
値 大きすぎる (たとえば、70 より大きい) ことをお勧めしません。これは、サーバーが他の同時実行クエリに十分な空きメモリを確保できない可能性があるためです。 これにより、エラー 8645
値 を 0 または小さい値に設定すると、sort や hashなどのワークスペース メモリを必要とする演算子を含むクエリが、ユーザー定義ワークロード グループで実行できなくなる可能性があります。 クエリ メモリの要件がこのパラメーターで定義されている制限を超えると、次の動作が発生します。
- ユーザー定義ワークロード グループの場合、サーバーは、メモリ要件が制限に満たされるまで、または DOP が 1 になるまで、要求 (クエリ) の並列処理 (DOP) の次数を減らそうとします。 クエリ のメモリ要件が引き続き制限を超えている場合は、エラー 8657 が発生し、クエリが失敗します。
-
internalおよびdefaultワークロード グループの場合、サーバーはクエリが必要なメモリを取得することを許可します。
どちらの場合も、サーバー 物理メモリが不足している場合は、エラー 8645 が発生する可能性があります。
REQUEST_MAX_CPU_TIME_SEC = 値
要求で使用できる CPU 時間の最大量を秒単位で指定します。 値 0 または正の整数である必要があります。 値 の既定の設定は 0 です。これは無制限を意味します。
既定では、リソース ガバナーは、最大時間を超えた場合に要求が続行されないようにしません。 ただし、イベントが生成されます。 詳細については、「CPU しきい値超過イベント クラス」を参照してください。
SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) CU3 以降、トレース フラグ 2422を使用すると、リソース ガバナーは最大 CPU 時間を超えると要求を中止します。
REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 値
クエリ ワークスペースメモリからのメモリ許可が使用可能になるまでクエリが待機できる最大時間を秒単位で指定します。 値 0 または正の整数である必要があります。 値0 の既定の設定では、クエリ コストに基づく内部計算を使用して最大時間を決定します。
メモリ許可のタイムアウトに達しても、クエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリが多すぎる場合のみです。 それ以外の場合、クエリは最小メモリ許可のみを取得し、クエリのパフォーマンスが低下する可能性があります。
MAX_DOP = 値の
並列クエリ実行の並列処理の最大次数 (MAXDOP) を指定します。
詳細については、MAXDOPの
GROUP_MAX_REQUESTS = 値の
ワークロード グループで同時に実行できる要求の最大数を指定します。 値 0 または正の整数である必要があります。 値 の既定の設定は 0 で、無制限の要求を許可します。 同時要求の最大数に達すると、そのグループ内のセッションを作成できますが、同時要求の数が指定した値を下回るまで待機状態になります。
USING { pool_name |[default] }
ワークロード グループを、pool_nameによって識別されるユーザー定義リソース プール、または default リソース プールに関連付けます。
pool_name が指定されていない場合、または USING 引数が指定されていない場合、ワークロード グループは組み込みの default プールに関連付けられます。
default は予約語であり、USINGで指定する場合は、角かっこ ([]) または引用符 ("") で囲む必要があります。
組み込みのリソース プールとワークロード グループでは、defaultなど、すべての小文字の名前が使用されます。 大文字と小文字を区別する照合順序を使用するサーバーでは、小文字の default を使用します。 大文字と小文字を区別しない照合順序を持つサーバーは、default、Default、および DEFAULT を同じ値として扱います。
備考
ALTER WORKLOAD GROUP は、default ワークロード グループでは許可されますが、internal グループでは許可されません。
ワークロード グループ構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE が実行されるまで有効になりません。
詳細については、「リソース ガバナーの
MAXDOP
特定のクエリの場合、有効な MAXDOP は次のように決定されます。
- クエリ ヒントとしての
MAXDOPは、ワークロード グループのMAX_DOP設定を超えない限り受け入れられます。 - クエリ ヒントとして
MAXDOPは、常にmax degree of parallelismサーバー構成をオーバーライドします。 詳細については、「サーバーの構成: 並列処理の最大次数」を参照してください。 - ワークロード グループ
MAX_DOPは、max degree of parallelismサーバー構成とMAXDOPデータベース スコープ構成をオーバーライドします。
MAXDOP の制限は、タスクごとに設定されます。
要求ごとの またはクエリごとの制限ではありません。 並列クエリの実行中、1 つの要求で、スケジューラに割り当てられている複数のタスクを生成できます。 詳細については、「スレッドとタスクのアーキテクチャ ガイド」を参照してください。
クエリがコンパイル時 (MAXDOP = 1) にシリアルとしてマークされている場合、ワークロード グループまたはサーバー構成の設定に関係なく、実行時に並列処理で実行することはできません。 クエリに対して MAXDOP が決定された後は、メモリ不足のためにのみ低下させることができます。 ワークロード グループの再構成は、メモリ許可キューで待機しているクエリには影響しません。
キャッシュされたプラン
MAX_DOPなどの設定に影響するプランを変更すると、新しい設定は、DBCC FREEPROCCACHE (<pool_name>)を実行した後にのみ、以前にキャッシュされたプランで有効になります。<pool_name> は、現在のワークロード グループによって使用されるリソース ガバナー リソース プールの名前です。
-
MAX_DOPを 1 に変更する場合、並列プランはシリアル モードで実行できるため、DBCC FREEPROCCACHEの実行は必要ありません。 ただし、このようなプランは、シリアル プランとしてコンパイルされたプランよりも効率が低い場合があります。 -
MAX_DOPを 1 から 0 に変更する場合、または 1 より大きい値を変更する場合、DBCC FREEPROCCACHEの実行は必要ありません。 ただし、シリアル プランは並列で実行できないため、それぞれのキャッシュをクリアすると、並列処理を使用して新しいプランをコンパイルできる可能性があります。
警告
複数のワークロード グループに関連付けられているリソース プールからキャッシュされたプランをクリアすると、<pool_name>によって識別されるユーザー定義リソース プールを使用するすべてのワークロード グループに影響します。
インデックスの作成
パフォーマンス上の理由から、インデックスの作成では、最初に許可されたよりも多くのメモリ ワークスペースを使用できます。 リソース ガバナーは、この特別な処理をサポートしています。 ただし、初期許可と追加のメモリ許可は、ワークロード グループとリソース プールの設定によって制限されます。
パーティション テーブルに非整列インデックスを作成するために消費されるメモリは、関係するパーティションの数に比例します。 必要なメモリの合計が、REQUEST_MAX_MEMORY_GRANT_PERCENT ワークロード グループ設定によって適用されるクエリごとの制限を超えると、インデックスの作成が失敗する可能性があります。
default ワークロード グループでは、下位互換性のために開始するために必要な最小メモリを使用してクエリごとの制限を超えることができるため、default リソース プールに十分な合計メモリがある場合は、default ワークロード グループを使用して同じインデックスを作成できます。
権限
CONTROL SERVER アクセス許可が必要です。
例
次の例は、既定のグループ内の要求の重要度を MEDIUM から LOWに変更する方法を示しています。
ALTER WORKLOAD GROUP [default]
WITH (IMPORTANCE = LOW);
ALTER RESOURCE GOVERNOR RECONFIGURE;
次の例は、ワークロード グループを現在 default プール内のプールから移動する方法を示しています。
ALTER WORKLOAD GROUP adHoc
USING [default];
ALTER RESOURCE GOVERNOR RECONFIGURE;
関連コンテンツ
- リソース ガバナーの
- リソース ガバナー ワークロード グループ の
- ワークロード グループ を作成する
- ワークロード グループを 移動する
- ワークロード グループ を作成する
- ワークロード グループ を削除する
- リソース プールの作成 の
- ALTER RESOURCE POOL の
- リソース プール を削除する
- ALTER RESOURCE GOVERNOR の
SQL Server の
* SQL Managed Instance *
Azure Synapse の
分析
SQL Server と SQL Managed Instance
既存のリソース ガバナー ワークロード グループ構成を変更し、必要に応じて別のリソース ガバナー リソース プールに割り当てます。
手記
Azure SQL Managed Instance の場合、リソース ガバナーの構成を変更するには、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 ワークロード グループの名前。
default システム予約語である DEFAULTとの競合を回避するために、ALTER WORKLOAD GROUP で使用する場合は、角かっこ ([]) または引用符 ("") にする必要があります。 詳細については、「データベース識別子の」を参照してください。
組み込みのリソース プールとワークロード グループでは、defaultなど、すべての小文字の名前が使用されます。 大文字と小文字を区別する照合順序を使用するサーバーでは、小文字の default を使用します。 大文字と小文字を区別しない照合順序を持つサーバーは、default、Default、および DEFAULT を同じ値として扱います。
IMPORTANCE = { LOW |MEDIUM |HIGH }
ワークロード グループ内の要求の相対的な重要度を指定します。 既定値は MEDIUMです。
IMPORTANCE は、ワークロード グループを含むリソース プールに対してローカルです。 同じリソース プール内の重要度が異なるワークロード グループは相互に影響しますが、他のリソース プールのワークロード グループには影響しません。
REQUEST_MAX_MEMORY_GRANT_PERCENT = 値
1 つの要求がプールから取得できるクエリ ワークスペース メモリの最大量を指定します。
値 は、MAX_MEMORY_PERCENTによって定義されたリソース プール サイズに対する割合です。 既定値は 25 です。
SQL Server 2017 (14.x) 以前では、値 は整数で、使用できる範囲は 1 から 100 です。
SQL Server 2019 (15.x) 以降では、float データ型を使用して値を小数にすることができます。 使用できる範囲は 0 ~ 100 です。
大事な
指定された量は、クエリ メモリ許可によって取得されたクエリ ワークスペース メモリのみを指します。
値 大きすぎる (たとえば、70 より大きい) ことをお勧めしません。これは、サーバーが他の同時実行クエリに十分な空きメモリを確保できない可能性があるためです。 これにより、エラー 8645
値 を 0 または小さい値に設定すると、sort や hashなどのワークスペース メモリを必要とする演算子を含むクエリが、ユーザー定義ワークロード グループで実行できなくなる可能性があります。 クエリ メモリの要件がこのパラメーターで定義されている制限を超えると、次の動作が発生します。
- ユーザー定義ワークロード グループの場合、サーバーは、メモリ要件が制限に満たされるまで、または DOP が 1 になるまで、要求 (クエリ) の並列処理 (DOP) の次数を減らそうとします。 クエリ のメモリ要件が引き続き制限を超えている場合は、エラー 8657 が発生し、クエリが失敗します。
-
internalおよびdefaultワークロード グループの場合、サーバーはクエリが必要なメモリを取得することを許可します。
どちらの場合も、サーバー 物理メモリが不足している場合は、エラー 8645 が発生する可能性があります。
REQUEST_MAX_CPU_TIME_SEC = 値
要求で使用できる CPU 時間の最大量を秒単位で指定します。 値 0 または正の整数である必要があります。 値 の既定の設定は 0 です。これは無制限を意味します。
既定では、リソース ガバナーは、最大時間を超えた場合に要求が続行されないようにしません。 ただし、イベントが生成されます。 詳細については、「CPU しきい値超過イベント クラス」を参照してください。
SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) CU3 以降、トレース フラグ 2422を使用すると、リソース ガバナーは最大 CPU 時間を超えると要求を中止します。
REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 値
クエリ ワークスペースメモリからのメモリ許可が使用可能になるまでクエリが待機できる最大時間を秒単位で指定します。 値 0 または正の整数である必要があります。 値0 の既定の設定では、クエリ コストに基づく内部計算を使用して最大時間を決定します。
メモリ許可のタイムアウトに達しても、クエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリが多すぎる場合のみです。 それ以外の場合、クエリは最小メモリ許可のみを取得し、クエリのパフォーマンスが低下する可能性があります。
MAX_DOP = 値の
並列クエリ実行の並列処理の最大次数 (MAXDOP) を指定します。
詳細については、MAXDOPの
GROUP_MAX_REQUESTS = 値の
ワークロード グループで同時に実行できる要求の最大数を指定します。 値 0 または正の整数である必要があります。 値 の既定の設定は 0 で、無制限の要求を許可します。 同時要求の最大数に達すると、そのグループ内のセッションを作成できますが、同時要求の数が指定した値を下回るまで待機状態になります。
USING { pool_name |[default] }
ワークロード グループを、pool_nameによって識別されるユーザー定義リソース プール、または default リソース プールに関連付けます。
pool_name が指定されていない場合、または USING 引数が指定されていない場合、ワークロード グループは組み込みの default プールに関連付けられます。
default は予約語であり、USINGで指定する場合は、角かっこ ([]) または引用符 ("") で囲む必要があります。
組み込みのリソース プールとワークロード グループでは、defaultなど、すべての小文字の名前が使用されます。 大文字と小文字を区別する照合順序を使用するサーバーでは、小文字の default を使用します。 大文字と小文字を区別しない照合順序を持つサーバーは、default、Default、および DEFAULT を同じ値として扱います。
備考
ALTER WORKLOAD GROUP は、default ワークロード グループでは許可されますが、internal グループでは許可されません。
ワークロード グループ構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE が実行されるまで有効になりません。
詳細については、「リソース ガバナーの
MAXDOP
特定のクエリの場合、有効な MAXDOP は次のように決定されます。
- クエリ ヒントとしての
MAXDOPは、ワークロード グループのMAX_DOP設定を超えない限り受け入れられます。 - クエリ ヒントとして
MAXDOPは、常にmax degree of parallelismサーバー構成をオーバーライドします。 詳細については、「サーバーの構成: 並列処理の最大次数」を参照してください。 - ワークロード グループ
MAX_DOPは、max degree of parallelismサーバー構成とMAXDOPデータベース スコープ構成をオーバーライドします。
MAXDOP の制限は、タスクごとに設定されます。
要求ごとの またはクエリごとの制限ではありません。 並列クエリの実行中、1 つの要求で、スケジューラに割り当てられている複数のタスクを生成できます。 詳細については、「スレッドとタスクのアーキテクチャ ガイド」を参照してください。
クエリがコンパイル時 (MAXDOP = 1) にシリアルとしてマークされている場合、ワークロード グループまたはサーバー構成の設定に関係なく、実行時に並列処理で実行することはできません。 クエリに対して MAXDOP が決定された後は、メモリ不足のためにのみ低下させることができます。 ワークロード グループの再構成は、メモリ許可キューで待機しているクエリには影響しません。
キャッシュされたプラン
MAX_DOPなどの設定に影響するプランを変更すると、新しい設定は、DBCC FREEPROCCACHE (<pool_name>)を実行した後にのみ、以前にキャッシュされたプランで有効になります。<pool_name> は、現在のワークロード グループによって使用されるリソース ガバナー リソース プールの名前です。
-
MAX_DOPを 1 に変更する場合、並列プランはシリアル モードで実行できるため、DBCC FREEPROCCACHEの実行は必要ありません。 ただし、このようなプランは、シリアル プランとしてコンパイルされたプランよりも効率が低い場合があります。 -
MAX_DOPを 1 から 0 に変更する場合、または 1 より大きい値を変更する場合、DBCC FREEPROCCACHEの実行は必要ありません。 ただし、シリアル プランは並列で実行できないため、それぞれのキャッシュをクリアすると、並列処理を使用して新しいプランをコンパイルできる可能性があります。
警告
複数のワークロード グループに関連付けられているリソース プールからキャッシュされたプランをクリアすると、<pool_name>によって識別されるユーザー定義リソース プールを使用するすべてのワークロード グループに影響します。
インデックスの作成
パフォーマンス上の理由から、インデックスの作成では、最初に許可されたよりも多くのメモリ ワークスペースを使用できます。 リソース ガバナーは、この特別な処理をサポートしています。 ただし、初期許可と追加のメモリ許可は、ワークロード グループとリソース プールの設定によって制限されます。
パーティション テーブルに非整列インデックスを作成するために消費されるメモリは、関係するパーティションの数に比例します。 必要なメモリの合計が、REQUEST_MAX_MEMORY_GRANT_PERCENT ワークロード グループ設定によって適用されるクエリごとの制限を超えると、インデックスの作成が失敗する可能性があります。
default ワークロード グループでは、下位互換性のために開始するために必要な最小メモリを使用してクエリごとの制限を超えることができるため、default リソース プールに十分な合計メモリがある場合は、default ワークロード グループを使用して同じインデックスを作成できます。
権限
CONTROL SERVER アクセス許可が必要です。
例
次の例は、既定のグループ内の要求の重要度を MEDIUM から LOWに変更する方法を示しています。
ALTER WORKLOAD GROUP [default]
WITH (IMPORTANCE = LOW);
ALTER RESOURCE GOVERNOR RECONFIGURE;
次の例は、ワークロード グループを現在 default プール内のプールから移動する方法を示しています。
ALTER WORKLOAD GROUP adHoc
USING [default];
ALTER RESOURCE GOVERNOR RECONFIGURE;
関連コンテンツ
- リソース ガバナーの
- リソース ガバナー ワークロード グループ の
- ワークロード グループ を作成する
- ワークロード グループを 移動する
- ワークロード グループ を作成する
- ワークロード グループ を削除する
- リソース プールの作成 の
- ALTER RESOURCE POOL の
- リソース プール を削除する
- ALTER RESOURCE GOVERNOR の
SQL Server の
SQL Managed Instance の
* Azure Synapse
分析 *
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 = 値
CAP_PERCENTAGE_RESOURCE = 値
値 は、1 から 100 までの整数の範囲です。 CAP_PERCENTAGE_RESOURCEの値は、MIN_PERCENTAGE_RESOURCEより大きくする必要があります。 CAP_PERCENTAGE_RESOURCEを変更するには、コマンドが完了する前に、実行中のすべてのクエリがワークロード グループで完了する必要があります。 詳細については、この記事の「ALTER WORKLOAD GROUP の動作
REQUEST_MIN_RESOURCE_GRANT_PERCENT = 値
値 は、0.75 ~ 100.00 の範囲の 10 進数です。 REQUEST_MIN_RESOURCE_GRANT_PERCENTの値は、MIN_PERCENTAGE_RESOURCEの係数であり、CAP_PERCENTAGE_RESOURCE未満である必要があります。
REQUEST_MAX_RESOURCE_GRANT_PERCENT = 値
値 は 10 進数であり、REQUEST_MIN_RESOURCE_GRANT_PERCENTより大きくする必要があります。
IMPORTANCE = { LOW |BELOW_NORMAL |NORMAL |ABOVE_NORMAL |HIGH }
ワークロード グループの要求の既定の重要度を変更します。
QUERY_EXECUTION_TIMEOUT_SEC = 値
クエリが取り消されるまでに実行できる最大時間を秒単位で変更します。 値は 0 または正の整数である必要があります。 値の既定の設定は 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 要求はすぐに失敗します。
ロック動作
ワークロード グループを変更するには、すべてのワークロード グループでグローバル ロックが必要です。 ワークロード グループを変更する要求は、既に送信された作成または削除のワークロード グループ要求の背後にキューに入ります。 alter ステートメントのバッチが一度に送信されると、送信された順序で処理されます。