リソース ガバナー
適用対象:
SQL ServerAzure SQL Managed Instance
リソース ガバナーを使用して、データベース エンジンのリソース消費を管理し、ユーザー ワークロードのポリシーを適用できます。 リソース ガバナーを使用すると、ユーザー クエリ ワークロードで使用できる CPU、メモリ、物理 I/O の量を予約または制限できます。 並列処理の程度やメモリ許可のサイズなど、各クエリのリソース消費動作を変更することもできます。
構成と監視の例、およびリソース ガバナーのベスト プラクティスについては、「チュートリアル: リソース ガバナーの構成例とベスト プラクティスを参照してください。
Note
Azure SQL Database ではリソース ガバナー (他の手法の中でも) を利用してリソースを管理していますが、Azure SQL Database でのリソース プールとワークロード グループのユーザー構成はサポートされていません。
Azure Synapse Analytics には、ワークロード分類機能を使用して、同様のリソース ガバナンス動作の異なる実装があります。
リソース ガバナーの利点
リソース ガバナーを使用すると、データベース エンジンのワークロードとリソースを管理できます。そのためには、予約と、要求ごとのリソース消費量の制限を指定します。 リソース ガバナー コンテキストでは、ワークロードは、単一のエンティティとして扱うことができるクエリ (要求) のセットです。 たとえば、特定のアプリケーションによって実行されるすべてのクエリがワークロードと見なされる場合があります。 これは必須ではありませんが、ワークロードのリソース使用パターンが均一であればあるほど、リソース ガバナーからより多くの恩恵を受けることができるようになります。
同じサーバーに複数の異なるワークロードが存在する場合、リソース ガバナーを使用すると、指定した制限に基づいて、異なるワークロードに異なる方法でリソースを割り当てることができます。
リソース ガバナーでサポートされる使用シナリオの一部を次に示します。
- 複数のクライアント ワークロードを提供する SQL Server の 1 つのインスタンスで、マルチテナント機能とリソースの分離を提供します。 つまり、サーバー上の使用可能なリソースをワークロード間で分散し、ワークロードがリソースの確保を求めて競合したときに発生する可能性のある問題を最小限に抑えることができます。
- マルチワークロードおよびマルチユーザー環境のワークロードに対して、予測可能なパフォーマンスとサポート SLA を提供します。
- 暴走クエリを分離して制限するか、I/O サブシステムを飽和させ、他のワークロードに悪影響を与える可能性のある I/O 集中型操作の I/O リソースを制限します。
- リソース使用量のチャージバックの詳細なリソース追跡を追加し、サーバー リソースのコンシューマーに予測可能な課金を提供します。
リソース ガバナーの制限事項
リソース ガバナーには、次の制限があります。
- リソース管理は、SQL Server データベース エンジンに限定されます。 リソース ガバナーは、Analysis Services、Integration Services、および Reporting Services には使用できません。
- リソース ガバナーは、複数の SQL Server インスタンスにわたってワークロードの監視やワークロード管理を提供しません。
- 一部の OLTP ワークロードのクエリなど、非常に短いクエリでは、CPU 帯域幅制御を適用するのに十分な長さがない可能性があります。 これにより、CPU 使用率の統計情報が歪み、CPU リソース ガバナンスの有効性が制限される可能性があります。
- 物理 I/O を管理する機能は、システム タスクではなく、ユーザー操作にのみ適用されます。 システム タスクは、トランザクション ログ、チェックポイント、およびレイジー ライター I/O を実行します。 リソース ガバナーは、ユーザーの物理読み取り I/O を管理しますが、システム タスクによって実行される書き込み I/O は管理しません。
internalリソース プールとワークロード グループのリソース ガバナンスコントロールを変更することはできません。- リソース ガバナーは、インスタンス レベルで動作します。 に含まれる可用性グループ を持つリソース ガバナーは適用されません。
リソースの概念
次の 3 つの概念は、リソース ガバナーを理解して使用するための基本的な概念です。
- リソース プール。 リソース プールは、CPU、メモリ、I/O など、サーバーの物理リソースのコンテナーを表します。
internalとdefaultの 2 つの組み込みリソース プールが常に存在します。 リソース ガバナーでは、ユーザー定義のリソース プールもサポートされています。 構成によっては、リソース プール内のリソースを他のプールと共有することも、予約することもできます。 詳細については、「リソース ガバナー リソース プール」を参照してください。 - ワークロードグループです。 ワークロード グループは、同じ方法で分類されるセッションのコンテナーを表します。 ワークロード グループを使用すると、セッションと要求リソースの消費量の集計監視が可能になり、要求ポリシーが定義されます。 各ワークロード グループはリソース プールに存在します。
internalとdefaultの 2 つの組み込みワークロード グループが常に存在し、それぞれinternalとdefaultリソース プールにマップされます。 リソース ガバナーは、ユーザー定義のワークロード グループもサポートします。 詳細については、「リソース ガバナー ワークロード グループの」を参照してください。 - 分類。 分類プロセスでは、カスタム分類ロジックを使用して、ログイン名やプログラム名などのセッションの属性に基づいて、受信セッションをワークロード グループに割り当てます。 セッションがワークロード グループに分類されると、そのセッションで実行されるすべての要求がワークロード グループ ポリシーの対象になります。 分類ロジックを定義するには、分類子関数と呼ばれるスカラー ユーザー定義関数を記述します。 詳細については、「リソース ガバナー分類子関数 」を参照してください。
Note
リソース ガバナーは、専用管理者接続 (DAC)に制御を強制しません。 DAC クエリは、常に internal ワークロード グループとリソース プールで実行されます。
次の図は、リソース ガバナー コンポーネントと、データベース エンジン内での相互の関係を示しています。 処理の観点から見たフローを簡単に示すと次のようになります。
- セッション (セッション 1/
n) に着信接続が存在します。 - セッションは分類されます。
- 分類結果を使用して、セッションはワークロード グループ (たとえば、
Group 4) に割り当てられます。 - ワークロード グループは、すべての要求に対してポリシーを適用し、関連付けられているリソース プール (たとえば、
Pool 2) を使用します。 - リソース プールは、アプリケーションで必要なリソース (たとえば、
Application 3) を提供し、制限します。
リソース ガバナー のタスク
| タスクの説明 | 記事 |
|---|---|
| 構成の例を表示する | リソース ガバナーの構成例とベスト プラクティス |
| リソース ガバナーを有効にする | リソース ガバナーの を有効にする |
| リソース ガバナーを無効にする | リソース ガバナーの を無効にする |
| リソース プールを作成、変更、および削除する | リソース ガバナーのリソース プール |
| ワークロード グループを作成、変更、移動、および削除する | リソース ガバナー ワークロード グループ |
| 分類子ユーザー定義関数を作成してテストする | リソース ガバナー分類子関数 |
| テンプレートを使用してリソース ガバナーを構成する | テンプレート を使用してリソース ガバナーを構成する |
| リソース ガバナーのプロパティを表示する | リソース ガバナーのプロパティを表示および変更 |