जबकि मैं प्रस्तुतकर्ता का सम्मान करता हूं, मैं प्रदान किए गए उत्तर से असहमत हूं और "धार्मिक कारणों" के लिए नहीं। दूसरे शब्दों में, मेरा मानना है कि Microsoft ने ऐसी कोई सुविधा नहीं दी है जो संग्रहीत प्रक्रियाओं का उपयोग करने के लिए मार्गदर्शन की आवश्यकता को कम करती है।
डेवलपर को प्रदान किया गया कोई भी निर्देश जो कच्चे पाठ के उपयोग का पक्षधर है, एसक्यूएल क्वेश्चन कई कैविटीज़ से भरे होने चाहिए, जैसे कि मुझे लगता है कि सबसे विवेकपूर्ण सलाह है कि आप स्टोर की गई प्रक्रियाओं के उपयोग को प्रोत्साहित करें और अपनी डेवलपर टीमों को अभ्यास में संलग्न होने से हतोत्साहित करें। SQL कथनों को कोड में एम्बेड करना, या SQL SPROCs (संग्रहीत कार्यविधियों) के बाहर कच्चे, सादे-पुराने पाठ-आधारित SQL अनुरोध सबमिट करना।
मुझे लगता है कि एसपीआरओसी का उपयोग करने के सवाल का सरल जवाब है, जैसा कि प्रस्तुतकर्ता ने कहा: एसपीआरआरसी पार्स, अनुकूलित और संकलित हैं। जैसे, उनकी क्वेरी / निष्पादन योजनाएँ कैश की जाती हैं क्योंकि आपने किसी क्वेरी के स्थिर प्रतिनिधित्व को सहेज लिया है और आप, सामान्य रूप से, इसे केवल मापदंडों द्वारा अलग-अलग करेंगे, जो कॉपी किए गए / चिपकाए गए एसक्यूएल स्टेटमेंट के मामले में सही नहीं है, जो मॉर्फ्ड है पृष्ठ-दर-पृष्ठ और घटक / स्तरीय, और अक्सर इस हद तक परिवर्तनशील होते हैं कि विभिन्न तालिकाओं, यहां तक कि डेटाबेस के नामों को कॉल-टू-कॉल से निर्दिष्ट किया जा सकता है। इस प्रकार के गतिशील तदर्थ के लिए अनुमति देनाएसक्यूएल सबमिशन, डीबी इंजन की संभावना को बहुत ही सख्त नियमों के अनुसार, अपने तदर्थ वक्तव्यों के लिए क्वेरी प्लान को फिर से उपयोग करने की संभावना को कम करता है। यहाँ, मैं डायनामिक एड हॉक क्वेश्चंस (उठाए गए प्रश्न की भावना में) बनाम कुशल सिस्टम SPROC sp_executesql के उपयोग के बीच अंतर कर रहा हूं।
अधिक विशेष रूप से, निम्नलिखित घटक हैं:
- सीरियल और समानांतर क्वेरी योजना जो उपयोगकर्ता के संदर्भ को नहीं रखती है और DB इंजन द्वारा पुन: उपयोग करने की अनुमति देती है।
- निष्पादन संदर्भ जो अलग-अलग डेटा मापदंडों के साथ एक नए उपयोगकर्ता द्वारा क्वेरी योजना के पुन: उपयोग के लिए अनुमति देता है।
- प्रक्रिया कैश जो डीबी इंजन प्रश्न पूछती है ताकि हम जो क्षमता चाहते हैं उसे बना सकें।
जब एक SQL कथन एक वेब पेज से जारी किया जाता है, जिसे "तदर्थ कथन" कहा जाता है, तो इंजन अनुरोध को संभालने के लिए मौजूदा निष्पादन योजना की तलाश करता है। क्योंकि यह एक उपयोगकर्ता से प्रस्तुत किया गया पाठ है, इसे मान्य, पार्स, संकलित और निष्पादित किया जाएगा, यदि यह मान्य है। इस समय इसे शून्य की क्वेरी लागत प्राप्त होगी। क्वेरी लागत का उपयोग तब किया जाता है जब डीबी इंजन अपने एल्गोरिथ्म का उपयोग यह निर्धारित करने के लिए करता है कि कौन सी निष्पादन योजना कैश से बेदखल करने की योजना है।
डिफ़ॉल्ट रूप से, तदर्थ प्रश्नों को शून्य का मूल क्वेरी मूल्य मान प्राप्त होता है। किसी अन्य उपयोगकर्ता प्रक्रिया (या एक ही) द्वारा सटीक उसी तदर्थ क्वेरी पाठ के बाद के निष्पादन पर, वर्तमान क्वेरी लागत मूल संकलन लागत पर रीसेट हो जाती है। चूंकि हमारी तदर्थ क्वेरी का संकलन लागत शून्य है, इसलिए पुन: उपयोग की संभावना के लिए यह अच्छी तरह से नहीं है। जाहिर है, शून्य न्यूनतम-मूल्यवान पूर्णांक है, लेकिन इसे क्यों निकाला जाएगा?
जब मेमोरी दबाव उत्पन्न होता है, और वे यदि आपके पास अक्सर उपयोग की जाने वाली साइट होती है, तो डीबी इंजन एक क्लीनअप एल्गोरिदम का उपयोग करता है यह निर्धारित करने के लिए कि यह कैसे मेमोरी को पुनः प्राप्त कर सकता है जो कि प्रोसीजर कैश का उपयोग कर रहा है। यह वर्तमान क्वेरी लागत का उपयोग करता है यह तय करने के लिए कि कौन सी योजना को बेदखल करना है। जैसा कि आप अनुमान लगा सकते हैं, शून्य की लागत वाली योजनाएं पहले कैश से बेदखल हैं क्योंकि शून्य का अनिवार्य रूप से "इस योजना का कोई वर्तमान उपयोगकर्ता, या संदर्भ नहीं" है।
- नोट: तदर्थ निष्पादन योजना - योजना की मूल संकलन लागत द्वारा प्रत्येक उपयोगकर्ता प्रक्रिया द्वारा वर्तमान लागत में वृद्धि की जाती है। हालाँकि, किसी भी योजना की अधिकतम लागत उसकी मूल संकलित लागत से अधिक नहीं हो सकती ... तदर्थ प्रश्नों के मामले में ... शून्य। तो, उस मूल्य से इसे "बढ़ाया" जाएगा ... शून्य - जिसका अनिवार्य रूप से मतलब है कि यह सबसे कम लागत की योजना बना रहेगा।
इसलिए, यह पूरी संभावना है कि इस तरह की योजना को पहली बार तब निकाला जाएगा जब मेमोरी दबाव उत्पन्न होता है।
इसलिए, यदि आपके पास बहुत सारी मेमोरी के साथ सर्वर बिल्ड-आउट "आपकी आवश्यकताओं से परे" है, तो आप इस समस्या को अक्सर एक व्यस्त सर्वर के रूप में अनुभव नहीं कर सकते हैं जिसमें केवल "पर्याप्त" मेमोरी है जो इसके कार्यभार को संभालने के लिए है। (क्षमा करें, सर्वर मेमोरी क्षमता और उपयोग कुछ व्यक्तिपरक / सापेक्ष हैं, हालांकि एल्गोरिथ्म नहीं है।)
अब, यदि मैं तथ्यात्मक रूप से एक या अधिक बिंदुओं के बारे में गलत हूं, तो मैं निश्चित रूप से सही होने के लिए खुला हूं।
अंत में, लेखक ने लिखा:
"अब हमारे पास स्टेटमेंट-लेवल ऑप्टिमाइज़ेशन है, इसलिए किसी एप्लिकेशन से आने वाली उचित पैरामीटर वाली क्वेरी उसी निष्पादन योजना का लाभ उठा सकती है, जो उस संग्रहित प्रक्रिया में एम्बेडेड है।"
मेरा मानना है कि लेखक "तदर्थ वर्कलोड के लिए अनुकूलन" विकल्प का उल्लेख कर रहा है।
यदि ऐसा है, तो यह विकल्प दो-चरणीय प्रक्रिया के लिए अनुमति देता है जो प्रक्रिया क्वेरी को पूर्ण क्वेरी योजना भेजने से तुरंत बचता है। यह केवल वहां एक छोटा क्वेरी स्टब भेजता है। यदि एक सटीक क्वेरी कॉल सर्वर पर वापस भेज दी जाती है, जबकि क्वेरी स्टब अभी भी प्रक्रिया कैश में है, तो उस समय पूर्ण क्वेरी निष्पादन योजना कार्यविधि कैश में सहेजी जाती है। यह मेमोरी पर बचाता है, जो मेमोरी प्रेशर की घटनाओं के दौरान बेदखल एल्गोरिथ्म को आपके स्टब से बेदखल एक बड़ी क्वेरी योजना की तुलना में कम बार बेदखल करने की अनुमति दे सकता है । फिर, यह आपके सर्वर मेमोरी और उपयोग पर निर्भर करता है।
हालाँकि, आपको यह विकल्प चालू करना होगा, क्योंकि यह डिफ़ॉल्ट रूप से बंद है।
अंत में, मैं इस बात पर जोर देना चाहता हूं कि, अक्सर, बहुत ही कारण डेवलपर्स SQL को पृष्ठों, घटकों और अन्य स्थानों में एम्बेड करेंगे, ऐसा इसलिए है क्योंकि वे लचीला होना चाहते हैं और गतिशील SQL क्वेरी को डेटाबेस इंजन में जमा करते हैं। इसलिए, एक वास्तविक दुनिया उपयोग के मामले में, बहुत ही पाठ, कॉल-ओवर-कॉल सबमिट करना, होने की संभावना नहीं है क्योंकि हम SQL सर्वर पर तदर्थ प्रश्नों को सबमिट करते समय कैशिंग / क्षमताएँ प्राप्त करते हैं।
अतिरिक्त जानकारी के लिए, कृपया देखें:
https://technet.microsoft.com/en-us/library/ms181055(v=sql.105).aspx
http://sqlmag.com/database-performance-tuning/don-t-dyear-dynamic-sql
सबसे अच्छा,
हेनरी