TempDB सामग्री

Question

हमारे पास SQL ​​Server 2014 SP1 पर एक सक्रिय OLTP 40GB डेटाबेस है। IO_Completion प्रतीक्षा के साथ क्वेरी धीमी पाई जाती हैं, डिस्क कतार लंबाई 900 तक बढ़ रही है, और SQL सर्वर प्रत्युत्तर देना बंद कर देता है। हमने क्या प्रयास किया:

1. आवृत्ति को पुनरारंभ करें और एक मिनट में यह उसी तरह व्यवहार करना शुरू कर देता है।

2. दूसरे पुनरारंभ के बाद, हमने प्रत्येक टेम्पर्ड डेटाफाइल के प्रारंभिक आकार को बदल दिया (इसमें 16 डेटा फाइलें बनाई गई हैं) और यह सही तरीके से काम करना शुरू कर देता है।

नोट: हम मध्यवर्ती परिणाम सेट के लिए तालिका चर का उपयोग कर रहे हैं। ये परिणाम सेट बहुत छोटे हैं।

यह एक महीने में दो बार हुआ। जब भी मैं डेटा फ़ाइलों में मैन्युअल रूप से थोड़ा सा स्थान जोड़ता हूं, तो यह सामान्य रूप से काम करना शुरू कर देता है। अधिक दिलचस्प बात यह है कि हमारे पास SQL ​​Server 2008 R2 और SQL Server 2012 पर समान सेटअप (समान हार्डवेयर, समान फ़ोल्डर और फ़ाइलें सेटअप, समान कार्यभार) ठीक काम कर रहा है।

स्थायी समाधान खोजने के लिए कृपया हमारी सहायता करें।

सभी डेटा फ़ाइलों का प्रारंभिक आकार समान 1000 एमबी है, वर्तमान 1500 एमबी प्रत्येक है। सभी समान हैं। प्रत्येक के लिए ऑटोग्रॉथ 100 एमबी है। इससे पहले हम पीएफएस और जीएएम पेज विवाद का सामना कर रहे थे और हम 16 तक बढ़ गए और समस्या हल हो गई। दोनों झंडे 1117 और 1118 सक्षम हैं। 2 NUMA नोड्स पर 24 कोर। सभी डेटाफ़ाइल्स एक ही वॉल्यूम पर हैं। सरल डिस्क, नहीं SAN।

इंस्टेंस एक भौतिक मशीन पर है। टेबल वेरिएबल्स के साथ प्रश्न और हैश जॉइन के साथ प्रश्न IO_Completion वेट को सबसे अधिक उत्पन्न कर रहे हैं।

---

वूडोब द्वारा विस्तृत उत्तर ने हमें और अधिक विस्तार से खोज करने के लिए प्रेरित किया। इससे पहले हम कैसे चूक गए:

डेटाबेस 'tempdb' में फ़ाइल 'टेम्पलॉग' का ऑटोज्रो उपयोगकर्ता द्वारा रद्द कर दिया गया था या 7704 मिलीसेकंड के बाद का समय समाप्त हो गया था। इस फ़ाइल के लिए एक छोटा FILEGROWTH मान सेट करने के लिए या स्पष्ट रूप से एक नया फ़ाइल आकार सेट करने के लिए ALAT DATABASE का उपयोग करें।

यह हम लॉग में पाया जब कभी इस प्रकार की समस्या हो रही है। हम तेज ड्राइव को अलग करने के लिए TempDB बढ़ रहे हैं।

Answer 1

मुझे लगता है कि आपने अपने tempdb को ओवरफ्रैगमेंट किया है और सर्वर सीपीयू और डिस्क सेटअप के बीच एक बेमेल है, लेकिन चलो कुछ और जानकारी एकत्र करते हैं:

प्रश्न / आगे की जानकारी की आवश्यकता है

• कृपया प्रोसेसर नाम और प्रकार की पुष्टि करें (मैं मूल रूप से यह स्थापित करने की कोशिश कर रहा हूं कि क्या यह एचटी के साथ 2 x हेक्स-कोर है)। सिस्टम जानकारी (उदाहरण के लिए कंट्रोल पैनल> सिस्टम और सुरक्षा> विंडोज सर्वर 2012 R2 पर सिस्टम) और / या sysinternals टूल CoreInfo का उपयोग करें।
• कृपया सर्वर मैक्सडॉप (जैसे EXEC sp_configure 'max degree of parallelism') की पुष्टि करें । यदि सीपीयू हेक्स-कोर हैं, तो सर्वर मैक्सडॉप अधिकतम 6 (प्रति के रूप में) होना चाहिए यहां के ) , या यकीनन एक ओएलटीपी सिस्टम पर कम होगा। मैं आम तौर पर अपने सर्वर डीओपी के साथ अधिकतम 8 तक अपनी टेम्पर्ड फाइलें रखता हूं, लेकिन हम उस पर आएंगे।
• कृपया बॉक्स और SQL सर्वर मेमोरी कैप (उदाहरण के लिए) सर्वर की कुल मेमोरी की पुष्टि करें EXEC sp_configure 'max server memory (MB)' ) ।
• कृपया पुष्टि करें कि क्या कोई अन्य सेवाएँ बॉक्स पर चल रही हैं (जैसे SSIS, SSAS, SSRS, एप्लिकेशन, iTunes आदि)
• कृपया पुष्टि करें कि SQL सर्वर सेवा खाते के लिए त्वरित फ़ाइल प्रारंभ सक्षम किया गया है। ( यहां परीक्षण करने के तरीके )।
• सीपीयू (गोमांस 2 नोड NUMA सेटअप) के बीच इतनी बड़ी विसंगति क्यों है, एक डिस्क (होम पीसी) का सत्यापन? टेम्पों के लिए डिस्क, स्ट्रिपिंग, एसएसडी को जोड़ने पर विचार करें (हालांकि अति-प्रतिक्रिया से बचें ।
• कृपया समस्या प्रश्नों में से किसी एक के लिए वास्तविक निष्पादन योजना जोड़ें। यदि आप चाहें तो SQL संतरी योजना एक्सप्लोरर के साथ अनाम ।

• एक ओएलटीपी प्रणाली में टेबल चर के साथ हश जुड़ता है? यह तालिका चर, मुख्य तालिका या दोनों पर अनुक्रमण की कमी का सुझाव देता है। क्या आप अपने टेबल वेरिएबल को इस तरह घोषित कर रहे हैं (जिसमें कोई इंडेक्स नहीं है)?

  DECLARE @t TABLE ( x INT )

• टेबल चर परिभाषा पर कंजूसी मत करो, भले ही वह छोटे परिणाम धारण कर रहा हो। ऑप्टिमाइज़र को हमेशा अधिक से अधिक जानकारी देना सबसे अच्छा है ताकि अशक्तता, विशिष्टता के साथ स्पष्ट हो, चाहे सूचकांक को क्लस्टर्ड / नॉन-क्लस्टर्ड, जैसे या नहीं

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• निष्पादन योजना को पोस्ट करने से इसका निदान करने में मदद मिलेगी।

• यहाँ , प्रति के रूप में तालिका चर कैशिंग को रोकने के लिए कोड की जाँच करें । मुझे लगता है कि गतिशील एसक्यूएल और RECOMPILE के साथ निष्पादित केवल टेबल चर को प्रभावित करने वाले हैं।

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• संदेशों के लिए SQL सर्वर लॉग (ऑब्जेक्ट एक्सप्लोरर> प्रबंधन> SQL सर्वर लॉग) की जाँच करें, उदाहरण के लिए IO चेतावनियाँ।

• Windows इवेंट व्यूअर की जाँच करें
• SP1 के बाद से कई बिल्ड जारी किए गए हैं। SP1 के बाद से लगाए गए CU फ़िक्सेस की समीक्षा करें । यह संभव है कि SP1 में बग्स हैं जो बाद के CUs, जैसे FIX में तय किए गए हैं: क्रमबद्ध ऑपरेटर SQL सर्वर 2012 या SQL सर्वर 2014 में tempdb तक फैलता है जब अनुमानित संख्या में पंक्तियाँ और पंक्ति आकार सही होते हैं https://support.microsoft.com/en- हमें / केबी / 3088480
• किसी भी हॉटफ़िक्स को लागू करने से पहले इसे स्थापित करें, हालांकि नई सुविधाओं की संख्या (इन-मेमोरी ओएलटीपी, क्लस्टर किए गए कॉलमस्टोर) के कारण, एसक्यूएल सर्वर 2014 के साथ सीयू के साथ अद्यतित रहना अधिक महत्वपूर्ण है।
• अंत में, प्रति कोर एक tempdb फ़ाइल की आवश्यकता एक मिथक है और आपके डिस्क सेटअप को देखकर मेरा अनुमान है कि tempdb अत्यधिक खंडित है। मुझे लगता है कि आपके पास एक डिस्क-हेड है, टेम्पर्डबेड में एक फाइलग्रुप, कई फाइलें हैं।

हालाँकि हम जो जानते हैं उसे भूल जाते हैं; एक परीक्षण रिग बनाएं जो आपकी समस्या को पुन: पेश करता है, और अस्थायी फ़ाइलों की संख्या को कम करने के साथ प्रयोग करें ... 1, 2, 4, 6 आदि पर शुरू करें, जानकारी इकट्ठा करें, एक प्रमाण-आधारित निर्णय लेने के लिए। अब यह कठिन है क्योंकि आपकी समस्या रुक-रुक कर आ रही है और हो सकता है कि आप अपने टेम्पर्ड सेटअप में गड़बड़ी न कर पाएं, लेकिन मैं इस बारे में सोचूंगा।

सौभाग्य। हमें बताएं कि आपके द्वारा किस प्रकार प्रबंध किया जाता है।

Comments

बहुत बहुत धन्यवाद, आपके विस्तार के जवाब ने हमें और अधिक विस्तार से खोज करने के लिए प्रेरित किया। डेटाबेस में "टेम्पोग्ल" फ़ाइल के ऑटोग्रॉव से पहले हमने इसे कैसे याद किया 'टेम्पर्डब' को उपयोगकर्ता द्वारा रद्द कर दिया गया था या 7704 मिलीसेकंड के बाद समय समाप्त हो गया था। इस फ़ाइल के लिए एक छोटा FILEGROWORD मान सेट करने के लिए या स्पष्ट रूप से एक नया फ़ाइल आकार सेट करने के लिए ALTER DATABASE का उपयोग करें। " यह हम लॉग में पाया जब कभी इस प्रकार की समस्या हो रही है। हम तेज ड्राइव को अलग करने के लिए TempDB बढ़ रहे हैं।

— आसीम.बदुल्ला

हाल ही में हमने पाया है कि, TempDB अभी भी दबाव में है और यह इसलिए हो रहा है क्योंकि हम "Contains Table" का उपयोग कर रहे हैं और SQL Server हर निष्पादन पर एक Hash Join बना रहा है। मूल रूप से SQL Server 2014 में इसकी बग। नवीनतम सीयू और मुद्दे का उपयोग करके फिक्स्ड। support.microsoft.com/en-us/kb/2999809

— aasim.abdullah