次の方法で共有


ALTER WORKLOAD GROUP (Transact-SQL)

既存のリソース ガバナー ワークロード グループの構成を変更します。必要に応じて、そのワークロード グループをリソース ガバナー リソース プールに割り当てることもできます。

トピック リンク アイコン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"
    既存のユーザー定義のワークロード グループの名前か、SQL Server 2008 のインストール時に作成されるリソース ガバナーの既定のワークロード グループを指定します。

    オプションの "default" を ALTER WORKLOAD GROUP で使用する場合は、システム予約語の DEFAULT と競合しないように引用符 ("") または角かっこ ([]) で囲む必要があります。詳細については、「区切られた識別子 (データベース エンジン)」を参照してください。

    注意注意

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

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

    • LOW

    • MEDIUM (既定)

    • HIGH

    注意注意

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

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

  • REQUEST_MAX_MEMORY_GRANT_PERCENT =value
    1 つの要求にプールから割り当てられる最大メモリ量を指定します。このパーセンテージは、MAX_MEMORY_PERCENT で指定したリソース プールのサイズが基準になります。

    注意注意

    指定した量だけがクエリ実行許可メモリに割り当てられます。

    value には、0 または正の整数を指定する必要があります。value の許容範囲は 0 ~ 100 です。value の既定の設定は 25 です。

    次の点に注意してください。

    • value を 0 に設定すると、ユーザー定義のワークロード グループでは SORT と HASH JOIN 操作を含むクエリが実行されなくなります。

    • 同時に他のクエリが実行されているとサーバーが空きメモリを十分に確保できない可能性があるため、value を 70 より大きな値に設定することはお勧めしません。空きメモリを十分に確保できないと、クエリの時間切れエラー 8645 が発生します。

    注意注意

    クエリのメモリ要求がこのパラメーターによって指定されている制限を超えると、サーバーは次のように対応します。

    ユーザー定義のワークロード グループでは、サーバーはクエリの並列処理の次数を下げます。これはメモリ要求が制限より低くなるか、並列処理の次数が 1 になるまで続きます。それでもクエリのメモリ要求が制限を超える場合は、エラー 8657 が発生します。

    内部および既定のワークロード グループでは、そのクエリに必要なメモリの確保がサーバーによって許可されます。

    サーバーに十分な物理メモリがない場合は、どちらの場合も時間切れエラー 8645 が発生する可能性があります。

    リソース ガバナーのエラー メッセージの詳細については、「リソース ガバナのトラブルシューティング」を参照してください。

  • REQUEST_MAX_CPU_TIME_SEC =value
    クエリが失敗する前に、リソースが使用可能になるのをそのクエリが待機できる最大時間を秒単位で指定します。value には、0 または正の整数を指定する必要があります。value の既定の設定は 0 で、クエリ コストに基づく内部の計算を使用して最大時間を決定します。

    注意注意

    リソース ガバナーでは、最大時間を超過しても、要求は継続されます。ただし、イベントが生成されます。詳細については、「CPU Threshold Exceeded イベント クラス」を参照してください。

  • REQUEST_MEMORY_GRANT_TIMEOUT_SEC =value
    メモリ許可 (作業バッファー メモリ) が使用可能になるのをクエリが待機できる最大時間を秒単位で指定します。

    注意注意

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

    value は正の整数にする必要があります。value の既定の設定は 0 で、クエリ コストに基づく内部の計算を使用して最大時間を決定します。

  • MAX_DOP =value
    並列要求の最大 DOP (並列処理の次数) を指定します。value には、0 または正の整数を指定する必要があります。value の許容範囲は 0 ~ 64 です。value の既定の設定である 0 を指定すると、サーバーで並列処理の最大限度が選択されます。これが既定値であり、推奨設定です。value が 0 の場合、サーバーで使用される最大値は 64 です。MAX_DOP は次のように処理されます。

    • ワークロード グループの MAX_DOP を超えない限り、クエリ ヒントとしての MAXDOP が有効です。

    • クエリ ヒントとしての MAXDOP は、sp_configure 'max degree of parallelism' よりも常に優先されます。

    • ワークロード グループの MAX_DOP は、sp_configure 'max degree of parallelism' よりも優先されます。

    • コンパイル時にクエリが直列 (MAX_DOP = 1) としてマークされている場合は、ワークロード グループまたは sp_configure の設定には関係なく、実行時に並列に戻すことはできません。

    DOP は、構成後、許可メモリの不足時にのみ下げることができます。ワークロード グループの再構成は、許可メモリ キューで待機している間は表示されません。

  • GROUP_MAX_REQUESTS =value
    ワークロード グループで実行を許可する同時要求の最大数を指定します。value には、0 または正の整数を指定する必要があります。value の既定の設定は 0 で、無制限に要求が許可されます。

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

    オプションの "default" を ALTER WORKLOAD GROUP で使用する場合は、システム予約語の DEFAULT と競合しないように引用符 ("") または角かっこ ([]) で囲む必要があります。詳細については、「区切られた識別子 (データベース エンジン)」を参照してください。

    注意注意

    オプションの "default" は、大文字と小文字が区別されます。

説明

ALTER WORKLOAD GROUP は、既定のグループに対して使用できます。

ワークロード グループの構成の変更は、ALTER RESOURCE GOVERNOR RECONFIGURE を実行しないと有効になりません。

DDL ステートメントを実行する場合、リソース ガバナーの状態について詳しく理解しておくことをお勧めします。詳細については、「リソース ガバナの状態」を参照してください。

REQUEST_MEMORY_GRANT_PERCENT: SQL Server 2005 のインデックス作成では、パフォーマンスを向上させるため、最初に許可されたメモリ量を超えるワークスペース メモリの使用が許可されます。この特別な処理は、SQL Server 2008 のリソース ガバナーでサポートされています。ただし、最初のメモリ許可も追加のメモリ許可も、リソース プール設定およびワークロード グループ設定によって制限されます。

パーティション テーブルのインデックス作成

非固定パーティション テーブルのインデックス作成によって消費されるメモリは、含まれるパーティションの数に比例します。必要なメモリの合計が、リソース ガバナーのワークロード グループの設定によって課せられているクエリごとの制限 (REQUEST_MAX_MEMORY_GRANT_PERCENT) を超えると、インデックス作成の実行に失敗します。"default" ワークロード グループでは、SQL Server 2005 との互換性を確保するために、クエリごとの制限を超えてクエリの開始に必要な最低限のメモリを使用できるため、"default" リソース プールでそのようなクエリを実行できるだけの十分な量のメモリが構成されていれば、同じインデックス作成を "default" ワークロード グループで実行できる場合があります。

権限

CONTROL SERVER 権限が必要です。

次の例は、既定のグループの要求の重要度を MEDIUM から LOW に変更する方法を示しています。

ALTER WORKLOAD GROUP "default"
WITH (IMPORTANCE = LOW)
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

次の例は、ワークロード グループを現在のプールから既定のプールに移動する方法を示しています。

ALTER WORKLOAD GROUP adHoc
USING [default];
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

変更履歴

変更内容

引数 REQUEST_MAX_MEMORY_GRANT_PERCENT の説明に「次の点に注意してください」以下の情報を追加しました。