運用中のデータベースでSQLプロファイラーを使用する

開発者として、私はSQLプロファイラーを頻繁に使用します。これは、コードが何をしているかを追跡し、パフォーマンスの問題を分析するのに適したデバッグツールです。

しかし、私は常に開発環境で非常に制御された方法でそれを使用してきました。

• アプリケーションを起動し、特定の状態にします
• プロファイラーでトレースを開始する
• アプリケーションで特定のアクションシーケンスを実行する
• トレースを停止し、結果を調べます。

SQLプロファイラーは、実稼働環境で実際に使用できますか？

私の最初の懸念は、パフォーマンスが低下することです。

私の2番目の懸念は、本番環境であるため、興味深いアクション自体をトリガーしていないということです。プロファイラーを長時間実行したままにして、結果を分析する必要があります。結果セットは扱いにくくなりますか？（ディスク容量を取りすぎており、クエリが困難です）。

誰かが本番環境でSQLプロファイラーを使用していますか？

Sql Server Profiler（GUIツール）を使用して運用サーバーをトレースすることはお勧めできません。ただし、負荷に依存します。代わりにサーバー側のSQLトレース（sp_trace_XXXプロシージャを参照）を使用します。また、私は記事を見つけました：

パフォーマンスへの影響：サーバー側のSQLトレース対プロファイラトレース、

SQL Serverでのサーバー側のトレースの自動化

プロファイラーで問題を引き起こすことを避ける

多分それは興味深く、役に立つでしょう。

Book Onlineのコメント：

• サーバー上で直接ではなくリモートでプロファイラーを実行する
• どうしても必要な場合を除き、頻繁に発生するイベント（例：Lock：Acquired）を含めないでください
• 必要なイベントクラスのみを含める
• 制限フィルターを指定して、イベントの数を減らします
• 冗長データを避けます（SQL：BatchStartingおよびSQL：BatchCompletedなど）
• プロファイラーで大きなトレースを実行しないでください。代わりにサーバー側のSQLトレースを検討してください
• サーバー側のトレースファイルのサイズを制限し、スペース使用量を管理する

私は常にSQLプロファイラーを本番環境に対して使用しています。サーバーに対して正しく行われた場合（非常に少量のデータを取得するようにフィルタリングする）、リスクは最小限です。すべてをたどることは役に立ちません。

1. はい、監視行為にはいくつかのリソースが必要です。過負荷のサーバーで実行すると、強制終了される可能性があります。

2. 実際に実際の負荷を監視します。この負荷のノイズでアクションが失われる可能性があります。

本番環境で実行することもあります。主に、特定のコード用のテキストフィルター、または実行時間の長いクエリをトラップするCPU /期間フィルターを使用します。そして、私たちはXML実行計画やそのようなノンセンスをキャプチャしようとはしません

重要なのは、あなたが探しているものを知ることです。私たちはそれを実行したままにしてすべてをトラップする傾向はありません。

この場合、いくつかのアクションの結果を表示したい場合、時間外に実行できますか？

プロファイラーは常にパフォーマンスに影響を与えます。

SQL Server 2008R2 +を使用している場合は、拡張イベントを使用できます。これにより、プロファイラーに表示される情報の多くがパフォーマンスヒットのほんの一部で提供されます。

書籍のオンライン紹介 http://technet.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

この機能は、SSMSのGUIを含むSQL Server 2012の大きな更新を受け取りました。