web-dev-qa-db-ja.com

「ロック|通信バッファーリソース」とはどういう意味ですか?

デッドロックを報告するエラーログがあります。

トランザクション(プロセスID 55)は、別のプロセスによってlock |通信バッファーリソースでデッドロックされ、デッドロックの犠牲者として選択されました。トランザクションを再実行します。

このエラーを再現しようとしていますが、標準のデッドロックSQLコードでdifferentエラーが発生します。

トランザクション(プロセスID 54)は別のプロセスでlock resourcesでデッドロックされ、デッドロックの犠牲者として選択されました。トランザクションを再実行します。

私はデッドロックが何であるかを尋ねているわけではありませんであることを明確にしたいと思います。私は基本を理解しています。

私の質問は、このコンテキストでのlock | communication buffer resourcesの意味は何ですか? 「通信バッファリソース」とは? lock |は何か意味がありますか?

私の推測では、並列スレッドが結果を結合するときに通信バッファーが使用されます。誰でもこれを確認または拒否できますか?

私の最終的な目標は、どういうわけか最初のエラーが再び発生するようにトリガーすることです。

22

私は、メッセージをロックリソースまたは通信バッファーリソースのいくつかの組み合わせのデッドロックとして解釈します。 「ロックリソース」は通常のオブジェクトロックであり、「通信バッファリソース」は並列クエリの結果を組み合わせるために使用されるexchangeEventsです。これらは https://blogs.msdn.Microsoft.com/bartd/2008/09/24/todays-annoyingly-unwieldy-term-intra-query-parallel-thread-deadlocks/ でさらに説明されています関連する段落は次のとおりです。

「exchangeEvent」リソースは、クエリプランに並列処理演算子が存在することを示します。大規模なスキャン、並べ替え、結合などの操作の作業は、複数の子スレッドで実行できるように分割されるという考え方です。面倒な作業を行い、行のセットを「コンシューマー」に送る「プロデューサー」スレッドがあります。クエリ内並列では、これらのワーカースレッド間のシグナリングが必要です。コンシューマーはプロデューサーがデータを渡すのを待たなければならず、プロデューサーはコンシューマーがデータの最後のバッチの処理を完了するのを待たなければならない場合があります。並列処理関連の待機は、SQL DMVでCXPACKETまたはEXCHANGE待機タイプとして表示されます(これらの待機タイプの存在は正常であり、単に並列クエリ実行の存在を示していることに注意してください-これらの待機自体は、このタイプまたはその他のタイプのデッドロックが発生しています)。

私が見たこれらのうちの1つのデッドロックグラフには、SPIDが1つだけの一連のプロセスと、オブジェクトロックと交換イベントのグラフが含まれていました。メッセージ「トランザクション(プロセスID 55)はロック時にデッドロックされました|別のプロセスとの通信バッファーリソースであり、デッドロックの犠牲者として選択されました。トランザクションを再実行してください」の代わりにが表示されます "クエリ内並列処理により、サーバーコマンド(プロセスID#51)がデッドロックしました。クエリヒントオプション(maxdop 1を使用して、クエリ内並列処理なしでクエリを再実行してください) "オブジェクトロックと交換イベントの組み合わせが原因であるか、記事が作成されてからSQL Serverでメッセージが変更されています。

1
Rattle

問題は並列処理に関連しており、エラーメッセージには問題が反映されておらず、maxdope設定を変更しないでください。エラーの原因を調べるには、トレースフラグ1204を使用する必要があります (トレースフラグの使用方法と取得する情報について確認してください

これを行うと、なぜ、どこで、どのコード行がロックを引き起こしたかについての答えが得られます。私はあなたがその時点から自分をググることができると思います、そしてそうでなければそれを投稿し、あなたはあなたが必要とする答えを得るでしょう。

1

MAXDOP 1をクエリヒントとして使用できます。つまり、サーバーの残りの部分に影響を与えることなく、1つのCPUでそのクエリを実行します。

これにより、そのクエリのエラーが回避されます-失敗した理由はわかりませんが、高速に動作させる必要がある場合の回避策は提供されます:-)

0
user240084