आँकड़ों को समझना, निष्पादन योजना, और 'आरोही प्रमुख समस्या'


11

मैं आँकड़ों, निष्पादन योजनाओं, संग्रहीत कार्यविधि निष्पादन के बीच संबंधों को बेहतर ढंग से समझने की कोशिश कर रहा हूं।

क्या मैं यह कहने में सही हूं कि आँकड़े केवल एक संग्रहीत प्रक्रिया के लिए निष्पादन योजना बनाते समय उपयोग किए जाते हैं, और उनका उपयोग वास्तविक निष्पादन संदर्भ में नहीं किया जाता है? दूसरे शब्दों में, यदि यह सच है, तो एक बार योजना बन जाने के बाद (और इसे ठीक से पुन: उपयोग किया जाता है), "आँकड़े" कितने महत्वपूर्ण हैं?

मैं विशेष रूप से मेरे द्वारा पढ़े गए एक लेख ( सांख्यिकी, पंक्ति अनुमान और आरोही तिथि स्तंभ ) से प्रेरित था , जो हमारे ग्राहक के कई डेटाबेस के साथ दैनिक रूप से सामना करने वाले एक परिदृश्य के समान है।

हमारे पास हमारे सबसे बड़े तालिकाओं में एक आरोही तिथि / समय स्तंभ है जिसे हम एक विशिष्ट संग्रहीत कार्यविधि का उपयोग करके नियमित रूप से क्वेरी करते हैं।

जब आप एक दिन में एक सौ हज़ार पंक्तियाँ जोड़ रहे हैं, तो आप फिजूलखर्ची को बढ़ने से कैसे रोक सकते हैं?

यदि हम इस समस्या का सामना करने के लिए बार-बार आँकड़े अपडेट कर रहे हैं, तो क्या इस संग्रहीत प्रक्रिया के विकल्प पर OPTION (RECOMPILE) संकेत का उपयोग करने का कोई मतलब होगा?

किसी भी सलाह या सिफारिशों की सराहना की जाएगी।

अद्यतन : मैं SQL सर्वर 2012 (SP1) का उपयोग कर रहा हूँ।

जवाबों:


5

क्या मैं यह कहने में सही हूं कि आँकड़े केवल एक संग्रहीत प्रक्रिया के लिए निष्पादन योजना बनाते समय उपयोग किए जाते हैं, और उनका उपयोग वास्तविक निष्पादन संदर्भ में नहीं किया जाता है?

नहीं, क्या होता है कि संग्रहीत प्रक्रिया के लिए निष्पादन योजना कैश की जाती है। यह मानते हुए कि योजना को जारी रखने के लिए पर्याप्त उपलब्ध मेमोरी है, यह तब तक नहीं बदलेगा जब तक कि निम्न में से कोई एक नहीं होता ( SQL Server दस्तावेज़ में निष्पादन योजना कैशिंग और पुन: उपयोग से, जोर दिया):

  • एक तालिका या दृश्य द्वारा किए गए परिवर्तन क्वेरी द्वारा संशोधित (वैकल्पिक तालिका और अन्य दृश्य)।
  • एकल प्रक्रिया में किए गए परिवर्तन, जो उस प्रक्रिया के लिए सभी योजनाओं को कैश से बदल देंगे (अलर्ट प्रक्रिया)।
  • निष्पादन योजना द्वारा उपयोग किए जाने वाले किसी भी सूचकांक में परिवर्तन।
  • निष्पादन योजना द्वारा उपयोग किए गए आंकड़ों पर अपडेट, या तो स्पष्ट रूप से एक स्टेटमेंट, जैसे कि अद्यतन सांख्यिकी, या स्वचालित रूप से उत्पन्न।
  • निष्पादन योजना द्वारा उपयोग किए गए सूचकांक को छोड़ना।
  • Sp_recompile के लिए एक स्पष्ट कॉल।
  • कुंजियों में परिवर्तन की बड़ी संख्या (आईएनएसईआरटी या DELETE द्वारा उत्पन्न अन्य उपयोगकर्ताओं के कथन जो क्वेरी द्वारा संदर्भित तालिका को संशोधित करते हैं)।
  • ट्रिगर्स वाली तालिकाओं के लिए, यदि सम्मिलित या हटाए गए तालिकाओं में पंक्तियों की संख्या काफी बढ़ जाती है।
  • RECOMPILE विकल्प का उपयोग करके संग्रहीत प्रक्रिया को निष्पादित करना।

इसलिए यदि आँकड़े अपडेट किए जाते हैं, तो कैश्ड योजना अपने आप नए आँकड़ों को ध्यान में रख लेगी और पुन: संकलित कर दी जाएगी।

जब आप एक दिन में एक सौ हज़ार पंक्तियाँ जोड़ रहे हैं, तो आप फिजूलखर्ची को बढ़ने से कैसे रोक सकते हैं?

एक तरीका यह है कि यदि तालिका में बहुत सारे अपडेट हैं, जैसा कि ऊपर बताया गया है। कुछ सौ हजार बदली हुई पंक्तियाँ इस स्थिति को संतुष्ट कर सकती हैं। लेकिन अगर आप सुनिश्चित होना चाहते हैं या आपके पास अधिक दानेदार नियंत्रण है: अपने आँकड़े अपडेट करके। आप SQL सर्वर को आँकड़ों को ऑटो बनाने और प्रबंधित करने की अनुमति दे सकते हैं या मैन्युअल रूप से स्वयं कर सकते हैं। आप SQL सर्वर ऑटो अद्यतन और ऑटो बनाएँ सांख्यिकी विकल्पों में से किसी भी विधि पर अधिक जानकारी प्राप्त कर सकते हैं । जब / यदि आप अनुक्रमितों का एक साप्ताहिक पुनर्निर्माण करते हैं, तो यह अद्यतन किए जाने की योजना को भी ट्रिगर करेगा। कुछ परीक्षण यह देखने के लिए करें कि आपके लिए सबसे अधिक फायदेमंद क्या है, क्योंकि आँकड़े भी अक्सर अपडेट करने से कोई वास्तविक प्रदर्शन परिणाम प्राप्त नहीं हो सकता है।

यदि हम इस समस्या का सामना करने के लिए बार-बार आँकड़े अपडेट कर रहे हैं, तो क्या इस संग्रहीत प्रक्रिया के विकल्प पर OPTION (RECOMPILE) संकेत का उपयोग करने का कोई मतलब होगा?

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


RECOMPILEवैसे भी एक आँकड़े अद्यतन का कारण नहीं होगा।
मार्टिन स्मिथ

@MartinSmith सही! मैं इसे और अधिक स्पष्ट करने के लिए संपादित करूँगा।
लोवलीडा

@LowlyDBA आप निम्नलिखित विषय का उल्लेख कर सकते हैं? dba.stackexchange.com/questions/207475/…
lukaszwinski

6

क्या मैं यह कहने में सही हूं कि आंकड़े केवल निष्पादन योजना बनाते समय उपयोग किए जाते हैं

नहीं, आउट-ऑफ-डेट आँकड़े प्रभावित बयान के एक इष्टतमता-संबंधित पुनर्संयोजन का कारण बन सकते हैं ।

हमारे पास हमारे सबसे बड़े तालिकाओं में एक आरोही तिथि / समय स्तंभ है जिसे हम नियमित रूप से क्वेरी करते हैं

उप-इष्टतम निष्पादन योजनाओं की वजह से बाहरी मान (विशेष रूप से ऊपर) होने के कारण संबंधित आँकड़ों में संग्रहीत मूल्यों की श्रेणी हिस्टोग्राम को आरोही कुंजी समस्या के रूप में जाना जाता है । सांख्यिकी का पुनर्निर्माण एक संभव समाधान है, लेकिन यह काफी संसाधन-गहन हो सकता है। विकल्प में शामिल हैं:

  • ट्रेस झंडे 2389 और 2390 । इसके लिए जरूरी है कि समस्याग्रस्त कॉलम में प्रमुख कुंजी के रूप में एक इंडेक्स मौजूद हो। यह विभाजित तालिकाओं के साथ काम नहीं करता है, और केवल SQL सर्वर 2014 में प्रभावी है यदि मूल कार्डिनैलिटी अनुमानक का उपयोग किया जाता है। यदि डेटा ऑब्जेक्ट ब्रांडेड स्टेशनरी है तो ट्रेस फ्लैग 4139 की भी आवश्यकता हो सकती है।

  • SQL सर्वर 2014 में नवीनीकरण करें। नए कार्डिनैलिटी अनुमानक में औसत घनत्व जानकारी का उपयोग करके हिस्टोग्राम से परे अनुमान लगाने के लिए तर्क शामिल हैं। यह कुछ महत्वपूर्ण परिस्थितियों में 2389/2390 ट्रेस झंडे की तुलना में कम सटीक हो सकता है।

  • ट्रेस ध्वज 2371 के साथ बड़ी तालिकाओं के लिए अधिक लगातार स्वचालित आँकड़े अपडेट सक्षम करें । इस ट्रेस ध्वज के साथ, 20% + 500 परिवर्तनों के बाद अद्यतन करने के बजाय, केवल SQRT(1000 * Table rows)संशोधनों की आवश्यकता है। यह पहले बताए गए समाधान के रूप में पूरा नहीं है, क्योंकि अद्यतन अभी भी अक्सर पर्याप्त ट्रिगर नहीं किया जा सकता है।

अगर आपकी समस्या का स्रोत परे-हिस्टोग्राम के मूल्यों के आधार पर बहुत अधिक योजना संकलन नहीं है, लेकिन पैरामीटर सूँघने के परिणामस्वरूप कभी-कभी इस तरह की बुरी योजना को प्रभावित करने के प्रभावों के बारे में, आप भी विचार कर सकते हैं:

  • ट्रेस फ़्लैग 4136 का उपयोग कर पैरामीटर सूँघना अक्षम करना
  • OPTIMIZE FOR (@parameter = value)एक ज्ञात प्रतिनिधि मूल्य के लिए एक योजना को संकलित करने के लिए उपयोग करना
  • OPTIMIZE FOR (@parameter UNKNOWN)औसत वितरण का उपयोग करके अनुकूलन करने के लिए उपयोग करना
  • उपयोग करना OPTIMIZE FOR UNKNOWN(4136 के समान, लेकिन प्रति-क्वेरी)
  • का उपयोग करते हुए OPTION (RECOMPILE)हर बार संकलित करने के लिए, विशेष रूप से मूल्य सूँघने। यदि रनटाइम मूल्यों का विशाल बहुमत हिस्टोग्राम के भीतर है, तो यह प्रभावी हो सकता है।

पैरामीटर सूँघने, एम्बेड करने और recompile विकल्पों के बारे में अधिक जानकारी के लिए, SQLperformance.com पर मेरा लेख देखें ।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.