id 필드에서 클러스터 및 비 클러스터형 인덱스를 사용할 때 잠금 동작이 다른 것을 알면서 교착 상태 문제를 해결하고 있습니다. 교착 상태 문제는 클러스터링 된 인덱스 또는 기본 키가 id 필드에 적용된 경우 해결 된 것으로 보입니다.
다른 행에 대해 하나 이상의 업데이트를 수행하는 다른 트랜잭션이 있습니다. 예를 들어 트랜잭션 A는 ID = a로 행만 업데이트하고 tx B는 ID = b로 행만 만집니다.
그리고 인덱스가 없으면 업데이트가 모든 행에 대한 업데이트 잠금을 획득하고 필요할 때 독점 잠금으로 은닉하여 결국 교착 상태로 이어진다는 것을 이해했습니다. 그러나 클러스터되지 않은 인덱스를 사용하는 경우 교착 상태가 여전히 존재하는 이유를 알 수 없습니다 (적중률이 떨어지는 것처럼 보입니다)
데이터 테이블 :
CREATE TABLE [dbo].[user](
[id] [int] IDENTITY(1,1) NOT NULL,
[userName] [nvarchar](255) NULL,
[name] [nvarchar](255) NULL,
[phone] [nvarchar](255) NULL,
[password] [nvarchar](255) NULL,
[ip] [nvarchar](30) NULL,
[email] [nvarchar](255) NULL,
[pubDate] [datetime] NULL,
[todoOrder] [text] NULL
)
교착 상태 추적
deadlock-list
deadlock victim=process4152ca8
process-list
process id=process4152ca8 taskpriority=0 logused=0 waitresource=RID: 5:1:388:29 waittime=3308 ownerId=252354 transactionname=user_transaction lasttranstarted=2014-04-11T00:15:30.947 XDES=0xb0bf180 lockMode=U schedulerid=3 kpid=11392 status=suspended spid=57 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2014-04-11T00:15:30.953 lastbatchcompleted=2014-04-11T00:15:30.950 lastattention=1900-01-01T00:00:00.950 clientapp=.Net SqlClient Data Provider hostname=BOOD-PC hostpid=9272 loginname=getodo_sql isolationlevel=read committed (2) xactid=252354 currentdb=5 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
executionStack
frame procname=adhoc line=1 stmtstart=62 sqlhandle=0x0200000062f45209ccf17a0e76c2389eb409d7d970b0f89e00000000000000000000000000000000
update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@owner
frame procname=unknown line=1 sqlhandle=0x00000000000000000000000000000000000000000000000000000000000000000000000000000000
unknown
inputbuf
(@para0 nvarchar(2)<c/>@owner int)update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@owner
process id=process4153468 taskpriority=0 logused=4652 waitresource=KEY: 5:72057594042187776 (3fc56173665b) waittime=3303 ownerId=252344 transactionname=user_transaction lasttranstarted=2014-04-11T00:15:30.920 XDES=0x4184b78 lockMode=U schedulerid=3 kpid=7272 status=suspended spid=58 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2014-04-11T00:15:30.960 lastbatchcompleted=2014-04-11T00:15:30.960 lastattention=1900-01-01T00:00:00.960 clientapp=.Net SqlClient Data Provider hostname=BOOD-PC hostpid=9272 loginname=getodo_sql isolationlevel=read committed (2) xactid=252344 currentdb=5 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
executionStack
frame procname=adhoc line=1 stmtstart=60 sqlhandle=0x02000000d4616f250747930a4cd34716b610a8113cb92fbc00000000000000000000000000000000
update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@uid
frame procname=unknown line=1 sqlhandle=0x00000000000000000000000000000000000000000000000000000000000000000000000000000000
unknown
inputbuf
(@para0 nvarchar(61)<c/>@uid int)update [user] WITH (ROWLOCK) set [todoOrder]=@para0 where id=@uid
resource-list
ridlock fileid=1 pageid=388 dbid=5 objectname=SQL2012_707688_webows.dbo.user id=lock3f7af780 mode=X associatedObjectId=72057594042122240
owner-list
owner id=process4153468 mode=X
waiter-list
waiter id=process4152ca8 mode=U requestType=wait
keylock hobtid=72057594042187776 dbid=5 objectname=SQL2012_707688_webows.dbo.user indexname=10 id=lock3f7ad700 mode=U associatedObjectId=72057594042187776
owner-list
owner id=process4152ca8 mode=U
waiter-list
waiter id=process4153468 mode=U requestType=wait
또한 흥미롭고 가능한 관련 발견은 클러스터형 및 비 클러스터형 인덱스의 잠금 동작이 서로 다른 것 같습니다
클러스터형 인덱스를 사용하는 경우 업데이트시 키에 대한 독점 잠금과 RID의 독점 잠금이 있습니다. 비 클러스터형 인덱스를 사용하는 경우 두 개의 서로 다른 RID에 대해 두 개의 배타적 잠금이 존재하므로 혼란 스럽습니다.
누군가도 이것에 대해 설명 할 수 있다면 도움이 될 것입니다.
SQL 테스트 :
use SQL2012_707688_webows;
begin transaction;
update [user] with (rowlock) set todoOrder='{1}' where id = 63501
exec sp_lock;
commit;
클러스터형 인덱스로 ID를 사용하는 경우 :
spid dbid ObjId IndId Type Resource Mode Status
53 5 917578307 1 KEY (b1a92fe5eed4) X GRANT
53 5 917578307 1 PAG 1:879 IX GRANT
53 5 917578307 1 PAG 1:1928 IX GRANT
53 5 917578307 1 RID 1:879:7 X GRANT
비 클러스터형 인덱스로 id 사용
spid dbid ObjId IndId Type Resource Mode Status
53 5 917578307 0 PAG 1:879 IX GRANT
53 5 917578307 0 PAG 1:1928 IX GRANT
53 5 917578307 0 RID 1:879:7 X GRANT
53 5 917578307 0 RID 1:1928:18 X GRANT
EDIT1 : 인덱스가없는 교착 상태에 대한 세부 사항
두 개의 tx A와 B가 있고 각각 두 개의 업데이트 문이 있고 행
tx A가 다릅니다 .
update [user] with (rowlock) set todoOrder='{1}' where id = 63501
update [user] with (rowlock) set todoOrder='{2}' where id = 63501
tx B
update [user] with (rowlock) set todoOrder='{3}' where id = 63502
update [user] with (rowlock) set todoOrder='{4}' where id = 63502
{1} 및 {4}는 교착 상태가 발생할 수 있습니다.
{1}에서, 테이블 스캔을 수행해야하기 때문에 행 63502에 대해 U 잠금이 요청되고 조건과 일치하므로 행 63501에서 X 잠금이 보유 될 수 있습니다.
{4}에서 행 63501에 대해 U 잠금이 요청되고 X 잠금이 이미 63502에 대해 보류됩니다.
txA는 63501을 보유하고 있으며 63502를 대기하고 txB는 63502를 대기하고 있으며 이는 교착 상태입니다.
EDIT2 : 내 테스트 케이스 의 버그가 여기에 차이가 있음을 나타 냅니다 혼란에 대한 죄송하지만 버그가 차이 상황을 만들어 결국 교착 상태를 일으키는 것으로 보입니다.
이 경우 Paul의 분석이 실제로 도움이되었으므로 답변으로 받아들입니다.
내 테스트 케이스의 버그로 인해 두 개의 트랜잭션 txA와 txB가 아래와 같이 동일한 행을 업데이트 할 수 있습니다.
tx A
update [user] with (rowlock) set todoOrder='{1}' where id = 63501
update [user] with (rowlock) set todoOrder='{2}' where id = 63501
tx B
update [user] with (rowlock) set todoOrder='{3}' where id = 63501{2} 및 {3}은 다음과 같은 경우 교착 상태가 발생할 수 있습니다.
txA는 RID에 대한 X 잠금을 유지하면서 키에 대한 U 잠금을 요청합니다 ({1}의 업데이트로 인해). txB는 키에 대한 U 잠금을 유지하면서 RID에 대한 U 잠금을 요청합니다.
