CREATE WORKLOAD GROUP (Transact-SQL)
製品を選択する
次の行で、興味のある製品の名前を選択すると、その製品の情報のみが表示されます。
* SQL Server *
SQL Server と SQL Managed Instance
リソース ガバナー ワークロード グループを作成し、ワークロード グループをリソース ガバナー リソース プールに関連付けます。
リソース ガバナーは、SQL Server のすべてのエディションで使用できるわけではありません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2022 の各エディションとサポートされている機能」を参照してください。
Note
Azure SQL Managed Instance の場合、リソース ガバナーの構成を変更するには、master データベースのコンテキストにある必要があります。
構文
CREATE WORKLOAD GROUP group_name
[ 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] ]
[ [ , ] EXTERNAL external_pool_name | [default] ]
} ]
[ ; ]
引数
group_name
ワークロード グループのユーザー定義の名前。
IMPORTANCE = { LOW | MEDIUM | HIGH }
ワークロード グループでの要求の相対的な重要度を指定します。 既定値は MEDIUMです。
IMPORTANCE は、ワークロード グループを含むリソース プールに対してローカルです。 同じリソース プール内の重要度が異なるワークロード グループは相互に影響しますが、他のリソース プールのワークロード グループには影響しません。
REQUEST_MAX_MEMORY_GRANT_PERCENT = value
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 = value
バッチ要求で使用できる CPU 時間の最大量を秒単位で指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定が 0 の場合は、無制限を示します。
最大 CPU 時間を超えると、cpu_threshold_exceeded 拡張イベントとトレース イベントが生成されます。 詳細については、「CPU Threshold Exceeded イベント クラス」を参照してください。
Azure SQL Managed Instance では、最大 CPU 時間を超えると、リソース ガバナーはエラー 10961 で要求を中止します。
SQL Server では、リソース ガバナーは既定で要求を中止しません。 ただし、SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) CU3 以降では、トレース フラグ 2422 が有効になっていて、最大 CPU 時間を超えると、リソース ガバナーはエラー 10961 で要求を中止します。
Note
CPU 時間の使用の検出間隔は 5 秒です。 クエリが指定された制限を 5 秒以上超えると、イベントが生成されます。 ただし、クエリが指定されたしきい値を 5 秒未満超えた場合、クエリのタイミングと前回の検出スイープの時刻によっては、検出が失敗する可能性があります。
REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value
クエリ ワークスペースメモリからのメモリ許可が使用可能になるまでクエリが待機できる最大時間を秒単位で指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定である 0 の場合、クエリ コストに基づく内部の計算を使用して、最大時間が決定されます。
メモリ許可のタイムアウトに達したときにクエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリが多すぎる場合のみです。 それ以外の場合、クエリは最小メモリ許可のみを取得し、クエリのパフォーマンスが低下する可能性があります。
MAX_DOP = value
並列クエリ実行の並列処理の最大次数 (MAXDOP) を指定します。
value の許容範囲は 0 から 64 です。
value の既定の設定は 0 で、グローバル設定が使用されます。
詳細については、MAXDOPの
GROUP_MAX_REQUESTS = value
ワークロード グループで実行を許可する同時要求の最大数を指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定は 0 であり、これでは無制限の要求が許可されます。 同時要求の最大数に達すると、そのグループ内のセッションを作成できますが、同時要求の数が指定した値を下回るまで待機状態になります。
USING { pool_name |[default] }
ワークロード グループを、pool_nameによって識別されるユーザー定義リソース プール、または default リソース プールに関連付けます。
pool_name が指定されていない場合、または USING 引数が指定されていない場合、ワークロード グループは組み込みの default プールに関連付けられます。
default は予約語であり、USINGで指定する場合は、角かっこ ([]) または引用符 ("") で囲む必要があります。
組み込みのリソース プールとワークロード グループでは、defaultなど、すべての小文字の名前が使用されます。 大文字と小文字を区別する照合順序を使用するサーバーでは、小文字の default を使用します。 大文字と小文字を区別しない照合順序を持つサーバーは、default、Default、および DEFAULT を同じ値として扱います。
EXTERNAL external_pool_name |[既定値]
適用対象: SQL Server 2016 (13.x) 以降。
ワークロード グループには、外部リソース プールを指定できます。 ワークロード グループを定義し、2 つのプールに関連付けることができます。
- データベース エンジン ワークロードのリソース プール。
- 外部プロセス用の外部リソース プール 詳細については、sp_execute_external_scriptを参照してください。
解説
詳細については、「リソース ガバナーの
MAXDOP
特定のクエリの場合、有効な MAXDOP は次のように決定されます。
- クエリ ヒントとしての
MAXDOPは、ワークロード グループのMAX_DOP設定を超えない限り受け入れられます。 - クエリ ヒントとして
MAXDOPは、常にmax degree of parallelismサーバー構成をオーバーライドします。 詳細については、「サーバーの構成: 並列処理の最大次数」を参照してください。 - ワークロード グループ
MAX_DOPは、max degree of parallelismサーバー構成とMAXDOPデータベース スコープ構成をオーバーライドします。
MAXDOP の制限は、タスクごとに設定されます。 この設定は、要求ごとまたはクエリ制限ごとではありません。 並列クエリの実行中、1 つの要求で、スケジューラに割り当てられている複数のタスクを生成できます。 詳細については、「スレッドとタスクのアーキテクチャ ガイド」を参照してください。
クエリがコンパイル時 (MAXDOP = 1) にシリアルとしてマークされている場合、ワークロード グループまたはサーバー構成の設定に関係なく、実行時に並列処理で実行することはできません。 クエリに対して MAXDOP が決定された後は、メモリ不足のためにのみ低下させることができます。 ワークロード グループの再構成は、メモリ許可キューで待機しているクエリには影響しません。
インデックスの作成
パフォーマンス上の理由から、インデックスの作成では、最初に許可されたよりも多くのメモリ ワークスペースを使用できます。 リソース ガバナーは、この特別な処理をサポートしています。 ただし、初期許可と追加のメモリ許可は、ワークロード グループとリソース プールの設定によって制限されます。
パーティション テーブルに非整列インデックスを作成するために消費されるメモリは、関係するパーティションの数に比例します。 必要なメモリの合計が、REQUEST_MAX_MEMORY_GRANT_PERCENT ワークロード グループ設定によって適用されるクエリごとの制限を超えると、インデックスの作成が失敗する可能性があります。
default ワークロード グループでは、下位互換性のために開始するために必要な最小メモリを使用してクエリごとの制限を超えることができるため、default リソース プールに十分な合計メモリがある場合は、default ワークロード グループを使用して同じインデックスを作成できます。
アクセス許可
CONTROL SERVER アクセス許可が必要です。
例
newReports リソース プールに default という名前のワークロード グループを作成し、最大メモリ許可、要求の最大 CPU 時間、および MAXDOPを制限します。
CREATE WORKLOAD GROUP newReports
WITH (
REQUEST_MAX_MEMORY_GRANT_PERCENT = 2.5,
REQUEST_MAX_CPU_TIME_SEC = 100,
MAX_DOP = 4
)
USING [default];
関連コンテンツ
- チュートリアル: リソース ガバナーの構成例とベスト プラクティス
- リソース ガバナーの
- リソース ガバナー ワークロード グループ の
- ワークロード グループ を作成する
- ALTER WORKLOAD GROUP の
- ワークロード グループ を削除する
- リソース プールの作成 の
- ALTER RESOURCE POOL の
- リソース プール を削除する
- ALTER RESOURCE GOVERNOR の
* SQL Managed Instance *
SQL Server と SQL Managed Instance
リソース ガバナー ワークロード グループを作成し、ワークロード グループをリソース ガバナー リソース プールに関連付けます。
リソース ガバナーは、SQL Server のすべてのエディションで使用できるわけではありません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2022 の各エディションとサポートされている機能」を参照してください。
Note
Azure SQL Managed Instance の場合、リソース ガバナーの構成を変更するには、master データベースのコンテキストにある必要があります。
構文
CREATE WORKLOAD GROUP group_name
[ 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] ]
[ [ , ] EXTERNAL external_pool_name | [default] ]
} ]
[ ; ]
引数
group_name
ワークロード グループのユーザー定義の名前。
IMPORTANCE = { LOW | MEDIUM | HIGH }
ワークロード グループでの要求の相対的な重要度を指定します。 既定値は MEDIUMです。
IMPORTANCE は、ワークロード グループを含むリソース プールに対してローカルです。 同じリソース プール内の重要度が異なるワークロード グループは相互に影響しますが、他のリソース プールのワークロード グループには影響しません。
REQUEST_MAX_MEMORY_GRANT_PERCENT = value
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 = value
バッチ要求で使用できる CPU 時間の最大量を秒単位で指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定が 0 の場合は、無制限を示します。
最大 CPU 時間を超えると、cpu_threshold_exceeded 拡張イベントとトレース イベントが生成されます。 詳細については、「CPU Threshold Exceeded イベント クラス」を参照してください。
Azure SQL Managed Instance では、最大 CPU 時間を超えると、リソース ガバナーはエラー 10961 で要求を中止します。
SQL Server では、リソース ガバナーは既定で要求を中止しません。 ただし、SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) CU3 以降では、トレース フラグ 2422 が有効になっていて、最大 CPU 時間を超えると、リソース ガバナーはエラー 10961 で要求を中止します。
Note
CPU 時間の使用の検出間隔は 5 秒です。 クエリが指定された制限を 5 秒以上超えると、イベントが生成されます。 ただし、クエリが指定されたしきい値を 5 秒未満超えた場合、クエリのタイミングと前回の検出スイープの時刻によっては、検出が失敗する可能性があります。
REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value
クエリ ワークスペースメモリからのメモリ許可が使用可能になるまでクエリが待機できる最大時間を秒単位で指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定である 0 の場合、クエリ コストに基づく内部の計算を使用して、最大時間が決定されます。
メモリ許可のタイムアウトに達したときにクエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリが多すぎる場合のみです。 それ以外の場合、クエリは最小メモリ許可のみを取得し、クエリのパフォーマンスが低下する可能性があります。
MAX_DOP = value
並列クエリ実行の並列処理の最大次数 (MAXDOP) を指定します。
value の許容範囲は 0 から 64 です。
value の既定の設定は 0 で、グローバル設定が使用されます。
詳細については、MAXDOPの
GROUP_MAX_REQUESTS = value
ワークロード グループで実行を許可する同時要求の最大数を指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定は 0 であり、これでは無制限の要求が許可されます。 同時要求の最大数に達すると、そのグループ内のセッションを作成できますが、同時要求の数が指定した値を下回るまで待機状態になります。
USING { pool_name |[default] }
ワークロード グループを、pool_nameによって識別されるユーザー定義リソース プール、または default リソース プールに関連付けます。
pool_name が指定されていない場合、または USING 引数が指定されていない場合、ワークロード グループは組み込みの default プールに関連付けられます。
default は予約語であり、USINGで指定する場合は、角かっこ ([]) または引用符 ("") で囲む必要があります。
組み込みのリソース プールとワークロード グループでは、defaultなど、すべての小文字の名前が使用されます。 大文字と小文字を区別する照合順序を使用するサーバーでは、小文字の default を使用します。 大文字と小文字を区別しない照合順序を持つサーバーは、default、Default、および DEFAULT を同じ値として扱います。
EXTERNAL external_pool_name |[既定値]
適用対象: SQL Server 2016 (13.x) 以降。
ワークロード グループには、外部リソース プールを指定できます。 ワークロード グループを定義し、2 つのプールに関連付けることができます。
- データベース エンジン ワークロードのリソース プール。
- 外部プロセス用の外部リソース プール 詳細については、sp_execute_external_scriptを参照してください。
解説
詳細については、「リソース ガバナーの
MAXDOP
特定のクエリの場合、有効な MAXDOP は次のように決定されます。
- クエリ ヒントとしての
MAXDOPは、ワークロード グループのMAX_DOP設定を超えない限り受け入れられます。 - クエリ ヒントとして
MAXDOPは、常にmax degree of parallelismサーバー構成をオーバーライドします。 詳細については、「サーバーの構成: 並列処理の最大次数」を参照してください。 - ワークロード グループ
MAX_DOPは、max degree of parallelismサーバー構成とMAXDOPデータベース スコープ構成をオーバーライドします。
MAXDOP の制限は、タスクごとに設定されます。 この設定は、要求ごとまたはクエリ制限ごとではありません。 並列クエリの実行中、1 つの要求で、スケジューラに割り当てられている複数のタスクを生成できます。 詳細については、「スレッドとタスクのアーキテクチャ ガイド」を参照してください。
クエリがコンパイル時 (MAXDOP = 1) にシリアルとしてマークされている場合、ワークロード グループまたはサーバー構成の設定に関係なく、実行時に並列処理で実行することはできません。 クエリに対して MAXDOP が決定された後は、メモリ不足のためにのみ低下させることができます。 ワークロード グループの再構成は、メモリ許可キューで待機しているクエリには影響しません。
インデックスの作成
パフォーマンス上の理由から、インデックスの作成では、最初に許可されたよりも多くのメモリ ワークスペースを使用できます。 リソース ガバナーは、この特別な処理をサポートしています。 ただし、初期許可と追加のメモリ許可は、ワークロード グループとリソース プールの設定によって制限されます。
パーティション テーブルに非整列インデックスを作成するために消費されるメモリは、関係するパーティションの数に比例します。 必要なメモリの合計が、REQUEST_MAX_MEMORY_GRANT_PERCENT ワークロード グループ設定によって適用されるクエリごとの制限を超えると、インデックスの作成が失敗する可能性があります。
default ワークロード グループでは、下位互換性のために開始するために必要な最小メモリを使用してクエリごとの制限を超えることができるため、default リソース プールに十分な合計メモリがある場合は、default ワークロード グループを使用して同じインデックスを作成できます。
アクセス許可
CONTROL SERVER アクセス許可が必要です。
例
newReports リソース プールに default という名前のワークロード グループを作成し、最大メモリ許可、要求の最大 CPU 時間、および MAXDOPを制限します。
CREATE WORKLOAD GROUP newReports
WITH (
REQUEST_MAX_MEMORY_GRANT_PERCENT = 2.5,
REQUEST_MAX_CPU_TIME_SEC = 100,
MAX_DOP = 4
)
USING [default];
関連コンテンツ
- チュートリアル: リソース ガバナーの構成例とベスト プラクティス
- リソース ガバナーの
- リソース ガバナー ワークロード グループ の
- ワークロード グループ を作成する
- ALTER WORKLOAD GROUP の
- ワークロード グループ を削除する
- リソース プールの作成 の
- ALTER RESOURCE POOL の
- リソース プール を削除する
- ALTER RESOURCE GOVERNOR の
* Azure Synapse
Analytics *
Azure Synapse Analytics
ワークロード グループを作成します。 ワークロード グループは、一連の要求用のコンテナーであり、システムでワークロード管理を構成する方法の基礎となります。 ワークロード グループでは、ワークロードの分離のためのリソースの予約、リソースの格納、要求ごとのリソースの定義、実行ルールへの準拠を行う機能が提供されます。 ステートメントが完了すると、設定が有効になります。
CREATE 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 は、sysname です。 これは長さを最大で 128 文字とすることができ、インスタンス内では一意である必要があります。
MIN_PERCENTAGE_RESOURCE = value
他のワークロード グループと共有されない、このワークロード グループに対して保証される最小リソース割り当てを指定します。 このパラメーターでは、メモリ リソースのみが制御されます。
value は 0 から 100 の範囲の整数です。 すべてのワークロード グループでの min_percentage_resource の合計は、100 を超えることはできません。 min_percentage_resource の値を cap_percentage_resource より大きくすることはできません。 サービス レベルごとに有効な最小値があります。 詳細については、「有効な値」を参照してください。
CAP_PERCENTAGE_RESOURCE = value
ワークロード グループ内のすべての要求に対するリソースの最大使用率を指定します。 このパラメーターでは、CPU とメモリ リソースのいずれも制限されます。 value に対して許可される整数の範囲は 1 から 100 です。 cap_percentage_resource の値は、min_percentage_resource よりも大きくする必要があります。 cap_percentage_resource の有効な値は、他のワークロード グループで min_percentage_resource が 0 より大きく構成されている場合に減らすことができます。
REQUEST_MIN_RESOURCE_GRANT_PERCENT = value
要求ごとに割り当てられるリソースの最小量を設定します。 このパラメーターでは、メモリ リソースのみが制御されます。
value は 0.75 から 100.00 の 10 進数の範囲の必須パラメーターです。 request_min_resource_grant_percent の値は、0.25 の倍数である必要があります。また、min_percentage_resource の係数であり、cap_percentage_resource よりも小さくする必要があります。 サービス レベルごとに有効な最小値があります。 詳細については、「有効な値」を参照してください。
次に例を示します。
CREATE WORKLOAD GROUP wgSample
WITH
( MIN_PERCENTAGE_RESOURCE = 26 -- integer value
, REQUEST_MIN_RESOURCE_GRANT_PERCENT = 3.25 -- factor of 26 (guaranteed a minimum of 8 concurrency)
, CAP_PERCENTAGE_RESOURCE = 100 )
request_min_resource_grant_percent のガイドラインとして、リソース クラスに使用される値を検討してください。 次の表には、Gen2 のリソース割り当てが含まれています。
| リソース クラス | リソースの割合 |
|---|---|
| Smallrc | 3% |
| Mediumrc | 10% |
| Largerc | 22% |
| Xlargerc | 70% |
REQUEST_MAX_RESOURCE_GRANT_PERCENT = value
要求ごとに割り当てられるリソースの最大量を設定します。 このパラメーターでは、メモリ リソースのみが制御されます。
value は省略可能な 10 進数のパラメーターで、既定値は request_min_resource_grant_percent と同じ値です。
value は request_min_resource_grant_percent 以上である必要があります。 request_max_resource_grant_percent の値が request_min_resource_grant_percent より大きく、システム リソースが使用可能な場合は、追加のリソースが要求に割り当てられます。
IMPORTANCE = { LOW | BELOW_NORMAL | NORMAL | ABOVE_NORMAL | HIGH }
ワークロード グループに対する要求の既定の重要度を指定します。 重要度は次のいずれかで、NORMAL が既定値です。
- LOW
- BELOW_NORMAL
- NORMAL (既定値)
- ABOVE_NORMAL
- HIGH
ワークロード グループでの重要度セットは、ワークロード グループ内のすべての要求に対する既定の重要度です。 ユーザーは、分類子レベルで重要度を設定することもできます。これにより、ワークロード グループの重要度の設定をオーバーライドできます。 これにより、ワークロード グループ内の要求の重要度を区別して、予約されていないリソースにすばやくアクセスできるようになります。 ワークロード グループ全体で min_percentage_resource の合計が 100 未満の場合は、重要度に基づいて割り当てられた予約されていないリソースがあります。
QUERY_EXECUTION_TIMEOUT_SEC = value
クエリが取り消されるまでに実行できる最大時間を秒単位で指定します。
value は、0 または正の整数にする必要があります。 value の既定の設定が 0 の場合は、クエリはタイムアウトしません。クエリが実行状態になると、QUERY_EXECUTION_TIMEOUT_SEC がカウントされます。クエリがキューに入れられたときではありません。
解説
リソース クラスに対応するワークロード グループは、旧バージョンとの互換性のために自動的に作成されます。 これらのシステム定義のワークロード グループは削除できません。 さらに 8 つのユーザー定義のワークロード グループを作成できます。
ワークロード グループが 0 より大きい min_percentage_resource を使用して作成されている場合、CREATE WORKLOAD GROUP ステートメントは、ワークロード グループを作成するのに十分なリソースが確保されるまでキューに格納されます。
有効な値
min_percentage_resource、cap_percentage_resource、request_min_resource_grant_percent、request_max_resource_grant_percent の各パラメーターは、現在のサービス レベルおよびその他のワークロード グループの構成のコンテキストで調整された有効な値が含まれます。
サービス レベルに応じてクエリごとに必要最低限のリソースがあるため、request_min_resource_grant_percent パラメーターには有効な値が含まれます。 たとえば、最も低いサービス レベル (DW100c) では、要求ごとに最小 25% のリソースが必要です。 ワークロード グループが 3% の request_min_resource_grant_percent と request_max_resource_grant_percent で構成されている場合、インスタンスが開始されると、両方のパラメーターの有効な値が 25% に調整されます。 インスタンスが DW1000c にスケールアップされる場合、両方のパラメーターに対して構成された有効な値は 3% になります。そのサービス レベルでサポートされている最小値が 3% であるためです。 インスタンスが DW1000c よりも高くスケーリングされた場合、両方のパラメーターに対して構成された有効な値は 3% のままになります。 さまざまなサービス レベルの有効な値の詳細については、以下の表を参照してください。
| サービス レベル | REQUEST_MIN_RESOURCE_GRANT_PERCENT の有効な最小値 | 同時クエリの最大数 |
|---|---|---|
| DW100c | 25% | 4 |
| DW200c | 12.5% | 8 |
| DW300c | 8% | 12 |
| DW400c | 6.25% | 16 |
| DW500c | 5% | 20 |
| DW1000c | 3% | 32 |
| DW1500c | 3% | 32 |
| DW2000c | 2% | 48 |
| DW2500c | 2% | 48 |
| DW3000c | 1.5% | 64 |
| DW5000c | 1.5% | 64 |
| DW6000c | 0.75% | 128 |
| DW7500c | 0.75% | 128 |
| DW10000c | 0.75% | 128 |
| DW15000c | 0.75% | 128 |
| DW30000c | 0.75% | 128 |
min_percentage_resource パラメーターは有効な request_min_resource_grant_percent 以上である必要があります。
min_percentage_resource が有効な min_percentage_resource 未満に構成されたワークロード グループには、実行時にゼロに調整された値が含まれています。 この場合、min_percentage_resource 用に構成されたリソースは、すべてのワークロード グループとの間で共有できます。 たとえば、DW1000c で実行されている wgAdHoc が 10% であるワークロード グループ min_percentage_resource には、有効な 10% の min_percentage_resource が含まれます (DW1000c でサポートされている最小値は 3% です)。 DW100c の wgAdhoc には、有効な 0% の min_percentage_resource が含まれます。
wgAdhoc 用に構成された 10% は、すべてのワークロード グループとの間で共有されます。
cap_percentage_resource パラメーターにも有効な値があります。 ワークロード グループ wgAdhoc が 100% の cap_percentage_resource で構成されていて、別のワークロード グループ wgDashboards が 25% の min_percentage_resource で作成されている場合、cap_percentage_resource の有効な wgAdhoc は 75% になります。
ワークロード グループの実行時の値を理解する最も簡単な方法は、システム ビュー sys.dm_workload_management_workload_groups_stats に対してクエリを実行することです。
アクセス許可
CONTROL DATABASE 権限が必要です。