INF: 분석 및 SQL Server 에서 교착 상태 방지

기술 자료 번역 기술 자료 번역
기술 자료: 169960 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

이 페이지에서

요약

Microsoft SQL Server 잠금을 사용하여 트랜잭션 무결성 및 데이터베이스 일관성을 유지합니다. SQL Server 버전 6.5 선택적으로 삽입 작업을 행 수준 잠금을 사용하고 다른 작업에 대해 페이지 수준 잠금을 사용합니다. 모든 관계형 데이터베이스 시스템과 마찬가지로, 잠금 교착 상태 수 사용자 간에 발생할 수 있습니다.

예를 들어, User1 (또는 Connection1) 잠금을 경우를 가정해 보겠습니다 데이터 항목 "A" 및 "B" 데이터 항목을 잠그려고합니다 User2가 데이터 항목 "B" 잠금을 가지며 이제 데이터 항목 "A" 잠그려고 이 SQL Server 시나리오에서는 User1 또는 User2가 교착 상태가 발생하여 수 있으며 다른 사용자가 요청한 잠금이 부여됩니다.

SQL Server에서 SET DEADLOCK_PRIORITY 교착 상태가 발생하여 후보 어떤 연결이 됩니다 응용 프로그램 개발자가 결정할 수 있습니다. 개발자는 교착 상태 우선 순위를 지정하는 경우, SQL Server 교착 상태가 발생하여를 잠금 순환 체인에서 완료된 프로세스를 선택하여 선택하는 예제입니다.

데이터베이스 응용 프로그램 시스템을 동작할 수 있습니다 관계형 데이터베이스 간에 다른 컴퓨터로 이식할 때 관계형 데이터베이스 시스템 구현에 따라 다르게 기반으로. 행태 변경 내용을 볼 수 있는 영역 중 하나가 잠그는 것입니다. 이 문서에서는 SQL Server 및 이를 방지하기 위해 사용할 수 있는 기술을 교착 상태를 분석하는 방법을 설명합니다.

추가 정보

이 문서에서는 추적 플래그 T1204 출력을 사용하여 교착 상태를 분석할 강조합니다. 추적 플래그 T1204 설정되어 있으면 발생할 때 SQL Server 교착 상태에 대한 정보를 인쇄합니다. 이 추적 플래그를 사용하여 SQL Server 시작하려면 명령 프롬프트에서 다음 명령을 사용합니다.
   sqlservr -c -T1204
				

오류 로그로 추적 결과를 보냅니다 추적 플래그 T3605, 설정하지 않으면 추적 결과가 콘솔 창에 보냅니다.

두 개의 연결을 반대 순서로 테이블을 업데이트할 때 교착 상태가 발생할 수 있습니다. 예를 들어, 다른 연결 테이블에 첫 번째 "example2" 및 "example1" 트랜잭션 내에서 데이터를 삽입하는 동안 한 연결 테이블에 첫 번째 "example1" 및 "example2" 로 삽입합니다. 교착 상태를 방지하는 방법을 설명하기 위해 예제 시나리오에 유용합니다.

이 예제에서는 테이블을 만드는 데 사용하는 SQL 문을 다음과 같습니다.
   create table example1 (column1 int, column2 char(20), column3 char(50))
   go
   create table example2 (column1 int, column2 char(20), column3 char(50))
   go
   declare @lvar int
   select @lvar = 0
   while @lvar < 500
   begin
   insert into example1 values (@lvar, 'AAA', 'CCC')
   insert into example2 values (@lvar, 'AAA', 'CCC')
   select @lvar = @lvar + 1
   end
   go
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
   create unique clustered index ex2ind1 on example2 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
				

대향 순서로 예제 1: 테이블 삽입

이 예제에서는 두 개의 테이블을 반대 순서로 삽입된 및 교착 상태가 발생했습니다. 반대 순서로 테이블에 대한 업데이트나 삭제가 더 많은 연결을 수행하는 교착 상태는 두 때에도 발생할 수 있습니다.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
				

이 시점에서 Connection1 행이 이미 삽입된 및 잠금이 있습니다 같은 페이지에 Connection2 삽입 행 수 있기 때문에 Connection1 Connection2를 차단할 수 있습니다.
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

이 시점에서 Connection2 Connection1, Connection2 행이 이미 삽입된 및 잠금을 보유하는 같은 페이지에 Connection1 삽입 행 수도 있으므로 차단할 수 있습니다. 이로 인해 교착 상태가 발생합니다.

추적 플래그 1204 때 교착 상태가 발생한 출력 다음과 같습니다.
97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES (100,
     'AAAA', 'CCC')
   spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (200,
   'AAAB', 'CCC')
   VICTIM: spid 13, pstat 0x0000 , cputime 30
				

교착 상태 추적 메시지의 각 줄에 사용자가 알 수 교착 상태를 자세히. Connection1 spid 13 있고 Connection2 spid 14 sp_who 시스템 저장 프로시저를 사용하여 연결이 연결된 spid 확인할 수 있습니다.
   >> 97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   The deadlock was detected between spid 13 and spid 14.
   >> spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES
   (100, 'AAAA', 'CCC')
				

Spid 13 EX_PAGE 잠금을 요청하는 및 테이블 example2 0x188 페이지에 대한 EX_PAGE 잠금을 dbid 6 이미 spid 14, 의해 차단되었습니다. 클러스터된 인덱스가 속한 페이지에서 잠금이 있습니다.
      Indid Value         Description
-------------------------------------
         0                Data page if there is no clustered index, or the
                          leaf page of a clustered index if there is one
         1                Non-leaf page of the clustered index page
       255                Text/image page
    Any other value       Non-clustered secondary index
				

현재 명령 13 spid에 의해 실행된 INSERT 있고 입력된 버퍼 일부가 추적을 제공합니다.
   >> spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES
   (200, 'AAAB', 'CCC')
				

Spid 14 EX_PAGE 잠금을 기다리는 및 EX_PAGE 잠금이 같은 페이지에 이미 spid 13, 의해 차단되었습니다.
   >> VICTIM: spid 13, pstat 0x0000 , cputime 30
   SQL Server has chosen spid 13 as the deadlock victim.
				

다양한 잠금 추적에서 의미에 대한 설명과 다음과 같습니다.

SH_INT 및 EX_INT
잠금 관리자에 다른 유형의 항목에 (이 경우, 페이지 및 테이블 간의 관계를 인식하지 않으므로 상위 수준의 항목 (예: 테이블) 하위 수준 잠금 (예를 들어, 페이지) 전에 수행되는 의도 잠금, 가져올 수 있습니다. 페이지에 EX_PAG 잠금을 넘어가려면 EX_INT 잠금을 테이블에 찍은 않는 경우 다른 사용자가 같은 테이블에 EX_TAB 잠금을 수행할 수 및 충돌이 존재하는 잠금 관리자가 알 수 없습니다. 현재 SQL Server 의도 잠금 테이블을 기반으로 합니다. 두 종류의 의도 잠금: 공유 (SH_INT) 및 (EX_INT) 단독 잠금을 설정합니다.

EX_PAGE
INSERT 문을 사용 안 함 (IRL을) 행 수준 잠금 삽입 또는 UPDATE, DELETE 인해 페이지를 업데이트할 때 수행되는 단독 페이지 잠금입니다.

UP_PAGE
이 페이지 공유 잠금 대신 페이지를 스캔한 페이지를 업데이트한 최적화 알고 때 수행되는 업데이트 페이지 잠금이 또는 UPDLOCK 힌트 사용됩니다.

PR_EXT, NX_EXT, UPD_EXT, 및 EX_EXT
이러한 잠금은 할당되거나 디스크 공간 할당 해제 때 수행됩니다. UPD_EXT 할당 또는 페이지에서 기존 익스텐트 할당 해제 때 수행되는 및 다른 할당 또는 할당 해제 전체 익스텐트를 때 사용됩니다.

IX_PAGE 및 LN_PAGE
이러한 IRL을 잠금이 있습니다. 페이지에 대한 의도를 수-일-행-잠금 잠금을 IX_PAGE가 있습니다. LN_PAGE 있는 IRL을 분할해야 하는 수행되는 것이 페이지 때 수행되지 않습니다.

RLOCK 및 XRLOCK
이러한 단기 잠금 않은 인덱스 B-트리 통과하는 때 수행됩니다. 가지 두 종류의 이러한 종류의 잠금: 공유 (RLOCK) 및 단독 (XRLOCK). 단독 잠금이 인덱스 페이지를 업데이트하는 동안 수행되는 동안 검색하는 동안 공유 잠금은 가져옵니다.

EX_TAB
이 SQL Server 최적화 프로그램이 테이블 스캔을 (예를 들어, 테이블에 인덱스가 있는 경우) 업데이트 쿼리를 해결하기 위해 가장 효율적인 방법은 결정됩니다 때 발생하는 단독 테이블 잠금으로 있습니다. EX_TAB 잠금을 TABLOCKX 힌트 또는 페이지 잠금을 테이블 잠금으로 테이블에 대해 SQL Server 에스컬레이션합니다 때 테이블을 잠글 때도 나타납니다.

SH_TAB
공유 이것은 최적화 프로그램은 테이블의 대부분의 때 사용되는 테이블 잠금이 검색됩니다 (또는 페이지 잠금을 에스컬레이션합니다) 또는 TABLOCK 힌트가 사용됩니다.

두 개의 연결이 다음 순서로 테이블을 업데이트하면 이전 교착 상태가 예제에서는 피할 수 있습니다.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

같은 테이블의 다른 파트에 예제 2: 삽입

행 페이지를 공유할 때 반대 순서로 같은 테이블의 다른 부분에 두 개의 연결을 삽입할 때 이 교착 상태가 발생할 수도 있습니다. 예를 들면:
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example1 VALUES (400, 'AAAA', 'CCC')
				

이 예제에서는 테이블의 경우 클러스터된 인덱스를 example1 테이블의 첫 번째 열 첫 번째 열에 대해 같은 값 가진 행을 모두 같은 페이지에 속하는 경향이 있습니다. 둘 다 400 클러스터된 인덱스 값을 가질 수 있기 때문에 예제에서는 Connection1에 의해 삽입된 행 아마도 Connection2에 의해 삽입된 첫 번째 행으로 같은 페이지에 쓰러질 것이다. 블록 Connection1 Connection2가 됩니다.
   Connection2 > INSERT INTO example1 VALUES (100, 'AAAB', 'CCC')
				

이제 Connection2 또한 교착 상태 선행 Connection1에 의해 차단될 수 있습니다. 교착 상태 추적 다음과 같습니다.
   97/04/20 12:56:01.40 spid16   *** DEADLOCK DETECTED with spid 15 ***
   spid 16 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 15, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (100,
   'AAAB', 'CCC')
   spid 15 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 16, dbid 6, page 0x8bd, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (400,
   'AAAA', 'CCC')
   VICTIM: spid 16, pstat 0x0000 , cputime 130
				

첫 번째 삽입 수행한 후 이미 페이지의 0x2c5 EX_PAGE 잠금을 보유하고 있는 spid에 의해 15, 페이지 0x2c5 EX_PAGE 잠금 spid 16 요청이 차단됩니다. 및 spid 15 또한 교착 상태 수 있는 페이지 0x8db 앞에 EX_PAGE 잠금 기다리는 16 spid에 의해 차단된 있어요.

테이블 example1 IRL을 사용하려면 다음 명령을 사용하여 이 교착 상태를 피할 수 있습니다.
   sp_tableoption 'example1', 'insert row lock', true
				

예제 3: 삽입 IRL을 사용

IRL을 종종 더 나은 처리량 결과 둘 이상의 사용자가 작업을 경우에만 삽입 작업을 수행할 때 페이지를 공유할 수 있습니다. 그러나 IRL을 사용하면 항상 교착 상태를 줄일 수 있습니다지 않습니다. 경우에 따라서는 IRL을 교착 상태가 발생할 수 있습니다.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (105, 'AAAB', 'CCC')
				

IRL을 사용할 수 있는 두 개의 새로운 행을 포함하는 페이지에서 두 연결을 IX_PAGE 잠금을 보관합니다. IRL을 사용할 경우 Connection1 EX_PAGE 잠금을 얻은 것입니다 및 Connection2 즉시 차단된 것입니다.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

이 시점에서 Connection2 Connection1의 IX_PAGE 잠금이 호환되지 UPDATE 문 하려면 단독 페이지 잠금을 합니다. 따라서 Connection2가 대기합니다.
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 100
   and column2 = 'AAAA'
				

이제 Connection1 교착 상태 선행 Connection2에 의해 차단될 수 있습니다. 교착 상태 추적 다음과 같습니다.
   97/04/20 15:13:50.07 spid17   *** DEADLOCK DETECTED with spid 18 ***
   spid 17 requesting UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 18, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 100 and column2 = 'AAAA'
   spid 18 waiting for UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 17, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   VICTIM: spid 17, pstat 0x0000 , cputime 20
				

Spid 17 (연결 하나를) 먼저 단독 페이지 잠금을 얻는 데에 대한 UP_PAGE 잠금을 기다리는 중입니다. 페이지 0x2c5 IX_PAGE 잠금을 보유한 spid 18, 의해 차단되지 않습니다. Spid 18 같은 페이지에 UP_PAGE 잠금을 기다리는 및 IX_PAGE 잠금을 보유한 spid 17에 의해 차단된. 반면 UP_LOCK 않은 IX_PAGE 잠금을 공유할, 있기 때문에 교착 상태가 발생합니다. 첫 번째 삽입 시 모두 같은 페이지에 있는 spids IX_PAGE 잠금이 있어요 및 UP_PAGE 잠금을 단독 있기 때문에 어떤 불가능합니다 UP_PAGE 잠금으로 잠금을 업그레이드를 시도한 나중에 자신이.

교착 상태를 방지하는 한 가지 방법은 테이블에 직접 삽입과 같은 트랜잭션에서 행을 업데이트하는 대신 업데이트된 값을 삽입할 수 있습니다. 이 경우 교착 상태가 발생하지 않도록 IRL을 사용하지 않으려면 다음 명령을 사용하여 도와줍니다.
   sp_tableoption 'example1', 'insert row lock', false
				

예제 4: 삽입 같은 페이지의 행 수

또한 두 spids 작업 중인 행을 서로 동일한 페이지에 속하는 경우 교착 상태가 발생할 수 있습니다.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 405
   and column2 = 'AAAA'
				

이 시점에서 Connection1 Connection2에 의해 차단될 수 있습니다. Connection1 Connection2 이미 행이 삽입된 위치를 페이지의 행을 업데이트할 원합니다 때문에 이러한 상황이 발생할 수 있습니다.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

이 시점에서 Connection2 또한 교착 상태가 발생할 Connection1에 의해 차단될 수 있습니다. Connection2 Connection1 행 삽입되어 있는 페이지 행을 업데이트할 때 이러한 상황이 발생할 수 있습니다. 교착 상태 추적 다음과 같습니다.
   97/04/20 15:48:21.18 spid20   *** DEADLOCK DETECTED with spid 19 ***
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x2c4, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0xc48, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 405 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 60
				

다른 페이지 위에 있는 행을 분산시켜 이 교착 상태를 피할 수 있습니다. 이렇게 큰 채우기 비율 가진 이 테이블의 클러스터된 인덱스를 다시 만들어야 하는 한 방법입니다. 채우기 비율을 50 % 로 클러스터된 인덱스를 만드는 문은 다음과 같습니다.
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 50, PAD_INDEX
				

이 문은 페이지 절반을 빈 PAD_INDEX 옵션을 때문에 클러스터된 인덱스의 리프 수준이 아닌 수준을 포함하여 두고 클러스터된 인덱스를 만듭니다. 테이블의 실제 크기를 두 배로 차지하고 어떤 있었던 절반을 페이지 당 행의 수는 있습니다.

테이블에 채우기 비율 유지, 인덱스 작성 시간 동안 지정된 채우기 비율을 가진 re-organized 테이블입니다. 시간이 지남에 따라 페이지 당 행 인덱스를 만드는 동안 지정된 채우기 비율에 에서 변경됩니다. 이 때 원하는 채우기 비율 사용하여 클러스터된 인덱스를 다시 만드는 것이 좋을 수 있습니다.

이전 교착 상태 상황을 피하기 위해 다른 솔루션을 것입니다 (예를 들어, dummy1 char(255)). 더미 열이 포함된 테이블을 패드합니다 행의 크기를 늘리고 (적게는 한 페이지 당 행) 페이지 당 더 적은 행을 이어집니다. 이 유형의 안쪽 시간대별로 관리되므로 안쪽 여백 (다른 이유로 클러스터된 인덱스를 다시 만들려면 원하는 수도 있지만 유지하기 위해 클러스터된 인덱스를 다시 만들 필요가 없습니다. 이 기법의 단점은 저장 공간을 더미 필드를 불필요하게 사용된 것입니다.

예제 5: 행 안쪽 여백

적은 수의 행을 페이지 당 행 안쪽 여백을 이어집니다 (따라서 적은 교착 상태), 있지만 교착 상태를 완전히 제거하는 것입니다.

이 예제에서는 테이블에 example1 페이지 당 한 행을 차지할 채워집니다. 이 예제에서는 테이블을 만드는 데 사용된 문은 다음과 같습니다.
   create table example1 (column1 int, column2 char(20), column3 char(50),
   dummy_column4 char (255), dummy_column5 char (255), dummy_column6 char
   (255))
   go
   create unique index ex1ind5 on example1 (column3, column2, column1,
   dummy_column4, dummy_column5, dummy_column6) with fill factor = 85
   go
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 401
   and column2 = 'AAAA'
				

이 시점에서 Connection1 행을 업데이트하는 동안 Connection2에 의해 차단됩니다. SQL Server 페이지 체인을 포인터를 유지 관리해야 하는 때문에 이전 페이지, 다음 페이지 및 업데이트 중인 페이지를 잠급니다. Connection2 이전 페이지에서 잠금이 때문에 Connection1 Connection2 트랜잭션이 커밋될 때까지 기다려야 합니다.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 101
   and column2 = 'AAAB'
				

Connection1에 의해 현재 잠겨 이전 페이지 잠금 합니다 이 시점에서 Connection2 Connection1에 의해 차단되었습니다. 교착 상태가 발생합니다. 교착 상태 추적 다음과 같습니다.
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x12b5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 101 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0x1531, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 401 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 300
				

더미 행을 업데이트 또는 삭제된 삽입되는 있는 행 사이에 삽입하여 이 교착 상태를 피할 수 있습니다. Connection1 (삽입, 업데이트 또는 삭제) 행 pk 작동하는 경우 예를 들어, 1 행 pk Connection2 작동하는 = 및 = 5, 이러한 두 행 사이에 행을 삽입 (pk 포함하는 행을 같은 = 3) 교착 상태를 방지합니다. 이 메서드는 테이블의 크기를 증가하지만 중요한 응용 프로그램에 해당 큐에 테이블 가장 좋은 방법일 수 있습니다.

예제 6: 클러스터되지 않은 인덱스

일부의 경우, 클러스터되지 않은 인덱스가 보조 교착 상태가 발생할 수 있습니다. 이 예제에서는 보조 인덱스 유지 관리 교착 상태가 도입되었습니다.

이 예제에서는 보조 인덱스를 만드는 데 사용된 문은 다음과 같습니다.
   create index ex1ind2 on example1 (column3) with fill factor = 90,
   PAD_INDEX
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCBA', ' ', '
   ', ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (300, 'AAAB', 'CCCZ', ' ', '
   ', ' ', ' ')
   Connection2 > UPDATE example1 SET column3 = 'CCBA' where column1 = 105
				

이 시점에서 Connection1 보조 클러스터되지 않은 인덱스 페이지에서 Connection2 업데이트해야 하는 잠금이 수 수 있기 때문에 Connection2 Connection1에 의해 차단될 수 있습니다.
   Connection1 > UPDATE example1 SET column3 = 'CCCZ' where column1 = 305
				

이 시점에서 Connection1 교착 상태가 발생하는 Connection2에 의해 차단될 수 있습니다. Connection1 Connection2 이미 삽입된 및 해당 페이지에 잠금이 클러스터되지 않은 보조 인덱스 업데이트 잠금을 기다리는 경우 이 이런 상황이 발생할 수 있습니다. 이 교착 상태 예를 들어 교착 상태 추적 다음과 같습니다.
   97/04/20 19:05:38.75 spid11   *** DEADLOCK DETECTED with spid 12 ***
   spid 11 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 12, dbid 6, page 0x112f, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCZ' where column1 = 305
   spid 12 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 11, dbid 6, page 0x1108, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCBA' where column1 = 105
   VICTIM: spid 11, pstat 0x0000 , cputime 50
				

보조 인덱스를 삭제하면 이 교착 상태를 피할 수 있습니다. 클러스터되지 않은 보조 인덱스를 제거하여 경우에만 또는 응용 프로그램을 수정하여 이러한 상황을 피할 수 있습니다 한 페이지에 한 행을 포함하므로 인덱스 채울 수 없습니다.

교착 상태 교착 상태 추적 수도 있는 교착 상태 및 충돌하는 잠금이 관련된 spids 나열되어 있으며 이 경우 두 개 이상의 연결을 사용할 경우 발생할 수 있습니다. 인덱스를 통과하는 동안 얻은 RLOCK 및 XRLOCK 잠금을 교착 상태가 발생할 수 있습니다. 익스텐트 잠금 PR_EXT, NX_EXT, UPD_EXT 및 EX_EXT 인해 교착 상태가 발생할 수도 있습니다.

교착 상태를 분석하는 방법에 대한 자세한 내용은 다음 추적 플래그를 사용할 수 있습니다.

t1200
발생할 때 교착 상태 또는 관련된 여부를 모든 잠금 요청/릴리스 정보를 인쇄합니다. 이 성능 측면에서 비용이 많이 있지만 분석에 유용하게 사용할 수 있습니다.

t1206
모든 교착 상태 참여 spids 보유한 잠금 인쇄합니다.

t1208
호스트 이름 및 클라이언트가 제공하는 프로그램 이름을 인쇄합니다. 이 클라이언트가 각 연결에 대해 고유한 값을 지정하는 가정할 경우 클라이언트가 교착 상태에 관련된 식별할 수 있습니다.

속성

기술 자료: 169960 - 마지막 검토: 2003년 10월 16일 목요일 - 수정: 3.0
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft SQL Server 6.5 Standard Edition
키워드:?
kbmt kbhowto kbusage KB169960 KbMtko
기계 번역된 문서
중요: 본 문서는 전문 번역가가 번역한 것이 아니라 Microsoft 기계 번역 소프트웨어로 번역한 것입니다. Microsoft는 번역가가 번역한 문서 및 기계 번역된 문서를 모두 제공하므로 Microsoft 기술 자료에 있는 모든 문서를 한글로 접할 수 있습니다. 그러나 기계 번역 문서가 항상 완벽한 것은 아닙니다. 따라서 기계 번역 문서에는 마치 외국인이 한국어로 말할 때 실수를 하는 것처럼 어휘, 구문 또는 문법에 오류가 있을 수 있습니다. Microsoft는 내용상의 오역 또는 Microsoft 고객이 이러한 오역을 사용함으로써 발생하는 부 정확성, 오류 또는 손해에 대해 책임을 지지 않습니다. Microsoft는 이러한 문제를 해결하기 위해 기계 번역 소프트웨어를 자주 업데이트하고 있습니다.
더 이상 지원되지 않는 제품의 KB 내용에 대한 고지 사항
이 문서에서는 Microsoft에서 더 이상 지원하지 않는 제품에 대해 설명합니다. 따라서 이 문서는 "있는 그대로" 제공되며 업데이트되지 않습니다.

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com