概要と比較可能なデータを取得するための私の現在のタスクは、さまざまな生産的なSQL Serverインスタンスに関するいくつかの数値を取得するためのパフォーマンスベースラインを作成することです。
私の考えは:
したがって、私が達成しようとしているのは、開始可能および停止可能(またスケジュール可能)の一般的なパフォーマンスモニタリングであり、次を返します。
進行中のパフォーマンス最適化タスクの成功を識別するために必要なすべての情報
長期的な進捗状況を視覚化するのに役立つ、いくつかの集約された単純な図..特に管理用;-)
個々のキューの変更とインデックス最適化タスクによる改善を比較するためのプロファイラートレース内の再実行可能な実行プラン
パフォーマンスベースラインの作成について説明している情報がいくつか見つかりました。それらのほとんどは、非常に複雑であるか、目的のパフォーマンスインジケーターの1つだけに焦点を当てています(ほとんどはパフォーマンスデータ)。
最も一致するサンプル/説明は次のとおりです: SQL Serverのパフォーマンスベースラインの作成
質問は:
この種のパフォーマンスモニターをすばやく実行可能な方法で作成した経験がある人はいますか?
1年以上後、私の経験とこの質問/トピックの最終結果をみんなに知らせたいと思います。
自分で物作りを始めました。最初に、Tim Fordが記事 CMVを使用してSQL Serverのパフォーマンスカウンターの履歴データを収集して保存する に従い、収集したいあらゆるデータでこれを拡張しました。そのため、1日1回、各SQL Serverでいくつかのストアドプロシージャを実行し、DMVから特定の情報を収集して、データベース内のローカルサーバーに結果を保存します。これには、インデックスの使用、欠落したインデックス、自動拡張などの特定のログエントリ、サーバー設定、アプリケーションデータベース設定、断片化、ジョブ実行、トランザクションログ情報、ファイル情報、待機統計などが含まれます。
さらに、Brent Ozarのsp_blitzの定期的な実行結果をこのリポジトリに追加して、作業、改善、および報告のための追加の貴重な指標を収集しました。
その後、すべてのデータはそこから専用の監視SQLサーバーに収集されます。このようにして、すべてのサーバーに関するパフォーマンス関連情報のバンドルストアを作成し、これを調査とレポートのベースとして使用します。
次に、Excelシートとレポートサービスを使用してレポートを作成し、分析と解釈を行いました。いくつかのサンプル:
また、Fedor Georgievの記事「 SQLサーバーテーブルへのパフォーマンスデータの収集 」に触発されたTYPEPERFを使用して、いくつかのパフォーマンスカウンター監視を構成しました。
私のSQL監視インスタンスから、typeperfをトリガーして、構成可能なサンプル間隔で構成可能な数のサンプルを実行および収集し、結果を中央監視データベースに保存します。
これにより、長期的なパフォーマンス値を観察できます。サンプル:
これを使用してベースライン情報を収集した後、失敗したジョブ、デバッグ手順の確認に費やす必要のあるメンテナンス作業はかなり多いことがわかりました(たとえば、DBがオフラインになった場合、スクリプトは失敗しました)、サーバーが交換された後の設定の維持...
また、すべてのレコードを収集するデータベースは、保守とパフォーマンスのチューニングが必要であるため、データを有用に保つために追加の作業が必要になります...
最後に完全に欠けているのは、ライブで起こっていることを見る能力です。ベストケースでは、データコレクターの実行後、翌日に何が起こっていたのかを知ることができます。また、すべての詳細が欠落しています。デッドロックグラフにアクセスできません。疑わしいタイムフレームで実行されていたクエリのクエリプランを確認できません。
そのすべてが、私が自分で作成することができない専門的な解決策にお金を使うために経営陣に請求するつもりでした。
最後の選択は、他と比較して説得力があり、苦痛点を特定するために必要な多くの情報を提供するので、SentryOneを購入することでした。
最終的な結論として、小規模で基本的に健全な環境が整っていない限り、同様の質問に対する答えを探している人は自分で作成しないようにアドバイスします。いくつかのシステムと多くの問題がある場合は、すぐに専門的な解決策を取り、多くの時間とお金を費やして有用性の低いハッシングを作成する代わりに、問題に対してベンダーの支援を利用することをお勧めします。しかし、このルートはまだ非常に興味深く、見逃したくない多くのことを学びました。
この質問スレッドに出会ったら、これが役に立つと思います。
EDIT 2017年4月20日:Brent Ozarは最近、SQL Tigerチームが採用した類似のアプローチの一種である次の記事をFacebookに投稿しました: https://blogs.msdn.Microsoft.com/sql_server_team/sql-server-performance-baselining-reports-unleashed-for-enterprise-monitoring/
ここにあなたがここで見つけることができるいくつかの実用的な例でいくつかの良い記事があります:
ベースラインを使用してSQL Serverのパフォーマンスの問題を検出する方法–パート1 –はじめに
ベースラインを使用してSQL Serverのパフォーマンスの問題を検出する方法–パート2 –メトリックの収集とレポート
ベースラインを使用してSQL Serverのパフォーマンスの問題を検出する方法–パート
パート1ではベースラインとは何かについての基本的な知識を提供しますが、パート2では「貧乏人」の方法を使用して自分でそれを行う方法についての情報を見つけることができます(無料で学習に適しています)。
パート3では、ベースラインを確立する方法と、ApexSQLモニターを介していくつかの問題のトラブルシューティングでベースラインを使用する方法のいくつかの例を示します
私はかなり新しく開発されたDBAとして、無料ツールの全範囲を実行し、有料スペース(DPA、SQL Sentry、およびFoglight)でいくつかの実験を行いましたが、それは実際にツールの目的に依存します。
私の経験では、最も重要なことは、パフォーマンスのベースラインを伝えることだけではなく(誰かが怒鳴る人がいない限り、管理はほとんど気にしませんでした)、優先順位を明確にし、パフォーマンスを追跡できる、使いやすい形式で何かを生み出しました生産における問題。
無料のルートをたどることでスキルを確実に高めることができ、SQL Serverのツールは優れています。
これらといくつかの追加のデータベース/テーブルおよびジョブと時間を使用して、基本的な監視システムを構築できます(ただし、美しくはありません)。これらはDBA向けのツールです。 Ozarのsp_blitzアプリはすごくクールですが、BIに長けていなければ、そこからビジネスフレンドリーな有用なものを作成するのに苦労します。
約1年を費やして無料のことを行い、多くの問題を解決しましたが(多くの賛同を得ることはありませんでした)、大きな問題の後、パフォーマンス監視ソフトウェアが優先事項であることを明確にすることができました。地獄や高水に来る。
前述のクライアントをデモした後、管理者は結果を簡単に消費できるため、DPAを選択しました。ただし、SQL Sentry Plan Explorer Proのクライアントライセンスは確かにあり(金額に見合う価値は1000%)、サーバーバージョンを使用するのが本当に好きでしたが、取得できませんでした。同じ方法。
ある時点でSQLNexusを動作させることも試みましたが、私が興味を持っていたよりも多く動作するようになりました。それはあなたのニーズに合うかもしれません。
さまざまな生産的なSQLインスタンスに関するいくつかの数値を取得するためのパフォーマンスベースラインをすばやく作成するには、Solarwinds Database Performance Analyserなどのサードパーティツールの無料トライアルを使用します。
この本を読んでください!!! SQL Serverタックルボックス
SSISおよびSQLクエリを使用して、環境内のすべてのSQL Serverインスタンスに関する監視情報を収集する方法を示します。
私は上記のポスターのいくつかに同様のルートをたどっていましたが、Microsoftが作成したものに偶然出会いました。
上記で簡単に説明しましたが、明示的なリンクはありませんでした。 Microsoft Tigerチームは、ここからダウンロード可能な「Tiger Toolbix」を開発しました: https://github.com/Microsoft/tigertoolbox
YouTubeのビデオでTiger Toolboxについて説明しています: https://www.youtube.com/watch?v=bx_NGNEz94k