データベースのパフォーマンスに関しては、多くの影響要因があります。 SQL Serverを監視することで特定のインスタンスの通常の変動を知ることは、動作が制御不能になっている時期を特定し、問題が発生する前に予測するのに役立ちます。
また、ワークロードの増加や季節的な急増によって引き起こされる自然な成長痛と、コードの調整、インデックスの最適化、または構成の調整を必要とするより深いパフォーマンスの問題とを区別するのにも役立ちます。
ご使用の環境でSQLサーバーのリストを作成したら、いくつかの重要な質問をする必要があります。
- このインスタンスはどの程度健全ですか？
- 最後にバックアップされたのはいつですか？
- SLAを満たすのに十分なCPU、メモリ、ストレージがありますか？
- このインスタンスではどのような種類のワークロードが実行されますか？
- このインスタンスを使用するアプリケーションとユーザーは何ですか？
- ワークロードが最も忙しいのはいつですか？
- フェイルオーバー戦略はありますか？
- これはミッションクリティカルなインスタンスですか？
- 24時間年中無休で利用できる必要がありますか？
- このインスタンスにはどのようなパフォーマンスの課題がありますか？
これらは明白な質問のように思えるかもしれませんが、SQL Serverのワークロードを初めて監視し始めると、根本的な問題を抱えているものがいくつあるかを見て、驚き、恐らく少し恐ろしいでしょう。
SQLServer監視のパフォーマンス目標を設定する
SQL Serverの監視作業で何を達成したいかを考え、これらの目標に優先順位を付けます。主要業績評価指標の観点から活動を構成することにより、エネルギーの価値と必要な投資を明確にすることが容易になります。次のリストから始められます。
高可用性
可用性の統計は何ですか？ユーザーが利用できないのは、サービスにアクセスできない場合であることに注意してください。これは、完全な停止、またはサービスを事実上利用できなくするパフォーマンスのボトルネックが原因である可能性があります。常時接続の構成はありますか？もしそうなら、あなたはそのステータスを知っていますか？
応答時間
問題が報告された時点から、どのくらい迅速に原因を特定し、症状を診断し、影響を受けたものに対応できますか？
解決時間
症状をどれだけ早く解決して、通常の動作に戻すことができますか？ 「絆創膏」の解決策は重要な始まりですが、問題の終わりを表すものであってはなりません。問題の根本的な原因を調査しましたか？再発が見られないと確信できますか？
SQLServerインスタンスの所有コストを理解する
所有コストは、SQLServerインスタンスを配置する場所を決定する際の重要な要素です。インフラストラクチャとライセンスに関連する先行投資コスト、継続的なメンテナンスコスト、およびクラウドベースのワークロードに関連する消費ベースのコストを測定することが重要です。
インスタンスがクラウドでいくらかかるかを決定しようとしている場合、重要なメトリックには、CPU使用率、読み取りと書き込みのアクティビティ、およびストレージが含まれます。これらを長期間にわたって測定して、ワークロードの境界を把握し、特定のインスタンスに期待するワークロードの範囲に対応できるようにする必要があります。
SQL Serverインスタンス全体で実行されているワークロードの特定の特性に精通することで、すべてが正常に実行され続け、ビジネスの現在と将来の両方のニーズを満たすことができるようになります。
SQLServerモニタリングを使用した長期にわたるパフォーマンスの調査
データベースは流動的なシステムです。安定した反復的で予測可能なワークロードを持っている人はほとんどいません。ユーザー数、自動化されたジョブ、トランザクション数、データ量などに基づいて変動する、時間の経過に伴う幅広い変動が見られることがはるかに一般的です。
販売データベースは月末に忙しくなります。また、季節のイベントの前後やマーケティングプロモーションによって促進される活動も急増します。
小さなスナップショットに基づいてパフォーマンスを分類することは、適切なポリシーではありません。収集および分析できる履歴が多いほど、各ワークロードの特性の変動と境界についてより多くの洞察を得ることができます。
保持するのが実際的である履歴の量と、それを処理するためのリソースがあるかどうかを判断する必要があります。考慮すべきコストとパフォーマンスへの影響があります。
データベース監視の全体像を把握する
すべてのデータベースは、多くの可動部分を持つ複雑なシステムです。多くの構成基準がパフォーマンスに影響を与える可能性があります。
データベース自体の設計とアーキテクチャは、結果に影響を与えます。コードの効率も、パフォーマンスを向上または低下させる可能性があります。構成オプションによって、SQLServerインスタンスが使用可能なリソースをどのように消費するかが決まります。
次のシナリオを検討してください。インスタンスの速度が低下して停止し、DBAがCXPACKETまたはCXCONSUMER待機の急増を検出しました。ひざまずく反応は、並列処理をシャットダウンすることです。待機がなくなり、現在のボトルネックが一時的に解消されます。現在、インスタンス全体の実行速度は遅くなっていますが、DBAは並列処理を再度有効にすることを望んでいません。さらに調査を行った場合、クエリの実行が特に遅く、原因がインデックスの欠落であることが明らかになります。
多くの異なる指標を並行して監視することで、根本原因を正確に特定し、同じ問題の繰り返しやエスカレーションを引き起こす可能性のある費用のかかる誤診を回避できます。