sql >> データベース >  >> RDS >> Sqlserver

XEvent Profilerを使用して、SQLServerでクエリをキャプチャします

    パフォーマンスの監視やシステムの速度低下などの問題のトラブルシューティングの過程で、実行時間やCPUが高いクエリ、または実行中に大量のI/Oを生成するクエリを検索またはキャプチャする必要がある場合があります。 DMVまたはクエリストアを使用してクエリのパフォーマンスに関する情報を取得できますが、両方のソースの情報は集約されています。 DMVは、クエリがキャッシュにある間のみ、クエリの平均CPU、I / O、期間などを表します。クエリストアは、多数のリソースの平均指標も提供しますが、定義された時間枠(30分や1時間など)で集計されます。もちろん、これらすべてとそれ以上を提供できるサードパーティの監視ソリューション(SentryOneなど)もありますが、この投稿では、ネイティブツールに焦点を当てたいと思いました。

    個々の実行のクエリパフォーマンスを理解して、問題となる可能性のある正確なクエリまたはクエリのセットを特定する場合、最も簡単なオプションは拡張イベントを使用することです。また、開始する最も簡単な方法の1つは、SQL Server Management Studio(バージョン17.3以降)から利用できるXEventProfilerを使用することです。

    SSMSのXEventプロファイラー

    基本的な使用法

    XEvent Profilerには、標準とTSQLの2つのオプションがあります。どちらかを使用するには、名前をダブルクリックするだけです。舞台裏では、内部で定義されたイベントセッションが作成され(まだ存在しない場合)、開始され、ライブデータビューアがすぐにフォーカスを持って開きます。 セッションを開始すると、下にも表示されることに注意してください 管理|拡張イベント|セッション。サーバーに対してアクティビティがあると仮定すると、5秒以内にエントリがビューアに表示されるようになるはずです。

    ライブデータビューア(ダブルクリックして標準セッションを開始した後)

    StandardセッションとTSQLセッションはいくつかのイベントを共有し、Standardには合計でより多くのイベントがあります。それぞれのイベントのリストは次のとおりです。

    Standard		TSQL
    sql_batch_starting	sql_batch_starting	
    sql_batch_completed	
                            rpc_starting
    rpc_completed	
    logout			logout
    login			login
    existing_connection	existing_connection
    attention

    クエリの実行にかかった時間や消費したI/Oなど、クエリの実行に関する情報を理解したい場合は、2つの完了したイベントがあるため、Standardの方が適しています。どちらのセッションでも、唯一のフィルターは、バッチ、RPC、およびアテンションイベントのシステムクエリを除外することです。

    データの表示と保存

    標準セッションを開始していくつかのクエリを実行すると、ビューアにイベント、クエリテキスト、およびcpu_time、logical_reads、durationなどの他の有用な情報が表示されます。 rpc_completedとsql_batch_completedを使用する利点の1つは、入力パラメーターが表示されることです。パフォーマンスに大きなばらつきがあるストアドプロシージャがある場合、入力パラメータをキャプチャすると、より時間がかかる実行をストアドプロシージャに渡される特定の値と照合できるため、非常に便利です。このようなパラメータを見つけるには、期間に基づいてデータを並べ替える必要があります。これは、データフィードがアクティブな場合には実行できません。あらゆる種類の分析を実行するには、データフィードを停止する必要があります。

    ライブビューアーでのデータフィードの停止

    クエリがぼやけて表示されなくなったので、期間列をクリックしてイベントを並べ替えることができます。初めてクリックすると昇順で並べ替えられます。怠惰で下をスクロールしたくないので、もう一度クリックして降順で並べ替えます。

    期間の降順で並べ替えられたイベント

    これで、キャプチャしたすべてのイベントを、期間が長いものから低いものの順に表示できます。遅い特定のストアドプロシージャを探している場合は、それが見つかるまで下にスクロールするか(これは苦痛になる可能性があります)、データをグループ化またはフィルタリングすることができます。ストアドプロシージャ名がわかっているので、ここではグループ化が簡単です。

    object_nameはビューアの上部に表示されますが、rpc_completedイベントをクリックすると、詳細ペインにキャプチャされたすべての要素が表示されます。 object_nameを右クリックして強調表示し、[テーブルに列を表示]を選択します。

    データビューアにobject_nameを追加

    上部のペインで、object_nameを右クリックして、[この列でグループ化]を選択できます。 usp_GetPersonInfoの下のイベントを展開してから、期間で再度並べ替えると、PersonID=3133での実行の期間が最も長いことがわかります。

    object_nameでグループ化されたイベント、期間の降順でソートされたusp_GetPersonInfo

    データをフィルタリングするには:[フィルター...]ボタン、メニューオプション([拡張イベント] | [フィルター...])、またはCTRL + Rを使用してウィンドウを表示し、表示されるさまざまなフィールドに基づいて結果セットを縮小します。この場合、object_name =usp_GetPersonInfoでフィルタリングしましたが、server_principal_nameやclient_app_nameなどのフィールドが収集されたときにフィルタリングすることもできます。

    StandardセッションとTSQLセッションのどちらもファイルに書き出さないことを指摘しておく価値があります。実際、どちらのイベントセッションにもターゲットはありません(ターゲットなしでイベントセッションを作成できることを知らなかった場合は、これでわかります)。さらに分析するためにこのデータを保存する場合は、次のいずれかを実行する必要があります。

    1. データフィードを停止し、[拡張イベント]メニューから出力をファイルに保存します([エクスポート先] | [XELファイル...])
    2. データフィードを停止し、[拡張イベント]メニュー([エクスポート先] | [テーブル...])を使用して、出力をデータベースのテーブルに保存します。
    3. イベントセッションを変更し、event_fileをターゲットとして追加します。

    オプション1は、他のユーザーと共有したり、後でManagement Studioで確認してさらに分析したりできるファイルをディスク上に作成するため、私の推奨事項です。 Management Studio内では、関連性のないデータを除外したり、1つ以上の列で並べ替えたり、データをグループ化したり、計算(平均など)を実行したりすることができます。データがテーブルの場合はこれを行うことができますが、TSQLを作成する必要があります。 UIでのデータの分析は、より簡単で高速です。

    XEventプロファイラーセッションの変更

    標準およびTSQLイベントセッションを変更できます。行った変更は、インスタンスの再起動後も保持されます。ただし、イベントセッションが(変更を加えた後に)ドロップされると、デフォルトにリセットされます。同じ変更を継続的に行っていることに気付いた場合は、変更をスクリプト化して、再起動後も持続する新しいイベントセッションを作成することをお勧めします。例として、これまでにキャプチャされた出力を見ると、アドホッククエリとストアドプロシージャの両方が実行されていることがわかります。ストアドプロシージャのさまざまな入力パラメータを確認できるのは素晴らしいことですが、この一連のイベントで実行されている個々のステートメントは表示されません。その情報を取得するには、sp_statement_completedイベントを追加する必要があります。

    標準イベントセッションとTSQLイベントセッションの両方が軽量になるように設計されていることを理解してください。 statement_completedイベントは、batchおよびrpcイベントよりも頻繁に発生するため、これらのイベントがイベントセッションの一部である場合は、オーバーヘッドが大きくなる可能性があります。ステートメントイベントを使用するとき、私は非常に 追加の述語を含めることをお勧めします。注意として、rpcイベントとbatchイベントは、システムクエリを除外するだけであり、他の述語はありません。一般に、特に大量のワークロードの場合は、これらのイベントに追加の述語を使用することもお勧めします。

    StandardセッションとTSQLセッションのどちらを実行してもシステムのパフォーマンスが低下するかどうかが心配な場合は、システムに過度のオーバーヘッドが発生すると、LiveDataViewerが切断されることを理解してください。これは非常に安全ですが、これらのイベントセッションを使用するときはまだ思いやりがあります。特にSQLServerや拡張イベントを初めて使用する場合は、トラブルシューティングの最初のステップとして最適だと思います。ただし、ライブデータビューアを開いていて、マシンから離れると、イベントセッションは引き続き実行されます 。ライブデータビューアを停止または閉じると、イベントセッションが停止します。これは、データ収集またはトラブルシューティングが終了したときにお勧めします。

    長期間実行するイベントセッションの場合は、event_fileターゲットに書き込み、適切な述語を持つ個別のイベントセッションを作成します。拡張イベントの開始に関する詳細情報が必要な場合は、昨年SQLBitsでプロファイラーから拡張イベントへの移行について行ったセッションを確認してください。


    1. MySQLに対するMySQLiの利点

    2. SQLフルテキストインデックスの作成がいつ終了したかを知るにはどうすればよいですか?

    3. 整数のリストをC#からOracleストアドプロシージャに渡します

    4. SQL Serverインデックスの後方スキャン:理解とパフォーマンスの調整