0

ここで何が起こっているのかを正確に理解しようとしています。選択/更新の組み合わせがデッドロックを引き起こす可能性があることを認識しています-この場合、長い待ち時間です。

シナリオは次のとおりです。クエリ A は、3 つのインデックスを使用する選択ステートメントです (非常に単純化されています)。

select * from ProblemTable Where Plan_Id=@planId and 
    Date_entered Between @startDate and @endDate and nabp=@nabp

インデックスはすべて非クラスタ化されています:

  1. Plan_Id
  2. Date_Entered
  3. Plan_Id、nabp

すべてに ProblemTable.Unique_Id の「出力」があります

クエリ B は、2 つのインデックスを使用する更新ステートメントです。

インデックスは次のとおりです。

  1. クラスター化されていない Date_Entered ASC、Source ASC、DataStartOffset ASC
  2. インデックス 1 のインデックス検索の結果で使用される Unique_Id のクラスター化インデックス。

更新クエリ:

Update ProblemTable Set ProcessingTime=@processingTime 
Where dateadd(dd, -datediff(dd, date_entered, 1), 1) = 
dateadd(dd, -datediff(dd, getdate(), 1), 1) 
and DateSource = 'xxyyzz' and DataStartOffset = 93148143

私は知っています.. dateaddは間抜けです。私はこれを書いていません:)

したがって、これはクエリ A とは別のインデックスをスキャンしますが、Date_Entered も使用します。このような状況のため、長い待ち時間が発生し続けます。デッドロックは発生していないように見えますが、各クエリが通常数秒で実行される場合、5 分以上の待機時間が発生する可能性があります。

これは、INSERT into ProblemTable でも発生することに注意してください。

したがって、SELECT stmt は、NC インデックス検索に基づいて最終的に選択することを決定した行のロックを取得し、更新ステートメントは、NC インデックスでの検索から返された行のロックを取得しようとすると推測しています。しかし、デッドロックが発生していないのに、なぜ長い時間がかかるのでしょうか?

質問は基本的に次のとおりです。

1 デッドロックではなく長い待機時間はなぜですか? 2. 何が原因ですか?

ここで利用できる十分な情報はありますか？

EDIT 1両方のクエリはかなり高速で、どちらもこれほど長くかかりません。長い時間は、ここでの「何らかの」未知のロックの問題の結果です。進行中の他の明示的なトランザクションはありません。

4

2 に答える 2

0

単一のテーブルからの選択では、通常、単一のインデックスが使用されます。使用可能なインデックスが複数ある場合、SQL Server は、自動的に格納された統計に基づいて、最も限定的なインデックスを選択しようとします。

5 分間待機する更新は正常ではありません。何がそれを妨げているのかを突き止めてみてください。Adam Machanic の sp_WhoIsActiveは良い出発点です。私の通常の疑いは、本来あるべきほど迅速にコミットされていない長時間実行されるトランザクションです。

于 2011-06-27T15:36:22.540 に答える
-1 
You can use Sql Profiler for the root cause of this issue.

このテーブルにトリガーを使用していますか?

selectステートメントにNo Locksを使用できます

于 2011-06-28T05:26:57.373 に答える