1

私はここで問題を説明しました: ReadCommited ILの下でのデッドロック と答えを得ました:

So a deadlock can occur when running SELECTs because the transaction running 
those selects had acquired write locks before running the SELECT.

さて、これを取り除くにはどうすればよいでしょうか？カバーされたインデックスを追加したり、SQL コマンド テキストを変更する分離レベルを変更したり、テーブル ヒントを使用したりすることで解決できる一般的なタイプのデッドロックがいくつかありますが、私の場合は適切な解決策が思いつきません。

これがデッドロックの最も一般的で最も簡単な理由のようです。

  1. プロセスAがリソースR1のロックを取得し、プロセスBがリソースR2のロックを取得します。
  2. プロセスAはリソースR2が解放されるのを待ち、プロセスBはR1を待ちます。

したがって、これは主に並列処理の問題であり、おそらくビジネス ロジックでもあります。

ロックが行に適用されていればデッドドックを回避できるかもしれませんが、ページ内にいくつかの行ロックがあり、ロックのエスカレーションが発生してページ全体がロックされているようです。

何をアドバイスしますか？ロックエスカレーションを無効にしますか? 1回の取引でローカルにできますか? または、テーブルヒント（WITH ROWLOCK）または何かを適用するかもしれません... idk

現在、分離レベルをスナップショット (またはその他のタイプ) に変更することはできません。ありがとう。

4

1 に答える 1

1

デッドロックの修正は、検討中の特定のトランザクションに固有のタスクです。一般的なアドバイスはほとんどありません (実行できないスナップショット分離を有効にすることを除いて)。

ただし、標準的な修正として 1 つのパターンが浮上しています。正しいロックモードを使用して、必要なすべてのロックを正しい順序で取得します。WITH (UPDLOCK, ROWLOCK, HOLDLOCK)これは、事前に行を U ロックするために選択することを意味する場合があります。

ロックのエスカレーションが問題になるのは見たことがありません。ロックを開始するには非常に大量のロックが必要だからです。もちろんそれが理由かもしれませんが、ほとんどの場合、行ロックはデッドロックを引き起こすのに十分です。

于 2012-11-13T09:22:14.590 に答える