それに該当しています。使用状況の情報を格納これらの情報は、セッションが存在している状態であれば、各種累計値を保持するようになっており、セッションが破棄されたタイミングでクリアされます。そのため、外部から「特定のセッションの情報」を取得するのは難しいのですが「自セッションの情報」であれば、容易に取得することができます。@@SPID」の情報を取得すればよいだけですので)本クエリでは、次のように実行することで「クエリ実行時に発生した値」を算出しています。クエリ実行前の自セッションの情報を一時テーブルに格納クエリ実行クエリ実行後の自セッションの情報と一時テーブルに格納した情報の差を算出これにより、クエリ実行時の情報の算出を行うことができます。格納しているため、この部分のオーバーヘッドが発生していますが、誤差の範囲だと思います。セッション単位の待ち事象の情報を取得することもできます。活用方法として覚えておくと便利かと。詳細については、クエリを読んでいただくとわかるのですが、次のような処理を実行しています。拡張イベントの中では何種類かのイベントをキャッチするように設定をしているのですが「全てのセッションの情報」を取得してしまうと、ノイズとなる情報が多すぎてデータの分析が困難になります。そのため、拡張イベントを作成する際には、「自セッションの情報に限定する」というようなフィルターを設定してあげる必要があります。含むように文字列連結で、拡張イベントを設定するためのクエリを生成して実行しています。ログディレクトリに「query_analyze_xxxx」というファイルを出力して実施しており、実行ごとにファイルを生成していますので、不要になったら削除してください。作ってもよかったのですが、情報の解析の手間がかかるので拡張イベントのターゲットについてはファイルターゲットとしています。クエリ実行で解析することができるのですが、そのままの状態で解析をすると、効率が悪く、解析に時間がかかります。インデックスを付与して、解析しやすい状態にしています。インデックス付きの一時テーブルに対してクエリを実行して必要な情報を抜き出します。情報は、指定したステートメントの情報を解析したものとなります。つのステートメントにするとわかりやすいかと。GETDATE())」は、「メッセージ」に出力している次のような処理時間の算出用ですので、この行は無視してください。行目以降が実行したステートメント単位の情報となります。リソースを消費しているのかという情報を確認することができます。不足インデックスのアドバイスがあった場合は、その情報を出力するようにしていますので、インデックスのアドバイス情報を抽出することもできるようになっています。情報はセッションで発生した待ち事象の情報を拡張イベントで取得したものになります。以降で動作するようにしておきたかったので、拡張イベントの情報を利用しています。「クエリで発生した待ち事象」が把握できると「クエリチューニングのポイント」が見えてきますので、クエリの実行効率の改善には有効な項目となります。(ロックの要求と解放)」となります。通常のクエリであればどのようなロックが取得されているか判断しやすいですが、運用系のクエリですとどのようなロックが取得されたかの判断が難しいケースがあります。「統計情報の更新」を実行した際にどのようなロックが取得されているかを把握できているでしょうか?今回のクエリの仕組みを利用すると「統計情報の更新を実行した場合に取得されたロック」についても取得できます。実行するクエリを次のように設定してみます。取得されたロックの情報には次のような情報が含まれています。対象のテーブルに対して、「OBJECT:X」のロックをかけていることが確認できますね。このほかにも統計情報のメタデータに対して、「SCH_M」のロックがかかっていることが確認できます。このような情報が取得できると、かなり強力な情報となるケースがあります。'1'このクエリを実行したときには、次のようなロックが取得されています。シンプルなロックの取得ですね。クエリを次のように変更してみるとどうでしょう。(RECOMPILE)この結果は一部のみとなっているのですが、「クエリのコンパイル」が発生した場合は、先ほどとは異なるロックの取得状況となっていることが確認できます。統計情報の更新では統計情報に対して「SCH_M」のロックが取得されているリコンパイルを伴うクエリ実行で使用された統計情報に対して「SCH_S」のロックが取得されているということがこの情報から確認できます。確認することができます。上述の「SCH_M」と「SCH_S」については互換性がなく競合するロックですので、これらのロックが同タイミングで発生した場合にはブロッキングによる処理遅延が発生することになります。統計情報の更新中は、統計情報に対して「SCH_M」が発生しているため、コンパイルを伴うクエリが実行された場合に該当の統計情報を取得するために必要となる「SCH_S」がブロッキングされ、統計情報の更新はクエリの同時実行性を低下させる一因となりえる可能性があるということを判断することができます。様々な情報がありますので、今回使用しなかった情報を組み合わせることで、いろいろな状態を取得することができます。「自セッションの情報をフィルターして情報を取得する」というアプローチは活用できるとかなり強力なものとなりますので、今回紹介した方法以外でも、自分なりの情報取得方法というものを持っているとよいのではないでしょうか。チューニング等をメインにしていますが、本ブログで情報発信している内容に関することでしたら対応できます。お仕事のご相談がありましたらTwitterfacebookやブログのコメントでご連絡いただけると幸いです。ブログにコメント頂いた内容は私が承認しない限り表示されません。受賞させていただきました。本ブログの内容は個人的に検証したものとなり、検証結果を含め記載している内容を保証するものではありません。体験記の連載をさせていただきました。最後まで飲み切れず...。