Bế tắc từ khóa trên cùng một bảng tạm thời trong các quy trình khác nhau

Tôi đã tìm thấy một bế tắc xuất hiện để hiển thị một cái gì đó tôi nghĩ là không thể. Có hai quá trình liên quan đến bế tắc:

1. process8cf948 SPID 63

Thực hiện BẢNG ALTER trên bảng tạm thời #PB_Cost_Excp_Process_Invoices_Work.
Sở hữu khóa IX trên bảng #PB_Cost_Excp_Process_Invoices_Work với ID đối tượng 455743580

2. process4cb3708 SPID 72

Thực hiện trong CẬP NHẬT trên bảng tạm thời #PB_Cost_Excp_Process_Invoices_Work được coi là bản sao duy nhất của bảng.
Sở hữu khóa Sch-M trên #PB_Cost_Excp_Process_Invoices_Work với cùng một đối tượng ID 455743580 !

Điều này được cho là không thể. Tui bỏ lỡ điều gì vậy? Bảng #T tạm thời có thực sự được sử dụng lại giữa hai SPID này không?

Đây là trên SQL Server 2008 R2 Gói dịch vụ 2 với Bản cập nhật tích lũy 1 (phiên bản 10.50.4260).

Dưới đây là dấu vết bế tắc không thay đổi đầy đủ. Lưu ý cách hai quy trình đều hoạt động trên cùng một ID đối tượng có cùng tên bảng # PB_Cost_Excp_Process_Invoices_Work_SNIP_0000000D8519:

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

CẬP NHẬT

Máy được đề cập hiển thị 16 bộ xử lý trong Trình quản lý tác vụ và Trình quản lý thiết bị, do đó phân vùng khóa được bật và hai khóa nằm trên các phân vùng khóa khác nhau. Tôi không biết phân vùng khóa có phải là nguyên nhân góp phần ở đây hay không.

Tôi cũng tìm thấy bài viết hấp dẫn này trên blog CSS SQL Server Engineers .

CẬP NHẬT 2

Các bảng tạm thời được loại bỏ ở cuối của mọi thủ tục được lưu trữ. Chúng được tạo với mẫu tạo #table, sửa đổi lược đồ, chèn, cập nhật, chọn và sau đó thả. Có nhiều điểm nhập vào một thủ tục chung sử dụng temp #table này, vì vậy chúng tôi có một trung tâm thiết lập các cột cần thiết để gọi Proc chung. Mặt khác, chúng ta phải sao chép định nghĩa #table giống nhau trong tất cả các procs điểm nhập cảnh.

Quá trình này được gọi thường xuyên từ nhiều ứng dụng khách. Một số ứng dụng khách gọi quy trình này từ nhiều luồng. Những người khác chạy nó một lúc. Hãy nghĩ rằng phần mềm kiểm kê / kế toán trong đó văn phòng tại nhà đang xử lý dữ liệu cho hàng ngàn cửa hàng song song trong khi các cửa hàng cũng tự chạy quy trình tương tự. Vì vậy, nếu đây là một vấn đề hiếm khi kích hoạt phân vùng khóa, thì nó sẽ không quá hiếm trên cơ sở dữ liệu khách hàng lớn hơn của chúng tôi.

CẬP NHẬT 3 - 2012-12-19

Một khách hàng khác đang gặp vấn đề tương tự trên SQL Server 2012 build 11.0.2100. Tôi không thấy bất kỳ đề cập nào về cách khắc phục sự cố này trong các mô tả cập nhật tích lũy. Nghiên cứu.

CẬP NHẬT 4 - 2013/02/13

Microsoft đã phát hành bản sửa lỗi cho lỗi này trong các bản cập nhật sau:

sql-server sql-server-2008 deadlock

— Paul Williams
nguồn

@AaronBertrand: Không, chúng tôi không muốn bộ nhớ đệm bảng #temp. Điều đó sẽ đủ tệ trên cùng một kết nối - ít được sử dụng lại giữa các quy trình. Tôi không có tệp .xdl, chỉ có thông tin cờ theo dõi 1222.

— Paul Williams

Chúng tôi rõ ràng bỏ các bảng #temp này khi thực hiện với chúng.

— Paul Williams

Tôi vẫn sẽ đề nghị chụp và đăng tệp .xdl ở đâu đó để người khác có thể xem xét kỹ hơn - nó sẽ có nhiều chi tiết tốt hơn.

— Aaron Bertrand

Tôi có thể xác nhận rằng phân vùng khóa có liên quan ở đây. Những bài đăng này có một số chi tiết về việc phân tích các bế tắc liên quan và do phân vùng khóa. bit.ly/Ruzmym bit.ly/W7yuRK Nhưng tôi không biết tại sao cả hai phiên đều đăng cùng một ObjectID.

— Roji P Thomas

@QueryKiwi Cảm ơn bạn đã xem xét vấn đề! Tôi đã không nghĩ về băm tài nguyên khóa. Cho rằng đó là trên một ID đối tượng, tôi nghi ngờ đó không phải là trường hợp, nhưng tôi chỉ đoán thôi. Khách hàng đã báo cáo những bế tắc cho chúng tôi trong vài ngày. Tôi chỉ có 1 ngày theo dõi bế tắc, nhưng tôi cá rằng đây là sự bế tắc mà họ đã trải qua. Chúng tôi đang mở một vé hỗ trợ với Microsoft để giúp chúng tôi tìm ra nó. Tôi sẽ cập nhật câu hỏi này khi tôi tìm hiểu thêm.

— Paul Williams

Chúng tôi đã mở một trường hợp với Microsoft về vấn đề này. Microsoft xác nhận rằng lỗi này cũng ảnh hưởng đến SQL Server 2012. Họ đang lên kế hoạch phát hành bản sửa lỗi trong SQL Server 2012 Service Pack 2 (không được phát hành tại thời điểm tôi đang viết câu trả lời này).

Cho đến khi Microsoft phát hành gói dịch vụ này, người dùng SQL Server 2012 có thể khắc phục sự cố bằng cách vô hiệu hóa phân vùng khóa thông qua cờ theo dõi 1229 .

Lưu ý rằng vấn đề này chỉ áp dụng cho các máy có 16 bộ xử lý trở lên.

Thông tin thêm về phân vùng khóa

Tôi cảm ơn sự hỗ trợ của Microsoft! Họ đã rất nhanh chóng và hữu ích.

CẬP NHẬT

Lỗi được sửa trong SQL Server 2012 Tích lũy Cập nhật 2 cho SQL Server 2012 SP 1 .

— Paul Williams
nguồn