SE の雑記

SQL Server のサポートチームのブログに DO’s&DONT’s #1: やらない方がいいこと ? 運用環境で、Profiler GUI を使用してトレースする という記事が公開されています。

この記事の中に

多数のクライアント接続があり、多数のリクエストを受け付けている SQL Server が生成するすべてのイベントをひとつの Profiler で受け取ることになるため、Profiler がボトルネックとなり、SQL Server 全体のパフォーマンスが著しく悪化し、実行中のクエリがタイムアウトする、ログインがタイムアウトする、場合によっては、クラスタやミラーリングのフェールオーバなどを招くこともあります。Profiler GUI は、ひとつの普通のクライアント接続を通じて、SQL Server からトレースイベントを受け取ります。当然、その接続で転送できる量は限られており、また、それをグラフィカル表示しなければならないため、SQL Server 側で生成されるイベント量が、Profiler が処理できるイベント量の限界を超える状況になると、SQL Server 側では新たなイベントを Profiler に渡せなくなり、イベントを生成している一般のクライアントは、イベント書き込み待ち状態になります。

という記載があります。

イベント書き込み待ちが発生するということは待ち事象が出ないかなと思ったので少し調べてみました。

■SQL Server Profiler と SQL Trace の待ち事象

SQL Profiler を実行している状態の待ち事象を拡張イベントで確認してみます。
今回は SQL Server 2012 を使用しているため、拡張イベントを使用した待ち事象の取得がとても楽です。

プロファイラのイベント書き込みに関する待ちは上記のような事象が発生していそうです。

それでは同じトレースを SQL Trace で実行してみます。
SQL Trace の設定方法に関してはサポートチームのブログ記事がわかりやすいです。
SQL トレーススクリプトの作成、実行 (SQL Server 2005, 2008, 2008 R2)

待ち事象を確認した結果がこちらになります。

Session ID 11 はトレース用のセッションになるようです。

SQL Server Profiler の場合は、TRACEWRITE という待ち事象が追加で発生しているようですね。
この待ち事象が何を表しているのかを sys.dm_os_wait_stats から調べてみます。

SQL Server Profiler 特有の待ちではなさそうですが、GUI でトレースを実行した場合はこの待ち事象が多くなるのかもしれないですね。
トレース系のイベントはほかにも用意されていますで、ポリシーベースのQoS等で意図的に回線を抑える等をして SQL Server を実行している端末以外から Profiler を接続してみれば、さらに詳細な待ち事象の動きがつかめるかも。
# 今回は SQL Server 上で Profiler を実行しています。