回答:
一般的に見られる完全なメッセージ:
トランザクション(プロセスID 53)がロック時にデッドロックされました| 別のプロセスとの通信バッファリソースであり、デッドロックの犠牲者として選択されています。トランザクションを再実行します。
このロックタイプは、SQL Serverが並列として実行するデッドロッククエリでよく見られ、「クエリ内並列デッドロック」と呼ばれることもあります。システムリソースが少ないことも指摘しているという声明をいくつか見てきました。
並列デッドロックかどうかを判断するために気づいた一般的なガイドラインは、XMLデッドロックグラフ(2008年以降のsystem_healthセッションで実行可能)をプルすると、異なるプロセスIDで同じコードのビットが表示されることです。実行スタック。
同様に、デッドロックグラフのリソースリストを見て、ウェイターイベントのタイプを確認します。最も一般的には「e_xxxxxx」、または次のようなものが表示されます。
<waiter-list>
<waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>
問題を解決しようとするために、さまざまな方法がオンラインおよび書籍で提供されています。通常、クエリ/プロシージャの実行計画を確認することから始め、並列実行を示している領域に焦点を合わせます。その後、最初にクエリを調整し、最後の手段としてクエリヒントの使用を開始します。
これらのデッドロックを解決するために言及される最も一般的なクエリヒントは、実装MAXDOP 1
です。ただし、その前に、サーバーレベルのMAXDOPとコストのしきい値の設定を確認することがあります。通常、コストのしきい値はデフォルトで5に設定されていますが、最初に35または40に上げて、問題のクエリのコードセクションのコストが低い場合、並行して実行する必要はない場合があります。私はMAXDOPクエリヒントを使用することを好むわけではありませんが、その場所と目的がないという意味ではありません。ただ私の意見。