UPDATEヒープテーブル - RIDのデッドロック

Question

デッドロックのシナリオを証明するためのテストケースを設定しており、何が起こっているのかについていくつかの洞察が必要です。 私はheapTableと呼ばれるヒープテーブルを持っています。この表は、2つのトランザクションによってシミュレートされて更新されます。

トランザクション1：

BEGIN TRAN 

UPDATE HeapTable 
SET FirstName = 'Dylan' 
WHERE FirstName = 'Ovidiu'; 

WAITFOR DELAY '00:00:15'; 

UPDATE HeapTable 
SET FirstName = 'Bob' 
WHERE FirstName = 'Thierry'; 

ROLLBACK TRANSACTION 

トランザクション2：

BEGIN TRAN 

UPDATE HeapTable 
SET FirstName = 'Pierre' 
WHERE FirstName = 'Michael'; 

ROLLBACK TRAN 

I最初のトランザクション1、予想トランザクション1は、いくつかの排他ロックを主張すると密接にトランザクション2が続くオフ火災排他的なものをいくつか意図しています。トランザクション2が来て、同じRIDに更新ロックを要求します：私は、これは単一の指すと思ったので、

spid dbid ObjId  IndId Type Resource  Mode Status 
55 5  711673583 0  RID  1:24336:10 X  GRANT 
57 5  711673583 0  RID  1:24336:10 U  WAIT 

私は、一種の2番目のトランザクションが同じRIDに更新ロックを求める見て驚きました&両方の更新ステートメントは異なるデータを処理します。私は何とか代わりにページレベルでの競合を期待していました。トランザクションの2回目の更新トランザクション2の1つのキックは、トランザクション1

のトランザクション2 &完了のロールバックが生じデッドロックの対象として見られる

2番目のトランザクションが更新を必要とする理由を誰かが私に説明できます別のレコードを更新しても同じRIDでロックしますか？

Answer 1

別のレコードを更新しても、2番目のトランザクションで同じRIDで更新ロックが必要な理由を説明できますか？

SQLは、ページ上の意図排他ロックがかかり、その後、Uを取るしようと何のインデックスが存在しない場合、UPDATE文は、更新する必要があるテーブルのロックを取得する方法、など。これは言い換えることができ

読み込み前にページの行をロックして、更新される値と一致する場合、このロックはXロックに変換されます。

このUロック戦略は、他の互換性のないロック同じ行に撮影されます

以下のリンクを参照してくださいKデラニーアレン同じ

http://sqlblog.com/blogs/kalen_delaney/archive/2009/11/13/update-locks.aspx