1年以上後、私の経験とこの質問/トピックの最終結果をみんなに知らせたいと思います。
自分で物作りを始めました。最初に、Tim Fordの記事「SQL ServerパフォーマンスカウンターデータとCMVの履歴の収集と保存」に従って、何かを取得し、収集したいあらゆるデータでこれを拡張しました。したがって、1日1回、DMVから特定の情報を収集し、その結果をデータベース内のローカルサーバーに保存するストアドプロシージャを各SQL Serverでいくつか実行します。これには、インデックスの使用、不足しているインデックス、自動拡張、サーバー設定、アプリケーションデータベース設定、断片化、ジョブ実行、トランザクションログ情報、ファイル情報、待機統計などの特定のログエントリが含まれます。
さらに、Brent Ozarのsp_blitzの定期的な実行結果をこのリポジトリに追加して、動作、改善、およびレポートのための追加の貴重な兆候を収集しました。
その後、すべてのデータはそこから専用の監視SQLサーバーに収集されます。この方法で、すべてのサーバーに関するパフォーマンス関連情報のバンドルストアを作成し、これを調査とレポートのベースとして使用します。
次に、Excelシートを作成し、レポートサービスを使用してレポートを作成して分析および解釈しました。いくつかのサンプル:
また、Fedor Georgievによる記事「SQL Serverテーブルへのパフォーマンスデータの収集」に触発されたTYPEPERFを使用して、いくつかのパフォーマンスカウンター監視を構成しました。
私のSQL監視インスタンスから、typeperfをトリガーして、構成可能なサンプル間隔で構成可能な数のサンプルを実行および収集し、結果を中央監視データベースに保存します。
これにより、長期的なパフォーマンス値を観察できます。サンプル:
これを使用してベースライン情報を収集した後、失敗したジョブ、デバッグ手順の確認に費やす必要のあるメンテナンス作業はかなり多いことがわかりました(たとえば、DBがオフラインになった場合、スクリプトは失敗しました)、サーバーが交換された後の設定の維持...
また、すべてのレコードを収集するデータベースは、保守とパフォーマンスのチューニングが必要であるため、データを有用に保つために追加の作業が必要になります...
最後に完全に欠けているのは、ライブで起こっていることを見る能力です。ベストケースでは、データコレクターの実行後、翌日に何が起こっていたのかを知ることができます。また、すべての詳細が欠落しています。デッドロックグラフにアクセスできません。疑わしい時間枠で実行されていたクエリのクエリプランを確認できません。
そのすべてが、私が自分で作成することができない専門的な解決策にお金を使うために経営陣に請求するつもりでした。
最後の選択は、他と比較して説得力があり、私たちの問題点を特定するために必要な多くの情報を提供するので、SentryOneを購入することでした。
最後の結論として、小規模で基本的に健全な環境が整っていない限り、同様の質問に対する答えを探している人は自分で作成しないようにアドバイスします。いくつかのシステムと多くの問題がある場合は、すぐに専門的な解決策を取り、多くの時間とお金を費やして有用性の低いハッシングを作成するのではなく、問題に対してベンダーの支援を利用することをお勧めします。しかし、このルートはまだ非常に興味深く、見逃したくない多くのことを学びました。
この質問スレッドに遭遇したら、これが役に立つと思います。
2017年4月20日編集:
ブレントオザーは最近、SQLタイガーチームが採用した類似のアプローチの一種である次の記事をFacebookに投稿しました:https ://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining -reports-unleashed-for-enterprise-monitoring /