SQL Server 2005データベースのテーブルを更新するアプリケーションがあります。このアプリには、それぞれの地域ごとに1つのスレッドがあり、これらのスレッドは同時に実行されます。パーティショニングによってデッドロックの問題が修正される
まれに、テーブルを更新するときにSQL Serverデッドロックエラーが発生します。
最近、私はテーブルを領域ごとに分割する必要がありました。問題は解消するはずですが、テスト環境でこのエラーを再現することができないため、私はそれを証明できません。
誰もがこれについて考えていますか？
ロックされているものと、ロックが行ロックからページ/テーブルロックにエスカレートした理由、または行ロック間のデッドロックの原因を調べる必要があります。
ロックエスカレーションが何らかの方法で再生されている可能性があると聞こえますが、あなたの投稿からの推論では、2つのスレッドが同じレコードに触れることは期待できませんが、データページ/テーブル。
SQL Server 2005に関する限り、ロックエスカレーションは行 - >ページ - >テーブルからです。 SQL Server 2008でのみ、パーティションのロックがそのエスカレーション内に配置されました。
デッドロックに遭遇していることの詳細を理解するには、デッドロックグラフを取得してデッドロックグラフを取得する必要があります。 MSDNのグラフの詳細：http://msdn.microsoft.com/en-us/library/ms188246(v=SQL.90).aspx
スレッドが同じ行を更新しない場合は、with rowlockヒントを使用する必要があります。すでにこのヒントを使用している場合は、標準デッドロック以外の問題が原因です。 （デッドロック以外のものは、コードが遅くなってエンジンがデッドロックメッセージでスレッドを強制終了させる原因になります）
取得元：http://support.microsoft.com/kb/323630 - ROWLOCKなどのロックヒントを使用すると、初期ロックプランのみが変更されます。ロック・ヒントは、ロック・エスカレーションを防止しません。 - それを使用することで動作するかもしれませんが、デッドロックがエスカレーションから来るかどうか、ページ/テーブルロックを使用するロックプランが最初からあるかどうかによって異なります。 （ – Andrew
スレッド呼び出しのうち非常に大きな割合が、単一の行への更新を行うストアドプロシージャを呼び出します。より小さい数は、ストアドプロシージャを呼び出すストアドプロシージャを呼び出します。 "with rowlock"は両方のprocsに格納されていますか？ – wcm
@wcm - はい、両方のprocsを試してください（傷つけることはありません）Andrewは指摘しているように、動作しないかもしれません。あなたは結合を持っていますか？これもデッドロックを引き起こす可能性があります - 結合が問題ではない場合（しばしばそうではありません）、結合のノーロックヒントを使用します。彼らが問題なのかどうかを見て、もっと助けてください。 – Hogan
更新コード/手順を掲載してください。次に、デッドロック問題を修正することができます。可能性のある修正についてのランダムな理論...そこでは助けられない。デッドロックとは、プロセスが長く実行され、殺されたということだけを意味します。それは技術的な意味にデッドロックがあったことを必ずしも意味しない。 – Hogan