sql >> データベース >  >> RDS >> Database

ベースラインの重要性

    SQL Serverを使用するコンサルタントとして、パフォーマンスの問題があるように見えるサーバーを調べるように何度も求められます。サーバーでトリアージを実行しているときに、通常のCPU使用率、平均ディスクレイテンシ、通常のメモリ使用率などの特定の質問をします。答えは通常、「わからない」または「その情報を定期的に収集していない」です。最近のベースラインがないため、異常な動作がどのように見えるかを知ることは非常に困難です。通常の行動が何であるかわからない場合、状況が良いか悪いかをどのようにして確実に知ることができますか?私はよく「監視していなければ測定できない」「測定していなければ管理できない」という表現を使います。

    監視の観点から、組織は少なくとも、バックアップ、インデックスメンテナンス、DBCC CHECKDB、およびその他の重要なジョブなどの失敗したジョブを監視する必要があります。これらの障害通知を設定するのは簡単です。ただし、ジョブが期待どおりに実行されていることを確認するためのプロセスも必要です。ハングして完了しないジョブを見てきました。ジョブが成功または失敗することはないため、失敗通知によってアラームがトリガーされることはありません。

    パフォーマンスベースラインから、キャプチャする必要のあるいくつかの主要なメトリックがあります。クライアントで使用するプロセスを作成しました。このプロセスは、主要な指標を定期的に取得し、それらの値をユーザーデータベースに保存します。私のプロセスは単純です。結果セットをテーブルに挿入する一般的なスクリプトを使用するストアドプロシージャを備えた専用データベースです。ストアドプロシージャを定期的に実行するSQLエージェントジョブと、X日より古いデータをパージするクリーンアップスクリプトがあります。私が常にキャプチャするメトリックは次のとおりです。

    ページの平均余命 :PLEは、システムが内部メモリの負荷にさらされているかどうかを判断するための最良の方法の1つです。ほとんどのシステムには、通常のワークロード中に変動するPLE値があります。最小値、平均値、最大値を知るために、これらの値をトレンド分析するのが好きです。 1日の特定の時間帯にPLEが低下した原因を理解して、それらのプロセスを調整できるかどうかを確認したいと思います。多くの場合、誰かがテーブルスキャンを実行し、バッファプールをフラッシュしています。これらのクエリに適切にインデックスを付けることができると役立ちます。正しいPLEカウンターを監視していることを確認してください–こちらを参照してください 。

    CPU使用率 :CPU使用率のベースラインがあると、システムが突然CPUプレッシャーにさらされているかどうかを知ることができます。多くの場合、ユーザーがパフォーマンスの問題について不満を言うと、CPUが高く見えることに気付くでしょう。たとえば、CPUが80%前後でホバリングしている場合、懸念があることに気付くかもしれませんが、問題が報告されていない前の週の同じ時間にCPUも80%であった場合、CPUが問題である可能性は非常に低くなります。トレンドCPUは、CPUが急上昇し、一貫して高い値を維持しているときにキャプチャするためだけのものではありません。アプリケーションに問題があったために、重大度1の会議ブリッジに持ち込まれたときの話はたくさんあります。 DBAである私は、「デフォルトの非難アクセプター」の帽子をかぶっていました。アプリケーションチームがデータベースに問題があると言ったとき、それが問題ではないことを証明するのは私にかかっていました。データベースサーバーは無罪であることが証明されるまで有罪でした。ユーザーが接続できなかったためにデータベースサーバーに問題が発生しているとアプリケーションチームが確信していた事件を鮮明に思い出します。彼らはインターネット上で、SQL Serverが接続を拒否している場合、スレッドプールの枯渇に苦しんでいる可能性があることを読んでいました。サーバーにジャンプして、リソースと、現在実行されているプロセスを調べ始めました。数分以内に、問題のサーバーが非常に退屈していることを報告しました。ベースラインメトリックに基づくと、CPUは通常60%で、アイドル状態は約20%で、ページの平均余命は通常よりも著しく長く、ロックやブロックは発生せず、I / Oは見栄えがよく、ログにエラーはありませんでした。セッション数は通常の約1/3でした。次に、「ユーザーはデータベースサーバーに到達していないようです」とコメントしました。これはネットワーク関係者の注目を集め、ロードバランサーに加えた変更が適切に機能していないことに気付き、接続の50%以上が正しくルーティングされておらず、データベースサーバーに到達していないと判断しました。ベースラインが何であるかを知らなかったとしたら、解決に至るまでにかなり長い時間がかかったでしょう。

    ディスクI/O :ディスクメトリックをキャプチャすることは非常に重要です。 DMV sys.dm_io_virtual_file_statsは、最後のサーバーの再起動以降累積されます。時間間隔にわたってI/Oレイテンシをキャプチャすると、その時間中の正常な状態のベースラインが得られます。累積値に依存すると、営業時間後のアクティビティやシステムがアイドル状態であった長期間のデータが歪む可能性があります。パウロはここについて話しました 。

    データベースファイルのサイズ :ファイルサイズ、使用済みサイズ、空き領域などを含むデータベースのインベントリを作成すると、データベースの増加を予測するのに役立ちます。データベースサーバーに今後1年間に必要なストレージの量を予測するように求められることがよくあります。週次または月次の成長傾向を知らなければ、私は賢く数字を思いつく方法がありません。これらの値の追跡を開始すると、これを適切にトレンド化できます。トレンドに加えて、予期しないデータベースの増加がいつあったかを見つけることもできました。予期しない成長を見て調査すると、通常、誰かがテーブルを複製してテストを実行したか(はい、本番環境で!)、または他の1回限りのプロセスを実行したことがわかります。このタイプのデータを追跡し、異常が発生したときに対応できることは、システムを積極的に監視していることを示すのに役立ちます。

    統計を待つ :待機統計を監視すると、特定のパフォーマンスの問題の原因を突き止めるのに役立ちます。多くの新しいDBAは、最初に待機統計の調査を開始したときに懸念を抱き、待機が常に発生することに気づきません。これがSQLServerのスケジューリングシステムの仕組みです。良性、またはほとんど無害と見なすことができる待機もたくさんあります。 Paul Randalは、人気のある待機統計スクリプトで、これらのほとんど無害な待機を除外しています。 Paulは、さまざまな待機タイプの膨大なライブラリも構築しました。 およびラッチクラス 待機とラッチのトラブルシューティングに関する説明とその他の情報が含まれています。

    データ収集プロセスを文書化しました。コードは私のブログにあります。 。クライアントが抱えている可能性のある状況や問題の種類によっては、追加のメトリックを取得したい場合もあります。 グレンベリー 彼がまとめた、平均タスク数、平均実行可能タスク数、平均保留I / O数、SQL ServerプロセスCPU使用率、およびすべてのNUMAノードの平均ページ寿命をキャプチャするプロセスについてブログに書いています。インターネットですばやく検索すると、 SQL Server Tiger Team でさえ、人々が共有している他のいくつかのデータ収集プロセスが見つかります。 T-SQLとPowerShellを利用するプロセスがあります。

    カスタムデータベースを使用して独自のデータ収集パッケージを構築することは、ベースラインをキャプチャするための有効なソリューションですが、私たちのほとんどは、完全なSQLServer監視ソリューションを構築するビジネスを行っていません。長時間実行されるクエリ、メモリ、I / O、CPUに基づく上位クエリとストアドプロシージャ、デッドロック、インデックスの断片化、1秒あたりのトランザクション数など、キャプチャに役立つものは他にもたくさんあります。そのために、私は常にクライアントがサードパーティの監視ツールを購入することをお勧めします。これらのベンダーは、SQL Serverの最新のトレンドと機能を常に把握していることを専門としているため、SQLServerが可能な限り安定して高速であることを確認することに時間を集中できます。

    SQL Sentryなどのソリューション (SQL Serverの場合)および DB Sentry (Azure SQLデータベースの場合)これらすべてのメトリックをキャプチャし、さまざまなベースラインを簡単に作成できるようにします。通常のベースライン、月末、四半期末などを設定できます。次に、ベースラインを適用して、状況がどのように異なるかを視覚的に確認できます。さらに重要なことに、さまざまな条件に対して任意の数のアラートを構成し、メトリックがしきい値を超えたときに通知を受け取ることができます。

    先週のベースラインは、SQLSentryダッシュボードのいくつかのSQLServerメトリックに適用されました。

    前の期間のベースラインは、DBSentryダッシュボード上のいくつかのAzureSQLデータベースメトリックに適用されました。

    SentryOneのベースラインの詳細については、これらの投稿を参照してください。 チームのブログ、またはこの2分間の火曜日のビデオ 。試用版のダウンロードに興味がありますか? 彼らもあなたをカバーしてくれます


    1. C#をOracleに接続する

    2. 値が存在しない場合にのみ行を返す

    3. PostgreSQLで年齢を年単位で計算する

    4. SQL30日より古いすべてのレコードを取得します