12

現在、SQL Server 2008 の特定のユーザー テーブルで頻繁にデッドロックが発生するという問題があります。この特定のテーブルに関するいくつかの事実を次に示します。

  1. 行数が多い (100 万から 200 万)
  2. このテーブルで使用されるすべてのインデックスには、オプションで「行ロックを使用する」のみがチェックされています 編集: テーブルには主キーであるインデックスが 1 つしかありません
  3. 行は複数のトランザクションによって頻繁に更新されますが、一意です (たとえば、1 時間ごとに異なる一意の行に対しておそらく 1000 以上の更新ステートメントが実行されます)。
  4. テーブルはパーティションを使用しません。

の表を確認したところ、が に設定されsys.tablesていることがわかりました。lock_escalationTABLE

このテーブルの lock_escalation を変更したいと強く思っていますがDISABLE、これがどのような副作用をもたらすかはよくわかりません。私が理解していることから、使用DISABLEするとレベルからのエスカレートするロックが最小限に抑えられTABLE、インデックスの行ロック設定と組み合わせると、理論的には遭遇しているデッドロックを最小限に抑えることができます..

Determining threshold for lock escalationで読んだことから、単一のトランザクションが 5000 行をフェッチすると、ロックが自動的にエスカレートするようです。

この意味で、単一のトランザクションは何を意味するのでしょうか? 個々の更新/選択ステートメントを介して 5000 行を取得する単一のセッション/接続?

それとも、5000 行以上をフェッチする単一の SQL 更新/選択ステートメントですか?

洞察をいただければ幸いです。ところで、n00b DBA はこちら

ありがとう

4

2 に答える 2

9

ステートメントが SINGLE オブジェクトに対して 5000 を超えるロックを保持している場合、LOCK エスカレーションがトリガーされます。同じテーブルの 2 つの異なるインデックスに対してそれぞれ 3000 個のロックを保持するステートメントは、エスカレーションをトリガーしません。

ロックのエスカレーションが試行され、競合するロックがオブジェクトに存在する場合、試行は中止され、さらに 1250 回のロック (保持されているが、取得されていない) の後に再試行されます。

したがって、更新が個々の行に対して実行され、列にサポート インデックスがある場合、ロックのエスカレーションは問題ではありません。

これは、プロファイラーから Locks-> lock escalation イベントを使用して確認できます。

デッドロックの実際の原因を特定するために、デッドロック トレースをキャプチャすることをお勧めします。

于 2012-12-19T06:24:45.973 に答える