SQL Server 2017でのリソースガバナーのベストプラクティスの使用
OLTPワークロードとデータウェアハウジング/レポートワークロードの両方を収容するサーバーで作業しています。 OLTPシステムでは、レポートワークロードのしきい値が分であるのに、1秒未満（ミリ秒単位）の応答時間が必要です。問題は、一部のユーザーがOLTP環境でトランザクションのピーク時に複数のレポートを実行するため、OLTPクエリの速度が低下することです。単独ではOLTPクエリは20〜30ミリ秒で実行される傾向がありますが、多くのレポート/データウェアハウスクエリが同時に起動されると、4 [5秒]でOLTPクエリが実行されます。範囲。すべての待機がここにあるため、ボトルネックはCPUのようです。
もちろん、2つの異なるサーバーのワークロードを分離したいのですが、リソースガバナーを使用してすぐに改善できるかどうか疑問に思っています。
2つのアプローチを検討しています：（1）25％のリソースが保証されるようにOLTPシステムにCPUの最小割り当てを設定する、または（2）最大でレポート\データウェアハウスクエリを制限するCPUの50％を超えることはできません。
ここの誰かが、これら2つの方向の1つに私を導くであろうリソースガバナーの実際的な経験を持っていますか？または、代わりに提案する別の使用パターンはありますか？
ハイブリッドワークロードをサポートするには、リソースガバナンス以上のものが必要です。
ドキュメントでは、このシナリオを Real-Time Operational Analytics と呼んでいます。これは、すべてが連携して動作する一連の機能です。
最初に、レポートユーザーがデータベースでブロッキングを作成しないようにするために、行のバージョン管理が必要です。したがって、データベースをREAD COMMITTED SNAPSHOTに設定するか、レポートを強制的にSNAPSHOT分離で実行します。
ロックが解決したら、レポートユーザーが過剰なサーバーリソースを使用しないように、リソースのガバナンスと分離が必要になります。多くのワークロードでは、OLTP部分はデータファイルの物理IOを必要としませんが、ログファイルIOに依存します。したがって、データとログを物理的に分離することで、IOがレポートからOLTPに干渉するのを防ぐことができます。リソースガバナンスについては、まずレポートワークロードのCPU、IOPS、メモリ、そしておそらくmaxdopに上限を設定します。
次に必要なのは、レポートのワークロードをより安価にすることです。これには、更新可能な非クラスター化列ストアインデックス、フィルター処理されたインデックス、インデックス付きビュー、および列ストア圧縮遅延のいくつかの組み合わせを使用します。
そして最後に、ワークロードを監視し、レポート開発者に計画を可視化するために Query Store を使用する必要があります。