CREATE WORKLOAD GROUP (Transact-SQL)

製品を選択する

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

* SQL Server *  

 

SQL Server と SQL Managed Instance

リソース ガバナー ワークロード グループを作成し、そのワークロード グループをリソース ガバナー リソース プールに関連付けます。 Resource Governor は、Microsoft Sql Server のすべてのエディションで使用できるわけではありません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2016 の各エディションがサポートする機能」を参照してください。

transact-sql SQL 構文表記規則

構文

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 のインスタンス内で一意である必要があり、識別子の規則に従っている必要があります。

重要度 = {LOW | |HIGH} は、ワークロードグループ内の要求の相対的な重要度を指定します。 重要度は次のいずれかで、MEDIUM が既定値です。

  • LOW
  • MEDIUM (既定)
  • HIGH

Note

各重要度の設定は、内部に計算用の数値として格納されます。

IMPORTANCE は、リソース プールに対してローカルです。同じリソース プール内の異なる重要度のワークロード グループは互いに影響しますが、別のリソース プールのワークロード グループには影響しません。

REQUEST_MAX_MEMORY_GRANT_PERCENT = は、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 = は、要求が使用できる最大 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 は、0 または正の整数にする必要があります。 value の既定の設定である 0 の場合、クエリ コストに基づく内部の計算を使用して、最大時間が決定されます。

Note

メモリ許可のタイムアウトに達しても、常にクエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリ数が多すぎる場合だけです。 それ以外の場合、クエリは最小限のメモリ許可しか取得できないので、クエリのパフォーマンスが低下します。

MAX_DOP = 並列クエリ実行の並列処理の最大限度 (MAXDOP)を指定します。 value は、0 または正の整数にする必要があります。 value の許容範囲は 0 から 64 です。 value の既定の設定は 0 で、グローバル設定が使用されます。 MAX_DOP は次のように処理されます。

Note

ワークロード グループの MAX_DOP では、並列処理の最大限度に対するサーバー構成と、MAXDOPデータベース スコープ構成がオーバーライドされます。

ヒント

これをクエリ レベルで行うには、MAXDOPクエリ ヒントを使用します。 ワークロード グループの MAX_DOP を超えない限り、クエリ ヒントとして並列処理の最大限度を設定することは有効です。 MAXDOP クエリヒントの値が、Resource Governor を使用して構成された値を超えた場合、SQL Server データベースエンジンでは Resource Governor MAX_DOP 値が使用されます。 MAXDOP クエリ ヒントでは常に、並列処理の最大限度のサーバー構成がオーバーライドされます。

データベース レベルでこれを行うには、MAXDOPデータベース スコープ構成を使用します。

これをサーバー レベルで行うには、並列処理の最大限度 (MAXDOP)サーバー構成オプションを使用します。

GROUP_MAX_REQUESTS = ワークロードグループで実行を許可する同時要求の最大数を指定します。 value には、0 または正の整数を指定する必要があります。 value の既定の設定は 0 であり、これでは無制限の要求が許可されます。 同時要求の最大数に達した場合、そのグループのユーザーはログインできますが、同時要求数が指定した値を下回るまで待機状態になります。

{ Pool_name"default" } を使用すると、ワークロードグループがpool_nameによって識別されるユーザー定義のリソースプールに関連付けられます。 実質的には、これによってワークロード グループがグループ リソースに配置されます。 pool_name を指定していない場合、または USING 引数を使用していない場合、ワークロード グループは事前に定義されたリソース ガバナーの既定のプールに配置されます。

予約語の "default" を USING で使用する場合は、引用符 ("") または角かっこ ([]) で囲む必要があります。

Note

定義済みのワークロード グループおよびリソース プールではすべて、"default" などの小文字の名前が使用されています。 大文字と小文字を区別する照合順序を使用するサーバーでは、これを考慮する必要があります。 SQL_Latin1_General_CP1_CI_AS など、大文字と小文字を区別しない照合順序を使用するサーバーでは、"default" と "Default" が同じものと見なされます。

外部 external_pool_name |"default"
は、SQL Server (SQL Server 2016 (13. x) 以降)
れます。

ワークロード グループには、外部リソース プールを指定できます。 ワークロード グループを定義し、2 つのプールに関連付けることができます。

  • SQL Server のワークロードとクエリのためのリソースプール
  • 外部プロセス用の外部リソース プール 詳細については、「 sp_execute_external_script (SQL transact-sql)」を参照してください。

解説

REQUEST_MEMORY_GRANT_PERCENT が使用される場合、インデックスの作成では、パフォーマンスの改善のために最初に付与されたのよりも多くのワークスペース メモリを使用できます。 この特別な処理は、SQL Server の Resource Governor でサポートされています。 ただし、最初のメモリ許可も追加のメモリ許可も、リソース プール設定およびワークロード グループ設定によって制限されます。

MAX_DOP制限は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は、MicrosoftSQL Server のすべてのエディションでは使用できません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2016 の各エディションがサポートする機能」を参照してください。

Transact-SQL構文規則

構文

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 = プールから 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 = 要求で使用できる最大 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 は、0 または正の整数にする必要があります。 value の既定の設定である 0 の場合、クエリ コストに基づく内部の計算を使用して、最大時間が決定されます。

Note

メモリ許可のタイムアウトに達しても、常にクエリが失敗するとは限りません。 クエリが失敗するのは、同時実行クエリ数が多すぎる場合だけです。 それ以外の場合、クエリは最小限のメモリ許可しか取得できないので、クエリのパフォーマンスが低下します。

MAX_DOP = 並列クエリ実行の並列処理の最大次 数 (MAXDOP) を指定します。 value は、0 または正の整数にする必要があります。 value の許容範囲は 0 から 64 です。 value の既定の設定は 0 で、グローバル設定が使用されます。 MAX_DOP は次のように処理されます。

Note

ワークロード グループの MAX_DOP では、並列処理の最大限度に対するサーバー構成と、MAXDOPデータベース スコープ構成がオーバーライドされます。

ヒント

これをクエリ レベルで行うには、MAXDOPクエリ ヒントを使用します。 ワークロード グループの MAX_DOP を超えない限り、クエリ ヒントとして並列処理の最大限度を設定することは有効です。 MAXDOP クエリ ヒントの値が Resource Governor を使用して構成された値を超える場合、SQL Server データベース エンジンは Resource Governor 値を使用MAX_DOPします。 MAXDOP クエリ ヒントでは常に、並列処理の最大限度のサーバー構成がオーバーライドされます。

データベース レベルでこれを行うには、MAXDOPデータベース スコープ構成を使用します。

これをサーバー レベルで行うには、並列処理の最大限度 (MAXDOP)サーバー構成オプションを使用します。

GROUP_MAX_REQUESTS = ワークロード グループで実行できる同時要求の最大数を指定します。 value には、0 または正の整数を指定する必要があります。 value の既定の設定は 0 であり、これでは無制限の要求が許可されます。 同時要求の最大数に達した場合、そのグループのユーザーはログインできますが、同時要求数が指定した値を下回るまで待機状態になります。

USING { pool_name"default" } ワークロード グループを、ワークロード グループによって識別されるユーザー定義リソース プールpool_name。 実質的には、これによってワークロード グループがグループ リソースに配置されます。 pool_name を指定していない場合、または USING 引数を使用していない場合、ワークロード グループは事前に定義されたリソース ガバナーの既定のプールに配置されます。

予約語の "default" を USING で使用する場合は、引用符 ("") または角かっこ ([]) で囲む必要があります。

Note

定義済みのワークロード グループおよびリソース プールではすべて、"default" などの小文字の名前が使用されています。 大文字と小文字を区別する照合順序を使用するサーバーでは、これを考慮する必要があります。 SQL_Latin1_General_CP1_CI_AS など、大文字と小文字を区別しない照合順序を使用するサーバーでは、"default" と "Default" が同じものと見なされます。

EXTERNAL external_pool_name |"default"
: SQL Server (SQL Server 2016 (13.x) から)。

ワークロード グループには、外部リソース プールを指定できます。 ワークロード グループを定義し、2 つのプールに関連付けることができます。

解説

REQUEST_MEMORY_GRANT_PERCENT が使用される場合、インデックスの作成では、パフォーマンスの改善のために最初に付与されたのよりも多くのワークスペース メモリを使用できます。 この特別な処理は、SQL Server の Resource Governor でサポートされています。 ただし、最初のメモリ許可も追加のメモリ許可も、リソース プール設定およびワークロード グループ設定によって制限されます。

MAX_DOP制限は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
解析
 

 

Azure Synapse Analytics

ワークロード グループを作成します。 ワークロード グループは、一連の要求用のコンテナーであり、システムでワークロード管理を構成する方法の基礎となります。 ワークロード グループでは、ワークロードの分離のためのリソースの予約、リソースの格納、要求ごとのリソースの定義、実行ルールへの準拠を行う機能が提供されます。 ステートメントが完了すると、設定が有効になります。

transact-sql SQL 構文表記規則

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 は 0 から 100 の範囲の整数です。 すべてのワークロード グループでの min_percentage_resource の合計は、100 を超えることはできません。 min_percentage_resource の値を cap_percentage_resource より大きくすることはできません。 サービス レベルごとに有効な最小値があります。 詳細については、「有効な値」を参照してください。

CAP_PERCENTAGE_RESOURCE = 値 ワークロードグループ内のすべての要求に対するリソースの最大使用率を指定します。 このパラメーターでは、CPU とメモリ リソースのいずれも制限されます。 value に対して許可される整数の範囲は 1 から 100 です。 cap_percentage_resource の値は、min_percentage_resource よりも大きくする必要があります。 cap_percentage_resource の有効な値は、他のワークロード グループで min_percentage_resource が 0 より大きく構成されている場合に減らすことができます。

REQUEST_MIN_RESOURCE_GRANT_PERCENT = 値 は、要求ごとに割り当てられるリソースの最小量を設定します。 このパラメーターでは、メモリ リソースのみが制御されます。 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 は省略可能な 10 進数のパラメーターで、既定値は request_min_resource_grant_percent と同じ値です。 value は request_min_resource_grant_percent 以上である必要があります。 request_max_resource_grant_percent の値が request_min_resource_grant_percent より大きく、システム リソースが使用可能な場合は、追加のリソースが要求に割り当てられます。

重要度 = {LOW |BELOW_NORMAL |NORMAL |ABOVE_NORMAL |高い
ワークロード グループに対する要求の既定の重要度を指定します。 重要度は次のいずれかで、NORMAL が既定値です。

  • LOW
  • BELOW_NORMAL
  • NORMAL (既定値)
  • ABOVE_NORMAL
  • HIGH

ワークロード グループでの重要度セットは、ワークロード グループ内のすべての要求に対する既定の重要度です。 ユーザーは、分類子レベルで重要度を設定することもできます。これにより、ワークロード グループの重要度の設定をオーバーライドできます。 これにより、ワークロード グループ内の要求の重要度を区別して、予約されていないリソースにすばやくアクセスできるようになります。 ワークロード グループ全体で min_percentage_resource の合計が 100 未満の場合は、重要度に基づいて割り当てられた予約されていないリソースがあります。

QUERY_EXECUTION_TIMEOUT_SEC = 値
クエリが取り消されるまでに実行できる最大時間を秒単位で指定します。 value は、0 または正の整数にする必要があります。 value の既定の設定が 0 の場合は、クエリはタイムアウトしません。クエリが実行状態になると、QUERY_EXECUTION_TIMEOUT_SEC がカウントされます。クエリがキューに入れられたときではありません。

解説

リソース クラスに対応するワークロード グループは、旧バージョンとの互換性のために自動的に作成されます。 これらのシステム定義のワークロード グループは削除できません。 さらに 8 つのユーザー定義のワークロード グループを作成できます。

ワークロード グループが 0 より大きい min_percentage_resource を使用して作成されている場合、CREATE WORKLOAD GROUP ステートメントは、ワークロード グループを作成するのに十分なリソースが確保されるまでキューに格納されます。

有効な値

min_percentage_resourcecap_percentage_resourcerequest_min_resource_grant_percentrequest_max_resource_grant_percent の各パラメーターは、現在のサービス レベルおよびその他のワークロード グループの構成のコンテキストで調整された有効な値が含まれます。

サービス レベルに応じてクエリごとに必要最低限のリソースがあるため、request_min_resource_grant_percent パラメーターには有効な値が含まれます。 たとえば、最も低いサービス レベル (DW100c) では、要求ごとに最小 25% のリソースが必要です。 ワークロード グループが 3% の request_min_resource_grant_percentrequest_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 権限が必要です。

関連項目