चयन / INSERT गतिरोध

Question

यह उदाहरण SharePoint 2007 डेटाबेस (SP) को होस्ट करता है। हम एसपी सामग्री डेटाबेस के भीतर एक भारी उपयोग की गई तालिका के खिलाफ कई चयन / इन्सर्ट गतिरोधों का सामना कर रहे हैं। मैंने इसमें शामिल संसाधनों को कम कर दिया है, दोनों प्रक्रियाओं को गैर-संकुल सूचकांक पर ताले की आवश्यकता होती है।
INSERT को SELECT संसाधन पर IX लॉक की आवश्यकता होती है और SELS को INSERT संसाधन पर S लॉक की आवश्यकता होती है। डेडलॉक ग्राफ में तीन और संसाधन हैं, 1.) SELECT (निर्माता / उपभोक्ता समानांतर धागे) से दो, और 2.) INSERT।
मैंने आपकी समीक्षा के लिए गतिरोध ग्राफ संलग्न किया है। क्योंकि यह Microsoft कोड और तालिका संरचनाएँ हैं, हम इनमें कोई बदलाव नहीं कर सकते हैं।
हालाँकि, मैंने MSFT SP साइट पर पढ़ा है, कि वे MAXDOP इंस्टेंस स्तर कॉन्फ़िगरेशन विकल्प 1 को सेट करने की सलाह देते हैं। चूंकि यह उदाहरण कई अन्य डेटाबेस / अनुप्रयोगों के बीच साझा किया जाता है, इसलिए यह सेटिंग अक्षम नहीं की जा सकती।

इसलिए, मैंने इन SELECT स्टेटमेंट को समानांतर जाने से रोकने की कोशिश करने का फैसला किया। मैं जानता हूं कि यह एक समाधान नहीं है, लेकिन समस्या निवारण में मदद करने के लिए अधिक अस्थायी संशोधन है। इसके अलावा, मैंने ऐसा करने पर अपने मानक 25 से 40 तक "समानांतर के लिए लागत सीमा" को बढ़ा दिया, भले ही कार्यभार नहीं बदला है (अक्सर होने वाले SELECT / INSERT) गतिरोध गायब हो गए हैं। मेरा सवाल यह है कि क्यों?

SPID 356 INSERT में गैर-संकुल सूचकांक से संबंधित पृष्ठ पर IX लॉक है
SPID 690 का चयन निष्पादन आईडी 0 में उसी गैर-संकुलित सूचकांक से संबंधित पृष्ठ पर S लॉक है

अभी

SPID 356 SPID 690 संसाधन पर IX लॉक चाहता है, लेकिन इसे प्राप्त नहीं कर सकता क्योंकि SPID 356 SPID 690 निष्पादन आईडी द्वारा अवरुद्ध किया जा रहा है। SID
690 निष्पादन आईडी 1 लॉक SPID 356 संसाधन पर S लॉक चाहता है, लेकिन इसे प्राप्त नहीं कर सकता क्योंकि SPID 690 निष्पादन आईडी 1 को SPID 356 द्वारा अवरुद्ध किया जा रहा है और अब हमारे पास हमारा गतिरोध है।

निष्पादन योजना मेरे स्काईड्राइव पर पाई जा सकती है

पूर्ण गतिरोध का विवरण यहां पाया जा सकता है

अगर कोई मुझे यह समझने में मदद कर सकता है कि मैं वास्तव में इसकी सराहना क्यों करूंगा।

EventReceivers तालिका।
Uniqueidentifier कोई 16 क्रमांक
नाम nvarchar कोई 512
uniqueidentifier कोई 16 SiteId
WebId uniqueidentifier कोई 16
hostid uniqueidentifier कोई 16
HostType पूर्णांक नहीं 4
Itemid पूर्णांक नहीं 4
dirname nvarchar कोई 512
nvarchar 256 LeafName
प्रकार पूर्णांक नहीं 4
SequenceNumber पूर्णांक नहीं 4
विधानसभा nvarchar कोई 512
वर्ग nvarchar कोई 512
डेटा nvarchar no 512
फ़िल्टर nvarchar no 512
SourceId tContentTypeId no 512
SourceType int no 4
क्रेडेंशियल int नहीं 4
संदर्भ पाठ क्रमांक 16
ContextEventType varbinary कोई 16
ContextId varbinary कोई 16
ContextObjectId varbinary कोई 16
ContextCollectionId varbinary कोई 16

INDEX_NAME index_description index_keys
EventReceivers_ByContextCollectionId nonclustered प्राथमिक SiteId पर स्थित है, ContextCollectionId
EventReceivers_ByContextObjectId प्राथमिक SiteId पर स्थित Nonclustered, ContextObjectId
EventReceivers_ById Nonclustered, प्राथमिक SiteId पर स्थित है, ईद अद्वितीय
EventReceivers_ByTarget क्लस्टर, प्राथमिक SiteId, WebId, hostid, HostType, प्रकार, ContextCollectionId, ContextObjectId पर स्थित अद्वितीय, ContextId, ContextType, ContextEventType, SequenceNumber, असेंबली, क्लास EventReceivers_IdUnique
nonclustered, अद्वितीय, अद्वितीय कुंजी जो PRIMARY Id पर स्थित है

Comments

हम XDL में क्या देख सकते हैं proc_InsertEventReceiverऔर proc_InsertContextEventReceiverक्या नहीं करते हैं? इसके अलावा समानता को कम करने के लिए क्यों न केवल इन बयानों को सीधे प्रभावित किया जाए (मैक्सडॉप 1 का उपयोग करके) सर्वर-वाइड सेटिंग्स के साथ फ्यूजिंग के बजाय?

— हारून बर्ट्रेंड

मैं उत्सुक हूं कि आपकी गंभीर विस्तृत MAXDOP सेटिंग क्या है और आपके पास कितने प्रोसेसर (तार्किक) हैं। SharePoint वास्तव में बेहतर काम करता है और एक सर्वर पर होना चाहता है जिसका MAXDOP सर्वर 1 से चौड़ा है .. मुझे यह पसंद नहीं है, लेकिन यही तरीका है कि उन्होंने इसे विकसित किया है। क्या आप वास्तविक निष्पादन योजनाओं को पोस्ट कर सकते हैं? सभी मैं उस लिंक को देखता हूं .xdl (डेडलॉक ग्राफ)

— माइक वॉल्श

नमस्ते सज्जनों, मैं वास्तव में समय लेने के लिए आपके व्यस्त कार्यक्रम के जवाब देने के लिए आपकी सराहना करता हूं। मैं स्काईड्राइव साइट पर आपकी समीक्षा के लिए दोनों प्रक्रियाओं और निष्पादन योजनाओं को पोस्ट करूंगा। मैंने क्वेरी विकल्प MAXDOP (1) को शामिल करने के लिए कोड को संशोधित करने के बारे में सोचा था, हालांकि, ऐसा करने से Microsoft के साथ हमारा समर्थन शून्य हो जाएगा। भौतिक सर्वर एक ProLiant है DL580 G4 MAXDOP सेटिंग कुल 8 भौतिक प्रोसेसर के साथ 4 है और एच / टी अक्षम है।

— SQLJarHead 13

नमस्ते सज्जनों, मैंने स्काईड्राइव पर सभी विवरणों के साथ एक ज़िप पैकेज बनाया है। मैंने पैकेज के लिए URL को शामिल करने के लिए मूल पोस्ट के शरीर को संशोधित किया। कृपया, मुझे यह न बताएं कि समस्या क्या है, बस मार्गदर्शन प्रदान करें और मुझे इसके लिए काम करना है। ध्यान दें: मैं अंतर्निहित स्कीमा में कोई कोड परिवर्तन या DDL संशोधन करने में सक्षम नहीं हूं।

— SQLJarHead

इसलिए, आप कोड को बदल नहीं सकते हैं और आप स्कीमा को बदल नहीं सकते हैं, आप अन्य समाधानों के साथ हमसे क्या उम्मीद करते हैं? यदि आप Microsoft समर्थन को रद्द करने के बारे में चिंतित हैं, तो इसका मतलब है कि आपके पास Microsoft समर्थन है, जिस स्थिति में - आपके द्वारा हमें बताए गए सभी प्रतिबंधों को देखते हुए आप ऐसा नहीं कर सकते - क्या आपने Microsoft के साथ समर्थन टिकट खोलने पर विचार किया है?

— हारून बर्ट्रेंड

Answer 1

इसके चेहरे पर, यह एक क्लासिक लुकअप गतिरोध की तरह दिखता है । इस गतिरोध पैटर्न के लिए आवश्यक सामग्री हैं:

• एक SELECTक्वेरी जो एक गैर-कवर गैर-क्रस्टेड इंडेक्स को कुंजी लुकअप के साथ उपयोग करती है
• एक INSERTक्वेरी जो क्लस्टर किए गए इंडेक्स को संशोधित करता है और फिर नॉनक्लेस्टेड इंडेक्स को

SELECTNonclustered अनुक्रमणिका पहले, तो संकुल अनुक्रमणिका तक पहुँचता है। INSERTपहुँच संकुल अनुक्रमणिका पहले, तो nonclustered अनुक्रमणिका। असंगत ताले प्राप्त करने वाले एक अलग क्रम में समान संसाधनों तक पहुंचना निश्चित रूप से एक गतिरोध को प्राप्त करने का एक शानदार तरीका है।

इस मामले में, SELECTप्रश्न यह है:

... और INSERTप्रश्न है:

हरे रंग के गैर-संकुलित अनुक्रमणिका रखरखाव पर ध्यान दें।

हमें SELECTयोजना के धारावाहिक संस्करण को देखने की आवश्यकता होगी यदि यह समानांतर संस्करण से बहुत अलग है, लेकिन जैसा कि जोनाथन केहियास ने डेडलॉक को संभालने के लिए अपने गाइड में नोट किया है , यह विशेष गतिरोध पैटर्न समय और आंतरिक क्वेरी निष्पादन विवरण के लिए बहुत संवेदनशील है। इस प्रकार का गतिरोध अक्सर स्पष्ट बाहरी कारण के बिना आता और जाता है।

संबंधित प्रणाली, और उपयुक्त अनुमतियों तक पहुँच को देखते हुए, मुझे यकीन है कि हम आखिरकार ठीक से काम कर सकते हैं क्यों कि गतिरोध समानांतर योजना के साथ होता है, लेकिन धारावाहिक (एक ही सामान्य आकार मानकर) नहीं। जांच की संभावित पंक्तियों में अनुकूलित नेस्टेड लूप और / या प्रीफेटिंग के लिए जाँच शामिल है - ये दोनों आंतरिक रूप से स्टेटमेंट की अवधि के लिए आइसोलेशन स्तर को बढ़ा सकते हैं REPEATABLE READ। यह भी संभव है कि समांतर इंडेक्स सीक रेंज असाइनमेंट की कुछ विशेषता इस मुद्दे पर योगदान करती है। यदि धारावाहिक योजना उपलब्ध हो जाती है, तो मैं कुछ समय आगे के विवरणों को देखने में लगा सकता हूं, क्योंकि यह संभावित रूप से दिलचस्प है।

इस प्रकार के गतिरोध के लिए सामान्य समाधान सूचकांक को ढंकना है, हालांकि इस मामले में स्तंभों की संख्या उस अव्यवहारिक (और इसके अलावा, हम SharePoint पर ऐसी चीजों के साथ गड़बड़ करने वाले नहीं हैं, मुझे बताया गया है)। अंततः, SharePoint का उपयोग करते समय केवल धारावाहिक की योजनाओं की अनुशंसा एक कारण के लिए होती है (हालांकि जरूरी नहीं कि यह एक अच्छा हो, जब यह सही हो जाए)। यदि समानता के लिए लागत सीमा में परिवर्तन पल के लिए समस्या को ठीक करता है, तो यह अच्छा है। लंबे समय तक, मैं शायद कार्यभार को अलग करने के लिए देखूंगा, शायद संसाधन राज्यपाल का उपयोग कर रहा हूं ताकि SharePoint आंतरिक प्रश्नों को वांछित MAXDOP 1व्यवहार मिले और दूसरा अनुप्रयोग समानता का उपयोग करने में सक्षम हो।

डेडलॉक ट्रेस में दिखाई देने वाले एक्सचेंजों का सवाल मुझे एक लाल हेरिंग लगता है; संसाधनों के मालिक हैं, जो तकनीकी रूप से पेड़ में दिखाई देने चाहिए। मुझे यह सुझाव देने के लिए कुछ भी नहीं दिखाई दे रहा है कि एक्सचेंज खुद ही डेडलॉकिंग मुद्दे पर सीधे योगदान दे रहे हैं।

Answer 2

यदि यह एक क्लासिक लुकअप गतिरोध था , तो संसाधन सूची में क्लस्टर इंडेक्स और गैर-क्लस्टर इंडेक्स दोनों शामिल होंगे। आमतौर पर सेलेक्ट NC इंडेक्स पर शेयर लॉक लगाएगा और CI पर शेयर लॉक का इंतजार करेगा, इस बीच INSERT CI पर EXCLUSIVE लॉक हासिल कर लेगा और NC पर EXCLUSIVE लॉक का इंतजार करेगा। डेडलॉक xml में संसाधन सूची इन दोनों वस्तुओं को इस मामले में सूचीबद्ध करेगी।

चूंकि डेडलॉक ग्राफ में केवल NC इंडेक्स शामिल होता है इसलिए हम उस विकल्प को नियंत्रित कर सकते हैं।

इसके अलावा, अगर नेस्टर्ड पेड के साथ नेस्टड लूप ज्वाइन होने के कारण यह डेड लॉक था , तो निष्पादन योजना हमें बताएगी कि क्या UNORDERED PREFETCH एल्गोरिथ्म का उपयोग किया गया है, जो फिर से यहां नहीं है (नीचे अपडेट देखें)।

यह हमें यह मानने के लिए छोड़ देता है कि समानांतर योजना के कारण यह गतिरोध है।

गतिरोध ग्राफ को ठीक से प्रस्तुत नहीं किया गया है, लेकिन यदि आप डेडलॉक XML को देखते हैं, तो आप देख सकते हैं कि चयन कथन (SPID 690) से दो थ्रेड गतिरोध में शामिल हैं। उपभोक्ता धागा पृष्ठ 1219645 पर शेयर लॉक लगा रहा है और निर्माता पर port801f8ed0 (e_waitPipeGetRow) का इंतजार कर रहा है। निर्माता थ्रेड पृष्ठ 1155940 पर साझा लॉक की प्रतीक्षा कर रहा है।

INSERT बयान पृष्ठ 1155940 पर एक IX लॉक पकड़ रहा है और पृष्ठ 1219645 पर IX लॉक की प्रतीक्षा कर रहा है, जिसके परिणामस्वरूप गतिरोध है।

मेरा मानना ​​है कि किसी भी बिंदु पर SELECT स्टेटमेंट के लिए सीरियल प्लान का उपयोग करते समय एक गतिरोध टल जाएगा क्योंकि इसमें एक से अधिक पेज पर SHARED लॉक की आवश्यकता होगी। मुझे यह भी लगता है कि धारावाहिक योजना लगभग समानांतर योजना (समानता ऑपरेटर के रूप में) के समान होगी।

[पॉल की टिप्पणी के आधार पर अद्यतन]

जाहिर तौर पर योजना एक ऑप्टिमाइज्ड नेस्टेड लूप एल्गोरिदम का उपयोग कर रही है

यह बताता है कि साझा किए गए ताले बयान के अंत तक क्यों आयोजित किए जाते हैं। समानांतर योजना के साथ संयुक्त READATABLE READ एक सीरियल प्लान की तुलना में गतिरोध के लिए अधिक असुरक्षित है क्योंकि समानांतर योजना एक सूचकांक की विभिन्न श्रेणियों से प्राप्त कर सकती है और लॉक रख सकती है जबकि सीरियल प्लान अधिक क्रमिक तरीके से ताले प्राप्त करता है।

Comments

माना। यदि यह गतिरोध वास्तविक LOOKUP के लिए प्रतीक्षा संसाधन से संबंधित था, तो SELECT के लिए, क्लस्टर्ड इंडेक्स संदर्भित होगा। मैं डीबीसीसी पेज के माध्यम से प्रत्येक प्रतीक्षा संसाधन (SPID 690 प्रतीक्षा संसाधन = पृष्ठ: SPID 356 प्रतीक्षा संसाधन = पृष्ठ 1219645) के लिए पृष्ठ शीर्षलेख प्रदर्शित करके यह नियम करने में सक्षम था कि दोनों सूचकांक ID 5 (IndexID 5 = EventReceivers_ByContextObjectId) पर थे। जो निर्दिष्ट तालिका (EventReceivers) पर नेकां सूचकांक को इंगित करता है।

— SQLJarHead

सज्जनों, धन्यवाद फिर से इस दिलचस्प मुद्दे का विश्लेषण करने में मदद करने के लिए। प्रश्नों के जोड़े: 1.) रूजी बताते हैं कि समानांतर SPID एक से अधिक पृष्ठ का अनुरोध कर रहा है। मुझे नहीं लगता कि किसी भी निष्पादन योजना में। INDEX SEEK ऑपरेटर के लिए पंक्तियों की संख्या को देखते हुए, दो उत्पादकों में से केवल एक धागा किसी भी पंक्तियों को संसाधित कर रहा है। आपने यह कैसे निर्धारित किया कि यह एक से अधिक पृष्ठ का अनुरोध कर रहा था? (१/२)

— SQLJarHead

2.) क्या एक ऑप्टिमाइज्ड नेस्टेड लूप एल्गोरिथम हमेशा अलग स्तर को REAPTABLE READ में सेट करेगा? मैंने एक्सएमएल आउटपुट निष्पादन योजनाओं की जांच की है और मैं केवल SPIDs कनेक्शन के लिए प्रतिबद्ध पढ़ा हुआ देखता हूं। मैं एक धारणा बना रहा हूं कि इसे केवल योजना ऑपरेटर स्तर पर ही लागू किया जाता है। (2/2)

— SQLJarHead

ऑप्टिमाइज्ड नेस्टेड लूप्स का लॉकिंग व्यवहार REPEATABLE READ ( स्टेटमेंट के अंत तक ताले रखता है) से तुलनीय है , लेकिन यह एक्सप्लोसिव को READATABLE READ के लिए ट्रांजेक्शन का आइसोलेशन लेवल सेट नहीं करता है। मुझे लगता है कि आपके प्रश्न का उत्तर भी एक है। ऐसा नहीं है कि समानांतर धागे एक समय में एक से अधिक पृष्ठ का अनुरोध कर रहे हैं, लेकिन एक समानांतर धागा एक पृष्ठ पर एक ताला लगा हुआ है और दूसरा धागा किसी अन्य पृष्ठ पर लॉक का इंतजार कर रहा है

— Roji P Thomas