गतिरोध पैदा करने वाली दो क्वेरी हैं SELECT नीचे (process id="process3980de4558" ):
select @existing = team_it_cube_attr_05 from tbl_Ref_Attr_Prod_Team where prod_id = @rec_key
और UPDATE नीचे क्वेरी (process id="process386ed48188" ):
UPDATE D
SET D.team_rss_attr_01 = LEFT(S.mkt_prodchar_13,25)...
<resource-list> अनुभाग SELECT नोट करता है query के पास एक पृष्ठ पर एक विशिष्ट (X) लॉक था और वह डेटा पढ़ रहा था, जबकि दूसरे पृष्ठ पर एक इंटेंट-शेयर्ड (IS) लॉक प्राप्त करने का प्रयास कर रहा था। UPDATE क्वेरी के पास पहले से ही एक IS लॉक है और वह अपडेट करने के लिए किसी पृष्ठ पर X लॉक प्राप्त करने का प्रयास कर रहा था।
इस तालिका में शामिल होने को देखते हुए:
...from tbl_Ref_Attr_Prod_Team where prod_id = @rec_key...
...INNER JOIN tbl_Ref_Attr_Prod_Team D ON D.prod_key=P.prod_key...
SELECT query के पास पहले से ही एक विशेष लॉक है। इसका शायद यह अर्थ है कि यह एक बड़े लेन-देन का हिस्सा है जो पहले ही एक UPDATE कर चुका है एक पूर्व क्वेरी में। लेन-देन के दौरान डेटा अखंडता को बनाए रखने के लिए पूर्व प्रश्नों के ताले बनाए रखे जाएंगे (लेन-देन अलगाव स्तर
)।
UPDATE क्वेरी को तालिका पढ़ने की जरूरत है tbl_Ref_Attr_Prod_team . यह डेटा पढ़ते समय पृष्ठों और पंक्तियों पर आशय-साझा ताले प्राप्त करता है। जब UPDATE क्वेरी मेल खाने वाली पंक्तियों को ढूंढती है, तो यह आईएस लॉक को एक्स लॉक में बदलने का प्रयास करेगी। IS लॉक, X लॉक के साथ संगत नहीं हैं। क्योंकि SELECT क्वेरी में पहले से ही उन पृष्ठों में से एक या अधिक पर एक IS लॉक है, एक दूसरे के साथ क्वेरी गतिरोध।
एक संभावित कारण tbl_Ref_Attr_Prod_team.prod_key पर अनुक्रमणिका न होना होगा . इस कॉलम पर एक अनुक्रमणिका के बिना, UPDATE क्वेरी tbl_Ref_Attr_Prod_team तालिका की सभी पंक्तियों को स्कैन करेगी ।
भले ही कोई अनुक्रमणिका prod_key . पर मौजूद हो , यदि तालिका में पंक्तियों की एक छोटी संख्या है, तो SQL सर्वर यह तय कर सकता है कि प्रदर्शन बेहतर होगा यदि क्वेरी इंडेक्स की तलाश के बजाय पूरी तालिका को स्कैन करती है। गतिरोध होने पर क्वेरी योजना को रिकॉर्ड करना इस सिद्धांत को सत्यापित करेगा।
नए डेटाबेस का मंचन करते समय हम नियमित रूप से छोटे टेबल डेडलॉक का सामना करते हैं। प्रारंभ में, टेबल छोटे होते हैं, और टेबल स्कैन सभी प्रकार के गतिरोध का कारण बनते हैं। बाद में, जब तालिकाएँ बड़ी होती हैं, तो तालिका को स्कैन करने की गणना की गई लागत सूचकांक की खोज की लागत से अधिक हो जाती है, और गतिरोध अब नहीं होता है। परीक्षण वातावरण में जहां पंक्तियों की संख्या हमेशा कम होती है, हमने FORESEEK का उपयोग करने का सहारा लिया है और WITH INDEX स्कैन के बजाय इंडेक्स को मजबूर करने के संकेत। हम SQL सर्वर 2016 की क्वेरी स्टोर सुविधा के माध्यम से क्वेरी योजनाओं को लागू करने में सक्षम होने की आशा कर रहे हैं।
