リソース ガバナーの概念

リソース プール

リソース プール (プール) は、サーバーの物理リソースを表します。プールは、SQL Server インスタンス内部の仮想 SQL Server インスタンスと考えることができます。

プールは 2 つの部分で構成されます。1 つは他のプールと重複しない部分であり、最小限のリソース予約をサポートします。もう 1 つは他のプールと共有される部分であり、最大限のリソース消費をサポートします。このリリースのリソース ガバナーでは、各リソースに次のいずれかを指定することで、プール リソースが設定されます。

• CPU の最小値または最大値

• メモリの最小値または最大値

最小値と最大値はそれぞれ、上記の各リソースについて、プールで最低限保証されるリソースの可用性およびプールの最大サイズを表します。

すべてのプールの最小値の合計が、サーバー リソースの 100% を超えないようにする必要があります。最大値は、最小値 ～ 100% (両方を含む) の間で設定できます。

プールにゼロ以外の最小値が定義されている場合は、設定されているプールの最大値か、他のプールの最小値の合計を 100% から差し引いた値のうち、小さい方になるように、有効な最大値が再調整されます。

次の表は、前述の概念を説明しています。表に示されているのは、内部プール、既定のプール、および 2 つのユーザー定義プールの設定です。有効な最大 % および共有 % の計算には、次の式が使用されます。

• min(X,Y) は、X と Y の小さい方の値を意味します。

• sum(X) はすべてのプールの X 値の合計を意味します。

• 共有 % の合計 = 100 - sum(最小 %)。

• 有効な最大 % = min(X,Y)。

• 共有 % = 有効な最大 % - 最小 %。

前のテーブルを例として、別のプールが作成されたときに行われる調整について説明します。作成するのはプール 3 で、その最小 % の設定は 5 です。

プールの共有部分は、使用可能なリソースの行き先を示すために使用されます。ただし、リソースが消費されると、共有部分は指定のプールに移動し、共有されません。これにより、指定のプールに要求がなく、かつそのプールに対して構成されたリソースを他のプールのために解放できる場合は、リソース使用率が向上する可能性があります。

プール構成の極端なケースを次に示します。

• すべてのプールで最小値が定義され、その合計がサーバー リソースの 100% を表しているケース。この場合、有効な最大値は最小値と等しくなります。このとき、いずれかのプール内でサーバー リソースが消費されているかどうかにかかわらず、リソースを重複しない断片に分割した場合と同等の状態になります。

• すべてのプールの最小値がゼロであるケース。すべてのプールが使用可能なリソースの確保を求めて競合し、それぞれの最終的なサイズが各プールのリソース消費に基づいて決まります。ポリシーなどその他の要因も、最終的なプール サイズの決定に影響します。

リソース ガバナーでは、内部プールと既定のプールの 2 つのリソース プールが事前に定義されます。

内部プール

内部プールは、SQL Server 自体が消費するリソースを表します。このプールは、常に内部グループのみを含んでおり、一切変更できません。内部プールによるリソースの消費は制限されません。このプール内のワークロードはサーバーの機能に不可欠と見なされ、内部プールが他のプールを圧迫して他のプールに設定されている制限に違反することになっても、リソース ガバナーはこれを許可します。

注
内部プールおよび内部グループのリソース使用量は、全体的なリソース使用量から差し引かれません。パーセンテージは、使用可能なリソース全体から計算されます。

既定のプール

既定のプールは、事前に定義される最初のユーザー プールです。構成が行われる前の既定のプールには、既定のグループのみが含まれています。既定のプールは作成または削除できませんが、変更することは可能です。既定のプールには、既定のグループ以外にユーザー定義グループを含めることができます。

注
既定のグループは変更できますが、既定のプールから移動することはできません。

ユーザー定義のリソース プール

リソース ガバナーには、リソース プールを作成、変更、および削除するための DDL ステートメントが用意されています。詳細については、「リソース ガバナー DDL とシステム ビュー」を参照してください。

ワークロード グループ

ワークロード グループは、分類基準を適用して類似すると判断されたセッション要求のコンテナーとして機能します。ワークロード グループによって、リソース消費の全体的な監視、およびグループ内のすべての要求に対する一貫したポリシーの適用が可能となります。グループは、そのメンバーに対するポリシーを定義します。

注
ユーザー定義のワークロード グループは、リソース プール間で移動できます。

リソース ガバナーでは、内部グループと既定のグループの 2 つのワークロード グループが事前に定義されます。内部グループとして分類されたグループは変更できませんが、監視することはできます。次の条件に当てはまる場合は、要求が既定のグループへと分類されます。

• 要求を分類する基準がない。

• 要求を存在しないグループに分類しようとした。

• 一般的な分類エラーが発生した。

リソース ガバナーには、ワークロード グループを作成、変更、および削除するための DDL ステートメントも用意されています。詳細については、「リソース ガバナー DDL とシステム ビュー」を参照してください。

分類

リソース ガバナーでは、着信セッションの分類がサポートされます。分類は、関数に含まれているユーザーが記述した一連の基準に基づいて行われます。この関数ロジックの結果を使用して、リソース ガバナーは、セッションを既存のワークロード グループに分類します。

注
内部ワークロード グループには、内部だけで使用される要求が格納されます。要求のルーティングに使用される基準は変更できません。また、要求を内部ワークロード グループに分類することもできません。

着信セッションをワークロード グループに割り当てるロジックを含んだスカラー関数を作成することができます。この関数を使用する前に、次の操作を完了する必要があります。

• ALTER RESOURCE GOVERNOR ステートメントを使用して、関数を作成し、登録します。詳細については、「ALTER RESOURCE GOVERNOR (Transact-SQL)」を参照してください。

• RECONFIGURE パラメーターを指定した ALTER RESOURCE GOVERNOR ステートメントを使用して、リソース ガバナーの構成を更新します。

関数を作成して構成の変更を適用すると、この関数から返されたワークロード グループ名がリソース ガバナーの分類で使用されて、適切なワークロード グループに新しい要求が送信されます。

重要
分類関数が指定のログイン タイムアウトまでに完了せずに、クライアント セッションがタイムアウトになることがあります。ログイン タイムアウトはクライアントのプロパティであるため、サーバーはタイムアウトを認識しません。分類関数の実行時間が長いと、孤立した接続がサーバーに長時間残される可能性があります。接続がタイムアウトになる前に実行が完了する分類関数を作成することが重要です。

ユーザー定義関数の特性と動作は次のとおりです。

• ユーザー定義関数は、接続プールが有効になっている場合でも、新しいセッションすべてに対して評価されます。

• ユーザー定義関数は、セッションにワークロード グループ コンテキストを割り当てます。グループのメンバーシップが確定すると、セッションがその有効期間にわたってワークロード グループにバインドされます。

• ユーザー定義関数が NULL、既定値、または存在しないグループの名前を返した場合は、セッションに既定のワークロード グループ コンテキストが割り当てられます。関数が何らかの理由で失敗した場合も、セッションに既定のコンテキストが割り当てられます。

• ユーザー定義関数は、サーバー スコープ (master データベース) で定義する必要があります。

• ユーザー定義の分類関数の指定は、ALTER RESOURCE GOVERNOR RECONFIGURE を実行するまで有効となりません。

• 分類子として指定できるのは、一度に 1 つのユーザー定義関数だけです。

• ユーザー定義の分類関数は、分類子の状態が削除されない限り、削除または変更できません。

• ユーザー定義の分類関数がない場合は、すべてのセッションが既定のグループに分類されます。

• 分類関数から返されたワークロード グループは、スキーマ バインド制限の対象外です。たとえば、テーブルを削除することはできませんが、ワークロード グループは削除できます。

重要
サーバー上で専用管理者接続 (DAC) を有効にすることをお勧めします。DAC は、リソース ガバナーの分類の対象ではなく、分類関数の監視とトラブルシューティングに使用できます。詳細については、「専用管理者接続の使用」を参照してください。トラブルシューティングに DAC を使用できない場合は、システムをシングル ユーザー モードで再起動します。シングル ユーザー モードは分類の対象となりませんが、実行中のリソース ガバナーによる分類をこのモードで診断することはできません。

分類処理

リソース ガバナーのコンテキストでは、セッションのログイン プロセスが次の手順で実行されます。

1. ログイン認証

2. LOGON トリガー実行

3. 分類

分類が開始されると、リソース ガバナーは分類子関数を実行し、関数から返された値を使用して適切なワークロード グループに要求を送信します。詳細については、「分類関数の記述に関する注意点」を参照してください。

注
分類関数および LOGON トリガーの実行に関する情報は、sys.dm_exec_sessions および sys.dm_exec_requests で公開されます。

関連項目

概念

その他の技術情報