運用中のデータベースでのSQLプロファイラーの使用
開発者として、私はSQLプロファイラーを頻繁に使用しています。これは、私のコードが何をしているかを追跡し、パフォーマンスの問題を分析するための優れたデバッグツールです。
しかし、私はいつもそれを使ってきました 開発 環境、そして非常に制御された方法で。
- アプリケーションを起動し、特定の状態にします
- プロファイラーでトレースを開始します
- アプリケーションで特定の一連のアクションを実行する
- トレースを停止し、結果を調べます。
SQLプロファイラーは、実稼働環境で実際に使用できますか？
私の最初の懸念は、それがパフォーマンスを低下させることです。
私の2番目の懸念は、本番環境にあるため、興味深いアクション自体をトリガーしていないことです。プロファイラーを長期間実行したままにして、結果を分析する必要があります。結果セットが扱いにくくなりますか？ （ディスク領域を占有しすぎて、クエリが困難です）。
本番環境でSQLプロファイラーを使用する人はいますか？
Sql Server Profiler（GUIツール）を使用して本番サーバーをトレースすることはお勧めできません。しかし、それは負荷に依存します。代わりに、サーバー側のSQLトレース（ sp_trace_XXX プロシージャを参照）を使用してください。また、私は記事を見つけました：
パフォーマンスへの影響：プロファイラートレースとサーバー側SQLトレースの比較 、
多分それは興味深く、役に立つでしょう。
オンラインで予約 は言う：
- サーバー上で直接ではなくリモートでプロファイラーを実行する
- 絶対に必要でない限り、頻繁に発生するイベント（Lock：Acquiredなど）を含めないでください
- 必要なイベントクラスのみを含める
- イベントの数を減らすために制限フィルターを指定する
- 冗長なデータを避けます（例：SQL：BatchStartingおよびSQL：BatchCompleted）
- プロファイラーで大きなトレースを実行しないでください。代わりにサーバー側のSQLトレースを検討してください
- サーバー側のトレースファイルサイズを制限し、スペース使用量を管理する
SQLプロファイラーを本番環境で常に使用しています。サーバーに対して正しく行われると（非常に少量のデータが返されるようにフィルタリングされます）、リスクは最小限になります。すべてをトレースダウンしても意味がありません。
はい、監視の行為はいくつかのリソースが必要になります。過負荷のサーバーで実行すると、強制終了する可能性があります。
実際の負荷を実際に監視します。この負荷のノイズによってアクションが失われる可能性があります。
本番環境で実行することもあります。主に特定のコードのテキストフィルター、またはCPU /期間フィルターを使用して、実行時間の長いクエリをトラップします。そして、XML実行計画やそのような無意味なものをキャプチャしようとはしません
重要なのは、あなたが何を探しているのかを知ることです。私たちはそれを実行したままにし、すべてをトラップする傾向はありません。
この場合、いくつかのアクションの結果を見たい場合は、時間外に実行できますか？
プロファイラーは常にパフォーマンスに影響を与えます。
SQL Server 2008R2 +を使用している場合は、拡張イベントを使用できます。これにより、プロファイラーに表示される情報の多くに、パフォーマンスヒットの一部が提供されます。
書籍のオンライン紹介 http://technet.Microsoft.com/en-us/library/bb630354（v = sql.105）.aspx
この機能はSQL Server 2012で大きな更新を受け、現在はSSMSのGUIが含まれています。