次の方法で共有

CREATE WORKLOAD GROUP (Transact-SQL)

  • [アーティクル]

製品を選択する

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

* SQL Server *  

SQL Managed Instance

Azure Synapse
分析

 

SQL Server と SQL Managed Instance

リソース ガバナー ワークロード グループを作成し、ワークロード グループをリソース ガバナー リソース プールに関連付けます。

リソース ガバナーは、SQL Server のすべてのエディションで使用できるわけではありません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2022 の各エディションとサポートされている機能」を参照してください。

Note

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

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 文字で、データベース エンジンのインスタンス内で一意である必要があり、データベース識別子の規則に従う必要があります。

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 Threshold Exceeded イベント クラス」を参照してください。

SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) CU3 以降、トレース フラグ 2422を使用すると、リソース ガバナーは最大 CPU 時間を超えると要求を中止します。

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 アクセス許可が必要です。

例

default リソース プールに newReports という名前のワークロード グループを作成し、最大メモリ許可、要求の最大 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];

関連コンテンツ

SQL Server

* SQL Managed Instance *  

Azure Synapse
分析

 

SQL Server と SQL Managed Instance

リソース ガバナー ワークロード グループを作成し、ワークロード グループをリソース ガバナー リソース プールに関連付けます。

リソース ガバナーは、SQL Server のすべてのエディションで使用できるわけではありません。 SQL Server の各エディションでサポートされる機能の一覧については、「SQL Server 2022 の各エディションとサポートされている機能」を参照してください。

Note

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

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 文字で、データベース エンジンのインスタンス内で一意である必要があり、データベース識別子の規則に従う必要があります。

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 Threshold Exceeded イベント クラス」を参照してください。

SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) CU3 以降、トレース フラグ 2422を使用すると、リソース ガバナーは最大 CPU 時間を超えると要求を中止します。

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 アクセス許可が必要です。

例

default リソース プールに newReports という名前のワークロード グループを作成し、最大メモリ許可、要求の最大 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];

関連コンテンツ

SQL Server

SQL Managed Instance

* Azure Synapse
Analytics *  

 

Azure Synapse Analytics

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

Transact-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
他のワークロード グループと共有されない、このワークロード グループに対して保証される最小リソース割り当てを指定します。 このパラメーターでは、メモリ リソースのみが制御されます。 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 権限が必要です。

関連項目