डीबी पदानुक्रमों को देखने की कोशिश करते समय "लॉक रिक्वेस्ट टाइम आउट अवधि पार हो गई" त्रुटि

17

मुझे डेटाबेस में समस्या आ रही है।

मैं बुनियादी प्रश्नों को चला सकता हूं, भले ही सामान्य से बहुत धीमी हो।
जब मैं SSMS ऑब्जेक्ट एक्सप्लोरर में तालिकाओं, विचारों या प्रक्रियाओं के लिए पदानुक्रम पेड़ों को देखने का प्रयास करता हूं, तो मुझे मिलता है lock request time out period exceeded।
इस डेटाबेस में वस्तुओं पर चलने वाली मेरी SSRS रिपोर्ट अब पूरी नहीं हो रही है।
इस डेटाबेस पर संग्रहीत कार्यविधियों से जुड़े कार्य भी नहीं चलते हैं।

मैंने sp_who2डेटाबेस पर सभी कनेक्शनों को खोजने और मारने का उपयोग करने की कोशिश की , हालांकि इससे समस्या हल नहीं हुई है।

यहाँ क्या हो रहा है? मैं इसे कैसे हल करूं?

sql-server sql-server-2008

— लॉयड बैंक
स्रोत

यह भी देखें: stackoverflow.com/questions/12167570/… ; सुनिश्चित नहीं है कि अगर एक डुप्लिकेट के रूप में गिना जाता है या नहीं।

— LittleBobbyTables - Au Revoir

नीचे मेरे जवाब के लिए आपकी टिप्पणी के आधार पर, मुझे लगता है कि आपको बहुत अधिक जानकारी प्रदान करने की आवश्यकता है। सर्वर का आकार कैसा है, क्या आपने देखा है कि यह प्रदर्शन काउंटर है, क्या यह डिस्क को स्वैप करना है या अन्यथा संसाधन किसी तरह से भूखे हैं। वास्तव में ऊपर की जाँच करना सुनिश्चित करें और कुछ भी नहीं मान लें। इसके अलावा, क्या ऐसा तब होता है जब आप डेस्कटॉप में रीमोट करते समय कनेक्ट होते हैं? क्या समस्या केवल एकल स्थान से पहुंचते समय उत्पन्न हो रही है? उस सर्वर के लिए नेटवर्क मौसम कैसा है (और इससे आपका कनेक्शन)?

— NotMe

3

लगता है जैसे आपके पास खुले लेनदेन हैं जो पढ़ने की पहुंच को तालिकाओं तक रोक रहे हैं।

— a_horse_with_no_name

12

यह एक लेन-देन के सतत रोलबैक के कारण हो रहा था। अंततः मेरे सर्वर क्लस्टर को फिर से शुरू करना पड़ा

— लॉयड बैंक
स्रोत

2

सेवा को फिर से शुरू करके मेरे लिए इसे हल कर दिया।

— हेरमैनकोडर

1

ऐसी स्थिति में पुनः

— आरंभ

dbcc opentran आपको बताएगा कि क्या खुले लेन

— Nate Anderson

मुझे यह अजीब लगता है कि जब कोई लेन-देन चल रहा होता है, तो मैं उदाहरण के लिए टेबल सेक्शन का विस्तार नहीं कर सकता। कोई डेटा नहीं, कोई DDL नहीं, कुछ भी नहीं, बस तालिकाओं की सूची।

— गेरेलिम

5

हरवेयर के विचार को छोड़कर, शायद आपको SQL सत्र को रोक देने वाली गतिविधि को जांचने के लिए स्क्रिप्ट को चलाने की आवश्यकता है, सामान्य परिदृश्य में से एक Implicit transactions OptionSQL सर्वर प्रबंधन स्टूडियो में उपयोग करने के लिए नहीं है ।

— टरबोट
स्रोत

हाय टर्बोट, क्या आप जो सुझाव दे रहे हैं उसके बारे में अधिक विस्तार में जा सकते हैं?

ऐसा लगता है कि जब यह पूरी तरह से समझाया नहीं जाता है, तो यह एक बेहतर जवाब हो सकता है, लेन-देन का सतत रोलबैक जो कि वापस रोल नहीं करता है, और केवल अंतर्निहित लेनदेन के कारण सक्षम हैं।

— कांस्टेंटाइनके

प्रश्न को पीछे हटाते हुए मैं यह नहीं कह सकता कि यह एक लेन-देन का स्थायी रोलबैक होना चाहिए। locking request time out period exceedमैं जज कहता हूं कि दौड़ने implicit transaction optionसे कारणों का बेहतर पता चल जाएगा।

— टर्बोट

उपकरण / विकल्प / क्वेरी निष्पादन / एसक्यूएल सर्वर / एएनएसआई / सेट अंतर्निहित लेनदेन

— तादेज

3

मुझे यह समस्या तब हुई जब मैंने एक स्पष्ट लेन-देन शुरू किया, जिसमें मैंने दूसरे डेटाबेस में चल रही स्क्रिप्ट से tempdb में तालिका बनाई (न कि tempdb)। जब मैंने लेन-देन किया था, तो मुझे उस टेबल पर ताला जारी नहीं हुआ था जिसे मैंने टेम्पर्ड बी में बनाया था।

इस पृष्ठ के लिए धन्यवाद , मैंने USEtempdb किया और निष्पादित किया DBCC OPENTRANऔर tempdb से उस कनेक्शन का SPID प्राप्त किया जो लॉक का कारण बन रहा था। फिर मुझे KILL <SPID number>इसे मारना है।

बहुत अनुग्रहकारी नहीं है, और मैंने टेम्पर्डब में बनाई गई तालिका में सभी जानकारी खो दी, लेकिन मेरे मामले में यह ठीक था।

— Baodad
स्रोत

हमारे मामले में, कोई DML आदेश (देखें परिभाषा) का उपयोग कर againt डेटाबेस जारी किया गया था पर सेट अंतर्निहित लेनदेन के बिना लेन-देन COMMIT , जो गलती से एक लंबे समय तक चलने लेन-देन का कारण बना। DBCC OPENTRAN का उपयोग करने से इस समस्या का जल्द पता लगाने में मदद मिली।

— जूलियो नोब्रे

1

ऐसी बहुत सी बातें हैं जो यह हो सकती हैं कि मैं आपको उत्तर देने के लिए मार्गदर्शन करने में मदद करने के लिए कुछ प्रश्न कर सकता हूं।

क्या DB सर्वर पर सिर्फ SQL सर्वर चलाने के लिए समर्पित है? यदि नहीं, तो कीमती प्रोसेसर समय चुराकर अन्य प्रक्रियाओं में हस्तक्षेप किया जा सकता है।
क्या DB सर्वर अनिवार्य रूप से मेमोरी से बाहर है? एसक्यूएल सर्वर हर एक बाइट को आवंटित करने का प्रयास करेगा, लेकिन अगर यह क्षमता पर है और आपके प्रश्नों को लोड करने के लिए अधिक डेटा की आवश्यकता होती है, तो वर्चुअल मेमोरी का उपयोग करने के लिए इसे वापस करना होगा, जो मूल रूप से सरल प्रश्नों को भी ले सकता है।
क्या समय पर तरीके से डेटा ट्रांसफर करने के लिए DB सर्वर का नेटवर्क बैंडविड्थ छोटा है?

दिन के अंत में, ऐसा लगता है कि आप जिस मशीन पर SQL सर्वर होस्ट कर रहे हैं, वह आकार में है जो आप करने की कोशिश कर रहे हैं। यह पूरी तरह से संभव है कि आप अंततः उन हार्डवेयर सीमाओं तक पहुंच गए हैं जहां प्रदर्शन मौलिक रूप से बंद हो रहा है। यदि यह मामला है (उपरोक्त प्रश्न आपको यह निर्धारित करने में मदद करेंगे) तो आप DB को एक सर्वर पर ले जाना चाहेंगे जो आपके द्वारा संसाधित किए जा रहे डेटा (और प्रश्नों) की मात्रा के लिए ठीक से आकार है।

इसका मतलब तेज प्रोसेसर, तेज ड्राइव या सिर्फ ज्यादा रैम इंस्टॉल करना हो सकता है।

— मैं नहीं
स्रोत

यह कोई हार्डवेयर समस्या नहीं है। सर्वर क्लस्टर कई डेटाबेस होस्ट करता है। यह एकमात्र डेटाबेस समस्या है

@ लॉयडबैंक: इसका मतलब यह नहीं है कि यह एक हार्डवेयर समस्या नहीं है। अगर मेरे पास 2 डेटाबेस हैं, तो वह उच्च लेनदेन दर के साथ 20GB आकार का है और दूसरा जो 1GB कम लेनदेन दर के साथ है तो मुझे उम्मीद है कि 1GB db को वर्चुअल मेमोरी में स्वैप किया जाएगा; जो क्वेरी समय को बढ़ाएगा। यदि 20GB db को काफी मुश्किल से मारा जा रहा है, तो इससे छोटे के साथ कनेक्टिविटी की समस्या हो सकती है।

— NotMe

1

"जब मैं SSMS ऑब्जेक्ट एक्सप्लोरर में तालिकाओं, विचारों या प्रक्रियाओं के लिए पदानुक्रम पेड़ों को देखने का प्रयास करता हूं, तो मुझे लॉक अनुरोध समय समाप्त हो गया है।"

मेरे पास बिल्कुल वही मुद्दा था। मैं क्वेरी निष्पादन विंडो में गया और; टाइप किया और निष्पादित ROLLBACKविवरण।

ऐसा लगता है कि कुछ बयानों की श्रृंखला से पहले मैं उस पर अमल कर रहा था, खुले लेनदेन का आयोजन किया। विशेष रूप से, क्योंकि उनमें से कुछ जहां डीडीएल बयान देते हैं। एक बार जब मैंने रोलबैक जारी किया, तो वस्तु पदानुक्रम ने काम करना शुरू कर दिया।

— टीएस
स्रोत

0

जैसा कि कई लोग पहले ही इंगित कर चुके हैं, आमतौर पर एक लंबे समय तक चलने वाला लेन-देन होता है, जो ज्यादातर मेरे द्वारा इस्तेमाल किए गए SET IMPLICIT TRANSACTIONS को मिस करता है, जिसका इस्तेमाल बिल्कुल भी नहीं किया जाना चाहिए। यह देखने के लिए कि ब्रेंट ओजर के अंतर्दृष्टि लेख की जांच क्यों करें

वैसे भी, आप निम्नलिखित क्वेरी का उपयोग करके लंबे समय तक चलने वाले लंबित लेनदेन की सूची प्राप्त कर सकते हैं।

SELECT
    [s_tst].[session_id],
    [s_es].[login_name] AS [Login Name],
    DB_NAME (s_tdt.database_id) AS [Database],
    [s_tdt].[database_transaction_begin_time] AS [Begin Time],
    [s_tdt].[database_transaction_log_bytes_used] AS [Log Bytes],
    [s_tdt].[database_transaction_log_bytes_reserved] AS [Log Rsvd],
    [s_est].text AS [Last T-SQL Text],
    [s_eqp].[query_plan] AS [Last Plan]
FROM
    sys.dm_tran_database_transactions [s_tdt]
JOIN
    sys.dm_tran_session_transactions [s_tst]
ON
    [s_tst].[transaction_id] = [s_tdt].[transaction_id]
JOIN
    sys.[dm_exec_sessions] [s_es]
ON
    [s_es].[session_id] = [s_tst].[session_id]
JOIN
    sys.dm_exec_connections [s_ec]
ON
    [s_ec].[session_id] = [s_tst].[session_id]
LEFT OUTER JOIN
    sys.dm_exec_requests [s_er]
ON
    [s_er].[session_id] = [s_tst].[session_id]
CROSS APPLY
    sys.dm_exec_sql_text ([s_ec].[most_recent_sql_handle]) AS [s_est]
OUTER APPLY
    sys.dm_exec_query_plan ([s_er].[plan_handle]) AS [s_eqp]
where [s_tdt].[database_transaction_begin_time] is not null
ORDER BY
    [Begin Time] ASC;

https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/

— जूलियो नोब्रे
स्रोत