संपादित करें: हल किया गया, तालिका पर एक लूप के साथ एक ट्रिगर था (नीचे अपना उत्तर नीचे पढ़ें)।DELETE स्टेटमेंट SQL सर्वर पर किसी स्पष्ट कारण के लिए लटकता है
DELETE FROM tablename WHERE pk = 12345
यह सिर्फ लटकी हुई है, कोई समय समाप्ति, कोई कुछ भी नहीं:
हम एक सरल हटाने बयान है कि इस तरह दिखता है।
हमने निष्पादन योजना को देखा है, और इसमें यह सुनिश्चित करने के लिए संबंधित तालिकाओं पर कई लुकअप शामिल हैं कि कोई भी विदेशी कुंजी डिलीट की यात्रा नहीं करेगी, लेकिन हमने सत्यापित किया है कि इनमें से किसी भी अन्य तालिका में कोई भी पंक्ति नहीं है विशेष पंक्ति
इस समय डेटाबेस से कोई अन्य उपयोगकर्ता कनेक्ट नहीं है।
हमने इसके खिलाफ डीबीसीसी चेकडबी चलाया है, और यह 0 त्रुटियों की रिपोर्ट करता है।
sp_who और sp_lock जबकि क्वेरी व्यतीत कर रहा है के परिणामों को देखते हुए, मुझे लगता है कि मेरी spid पीएजी और कुंजी ताले के बहुत सारे है, साथ ही कभी-कभी टैब ताला है पर ध्यान दें।
तालिका में 1.777.621 पंक्तियां हैं, और हाँ, पीके प्राथमिक कुंजी है, इसलिए यह सूचकांक के आधार पर एक पंक्ति पंक्ति हटा है। निष्पादन योजना में कोई तालिका स्कैन नहीं है, हालांकि मुझे लगता है कि इसमें कुछ ऐसा है जो टेबल स्पूल (उत्सुक स्पूल) कहता है, लेकिन पंक्तियों की अनुमानित संख्या कहता है 1. क्या यह वास्तव में छिपाने में टेबल-स्कैन हो सकता है? यह केवल कहता है कि यह प्राथमिक कुंजी कॉलम को देखता है।
तालिका पर डीबीसीसी डीब्रेन्डएक्स और अद्यतन सांख्यिकी का प्रयास किया। दोनों उचित समय के भीतर पूरा हो गया।
दुर्भाग्य से इस विशेष तालिका पर सूचकांक की एक बड़ी संख्या है। यह हमारे सिस्टम में कोर टेबल है, जिसमें बहुत से कॉलम और संदर्भ हैं, दोनों आउटगोइंग और इनकमिंग। सटीक संख्या 48 इंडेक्स + प्राथमिक कुंजी क्लस्टर सूचकांक है।
हमें और क्या देखना चाहिए?
ध्यान दें कि इस तालिका में पहले यह समस्या नहीं थी, यह समस्या आज सुस्त हो गई। हमारे पास एक ही टेबल सेटअप (ग्राहक डेटाबेस की प्रतियां) के साथ कई डेटाबेस भी हैं, और वे अपेक्षा के अनुसार व्यवहार करते हैं, यह केवल समस्याग्रस्त है।
आपने एक लूप का उपयोग न करने के लिए ट्रिगर को ठीक किया है ना? एक ट्रिगर में लगभग कर्सर या लूप नहीं होना चाहिए। – HLGEM