上記に加えて「CXCONSUMER」という待ち事象が増えています。方に集計されるようになります。リリースされたことで実際に検証が可能となりました。ドキュメントも更新されています。これは、並列クエリの実行の通常の一部です。実行しても短くできない場合は、並列処理のコストしきい値を調整したり並列処理の次数を下げたりすることを検討してください。待機の種類で個別に追跡されます。検証する際は、次のドキュメントと合わせて確認すると理解しやすいかと。並列クエリが実行されているものがあったので、これを使いながら軽く検証を。違うクエリを実行します。排他ロックを取得するクエリを実行して、ロック競合が発生した状態にします。トランザクションが完了するまで、ロック競合の状態になります。競合が解消された後に実行される、セッション単位の待ち事象の情報としては次のような情報が取得できます。上記のクエリでは、ビューから情報を取得しているのですが、ビューの検索時には並列クエリとして実行されています。適用する前の状態では、「CXPACKET」と「LCK_M_X」が高い値となっていますね。スレッドに対して、データを渡すことが出いない状態になっています。今までのバージョンでは、待ち事象からは、これ以上詳細に確認することができませんでした。発生している要因が、クエリの並列実行に起因しているのか、それとも他の事象に起因しているのかの判断が難しいというような課題がありました。適用した状態で同様のことを実施してみます。「CXPACKET」の待ち事象が減り、「LCM_M_X」と「CXCONSUMER」が高い値を示していますね。個のコンシューマースレッドが生成されている状態で発生しているという読み方ができそうです。スレッドにデータを渡すことができず「CXCONSUMER」待機が発生しているという推測が可能となります。数の調整をしても効果は薄く、利用するスレッド数からのアプローチではなく、クエリの最適化のアプローチが必要になるという判断ができるかと。並列度の最適化により、クエリの実行性能が改善するかの判断をする際に、強力な確認方法となりそうですので、有効に活用したいですね。ついては情報を確認することができるかと。チューニング等をメインにしていますが、本ブログで情報発信している内容に関することでしたら対応できます。お仕事のご相談がありましたらTwitterfacebookやブログのコメントでご連絡いただけると幸いです。ブログにコメント頂いた内容は私が承認しない限り表示されません。受賞させていただきました。本ブログの内容は個人的に検証したものとなり、検証結果を含め記載している内容を保証するものではありません。体験記の連載をさせていただきました。最後まで飲み切れず...。