एसक्यूएल सर्वर 2008: डेडलॉक्स प्राप्त करना ... किसी भी ताले के बिना

Question

मैं वर्तमान में SQL सर्वर 2008 डेटाबेस पर कुछ प्रयोग कर रहा हूं।

UPDATE from Table A where rowID='123' 

हालांकि, मैं गतिरोध त्रुटियों की एक टन हो रही है (: अधिक विशेष रूप से, मैं एक JDBC आवेदन समवर्ती धागे के सैकड़ों का उपयोग करता है कार्य के हजारों निष्पादित करने के लिए, जिनमें से प्रत्येक डेटाबेस पर निम्न क्वेरी चलाता है एसक्यूएल अपवाद 1205) जब भी मैं अलगाव स्तर को READ_UNCOMMITTED से अधिक होने के लिए सेट करता हूं। यह तब भी होता है जब मैं पंक्ति लॉकिंग, टेबल लॉकिंग और अनन्य लॉक संकेत सेट करता हूं! और स्नैपशॉट अलगाव में भी, जो ताले का उपयोग नहीं करता है, मुझे अभी भी डेडलॉक त्रुटियां मिलती हैं।

जब ऐसा होता है तो मैं डेडलॉक ग्राफ प्राप्त करने के लिए एसक्यूएल प्रोफाइलर के माध्यम से एक ट्रेस चलाता था, लेकिन इसका अधिक उपयोग नहीं था। यह पीड़ित प्रक्रिया को दिखाता है, जो "थ्रेड पूल" से जुड़ा हुआ है, जो सैकड़ों अन्य प्रक्रियाओं से जुड़ा हुआ है। आप यहाँ यह बाहर की जाँच कर सकते हैं:

http://i.stack.imgur.com/7rlv3.jpg

किसी को भी इस क्यों हो रहा है के बारे में कोई संकेत है? मैं पिछले कुछ दिनों में इसे समझने की कोशिश कर पागल हो रहा हूं। मेरी वर्तमान परिकल्पना यह है कि यह मेरे डीबी उदाहरण में उपलब्ध वर्कर थ्रेड से संबंधित है, उपलब्ध स्मृति की मात्रा, या कुछ वास्तविक क्वेरी-स्तर ताले से संबंधित नहीं है।

धन्यवाद!

Answer 1

इस तरह के डेडलॉक्स/ताले अजीब हैं और SQL सर्वर के बाहर कुछ इंगित करते हैं। इसके लायक होने के लिए, हमारे पास बहुत सी डेडलॉक समस्याएं थीं जो डिस्क की बाधा बन गईं!

मेरा सुझाव है कि आप परफमन चलाएं (और इसके बाद इसके कई अन्य टूल) और देखें कि यह कैसा चल रहा है।

Answer 2

आप ताले बिना एसक्यूएल सर्वर में कुछ भी ऐसा नहीं कर सकते - यहां तक ​​कि सबसे बुनियादी NOLOCK बयानों के साथ पलस्तर न्यूनतम पर एक स्कीमा ताला और शायद कुछ पेज ताले जारी करेगा क्वेरी।

डेडलॉक को हल करने के लिए आपको टी 1204 डेडलॉक ट्रेस प्राप्त करने की आवश्यकता है (अधिक जानकारी के लिए Deadlock Troubleshooting, Part 1 देखें) जो डेडलॉक में शामिल सटीक ताले और ऑब्जेक्ट्स को सूचीबद्ध करेगा - यह पता लगाने के लिए पर्याप्त जानकारी होनी चाहिए (उचित के साथ सिर खरोंच की मात्रा) वास्तव में क्या गलत हो गया।

पूरी तरह से एक गतिरोध के पीछे कारण को समझे बिना अलगाव स्तर बदल रहा है एक बालक मेरे लिए खतरनाक ...

एक कूबड़ यह मेरे एक मुद्दा मैं कुछ साल पहले किया था की याद दिलाता है के रूप में लगता है - UPDATE बयान deadlocking है SELECT कथन के विरुद्ध? (टी 1024 ट्रेस आपको यह बताएगा) और क्या आपके पास rowID पर गैर-क्लस्टर्ड इंडेक्स है? यदि ऐसा है तो आप this MSDN article पर विशेष रूप से उदाहरण 6: Nonclustered अनुक्रमणिका देखें। यदि नहीं, तो फिर भी उस आलेख को देखें क्योंकि यह कुछ अन्य प्रासंगिक डेडलॉक परिदृश्यों को समझाने में मदद कर सकता है, यदि आपको इसका विश्लेषण करने में सहायता की आवश्यकता है तो T1024 ट्रेस के परिणाम भी पोस्ट करें।

Answer 3

आपको एक अधिक गूढ़ जानवर का सामना करना पड़ा है: एक संसाधन डेडलॉक। आपके पास काम करने के लिए बच्चे के कार्यों (sys.dm_os_tasks) को बढ़ाने के लिए कोई धागा नहीं है क्योंकि सभी कर्मचारी (sys.dm_os_workers) व्यस्त हैं। बदले में, व्यस्त श्रमिक उन कार्यों को निष्पादित करते हैं जो अवरुद्ध होते हैं, संभवतः सामान्य ताले पर, शिकार द्वारा।

1) अद्यतन आप पोस्ट समानांतर जाने का प्रयास कर रहा है:

घर ले जाने के दो सबक मैं यहाँ देख रहे हैं। यदि अपडेट ठीक उसी प्रकार है जैसा आपने पोस्ट किया है, तो इसका मतलब है एक और केवल एक चीज: rowId पर कोई अनुक्रमणिका नहीं।

2) आपने ऊपरी छत पर max worker threads सेटिंग द्वारा सेट किया है। कोई आश्चर्य नहीं कि, आप क्लाइंट (hundreds of concurrent threads to execute thousands of task) में थ्रेड का दुरुपयोग करते हैं और अवांछित समांतरता के कारण सर्वर में इसे गुणा करते हैं।

एक समझदार डिज़ाइन एसिंक निष्पादन (BeginExecuteNonQuery) वास्तव में एसिंक कनेक्शन (AsynchronousProcessing=true) पर उपयोग करेगा और लंबित अनुरोधों के पूल का उपयोग करेगा ताकि यह किसी निश्चित दहलीज से ऊपर न हो। अधिक संभावना है कि, अभी भी, आप table valued parameter द्वारा अपडेट मानों के पूरे बैच में पास होंगे और फिर एक ही कथन में बैच किए गए पूरे सेट या पंक्तियों को अपडेट करेंगे। मैं समझता हूं कि मेरे सभी लिंक नेट के लिए हैं, जावा के लिए नहीं, मुझे परवाह नहीं है, आप समकक्ष जावा कार्यक्षमता को स्वयं खोद सकते हैं।

तो दिलचस्प है कि आपने इस तरह के एक गूढ़ डेडलॉक की खोज की है, यह केवल दिखाता है क्योंकि आपका डिज़ाइन, अच्छा ... बेकार है।