共有 SQL Server 2005 クラスター インスタンス上にいくつかのデータベースがあり、それらのパフォーマンス メトリックが必要です。非常に長時間実行されるプロセスがいくつかあり、不十分なハードウェアではなく、コードの非効率性が原因であると思われます。
データベース ハードウェアが原因である可能性を除外できるように、これらのパフォーマンス メトリックを取得する何らかの方法が必要です。
共有 SQL Server 2005 クラスター インスタンス上にいくつかのデータベースがあり、それらのパフォーマンス メトリックが必要です。非常に長時間実行されるプロセスがいくつかあり、不十分なハードウェアではなく、コードの非効率性が原因であると思われます。
データベース ハードウェアが原因である可能性を除外できるように、これらのパフォーマンス メトリックを取得する何らかの方法が必要です。
ああ、SQL Profiler の仕事のようですね。 http://msdn.microsoft.com/en-us/library/ms181091(SQL.90).aspx
この問題について、typeperf.exe に組み込まれた Windows の使用に関するすばらしい記事を読みました。 http://www.mssqltips.com/tip.asp?tip=1575
それは難しいです...パフォーマンスモニターを使用して、ハードウェアとOSの要因を追跡できます-CPU使用率、メモリなど。また、1 秒あたりのクエリ数などのさまざまな SQL Server カウンターもあります。明らかにメモリ使用量から、より多くの RAM が必要かどうかがわかりますが、(たとえば) CPU 使用率が高いのは非効率的なコードによるものなのか、集中的なコードによるものなのかを判断するのは簡単ではありません。
一部のカウンターは、パフォーマンスの問題をドリルダウンするのに役立ちます。DB のロックなどをカウントできます。問題は、すべてのコードの動作が異なるため、多すぎる数がわからないことです。発生している回数が多すぎるのか、それとも速度が遅い期間が大きな回数に相当するのかがわかります。これは、他のさまざまなカウンターにも当てはまります。
もう 1 つは、トレース (SQL サーバー ツール) を実行して、実行されたクエリのリストを取得することです。最も遅い/最大のものをいくつか取り上げて、それらを実行したときにどのような実行プランが表示されるかを確認します。これは、クエリを最適化することを示唆していますが、コードが非効率的であるか、以前と同じように集中的であるかを判断するのはあなた次第です.
最後に、多くのデータベース統計をまとめて詳細に表示する Spotlight のようなツールを入手してください。