삭제 명령문의 교착 상태

SQL Server 작업이 실행될 때 교착 상태가 발생합니다. 교착 상태는 간단한 DELETE 문에서 발생합니다. 교착 상태를 유발하기 위해 SELECT / UPDATE 쿼리가 실행 중이어야한다고 생각 했습니까? 그러나 DELETE / DELETE 교착 상태 인 것 같습니다 ...

내가 찾고있는 것은 왜 DELETE / DELETE 교착 상태가 발생하는지입니다. 그것은 다른 매개 변수를 전달하는 것입니다.

어떤 아이디어? 감사.

deadlock-list
2014-05-20 07:30:09.66 spid25s      deadlock victim=process409048
2014-05-20 07:30:09.66 spid25s       process-list
2014-05-20 07:30:09.66 spid25s        process id=process409048 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127294 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x397219620 lockMode=U schedulerid=5 kpid=3792 status=suspended spid=150 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process432e08 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=2648 ownerId=629859744 transactionname=DELETE lasttranstarted=2014-05-20T07:30:04.833 XDES=0x4c3426b50 lockMode=U schedulerid=6 kpid=5988 status=suspended spid=146 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:04.833 lastbatchcompleted=2014-05-20T07:30:04.820 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629859744 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process39ea562c8 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x13e0e4b50 lockMode=U schedulerid=2 kpid=7124 status=suspended spid=150 sbid=0 ecid=1 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2

내가 찾고있는 것은 왜 DELETE / DELETE 교착 상태가 발생하는지입니다.

교착 상태는 다음과 같은 이유로 발생합니다.

1. spid 54 ecid 0에 업데이트 ( U) 페이지 잠금을 얻습니다 .PAGE: 12:1:5147422
2. spid 166 ecid 3U같은 페이지에서 업데이트 ( ) 페이지 잠금을 요청하고 차단됨
3. spid 54 ecid 2U같은 페이지에서 업데이트 ( ) 페이지 잠금을 요청합니다 ...

에 의해 획득 된 업데이트 잠금과 ​​함께 페이지가 쿼리에 대해 프리 페치됩니다 ecid 0. 위의 1 단계입니다. 3 단계에서 동일한 병렬 쿼리 ( ecid 2) 의 하위 스레드가 동일한 잠금을 요청합니다. 일반적으로 이것은 문제가되지 않습니다. SQL Server는 알고 ecid 0와 ecid 2같은 부모 프로세스의 스레드입니다. 불행히도 2 단계는이 과정을 방해하고 교착 상태가 발생합니다.

즉, 교착 상태가 발생 하는 이유 에 대해별로 신경 쓰지 않아야 하며 중요한 질문은 어떻게 피해야하는지입니다. 대답은에 대한 효율적인 액세스 경로를 제공하는 것 DELETE입니다. 명령문은 rows를 찾아야 WHERE Username = @P1 AND UserDate = @P2하므로이 열에 키를 입력해야합니다.

그리고 물론 당신은 그러한 색인을 가지고 있습니다. 진짜 문제는 문제가 필터링 된 인덱스를 추가 한 후 발생하는 시작하는 이유입니다.

이에 대한 대답은 필터링 할 인덱스 행을 찾아 삭제하고 조건자를 확인하기 위해 추가 열 정보가 필요하다는 것입니다. 쿼리가 행 / 좁은 행 실행 계획 을 사용하는 경우 실행 엔진은 너비 / 인덱스 계획에서와 같이 클러스터형 인덱스 삭제 연산자에서 추가 열을 페치 할 수 없습니다.

이 블로그 게시물에서 이에 대한 자세한 내용과 예제 를 찾을 수 있습니다 .

이 경우 열 정보는 계획의 일부에서 클러스터형 인덱스 삭제 오른쪽으로 가져와야하므로 병렬 클러스터형 인덱스 스캔이 사용되므로 교착 상태 가능성이 높은 쿼리가 느려집니다.

대답은 다음 중 하나를 수행하는 것입니다.

1. 필터링 된 인덱스 제거
2. 기존 이름 / 날짜 색인에 필터링 된 색인 키 / 포함 / 조건 자 열 추가
3. 광범위한 업데이트 계획 시행 ( 지원되는 방법 없음 )
4. 스냅 샷 격리 (RCSI 아님)에서 쿼리 실행

옵션 2는 제가 선호하는 것입니다.

옵션 4 (Jack Douglas에게 감사)는 교착 상태를 제거 할 수 있다는 이점이 있으며 변경의 불연속적인 특성을 고려할 때 "업데이트 충돌"을 발생 시키지 않아야 하지만 데이터베이스 수준에서 스냅 샷 격리를 활성화하고 격리 수준을 명시 적으로 변경해야합니다. 그리고 근본적인 문제를 해결하지 않을 것이다 : 당신은 여전히 좋은 지수는 당신이 정말로 원하는 무엇을 추구 낭비 병렬 테이블 스캔, 될 겁니다.