- प्रक्रिया 9196ए8 में पृष्ठ 151867 स्लॉट 174 एक्स मोड में है और पृष्ठ 140302 स्लॉट 31 एस मोड में चाहता है
- प्रक्रिया 88b5b8 में पृष्ठ 140302 स्लॉट 31 X मोड में है और पृष्ठ 151867 स्लॉट 174 S मोड में चाहता है
- दो डिलीट
isolationlevel="repeatable read (3)". के तहत चलते हैं
तो गतिरोध तालिका के आधार ढेर पर होता है (कुंजी ताले के बजाय आरआईडी ताले का अर्थ है एक ढेर नहीं एक बीटी)। उच्च अलगाव स्तर (डीटीसी के कारण होने की संभावना, xact नाम से देखते हुए) आरसीएसआई सेटिंग को अप्रासंगिक बना देता है।
PARTYEXTERNALREF और PARTYTYPE कॉलम किस प्रकार के होते हैं? पास किए गए पैरामीटर NVARCHAR (यानी यूनिकोड) हैं और यदि कॉलम VARCHAR (यानी Ascii) हैं तो डेटा प्रकार वरीयता एनसी सूचकांक का उपयोग नहीं किया जाएगा। टेबल स्कैन में शामिल होने के कारण, उपयोग में उच्च अलगाव स्तर के साथ, एक गतिरोध लगभग अपरिहार्य है।
समाधान @P0 और @P1 के लिए VARCHAR प्रकार के मापदंडों का उपयोग करना होगा ताकि टेबल स्कैन से बचने के लिए NC इंडेक्स का लाभ उठाया जा सके।
यदि पैरामीटर पहले से ही VARCHAR प्रकार के हैं और आप निष्पादन योजना से पुष्टि कर सकते हैं कि NC पर एक खोज का उपयोग किया जाता है, तो मेरा पहला प्रश्न यह होगा कि else क्या होगा क्या लेन-देन डिलीट स्टेटमेंट के अलावा अन्य कर रहा है?
बीटीडब्ल्यू, आप केवल एनसी इंडेक्स का नाम देते हैं लेकिन मुझे लगता है कि (PARTYEXTERNALREF, ISCOUNTERPARTY, PARTYID) पर है ।
अपडेट करें
चूंकि आपकी टिप्पणी कहती है कि कॉलम हैं NVARCHAR तो टेबल स्कैन परिकल्पना शायद गलत है। गतिरोध पैदा करने की तीन और संभावनाएं हैं जिनकी जांच की आवश्यकता है:
- DELETE से पहले लेन-देन द्वारा चलाया गया कोई अन्य विवरण (यह सबसे अधिक संभावना है)
- गतिरोध में शामिल दो DELETE कथनों द्वारा चयनित पंक्तियों में कोई भी ओवरलैप
- हैश टक्कर
केवल पहली दो परिकल्पनाओं के लिए आप अभी कुछ भी कर सकते हैं (जांच करें कि क्या वे सही हैं)। आखिरी के लिए मैं आपको बता सकता हूं कि इसे कैसे सत्यापित किया जाए, लेकिन यह मामूली नहीं है। ऐसा होने की संभावना नहीं है और साबित करना थोड़ा मुश्किल है, लेकिन यह संभव है। चूंकि आप डेडलॉक केस (संलग्न एक्सएमएल) के रूप में जानते हैं, इसलिए इसे जांच आधार के रूप में उपयोग करें:
- डेटाबेस की पॉइंट-इन-टाइम कॉपी को पुनर्स्थापित करें पर स्टॉप के साथ 2011-09-02T19:00:29.690
- चलाएं
DBCC TRACEON(3604,-1) DBCC PAGE (<restored db id>, 1, 151867, 3)स्लॉट 174 में मूल्यों का निरीक्षण करें- DBCC PAGE(, 1, 140302, 3)` का उपयोग करके स्लॉट 31 पर मानों का निरीक्षण करें
- चलाएं
SELECT %%lockres%% FROM PARTIES WHERE PARTYEXTERNALREF = ... AND ISCOUNTERPARTY='N' and PARTYID=...और ऊपर पढ़े गए मानों में पास करें - परिणामस्वरूप लॉक हैश मानों की तुलना करता है, यदि वे मेल खाते हैं तो आपके पास हैश टकराव है और यह गतिरोध का कारण बना।
