前回の投稿では、sysprocessesなどの非推奨のシステムテーブルの使用をやめるべき理由の1つを説明しました。 。これは、パフォーマンス上の理由から直接、または単にMicrosoftの文書化されたベストプラクティスに従うためではなく、一部のデータにしかアクセスできない場合に行う可能性のある決定を中心に展開されました。
今回は、SQL Serverクライアントツールに含まれている、最近は使用すべきではない機能について説明したいと思います。これは、廃止されただけでなく、さらに重要なことに、サーバーを完全に停止させる可能性があるためです。
SQLServerプロファイラー
SQL Server 2012以降（および、SQL Server 2008以降）、SQLServerインスタンスのイベントを監視するための最も完全で柔軟なソリューションは拡張イベントです。一方、SQL Server Profilerは、最初に発明されて以来（ほぼキャリアを開始した頃）、サーバーを誤ってひざまずかせてしまう最も多作な方法の1つでした。
少し前まで、このようなことが私たちに起こりました。開発者は、アプリケーションに変更を加えて、行っていたラウンドトリップの数を減らしました。彼らは、フィルタリングされたトレースを備えたProfilerを使用して、アプリケーションをローカルおよび開発環境で実行し、変更が期待どおりに機能していることを確認しました。この時点で、SQLServerProfilerの公式ドキュメントに次の警告が含まれていることを思い出してください。
SQLTraceとSQLServerProfilerは非推奨です。 MicrosoftSQLServerのTraceオブジェクトとReplayオブジェクトを含むMicrosoft.SqlServer.Management.Trace名前空間も非推奨になりました。この機能は、MicrosoftSQLServerの将来のバージョンで削除される予定です。新しい開発作業でこの機能を使用することは避け、現在この機能を使用しているアプリケーションを変更することを計画してください。とにかく、彼らがアプリケーションの新しいバージョンを本番環境にデプロイし、同じフィルター処理されたトレースで本番サーバーをターゲットにしたとき、それはあまりうまくいきませんでした。アプリケーション名のワイルドカードフィルターは、このサーバーに接続している他の（同様の名前の）アプリケーションを考慮せず、開いているプロファイラーウィンドウが処理できるよりもはるかに多くの情報をすぐにキャプチャし始めました。これにより、そのインスタンスに接続するすべてのユーザーとアプリケーションの接続時間が壊滅的に増加しました。苦情が申し立てられたと言っても過言ではありません。
原因が特定され、開発者からの応答があった場合、プロファイラートレースを停止した直後に、接続時間が通常に戻ったことがわかります（クリックして拡大）：
SQLServerプロファイラーのミニ災害
これは間違いなく、古い「私のマシンで動作しました」というステートメントが、ビジー状態の本番サーバーで正常に動作することを意味するわけではないというシナリオです。そして、この事件は、プロファイラーが接続文字列で渡すアプリケーション名を単にブロックするために、環境内のすべてのサーバーにすでに存在するログオントリガーを変更することについて活発な会話を引き起こしました。
多分これはプロファイラーの問題ではありません。 （しかし、それは一種です。）
私は、拡張イベントを含む他の監視ツールを不適切に使用して、同様の（またはさらに悪い！）方法でサーバーをダウンさせることができないことを示唆するためにここにいるわけではありません。 SQL Server Profilerに触れることなく、SQLServerのインスタンスに実際に悪影響を与える可能性がたくさんあります。
しかし、プロファイラーは、消費するため、このタイプの症状で有名です。 データ。これは、新しい行を受け取ったときにそれを表示するグリッドを備えたユーザーインターフェイスです。残念ながら、SQL Serverがより多くの行を送信できるようになる前に、SQLServerがそれらをレンダリングする間待機します。この動作は、SQL Server Management Studioがクエリの速度を低下させ、ASYNC_NETWORK_IOを高くする方法と似ています。 大量の出力を独自のグリッドにレンダリングしようとするときに待機します。これは単純化です（Greg Gonzalez（@SQLsensei）が「トレースを恐れないでください」で説明している、基盤となるSQLトレースの動作方法と混同しないでください）が、まさにそれが上記のシナリオのタイプ：そのボトルネックは、トレースしているものと同じコードパスで何かを実行しようとしている他のプロセス（接続の確立の試行を含む）にカスケード効果をもたらします。
拡張イベントを恐れていますか？
しないでください。今こそプロファイラーを捨てて現在を受け入れる 。 Microsoft独自のQuickStartや、このサイトにあるいくつかの記事など、チュートリアルやガイドが不足することはありません。
依存する既存のトレースがある場合、Jonathan Kehayias（@SQLPoolBoy）には、既存のトレースを拡張イベントに変換するための非常に便利なスクリプトがあります。それでも、プロファイラーUIを使用して元のトレースを自由に構成できます（それが最も快適な場合）。実稼働サーバーに接続せずに実行してください。そのスクリプトについてはここで読むことができ、ジョナサンの他の拡張イベントの記事のいくつかをここで見ることができます。
ユーザーエクスペリエンスに苦労している場合は、あなただけではありませんが、いくつかの答えがあります：
- Erin Stellato（@erinstellato）は長い間、拡張イベントの見事な支持者であり、なぜ人々がプロファイラーとSQLトレースを一般的に手放すことに消極的であるのか疑問に思うことがよくあります。彼女は2016年の投稿「なぜ拡張イベントを回避するのですか？」でいくつかの洞察を持っています（そして多くのコメントに影響を与えました）。おそらく、差し控える理由が2021年でもまだ有効であるかどうかについての洞察があります。
- 最新バージョンのSSMSに組み込まれているXEventProfilerがあり、AzureDataStudioと同等の拡張機能があります。ただし、紛らわしいことに、彼らはこの拡張機能を、想像できるすべてのものの中で、SQLServerプロファイラー 。エリンもその選択についていくつか考えています。
- Eric Darling（@erikdarlingdata）が
sp_HumanEventsを作成しました 拡張イベントへの切り替えの手間を省くため。私のお気に入りの「要点に固執する」人々の1人であるエリックは、sp_HumanEventsについて説明しています。 次のようになります。「クエリメトリックのプロファイリング、統計の待機、ブロック、コンパイル、または拡張イベントを使用した再コンパイルを簡単に行う方法が必要な場合は、これがユニコーンです。」