いう投稿を書きました。待ち事象を確認することができます。比較して、待ち事象の取得方法が複数用意されています。今回の投稿ではどのような方法があるかを確認してみたいと思います。待ち事象について解説されています。版だとかなり安いので、興味のある方は一度見てみるとよいかと思います。私は英語が本気でダメダメなのですが、こんな感じかな~と思いながら最後まで眺めることはできました。種類が一般的かと思います。それずれについてみていきたいと思います。待ち事象を確認するための動的管理ビューとしては、sys.dm_os_wait_statssys.dm_os_latch_statsを使うことが多いかと思います。確認をするという流れになります。場合はすべての待ち事象についての情報が出力されます。程度の待ち事象が取得できます。増加するものがあります。そのため、情報の解析をする場合にはこれらの待ち事象は除く必要があります。用意して、サービスを起動して数分放置し、待ちが増加したものを取り除くとよいかと思います。動的管理ビューの待ち事象については、サービスを最後に起動してからの累積値となります。コマンドを実行します。先ほどの動的管理ビューでは累積値の取得となるため、特定の時間でトータルとして、どれだけ発生したかはわかるのですが、時系列に動きをみるということはできません。どのような待ちがどのタイミングで発生したかを可視化する際にはパフォーマンスモニターを利用するとよいかと思います。パフォーマンスモニターで取得できる項目は以下のように限定的なものとなっています。ディスク関連のパフォーマンスモニターの項目と照らし合わせながら解析を行うと有効に利用することができますので、見方の一つとして覚えておくと便利かと思います。以降であれば、拡張イベントが追加されています。以降になると思いますが、拡張イベントでも待ち事象を確認することができます。いうイベントが含まれており、このイベントを使用することで、待ち事象を取得することができます。拡張イベントを使用した待ち事象の取得の大きな特徴の一つとしては、セッション単位で待ち事象を取得できるところがあるかと思います。指定することで特定のセッションの待ち事象について取得することができます。これにより、クエリによりどのような待ちが発生するかを確認することができます。使用するクエリをデータがキャッシュされていない状態で実行してみます。等の待ちが発生しています。集計をすることができるため取得したデータを以下のように表示することができます。取得したものになります。こちらが同様のクエリをデータがキャッシュされている状態で実行したものとなります。メモリにキャッシュされているため、ディスクからのデータ読み込みの待ちは発生しなくなっていますが、並列クエリの同期待ちは継続として発生していることが、ここからわかるかと思います。このような動作を見たい時には拡張イベントを使用すると便利かと思います。状態を把握する際の情報を取得することができるようになります。チューニング等をメインにしていますが、本ブログで情報発信している内容に関することでしたら対応できます。お仕事のご相談がありましたらTwitterfacebookやブログのコメントでご連絡いただけると幸いです。ブログにコメント頂いた内容は私が承認しない限り表示されません。受賞させていただきました。本ブログの内容は個人的に検証したものとなり、検証結果を含め記載している内容を保証するものではありません。体験記の連載をさせていただきました。最後まで飲み切れず...。