मुझे एक गतिरोध मिला है जो ऐसा प्रतीत होता है कि मुझे लगा कि कुछ असंभव है। गतिरोध में दो प्रक्रियाएँ शामिल हैं:
1. process8cf948 SPID 63
अस्थायी तालिका #PB_Cost_Excp_Process_Invoices_Work पर एक वैकल्पिक तालिका का प्रदर्शन करना।
सारणी पर IX लॉक #PB_Cost_Excp_Process_Invoices_Work के साथ ऑब्जेक्ट आईडी 455743580
2. process4cb3708 SPID 72
अस्थायी तालिका #PB_Cost_Excp_Process_Invoices_Work पर UPDATE में प्रदर्शन करना, जो तालिका की अपनी अनूठी प्रति माना जाता है।
एक ही ऑब्जेक्ट आईडी 455743580 के साथ #PB_Cost_Excp_Process_Invoices_Work पर Sch-M लॉक करें !
यह असंभव माना जाता है। क्या मैं कुछ भूल रहा हूँ? क्या वास्तव में इन दोनों SPID के बीच एक # टेबल टेबल का पुन: उपयोग हुआ है?
यह संचयी अद्यतन 1 (संस्करण 10.50.4260) के साथ SQL Server 2008 R2 सर्विस पैक 2 पर है।
पूर्ण अनलेडेड गतिरोध ट्रेस नीचे है। ध्यान दें कि दोनों प्रक्रियाएँ एक ही ऑब्जेक्ट ID पर समान टेबल नाम # 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
अपडेट करें
प्रश्न में मशीन टास्क मैनेजर और डिवाइस मैनेजर में 16 प्रोसेसर दिखाती है, इसलिए लॉक विभाजन सक्षम है, और दो लॉक अलग-अलग लॉक विभाजन पर हैं। मुझे नहीं पता कि लॉक पार्टिशनिंग यहां योगदान देने वाला कारण है या नहीं।
मुझे CSS SQL Server Engineers ब्लॉग पर यह पेचीदा पोस्ट भी मिली ।
अद्यतन २
प्रत्येक संग्रहीत प्रक्रिया के अंत में अस्थायी तालिकाओं को गिरा दिया जाता है। वे #table बनाने के पैटर्न के साथ बनाए जाते हैं, स्कीमा को संशोधित करते हैं, सम्मिलित करते हैं, अपडेट करते हैं, चयन करते हैं, और फिर ड्रॉप करते हैं। एक सामान्य प्रक्रिया के लिए कई प्रवेश बिंदु हैं जो इस अस्थायी # विकल्प का उपयोग करता है, इसलिए हमारे पास एक केंद्रीय खरीद है जो सामान्य खरीद को कॉल करने के लिए आवश्यक कॉलम सेट करता है। अन्यथा, हमें सभी प्रविष्टि बिंदु प्रॉपर में समान # संगत परिभाषा को दोहराना होगा।
प्रक्रिया कई ग्राहक अनुप्रयोगों से अक्सर आह्वान की जाती है। कुछ क्लाइंट एप्लिकेशन इस प्रक्रिया को कई थ्रेड से कॉल करते हैं। दूसरे इसे एक बार में चलाते हैं। इन्वेंट्री / अकाउंटिंग सॉफ्टवेयर के बारे में सोचें, जहां होम ऑफिस समानांतर में हजारों स्टोरों के लिए डेटा प्रोसेस कर रहा है, जबकि स्टोर्स खुद भी यही प्रक्रिया चलाते हैं। इसलिए यदि लॉक विभाजन सक्षम होने पर यह एक दुर्लभ मुद्दा है, तो यह हमारे बड़े ग्राहक डेटाबेस पर इतना दुर्लभ नहीं होगा।
अद्यतन 3 - 2012-12-19
एक अन्य ग्राहक SQL Server 2012 बिल्ड 11.0.2100 पर एक ही समस्या है। मैंने संचयी अद्यतन विवरण में इस समस्या के लिए किसी भी निर्धारण का उल्लेख नहीं देखा। शोध।
अद्यतन 4 - 2013-02-13
Microsoft ने निम्न अपडेट में इस बग के लिए सुधार जारी किया है: