स्लीपिंग एसपीआईडी ​​अन्य लेनदेन को अवरुद्ध करता है

Question

मुझे वास्तव में परेशानी हो रही है कि हम जो कुछ अनुभव कर रहे हैं, उसे रोककर ट्रैक करें।

SPID की स्थिति को रोकने वाली जड़ 'स्लीपिंग' है, cmd 'AWAITING COMMAND' है, और sqltextहै SET TRANSACTION ISOLATION LEVEL READ COMMITTED।

जब मैं अवरुद्ध लेनदेन गणना रिपोर्ट द्वारा शीर्ष लेनदेन को देखता हूं, तो ब्लॉकिंग SQL स्टेटमेंट '-' है।

मैंने SQL पर एक ट्रेस किया है और जब ब्लॉकिंग रूट ब्लॉकिंग SPID ट्रेसिंग होता है, लेकिन यह वास्तव में मुझे कहीं भी नहीं ले गया है। अंतिम ट्रेस स्टेटमेंट sqltextउपरोक्त के समान है SET TRANSACTION ISOLATION LEVEL READ COMMITTED।

मैंने सभी संबंधित संग्रहीत कार्यविधियाँ जाँच ली हैं जिन्हें मैं यह सुनिश्चित करने के लिए पा सकता हूँ कि उनके पास TRY / CATCH BEGIN TRAN / COMMIT TRAN / ROLLBACK TRAN स्टेटमेंट हैं (हम हर चीज के लिए संग्रहीत कार्यविधियों का उपयोग करते हैं ताकि कोई स्टैंडअलोन स्टेटमेंट न चले)। यह मुद्दा अभी पिछले 24 घंटों से अधिक हो रहा है और कोई भी सिस्टम में कोई बदलाव करने का दावा नहीं कर रहा है।

समाधान: हमारी शायद ही कभी इस्तेमाल की गई संग्रहीत प्रक्रियाओं में से एक सम्मिलित करने के साथ एक त्रुटि थी (स्तंभों की संख्या मेल नहीं खाती), लेकिन हम अभी भी उलझन में हैं कि वास्तव में क्या हो रहा था।

जब सभी ट्रेस जानकारी को देखते हैं, तो इस संग्रहीत कार्यविधि के लिए EXEC कथन कई बार सूचीबद्ध किया गया था, लेकिन ब्लॉक SPID पर ब्लॉक होने से ठीक पहले कभी नहीं। ऐसा लगता था कि जब यह अवरुद्ध करना शुरू कर रहा था, तो ट्रेस ने इसे निष्पादित नहीं किया था (या इसके भीतर कोई भी कथन)। हालांकि, अन्य बार भी ट्रेस रिकॉर्ड किया गया था कि यह निष्पादन है और कोई अवरुद्ध नहीं हुआ।

संग्रहीत कार्यविधि त्रुटि रिपोर्ट एक उपयोगकर्ता से आई थी, और मैं एसएससीएमएस में कई EXEC बयानों को खोजने और उन्हें चलाने में सक्षम था। कोई समय नहीं जब मैंने उन्हें दौड़ाया था, क्या हमारे पास कोई अवरोधक था या क्या वे लटकाए थे। वे उम्मीद के मुताबिक भागे (कैच ब्लॉक ने निकाल दिया और त्रुटि के बाद लेन-देन वापस कर दिया)। संग्रहीत कार्यविधि को हल करने के बाद, हमने समस्या को फिर से नहीं देखा है।

Comments

मुझे लगता है कि अवरुद्ध SPID का होस्ट नाम बिल्कुल भी मदद नहीं कर रहा है?

— जॉन सिगेल

नहीं, यह सिर्फ हमारे वेबसर्वरों में से एक का आईपी है ... हमारे पास लॉगिन / पंजीकरण प्रक्रिया के दौरान प्रत्येक एसपीआरओसी कॉल के लिए एसक्यूएल लॉगिन को बदलने का एक और विचार है (जो हमें लगता है कि जहां त्रुटि हो रही है) एक अलग उपयोगकर्ता नाम के लिए हो सकता है हमें अलग करने में मदद करें जो SPROC अवरुद्ध होने का कारण हो सकता है।

— ब्रैड

TRY / CATCH संकलन त्रुटियों को नहीं पकड़ेगा और एक बेमेल कॉलम सम्मिलित करना ऐसी संकलन त्रुटि होगी। यह भी XX के कई को ट्रिगर नहीं करेगा: पूरी तरह से प्रोफाइलर घटनाओं।

— रेमस रूसु

यह वास्तव में इस मामले में एक संकलन त्रुटि नहीं है क्योंकि प्रतिभाशाली डेवलपर ने INSERT INTO [टेबल] का चयन किया [*] अन्य से [*] और यह सहकर्मी में पकड़ा नहीं गया था। मैंने 3 बार के सत्रों में कोल्डफ़्यूज़न से 1000 बार SPROC को डेवलपमेंट पर चलाया और इसने लेन-देन को कभी भी खुला नहीं छोड़ा जैसे यह उत्पादन पर था।

— ब्रैड

Answer 1

टिप्पणियों से, मैं अनुमान लगा रहा हूं कि आपके पास एक क्लाइंट साइड कमांड टाइमआउट था जिसने एसक्यूएल क्वेरी को निरस्त कर दिया है। यह लेन-देन को रोलबैक नहीं करता है क्योंकि कनेक्शन पूलिंग के कारण कनेक्शन SQL सर्वर पर खुला रहता है।

तो, आपको SET XACT_ABORT का उपयोग करना होगा या कुछ क्लाइंट रोलबैक कोड जोड़ना होगा

देखें एसक्यूएल सर्वर लेन-देन समय समाप्त सभी रक्तमय जानकारी के लिए

Comments

हमारे सभी SPROCs में TRY / CATCH ब्लॉक और BEGIN TRAN / COMMIT TRAN / ROLLBACK TRAN स्टेटमेंट, ROLLBACK CATCH में हैं। क्या अभी भी XACT_ABORT का प्रभाव पड़ेगा?

— ब्रैड

@ ब्रैड: हाँ। मेरा लिंक देखें पकड़ ब्लॉक कमांडटाइमआउट पर हिट नहीं है

— gbn

gbn: धन्यवाद। मैं अभी भी असमंजस में हूँ। हमारे कनेक्शन कभी भी टाइमआउट (0) पर सेट नहीं हैं। इसलिए आप कह रहे हैं कि यदि हम कनेक्शन का पुन: उपयोग करते हैं, और एक कनेक्शन एक त्रुटि के साथ एक SPROC चलाता है (जिसमें TRY / CATCH और TRAN ब्लॉक हैं), तो यह किसी भी तरह CATL ब्लॉक में ROLLBACK को कभी नहीं चला सकता है और इस प्रकार तालिकाओं को लॉक कर सकता है और लेन-देन कर सकता है। खुला हुआ? यह मेरे लिए कोई मतलब नहीं है।

— ब्रैड

@ ब्रैड: एक SPROC एक त्रुटि के साथ CATCH ब्लॉक को हिट करेगा। मैंने अन्यथा या अलग नहीं कहा। लेकिन मेरा लिंक बताता है कि अगर आपके पास एक कमांडटाइमआउट है, जो एक कनेक्शन टाइमआउट के लिए अलग है। क्लाइंट का कहना है कि "गर्भपात" और SQL सर्वर प्रोसेसिंग बंद कर देता है। Ergo, CATCH ब्लॉक या रोलबैक या कमिट कभी हिट नहीं होता है

— gbn

मुझे नहीं लगता कि हमारे पास कमांडटाइमआउट निर्दिष्ट है। हमारे सभी संग्रहीत कार्यविधियाँ sqlstress का उपयोग करके परीक्षण कर रही हैं और 10 उपयोगकर्ताओं 10 पुनरावृत्तियों (न्यूनतम पर) में 1000ms के तहत प्रदर्शन करना चाहिए। मैं अभी भी बहुत उलझन में हूं कि क्या हुआ है, लेकिन मैं इस सवाल को अपडेट कर रहा हूं कि हमें क्या समस्या थी।

— ब्रैड

Answer 2

अंतिम स्टेटमेंट को देखने के लिए sysinos_exec_connections में सबसे ज्यादा_सेंट_सक्कल_हैंडल का उपयोग करें।

SELECT  t.text,
        QUOTENAME(OBJECT_SCHEMA_NAME(t.objectid, t.dbid)) + '.'
        + QUOTENAME(OBJECT_NAME(t.objectid, t.dbid)) proc_name,
        c.connect_time,
        s.last_request_start_time,
        s.last_request_end_time,
        s.status
FROM    sys.dm_exec_connections c
JOIN    sys.dm_exec_sessions s
        ON c.session_id = s.session_id
CROSS APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) t
WHERE   c.session_id = 72;--your blocking spid

यह भी जांचें कि क्या उस स्पिड के लिए कोई खुला लेनदेन है

SELECT  st.transaction_id,
        at.name,
        at.transaction_begin_time,
        at.transaction_state,
        at.transaction_status
FROM    sys.dm_tran_session_transactions st
JOIN    sys.dm_tran_active_transactions at
        ON st.transaction_id = at.transaction_id
WHERE   st.session_id = 72;--your blocking spid

Comments

आप DBCC INPUTBUFFER(spid)अंतिम SQL निष्पादित को देखने के लिए भी उपयोग कर सकते हैं।

— माइक फाल

मैंने उन सभी का उपयोग किया है और अंतिम कमांड हमेशा वही है जो मैंने अपने मूल पद पर रखी है: सेट ट्रांसलेशन इज़ेक्शन लेवल रीड कमिटेड। मैंने DBCC OPENTRAN भी चलाया और देख सकते हैं कि अवरुद्ध PID के लिए एक खुला लेनदेन है।

— ब्रैड

मेरा पहला चयन भी आपको प्रक्रिया का नाम देता है, यदि कथन वास्तव में एक प्रक्रिया का हिस्सा है।

— सेबस्टियन मेन

मैं आपको विश्वास दिलाता हूं कि हम अपने वेब सर्वर से कोई एडहॉक क्वेरी का उपयोग नहीं करते हैं, और जब मैं उस पहली क्वेरी को चलाता हूं, तब भी, जहां बिना किसी क्लॉज के मुझे केवल कुछ ही एसपीआरसी सत्रों में नामित SPROC मिलता है, बाकी वह कॉलम NULL है।

— ब्रैड

मुझे लगता है कि मेरे पास सत्र के टन हैं जो कहते हैं कि 'सेट ट्रांसलेशन इज़ेक्शन लेवल रीड कमिटेड' और ये सभी कोल्डफ़्यूज़न (हमारे वेब सर्वर पर उपयोग की जाने वाली मुख्य स्क्रिप्टिंग) से हैं। शायद कोल्डफ़्यूजन जब निष्क्रिय कनेक्शन जारी करने के लिए उस बयान को जारी करता है (जैसा कि कनेक्शन खुला रखने के लिए सेट है)।

— ब्रैड

Answer 3

क्या आपने एडम मैकहानिक के sp_whoisactive का उपयोग करने की कोशिश की है ? यह देखने के लिए कि यह वास्तव में एक खरीद के भीतर है, बाहरी आदेश प्राप्त करने का विकल्प है। यह हो सकता है कि यह आवेदन एक लेन-देन करने के बजाय खुला लेनदेन कर रहा हो। साथ ही DBCC OPENTRAN को देखने का प्रयास करें ।

Comments

DBCC OPENTRAN के लिए धन्यवाद। यह मुझे बताता है कि अवरुद्ध पीआईडी ​​में एक खुला लेनदेन है, लेकिन अधिक विवरण उपलब्ध नहीं हैं। sp_whoisactive अवरुद्ध प्रक्रिया पर वही जानकारी देता है जैसा कि मैं अपने दम पर प्राप्त करने में सक्षम रहा हूं। अभी भी इस बात का कोई ब्योरा नहीं है कि ATION सेट ट्रांजैक्शन आईवोल्यूशन लेवल रीड कमिटी ’के अलावा क्या चल रहा है

— ब्रैड