अच्छा पर्याप्त योजना के बिना क्वेरी मिली


20

मेरे पास SQL ​​Server 2012 डेटाबेस है। मैंने Reason for early termination of statement optimizationकुछ प्रश्नों पर ध्यान दिया और सभी दिए Good Enough Plan Found। अब मेरे प्रश्न हैं:

  1. "कथन अनुकूलन के शीघ्र समाप्ति के कारण" के सभी संभावित प्रकार क्या हैं। मैंने इसके लिए msdn में खोज की लेकिन मूल्यों की पूरी सूची नहीं मिली।
  2. क्या सभी प्रश्नों को सूचीबद्ध करने के लिए एक डीएमवी या विस्तारित घटना है, जिसके लिए गुड एनफ प्लान के अलावा अन्य कारणों से अनुकूलन को समाप्त किया गया था? मैंने निम्नलिखित दो लेखों का उल्लेख किया है जो संभावनाओं की पूरी सूची को सूचीबद्ध नहीं करता है। [इसके अलावा, वे मुझे मेरे डेटाबेस में अलग परिणाम देते हैं]।

यहां छवि विवरण दर्ज करें


जवाबों:


20
  • मेमोरी सीमा पार हो गई

    आशावादी को स्मृति दबाव के कारण बेहतर योजना विकल्पों की तलाश करने से रोकने के लिए मजबूर किया गया था। उसके कारण की जांच और सुधार किया जाना चाहिए, फिर क्वेरी संकलन फिर से प्रयास किया जाना चाहिए। लौटाया गया प्लान बहुत अच्छी तरह से नहीं हो सकता है कि जिस ऑप्टिमाइज़र का चयन किया गया है वह कम मेमोरी स्थिति में मौजूद नहीं था।

  • समय समाप्त

    यह कारण बहुत गलत समझा गया है

    क्वेरी ऑप्टिमाइज़र का उद्देश्य उचित योजना को जल्दी से ढूंढना है । यह सबसे अच्छा संभव योजना खोजने के लिए एक संपूर्ण खोज नहीं करता है। डिजाइन के अनुसार, यह आवश्यकता से अधिक अनुकूलन पर अधिक समय बिताने से बचता है। इनमें से एक विशेषता जो यह सुनिश्चित करने के लिए काम करती है कि यह 'टाइम आउट' है (समय का माप नहीं)।

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

    यदि यह बजट अपने खोज चरणों में से एक से अधिक है, तो चरण समाप्त हो जाता है। यह ऑप्टिमाइज़र के डिज़ाइन और सामान्य ऑपरेशन का हिस्सा है। अधिक ऑप्टिमाइज़र प्रयास की आवश्यकता वाले क्वेरी इसे प्राप्त करते हैं; जो नहीं, नहीं।

    Found टाइम आउट ’को Plan गुड इनफ प्लान प्लान’ के रूप में देखें।

  • अच्छी पर्याप्त योजना मिली

    इसका मतलब बिल्कुल एक खाली कारण के समान है। यह केवल एक ऐतिहासिक विचित्रता है जिसकी लागत 0.909090 से कम है ... (1 / 1.1) को इस तरह से लेबल किया जाता है। कुछ भी जल्दी नहीं रुकता है या अन्यथा विशेष रूप से संभाला जाता है या ऑप्टिमाइज़र कोड के भीतर अलग होता है जब यह कारण दिखाई देता है।

मेमोरी सीमा पार होने के बावजूद, क्वेरी ट्यूनिंग या प्रदर्शन विश्लेषण के लिए 'प्रारंभिक समाप्ति कारणों' में से कोई भी बहुत अधिक (यदि कुछ भी हो) का मतलब नहीं है। मैं आमतौर पर उनकी अनदेखी करता हूं।

सलाह

वास्तविक प्रदर्शन मीट्रिक (व्यतीत समय, सीपीयू / मेमोरी उपयोग, ... जो भी संदर्भ में महत्वपूर्ण है) के आधार पर लक्षित क्वेरी ट्यूनिंग प्रयास। यदि कोई क्वेरी अपने इच्छित उद्देश्य के लिए बहुत धीमी है, तो इसे तेजी से बनाने में समय व्यतीत करें। वास्तविक प्रदर्शन को मापें, आधारभूत और इतिहास के साथ तुलना करें, और महत्वपूर्ण संस्करण में ट्यूनिंग प्रयास को लक्षित करें।

उपयोगी आँकड़ों और अनुक्रमित और अच्छी तरह से लिखित, अनुकूलक-अनुकूल प्रश्नों के साथ एक उचित संबंधपरक स्कीमा में गारंटीकृत-स्वच्छ डेटा संग्रहीत करें।


10

यदि आप http://schemas.microsoft.com/sqlserver/2004/07/showplan/showplanxml.xsd पर जाते हैं (जो कि आप देखेंगे कि यदि आप xml के रूप में निष्पादन योजना खोलते हैं), तो आप देखेंगे सूचीबद्ध तीन कारण, जो हैं:

  • समय समाप्त
  • MemoryLimitExceeded
  • GoodEnoughPlanFound

जिन लेखों का आप उल्लेख करते हैं, वे इन घटनाओं को खोजने के लिए ठीक लगते हैं, क्या आपको कोई विशेष समस्या है? ध्यान रखने वाली बात यह है कि ये DMV सर्वर पर चलने वाले सभी SQL कमांड को कभी भी कैप्चर नहीं करते हैं और सर्वर के रीस्टार्ट होने पर रीसेट हो जाता है। आप एक्सक्लूसिव इवेंट्स और क्वेरी के साथ showplan xml को फँसा सकते हैं, लेकिन यह मेरे लिए ओवरकिल जैसा लगता है।

मैं GoodEnoughPlanFound के बारे में बहुत अधिक चिंता नहीं करूँगा, ऐसा लगता है कि आशावादी अपना काम कर रहा है (जल्दी से एक अच्छी योजना खोजने का) बहुत अच्छा।

HTH

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