CREATE WORKLOAD GROUP (Transact-SQL)
製品を選択する
次の行で、興味のある製品の名前を選択すると、その製品の情報のみが表示されます。
* SQL Server *
SQL Server と SQL Managed Instance
リソース ガバナー ワークロード グループを作成し、そのワークロード グループをリソース ガバナー リソース プールに関連付けます。 Resource Governor は、SQL Server のすべてのエディションで使用できるわけではありません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2022 の各エディションとサポートされている機能」を参照してください。
構文
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
ワークロード グループのユーザー定義の名前。 group_name には英数字を最大 128 文字まで使用できます。SQL Server のインスタンス内で一意である必要があり、データベース識別子のルールに従っている必要があります。
IMPORTANCE = { LOW | MEDIUM | HIGH }
ワークロード グループでの要求の相対的な重要度を指定します。 重要度は次のいずれかで、MEDIUM が既定値です。
- LOW
- MEDIUM (既定)
- HIGH
Note
各重要度の設定は、計算用の数値として内部に格納されます。
IMPORTANCE は、リソース プールに対してローカルです。 同じリソース プール内の重要度が異なるワークロード グループは互いに影響しますが、別のリソース プールのワークロード グループには影響しません。
REQUEST_MAX_MEMORY_GRANT_PERCENT = value
1 つの要求にプールから割り当てられる最大メモリ量を指定します。 value は、MAX_MEMORY_PERCENT で指定したリソース プールのサイズが基準になります。 既定値は 25 です。
SQL Server 2017 (14.x) までは、value は整数で、許容範囲は 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 の場合は、無制限を示します。
Note
既定では、リソース ガバナーでは最大時間を超過しても、要求は継続されます。 ただし、イベントが生成されます。 詳細については、「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 は、0 または正の整数にする必要があります。 value の既定の設定である 0 の場合、クエリ コストに基づく内部の計算を使用して、最大時間が決定されます。
Note
メモリ許可のタイムアウトに達しても、常にクエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリ数が多すぎる場合だけです。 それ以外の場合、クエリは最小限のメモリ許可しか取得できないので、クエリのパフォーマンスが低下します。
MAX_DOP = value
並列クエリ実行に対する並列処理の最大限度 (MAXDOP) を指定します。 value は、0 または正の整数にする必要があります。 value の許容範囲は 0 から 64 です。 value の既定の設定は 0 で、グローバル設定が使用されます。
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 は、構成した後、許可メモリの不足時にのみ低くすることができます。 ワークロード グループの再構成は、許可メモリ キューで待機している間は表示されません。
注意
ワークロード グループの MAX_DOP では、並列処理の最大限度に対するサーバー構成と、MAXDOPデータベース スコープ構成がオーバーライドされます。
ヒント
これをクエリ レベルで行うには、MAXDOPクエリ ヒントを使用します。 ワークロード グループの MAX_DOP を超えない限り、クエリ ヒントとして並列処理の最大限度を設定することは有効です。 MAXDOP クエリ ヒントの値が Resource Governor を使用して構成されている値を超える場合は、SQL Server データベース エンジンでは Resource Governor の MAX_DOP 値が使用されます。 MAXDOP クエリ ヒントでは常に、並列処理の最大限度のサーバー構成がオーバーライドされます。
データベース レベルでこれを行うには、MAXDOPデータベース スコープ構成を使用します。
これをサーバー レベルで行うには、並列処理の最大限度 (MAXDOP)サーバー構成オプションを使用します。
GROUP_MAX_REQUESTS = value
ワークロード グループで実行を許可する同時要求の最大数を指定します。 value には、0 または正の整数を指定する必要があります。 value の既定の設定は 0 であり、これでは無制限の要求が許可されます。 同時要求の最大数に達した場合、そのグループのユーザーはログインできますが、同時要求数が指定した値を下回るまで待機状態になります。
USING { pool_name | "default" }
ワークロード グループを pool_name で識別されるユーザー定義のリソース プールに関連付けます。 実質的には、これによってワークロード グループがグループ リソースに配置されます。 pool_name を指定しない場合、または USING 引数を使用しない場合、ワークロード グループは事前に定義された Resource Governor の既定のプールに配置されます。
予約語の "default" を USING で使用する場合は、引用符 ("") または角かっこ ([]) で囲む必要があります。
Note
定義済みのワークロード グループおよびリソース プールではすべて、"default" などの小文字の名前が使用されています。 大文字と小文字を区別する照合順序を使用するサーバーでは、これを考慮する必要があります。 SQL_Latin1_General_CP1_CI_AS など、大文字と小文字を区別しない照合順序を使用するサーバーでは、"default" と "Default" が同じものと見なされます。
EXTERNAL external_pool_name | "default"
適用対象: SQL Server 2016 (13.x) 以降。
ワークロード グループには、外部リソース プールを指定できます。 ワークロード グループを定義し、2 つのプールに関連付けることができます。
- SQL Server のワークロードおよびクエリのリソース共有元
- 外部プロセス用の外部リソース プール 詳細については、「sp_execute_external_script (Transact-SQL)」を参照してください。
解説
REQUEST_MEMORY_GRANT_PERCENT が使用される場合、インデックスの作成では、パフォーマンスの改善のために最初に付与されたのよりも多くのワークスペース メモリを使用できます。 この特別な処理は、SQL Server の Resource Governor でサポートされています。 ただし、最初のメモリ許可も追加のメモリ許可も、リソース プール設定およびワークロード グループ設定によって制限されます。
MAX_DOP の制限は、タスクごとに設定されます。 この設定は、要求ごとまたはクエリ制限ごとではありません。 つまり、並列クエリ実行中に、1 つの要求で、スケジューラに割り当てられてた複数のタスクを生成することができます。 詳細については、「スレッドおよびタスクのアーキテクチャ ガイド」を参照してください。
MAX_DOP が使用されていて、コンパイル時にクエリが直列としてマークされている場合は、ワークロード グループまたはサーバー構成の設定にかかわらず、実行時に並列に変更することはできません。 構成後の MAX_DOP は、メモリの不足時にのみ低くすることができます。 ワークロード グループの再構成は、許可メモリ キューで待機している間は表示されません。
パーティション テーブルのインデックス作成
非固定パーティション テーブルのインデックス作成によって消費されるメモリは、含まれるパーティションの数に比例します。 必要なメモリの合計が、Resource Governor のワークロード グループの設定によって課せられているクエリごとの制限 REQUEST_MAX_MEMORY_GRANT_PERCENT を超えると、このインデックス作成の実行に失敗します。 "default" ワークロード グループでは、クエリごとの制限を超えてもクエリの開始に必要な最低限のメモリを使用できるようになっているので、そのようなクエリを実行するのに十分な量のメモリが "default" リソース プールに対して構成されていれば、同じインデックス作成を "default" ワークロード グループで実行できる可能性があります。
アクセス許可
CONTROL SERVER 権限が必要です。
例
Resource Governor の既定の設定を使用し、Resource Governor の既定のプールに配置される、newReports という名前のワークロード グループを作成します。 この例では default プールを指定していますが、必須ではありません。
CREATE WORKLOAD GROUP newReports
WITH
(REQUEST_MAX_MEMORY_GRANT_PERCENT = 2.5
, REQUEST_MAX_CPU_TIME_SEC = 100
, MAX_DOP = 4)
USING "default" ;
GO
関連項目
* SQL Managed Instance *
SQL Server と SQL Managed Instance
リソース ガバナー ワークロード グループを作成し、そのワークロード グループをリソース ガバナー リソース プールに関連付けます。 Resource Governor は、SQL Server のすべてのエディションで使用できるわけではありません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2022 の各エディションとサポートされている機能」を参照してください。
構文
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
ワークロード グループのユーザー定義の名前。 group_name には英数字を最大 128 文字まで使用できます。SQL Server のインスタンス内で一意である必要があり、データベース識別子のルールに従っている必要があります。
IMPORTANCE = { LOW | MEDIUM | HIGH }
ワークロード グループでの要求の相対的な重要度を指定します。 重要度は次のいずれかで、MEDIUM が既定値です。
- LOW
- MEDIUM (既定)
- HIGH
Note
各重要度の設定は、計算用の数値として内部に格納されます。
IMPORTANCE は、リソース プールに対してローカルです。 同じリソース プール内の重要度が異なるワークロード グループは互いに影響しますが、別のリソース プールのワークロード グループには影響しません。
REQUEST_MAX_MEMORY_GRANT_PERCENT = value
1 つの要求にプールから割り当てられる最大メモリ量を指定します。 value は、MAX_MEMORY_PERCENT で指定したリソース プールのサイズが基準になります。 既定値は 25 です。
SQL Server 2017 (14.x) までは、value は整数で、許容範囲は 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 の場合は、無制限を示します。
Note
既定では、リソース ガバナーでは最大時間を超過しても、要求は継続されます。 ただし、イベントが生成されます。 詳細については、「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 は、0 または正の整数にする必要があります。 value の既定の設定である 0 の場合、クエリ コストに基づく内部の計算を使用して、最大時間が決定されます。
Note
メモリ許可のタイムアウトに達しても、常にクエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリ数が多すぎる場合だけです。 それ以外の場合、クエリは最小限のメモリ許可しか取得できないので、クエリのパフォーマンスが低下します。
MAX_DOP = value
並列クエリ実行に対する並列処理の最大限度 (MAXDOP) を指定します。 value は、0 または正の整数にする必要があります。 value の許容範囲は 0 から 64 です。 value の既定の設定は 0 で、グローバル設定が使用されます。
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 は、構成した後、許可メモリの不足時にのみ低くすることができます。 ワークロード グループの再構成は、許可メモリ キューで待機している間は表示されません。
注意
ワークロード グループの MAX_DOP では、並列処理の最大限度に対するサーバー構成と、MAXDOPデータベース スコープ構成がオーバーライドされます。
ヒント
これをクエリ レベルで行うには、MAXDOPクエリ ヒントを使用します。 ワークロード グループの MAX_DOP を超えない限り、クエリ ヒントとして並列処理の最大限度を設定することは有効です。 MAXDOP クエリ ヒントの値が Resource Governor を使用して構成されている値を超える場合は、SQL Server データベース エンジンでは Resource Governor の MAX_DOP 値が使用されます。 MAXDOP クエリ ヒントでは常に、並列処理の最大限度のサーバー構成がオーバーライドされます。
データベース レベルでこれを行うには、MAXDOPデータベース スコープ構成を使用します。
これをサーバー レベルで行うには、並列処理の最大限度 (MAXDOP)サーバー構成オプションを使用します。
GROUP_MAX_REQUESTS = value
ワークロード グループで実行を許可する同時要求の最大数を指定します。 value には、0 または正の整数を指定する必要があります。 value の既定の設定は 0 であり、これでは無制限の要求が許可されます。 同時要求の最大数に達した場合、そのグループのユーザーはログインできますが、同時要求数が指定した値を下回るまで待機状態になります。
USING { pool_name | "default" }
ワークロード グループを pool_name で識別されるユーザー定義のリソース プールに関連付けます。 実質的には、これによってワークロード グループがグループ リソースに配置されます。 pool_name を指定しない場合、または USING 引数を使用しない場合、ワークロード グループは事前に定義された Resource Governor の既定のプールに配置されます。
予約語の "default" を USING で使用する場合は、引用符 ("") または角かっこ ([]) で囲む必要があります。
Note
定義済みのワークロード グループおよびリソース プールではすべて、"default" などの小文字の名前が使用されています。 大文字と小文字を区別する照合順序を使用するサーバーでは、これを考慮する必要があります。 SQL_Latin1_General_CP1_CI_AS など、大文字と小文字を区別しない照合順序を使用するサーバーでは、"default" と "Default" が同じものと見なされます。
EXTERNAL external_pool_name | "default"
適用対象: SQL Server 2016 (13.x) 以降。
ワークロード グループには、外部リソース プールを指定できます。 ワークロード グループを定義し、2 つのプールに関連付けることができます。
- SQL Server のワークロードおよびクエリのリソース共有元
- 外部プロセス用の外部リソース プール 詳細については、「sp_execute_external_script (Transact-SQL)」を参照してください。
解説
REQUEST_MEMORY_GRANT_PERCENT が使用される場合、インデックスの作成では、パフォーマンスの改善のために最初に付与されたのよりも多くのワークスペース メモリを使用できます。 この特別な処理は、SQL Server の Resource Governor でサポートされています。 ただし、最初のメモリ許可も追加のメモリ許可も、リソース プール設定およびワークロード グループ設定によって制限されます。
MAX_DOP の制限は、タスクごとに設定されます。 この設定は、要求ごとまたはクエリ制限ごとではありません。 つまり、並列クエリ実行中に、1 つの要求で、スケジューラに割り当てられてた複数のタスクを生成することができます。 詳細については、「スレッドおよびタスクのアーキテクチャ ガイド」を参照してください。
MAX_DOP が使用されていて、コンパイル時にクエリが直列としてマークされている場合は、ワークロード グループまたはサーバー構成の設定にかかわらず、実行時に並列に変更することはできません。 構成後の MAX_DOP は、メモリの不足時にのみ低くすることができます。 ワークロード グループの再構成は、許可メモリ キューで待機している間は表示されません。
パーティション テーブルのインデックス作成
非固定パーティション テーブルのインデックス作成によって消費されるメモリは、含まれるパーティションの数に比例します。 必要なメモリの合計が、Resource Governor のワークロード グループの設定によって課せられているクエリごとの制限 REQUEST_MAX_MEMORY_GRANT_PERCENT を超えると、このインデックス作成の実行に失敗します。 "default" ワークロード グループでは、クエリごとの制限を超えてもクエリの開始に必要な最低限のメモリを使用できるようになっているので、そのようなクエリを実行するのに十分な量のメモリが "default" リソース プールに対して構成されていれば、同じインデックス作成を "default" ワークロード グループで実行できる可能性があります。
アクセス許可
CONTROL SERVER 権限が必要です。
例
Resource Governor の既定の設定を使用し、Resource Governor の既定のプールに配置される、newReports という名前のワークロード グループを作成します。 この例では default プールを指定していますが、必須ではありません。
CREATE WORKLOAD GROUP newReports
WITH
(REQUEST_MAX_MEMORY_GRANT_PERCENT = 2.5
, REQUEST_MAX_CPU_TIME_SEC = 100
, MAX_DOP = 4)
USING "default" ;
GO
関連項目
* 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 で実行されている min_percentage_resource が 10% であるワークロード グループ wgAdHoc には、有効な 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 で作成されている場合、wgAdhoc の有効な cap_percentage_resource は 75% になります。
ワークロード グループの実行時の値を理解する最も簡単な方法は、システム ビュー sys.dm_workload_management_workload_groups_stats に対してクエリを実行することです。
アクセス許可
CONTROL DATABASE 権限が必要です。
関連項目
フィードバック
近日公開予定: 2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub イシューを段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、以下を参照してください: https://aka.ms/ContentUserFeedback。
フィードバックの送信と表示