다른 프로세스에서 동일한 임시 테이블의 잠금에서 교착 상태

내가 불가능하다고 생각한 것을 보여주는 교착 상태를 발견했습니다. 교착 상태와 관련된 두 가지 프로세스가 있습니다.

1. process8cf948 SPID 63

임시 테이블 #PB_Cost_Excp_Process_Invoices_Work에서 ALTER TABLE 수행
오브젝트 ID가 455743580 인 테이블 #PB_Cost_Excp_Process_Invoices_Work에서 IX 잠금을 소유합니다.

2. process4cb3708 SPID 72

임시 테이블 #PB_Cost_Excp_Process_Invoices_Work에서 UPDATE로 수행하며, 고유 한 테이블 사본이어야합니다.
동일한 객체 ID가 455743580 인 #PB_Cost_Excp_Process_Invoices_Work 에서 Sch-M 잠금을 소유 합니다 !

불가능합니다. 뭔가 빠졌습니까? 이 두 SPID간에 #Temporary 테이블이 실제로 재사용 되었습니까?

누적 업데이트 1 (버전 10.50.4260)이 포함 된 SQL Server 2008 R2 서비스 팩 2에 있습니다.

변경되지 않은 전체 교착 상태 추적은 다음과 같습니다. 두 프로세스가 모두 테이블 이름이 # PB_Cost_Excp_Process_Invoices_Work_SNIP_0000000D8519 인 동일한 오브젝트 ID에서 어떻게 작동하는지 참고하십시오.

12/14/2012 13:46:03,spid23s,Unknown,waiter id=process8cf948 mode=X requestType=wait
12/14/2012 13:46:03,spid23s,Unknown,waiter-list
12/14/2012 13:46:03,spid23s,Unknown,owner id=process4cb3708 mode=Sch-M
12/14/2012 13:46:03,spid23s,Unknown,owner-list
12/14/2012 13:46:03,spid23s,Unknown,objectlock lockPartition=0 objid=455743580 subresource=FULL dbid=2 objectname=tempdb.dbo.#PB_Cost_Excp_Process_Invoices_Work_________________________________________________________________________________0000000D8519 id=lock371705d00 mode=Sch-M associatedObjectId=455743580
12/14/2012 13:46:03,spid23s,Unknown,waiter id=process4cb3708 mode=Sch-M requestType=wait
12/14/2012 13:46:03,spid23s,Unknown,waiter-list
12/14/2012 13:46:03,spid23s,Unknown,owner id=process8cf948 mode=IX
12/14/2012 13:46:03,spid23s,Unknown,owner-list
12/14/2012 13:46:03,spid23s,Unknown,objectlock lockPartition=3 objid=455743580 subresource=FULL dbid=2 objectname=tempdb.dbo.#PB_Cost_Excp_Process_Invoices_Work_________________________________________________________________________________0000000D8519 id=lock3139b4780 mode=IX associatedObjectId=455743580
12/14/2012 13:46:03,spid23s,Unknown,resource-list
12/14/2012 13:46:03,spid23s,Unknown,Proc [Database Id = 8 Object Id = 1857974987]
12/14/2012 13:46:03,spid23s,Unknown,inputbuf
12/14/2012 13:46:03,spid23s,Unknown,EXEC PB_ProcessExc_Costs_Submit_SP @SiteKey, @PWDate
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.DR_SubmitPaperwork_SP line=174 stmtstart=12912 stmtend=13018 sqlhandle=0x03000800cb72be6e500434018da000000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,EXEC PB_ProcessExc_Costs_Create_SP

    -- Clean up work table
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_Submit_SP line=138 stmtstart=11890 stmtend=12012 sqlhandle=0x03000800428c1f1950f833018da000000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,UPDATE #PB_Cost_Excp_Process_Invoices_Work
    SET PBCEPrcInv_RtlPkg_Item_Quantity = RtlPkg_Item_Quantity
    FROM #PB_Cost_Excp_Process_Invoices_Work
        INNER JOIN Item_Packages (NOLOCK)
            ON PBCEPrcInv_ItemPkg_Key = ItemPkg_Key
        INNER JOIN Retail_Packages (NOLOCK)
            ON ItemPkg_RtlPkg_Key = RtlPkg_Key

    -- Lookup pricebook cost
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_Create_SP line=25 stmtstart=2394 stmtend=3050 sqlhandle=0x030008003a082846321f46018da000000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,executionStack
12/14/2012 13:46:03,spid23s,Unknown,process id=process8cf948 taskpriority=0 logused=0 waitresource=OBJECT: 2:455743580:0  waittime=3739 ownerId=707053534 transactionname=UPDATE lasttranstarted=2012-12-14T13:45:59.327 XDES=0x3c4502930 lockMode=X schedulerid=4 kpid=7276 status=suspended spid=72 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2012-12-14T13:45:58.337 lastbatchcompleted=2012-12-14T13:45:58.337 clientapp=PDI WCF Services - pdidb01-PDIMaster.cfg hostname=PDIWEB01 hostpid=2084 loginname=pdiuser isolationlevel=read committed (2) xactid=707053534 currentdb=8 lockTimeout=4294967295 clientoption1=673316896 clientoption2=128568
12/14/2012 13:46:03,spid23s,Unknown,Proc [Database Id = 8 Object Id = 1857974987]
12/14/2012 13:46:03,spid23s,Unknown,inputbuf
12/14/2012 13:46:03,spid23s,Unknown,EXEC PB_ProcessExc_Costs_Submit_SP @SiteKey, @PWDate
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.DR_SubmitPaperwork_SP line=174 stmtstart=12912 stmtend=13018 sqlhandle=0x03000800cb72be6e500434018da000000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,EXEC dbo.PB_ProcessExc_Costs_CreateInvoiceWorkTable_SP
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_Submit_SP line=58 stmtstart=5782 stmtend=5894 sqlhandle=0x03000800428c1f1950f833018da000000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,ALTER TABLE #PB_Cost_Excp_Process_Invoices_Work DROP COLUMN PBCEPrcInv_Filler
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_CreateInvoiceWorkTable_SP line=50 stmtstart=5382 stmtend=5538 sqlhandle=0x0300080025d75a14ffff4701969f00000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,executionStack
12/14/2012 13:46:03,spid23s,Unknown,process id=process4cb3708 taskpriority=0 logused=0 waitresource=OBJECT: 2:455743580:3  waittime=3739 ownerId=707052778 transactionname=ALTER TABLE lasttranstarted=2012-12-14T13:45:58.517 XDES=0x5f48bce80 lockMode=Sch-M schedulerid=6 kpid=7212 status=suspended spid=63 sbid=0 ecid=0 priority=0 trancount=1 lastbatchstarted=2012-12-14T13:45:58.513 lastbatchcompleted=2012-12-14T13:45:58.513 clientapp=PDI WCF Services - pdidb01-PDIMaster.cfg hostname=PDIWEB01 hostpid=2084 loginname=pdiuser isolationlevel=read committed (2) xactid=707052778 currentdb=2 lockTimeout=4294967295 clientoption1=673316896 clientoption2=128568
12/14/2012 13:46:03,spid23s,Unknown,process-list
12/14/2012 13:46:03,spid23s,Unknown,deadlock victim=process4cb3708
12/14/2012 13:46:03,spid23s,Unknown,deadlock-list

최신 정보

해당 시스템은 작업 관리자 및 장치 관리자에 16 개의 프로세서를 표시하므로 잠금 파티셔닝이 활성화되고 두 잠금이 서로 다른 잠금 파티션에 있습니다. 잠금 파티셔닝이 여기서 중요한 원인인지 아닌지 모르겠습니다.

CSS SQL Server Engineers 블로그에서이 흥미로운 게시물을 찾았 습니다 .

업데이트 2

임시 테이블은 모든 저장 프로 시저의 끝에서 삭제됩니다. 패턴 작성 #table, 스키마 수정, 삽입, 업데이트, 선택 및 삭제 패턴으로 작성됩니다. 이 임시 테이블을 사용하는 공통 프로 시저에는 여러 개의 진입 점이 있으므로 공통 proc을 호출하는 데 필요한 열을 설정하는 중앙 proc이 있습니다. 그렇지 않으면 모든 진입 점 프로세스에서 동일한 #table 정의를 복제해야합니다.

프로세스는 여러 클라이언트 애플리케이션에서 자주 호출됩니다. 일부 클라이언트 응용 프로그램은 여러 스레드에서이 프로세스를 호출합니다. 다른 사람들은 한 번에 하나씩 실행합니다. 본사가 수천 개의 매장에 대한 데이터를 동시에 처리하는 동안 재고 / 회계 소프트웨어를 생각해보십시오. 따라서 잠금 파티셔닝이 활성화 될 때 이것이 드문 문제인 경우, 더 큰 고객 데이터베이스에서는 드물지 않을 것입니다.

업데이트 3-2012-12-19

다른 고객이 SQL Server 2012 빌드 11.0.2100에서 동일한 문제를 겪고 있습니다. 누적 업데이트 설명에서이 문제에 대한 수정 사항에 대한 언급이 없습니다. 연구.

업데이트 4-2013-02-13

Microsoft는 다음 업데이트에서이 버그에 대한 수정 프로그램을 출시했습니다.

sql-server sql-server-2008 deadlock

— 폴 윌리엄스
소스

@AaronBertrand : 아니요, #temp 테이블 캐싱을 원하지 않습니다. 동일한 연결에서 충분히 나쁘고 프로세스 간 재사용이 훨씬 적습니다. .xdl 파일이 없으며 추적 플래그 1222 정보 만 있습니다.

— Paul Williams

이 #temp 테이블을 완료하면 명시 적으로 삭제합니다.

— Paul Williams

나는 여전히 .xdl 파일을 캡처하고 게시하여 다른 사람들이 더 자세히 볼 수 있도록 제안 할 것입니다.

— Aaron Bertrand

잠금 파티셔닝이 여기에 포함되어 있음을 확인할 수 있습니다. 이 게시물에는 잠금 파티션과 관련된 교착 상태 분석 및 잠금 파티션으로 인한 세부 정보가 있습니다. bit.ly/Ruzmym bit.ly/W7yuRK 그러나 두 세션이 동일한 ObjectID를 게시 한 이유를 모르겠습니다.

— Roji P Thomas

@SQLKiwi 문제를 찾아 주셔서 감사합니다! 잠금 리소스 해싱에 대해서는 생각하지 않았습니다. 그것이 객체 ID에 있다고 가정하면, 그렇지 않다고 생각하지만 추측하고 있습니다. 고객이 며칠 동안 교착 상태를보고했습니다. 교착 상태 추적은 1 일 분량이지만 이것이 경험 한 교착 상태입니다. Microsoft는이를 파악할 수 있도록 지원 티켓을 Microsoft와 함께 개설하고 있습니다. 자세한 내용은이 질문을 업데이트하겠습니다.

— Paul Williams

이 문제와 관련하여 Microsoft에 사례를 열었습니다. Microsoft는이 버그가 SQL Server 2012에도 영향을 미친다는 것을 확인했습니다. SQL Server 2012 서비스 팩 2에서이 수정 프로그램을 릴리스 할 계획입니다 (이 답변을 작성할 당시에는 릴리스되지 않았습니다).

Microsoft가이 서비스 팩을 출시 할 때까지 SQL Server 2012 사용자는 추적 플래그 1229 를 통해 잠금 파티셔닝을 비활성화하여이 문제를 무시할 수 있습니다 .

이 문제는 16 개 이상의 프로세서가있는 시스템에만 적용됩니다.

잠금 파티셔닝에 대한 추가 정보

Microsoft 지원에 감사합니다! 그들은 매우 신속하고 도움이되었습니다.

최신 정보

버그는 SQL Server 2012 SP 1 용 SQL Server 2012 누적 업데이트 2 에서 수정되었습니다 .

— 폴 윌리엄스
소스