6

SQL 2000 サーバーを使用しており、1 日のさまざまな時間帯や月のさまざまな日に実行されるさまざまなジョブが実行されています。通常、SQL プロファイラーを使用してトレースを実行するのは、パフォーマンスのトラブルシューティングのために非常に短い期間だけですが、この場合、データベースに対して実行されるクエリの種類の全体像を正確に把握することはできません。日または週または月のコース。

長時間実行される SQL トレースのパフォーマンス オーバーヘッドを最小限に抑えるにはどうすればよいですか? 私はすでに知っています：

  • SQL プロファイラー UI を使用する代わりに、トレース サーバー側 (sp_ create_trace) を実行します。
  • データベース テーブルではなく、ファイルにトレースします (DB サーバーに余分なオーバーヘッドが追加されます)。

私の質問は本当にフィルターに関するものです。特定の期間または読み取りを超えて実行されるクエリのみをログに記録するフィルターを追加した場合でも、サーバー上のすべてのアクティビティを調べて、ログに記録する必要があるかどうかを判断する必要がありますよね? では、そのフィルターを使用しても、トレースは、既に容認できないパフォーマンスの限界に達しているサーバーに対して、容認できないレベルのオーバーヘッドを作成するのでしょうか?

4

4 に答える 4

2

問題が発生する可能性があるため、実際にはサーバーにトレースを処理させないでください。「サーバーがトレースを処理する場合、すべてのイベントをキャプチャするためにサーバーのパフォーマンスを犠牲にすることを意味する場合でも、イベントはドロップされません。一方、プロファイラーがトレースを処理している場合は、サーバーがビジー状態になると、イベントがスキップされます。」（SQL 70-431試験集のベストプラクティスから。）

于 2008-11-13T19:28:25.193 に答える
2

SQL プロファイラー セッションとサーバー側トレースのパフォーマンスへの影響を実際に測定する記事を見つけました。

http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx

これは本当に私の根底にある質問でした。トレース中に実稼働サーバーが停止しないようにする方法です。正しく行うと、オーバーヘッドが最小限になるようです。

于 2008-12-30T15:34:57.977 に答える
2

フィルターを追加すると、イベント収集のオーバーヘッドが最小限に抑えられ、サーバーが不要なトランザクション エントリをログに記録することも防止されます。

トレースによって許容できないレベルのオーバーヘッドが発生するかどうかについては、テストして、追加の苦情がある場合は停止するだけです。ただし、本番環境のトレース ファイルを使用して DB Tuning Advisor のヒントを得ることで、明日は全員のパフォーマンスが向上する可能性があります。

于 2008-11-13T16:11:19.863 に答える
0

実際には、Profiler から収集できるよりも詳細な測定値を収集することが可能であり、オーバーヘッドを発生させることなく、インスタンス全体で 24 時間 365 日実行できます。これにより、何をフィルタリングする必要があるかを前もって把握する必要がなくなります。これは難しい場合があります。

完全な開示: 私はそのようなツールを提供するベンダーの 1 つで働いています... しかし、あなたが私たちのツールを使用しているか、他の誰かのツールを使用しているかにかかわらず... これにより、ここでの中心的な問題を回避できる可能性があります。

ツールの詳細については、http://bit.ly/aZKerzをご覧ください。

于 2010-11-18T17:52:28.267 に答える