SQL Server 2008r2データベースが子テーブルと親テーブル(外部キー制約に関連する)の両方に更新ステートメントを同時に受信していた場合、更新ステートメントはデッドロック状況を作成できますか?T-SQLでは、親テーブルと子テーブルへの更新ステートメントがデッドロックする可能性はありますか?
コメントに基づく注:この状況で更新されるフィールドはキーフィールドではなく、カウンタフィールドのみです。
ありがとうございました。
SQL Server 2008r2データベースが子テーブルと親テーブル(外部キー制約に関連する)の両方に更新ステートメントを同時に受信していた場合、更新ステートメントはデッドロック状況を作成できますか?T-SQLでは、親テーブルと子テーブルへの更新ステートメントがデッドロックする可能性はありますか?
コメントに基づく注:この状況で更新されるフィールドはキーフィールドではなく、カウンタフィールドのみです。
ありがとうございました。
はいできます。ここに証拠があります:
--setup
use tempdb;
create table Parent (
ParentID int not null,
constraint PK_Parent primary key clustered (ParentId)
);
insert into Parent values (1), (2), (3);
create table Child (
ChildId int identity,
constraint PK_Child primary key clustered (ChildId),
ParentId int,
constraint FK_Child_Parent foreign key (ParentId)
references Parent (ParentId)
);
insert into Child (ParentId) values (2), (2), (3);
--in window 1
use tempdb;
begin tran;
update Child set ParentId = 1 where ParentId = 3;
--in window 2
use tempdb;
begin tran;
update Parent set ParentId = 4 where ParentId = 1;
--back in window 1
update Child set ParentId = 4 where ParentId = 2;
私はこれをテストし、デッドロックを生成することができました。
ええ、主キーを更新しています... –
問題の声明にそのような前提はありませんでした。実用主義はさておき、これは起こり得る。 –
真実 - それほど一般的ではない –
いいえデッドロックには共有依存関係が必要です。 – bnieland
はい私は、外部キー制約によって参照される値自体が更新によって変更される可能性があると信じています。彼らは?わかりやすくするために、問題のシナリオのテーブルスキーマを共有することをお勧めします。 –
@bnieland私はPK FK関係を共有依存関係とみなします。 – Paparazzi