यह सरल पैरामीटरीकरण . के बारे में श्रृंखला का पहला भाग है और तुच्छ योजनाएँ . ये दो संकलन सुविधाएँ निकट से जुड़ी हुई हैं और इनके समान लक्ष्य हैं। अक्सर साधारण विवरण सबमिट करने वाले कार्यभार के लिए लक्ष्य प्रदर्शन और दक्षता दोनों।

"सरल" और "तुच्छ" नामों के बावजूद, दोनों में सूक्ष्म व्यवहार और कार्यान्वयन विवरण हैं जो उन्हें समझने में मुश्किल काम कर सकते हैं। यह श्रंखला बुनियादी बातों पर ज्यादा देर तक नहीं टिकती है, लेकिन कम जाने-माने पहलुओं पर ध्यान केंद्रित करती है, जो सबसे अनुभवी डेटाबेस पेशेवरों तक भी पहुंच सकते हैं।

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

Simple Parameterization

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

अधिकांश क्लाइंट और ड्राइवर स्पष्ट पैरामीटरकरण का उपयोग करने के लिए विशिष्ट तरीके प्रदान करते हैं। sp_executesql . जैसे विकल्प भी हैं , संग्रहीत कार्यविधियाँ, और कार्य।

मैं पैरामीटर सूँघने या SQL इंजेक्शन के संबंधित मुद्दों में नहीं जा रहा हूँ, क्योंकि महत्वपूर्ण होने पर, वे इस श्रृंखला का फोकस नहीं हैं। फिर भी, आपको अपने दिमाग के सामने दोनों के साथ कोड लिखना चाहिए।

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

शैल योजनाएँ

जब SQL सर्वर 2005 ने जबरन पैरामीटरीकरण की शुरुआत की थी , मौजूदा स्वतः-पैरामीटरीकरण सुविधा का नाम बदलकर सरल पैरामीटरकरण . कर दिया गया . शब्दावली में बदलाव के बावजूद, सरल मानकीकरण स्वतः-पैरामीटरीकरण . के समान कार्य करता है हमेशा किया:SQL सर्वर पैरामीटर मार्करों के साथ तदर्थ कथनों में निरंतर शाब्दिक मानों को बदलने का प्रयास करता है। इसका उद्देश्य कैश्ड योजना के पुन:उपयोग को बढ़ाकर संकलन को कम करना है।

आइए एक उदाहरण देखें, SQL सर्वर 2019 CU 14 पर स्टैक ओवरफ़्लो 2010 डेटाबेस का उपयोग करते हुए। डेटाबेस संगतता 150 पर सेट है, और समानांतरवाद के लिए लागत सीमा 50 पर सेट की गई है ताकि इस समय समानांतरवाद से बचा जा सके:

EXECUTE sys.sp_configure @configname ='उन्नत विकल्प दिखाएं', @configvalue =1;RECONFIGURE;GOEXECUTE sys.sp_configure @configname ='समानांतरता के लिए लागत सीमा', @configvalue =50;RECONFIGURE;

उदाहरण कोड:

-- इस डेटाबेस के लिए योजनाओं का कैश साफ़ करेंALTER DATABASE स्कोप्ड कॉन्फ़िगरेशन स्पष्ट PROCEDURE_CACHE;GOSELECT U.DisplayNameFROM dbo.Users as U जहाँ U.Reputation =2521;GOSELECT U.DisplayNameFROM dbo.Users AS U WHERE U.Reputation =2827;GOSELECT U.DisplayNameFROM dbo.Users as U जहाँ U.Reputation =3144;GOSELECT U.DisplayNameFROM dbo.Users as U जहाँ U.Reputation =3151;GO

उन बयानों में विधेय की विशेषता होती है जो केवल उनके निरंतर शाब्दिक मूल्यों में भिन्न होते हैं। SQL सर्वर सरल पैरामीटरकरण को सफलतापूर्वक लागू करता है , जिसके परिणामस्वरूप एक पैरामीटरयुक्त योजना है। जैसा कि हम प्लान कैश को क्वेरी करके देख सकते हैं, एकल पैरामीटरयुक्त योजना का चार बार उपयोग किया जाता है:

 CP.usecounts, CP.cacheobjtype, CP.objtype, CP.size_in_bytes, ST.[text], QP.query_planFROM sys.dm_exec_cached_plans AS CPOUTER APPLY sys.dm_exec_sql_text (CP.plan_handle_sys.dm_exec_sql_text (CP.plan_handle) AS STOUT (CP.plan_handle) AS STOUTc. CP.plan_handle) QPWHERE ST के रूप में। [पाठ] '%dm_exec_cached_plans%' और ST को पसंद नहीं है। 

 परिणाम एक तदर्थ . दिखाते हैं प्रत्येक मूल विवरण के लिए कैश प्रविष्टि की योजना बनाएं और एक तैयार योजना:
 

 चार एडहॉक प्लान और एक तैयार प्लान 
 

 एक तैयार स्टेटमेंट एडहॉक में पाए जाने वाले शाब्दिक मानों से अनुमानित पैरामीटर के साथ एक संग्रहीत प्रक्रिया के समान है। बयान। सर्वर-साइड पैरामीटरकरण प्रक्रिया के बारे में सोचते समय मैं इसका एक उपयोगी मानसिक मॉडल के रूप में उल्लेख करता हूं।
 

 ध्यान दें कि SQL सर्वर दोनों को कैश करता है मूल पाठ और पैरामीटरयुक्त रूप। जब सरल मानकीकरण सफल होता है, तो मूल पाठ से जुड़ी योजना तदर्थ होती है और इसमें पूर्ण निष्पादन योजना शामिल नहीं है। इसके बजाय, संचित योजना एक खोल . है तैयार . के सूचक के अलावा बहुत कम के साथ पैरामीटरयुक्त योजना।
 

 खोल योजनाओं . का XML प्रतिनिधित्व इस तरह का टेक्स्ट शामिल करें:
 
 

 यही है पूरी योजना। पैरामीटरेटेडप्लानहैंडल तदर्थ . से अंक पूर्ण पैरामीटरयुक्त योजना के लिए खोल। सभी चार शेल योजनाओं के लिए हैंडल मान समान है।
 
प्लान स्टब्स
 

 शेल योजनाएँ पूर्ण संकलित योजना से छोटी होती हैं—उदाहरण में 40KB के बजाय 16KB। यह अभी भी एक महत्वपूर्ण मात्रा में स्मृति को जोड़ सकता है यदि आपके पास सरल पैरामीटरकरण या बहुत से विभिन्न पैरामीटर मानों का उपयोग करके कई कथन हैं। अधिकांश SQL सर्वर इंस्टेंस मेमोरी से इतने भरे नहीं होते हैं कि वे इसे इस तरह बर्बाद कर सकते हैं। SQL सर्वर द्वारा शेल योजनाओं को बहुत ही डिस्पोजेबल माना जाता है, लेकिन उन्हें खोजने और हटाने से संसाधनों की खपत होती है और यह विवाद का विषय बन सकता है।
 

 हम एड हॉक वर्कलोड विकल्प के लिए ऑप्टिमाइज़ को सक्षम करके शेल योजनाओं के लिए कुल मेमोरी खपत को कम कर सकते हैं।
 
EXECUTE sys.sp_configure @configname ='उन्नत विकल्प दिखाएं', @configvalue =1;RECONFIGURE;GOEXECUTE sys.sp_configure @configname ='एड हॉक वर्कलोड के लिए ऑप्टिमाइज़', @configvalue =1;RECONFIGURE;
 

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

 तदर्थ कार्यभार के लिए अनुकूलित करें . के साथ उदाहरण को फिर से चलाना सक्षम योजना कैश पर प्रभाव दिखाता है।
 

 संकलित योजना स्टब्स 
 

 तदर्थ विवरण के लिए कोई योजना संचित नहीं है, केवल एक आधार है। कोई ParameterizedPlanHandle नहीं है तैयार . के लिए सूचक योजना, हालांकि एक पूर्ण पैरामीटरयुक्त योजना है कैश्ड।
 

 परीक्षण बैचों को दूसरी बार चलाने से (प्लान कैश को साफ़ किए बिना) वही परिणाम देता है जब तदर्थ कार्यभार के लिए अनुकूलित सक्षम नहीं था—चार तदर्थ तैयार . की ओर इशारा करते हुए शेल योजनाएं योजना।
 

 जारी रखने से पहले, तदर्थ कार्यभार के लिए अनुकूलित करें . को रीसेट करें शून्य पर सेट करना:
 
EXECUTE sys.sp_configure @configname ='एड हॉक वर्कलोड के लिए ऑप्टिमाइज़', @configvalue =0;RECONFIGURE;
 
प्लान कैश साइज लिमिट्स
 

 चाहे प्लान शेल या प्लान स्टब्स का उपयोग किया जाए, इन सभी एडहॉक में अभी भी कमियां हैं कैश प्रविष्टियाँ। मैंने पहले ही कुल मेमोरी उपयोग का उल्लेख किया है, लेकिन प्रत्येक प्लान कैश में अधिकतम संख्या . भी होती है प्रविष्टियों का। यहां तक ​​​​कि जहां कुल मेमोरी उपयोग चिंता का विषय नहीं है, वह बहुत अधिक मात्रा में हो सकता है।
 

 सीमाएँ प्रलेखित ट्रेस फ़्लैग 174 (प्रविष्टियों की संख्या) और ट्रेस फ़्लैग 8032 (कुल आकार) के साथ बढ़ाई जा सकती हैं। कार्यभार और अन्य स्मृति मांगों के आधार पर, यह सबसे अच्छा समाधान नहीं हो सकता है। आखिरकार, इसका मतलब है अधिक कम मूल्य वाले Adhoc . को कैशिंग करना योजनाओं, स्मृति को अन्य जरूरतों से दूर ले जाना।
 
केवल कैशिंग तैयार योजनाएं
 

 यदि कार्यभार शायद ही कभी बिल्कुल . के साथ तदर्थ बैच जारी करता है वही स्टेटमेंट टेक्स्ट, कैशिंग प्लान शेल या प्लान स्टब्स संसाधनों की बर्बादी है। यह मेमोरी की खपत करता है और एसक्यूएल प्लान्स . के दौरान विवाद पैदा कर सकता है कैश स्टोर (CACHESTORE_SQLCP ) को कॉन्फ़िगर की गई सीमाओं में फ़िट होने के लिए छोटा करने की आवश्यकता है।
 

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

 ऐसे वर्कलोड के लिए जो साधारण पैरामीटराइजेशन से लाभान्वित होते हैं, लेकिन एडहॉक . के कैशिंग से नहीं प्रविष्टियां, कुछ विकल्प हैं।
 
अनडॉक्यूमेंटेड ट्रेस फ्लैग
 

 पहला विकल्प अनिर्दिष्ट ट्रेस फ्लैग 253 को सक्षम करना है। यह रोकता है एडहॉक . की कैशिंग पूरी तरह से योजना। यह केवल ऐसी योजनाओं की संख्या को सीमित नहीं करता है, या उन्हें कैश में "रहने" से रोकता है, जैसा कि कभी-कभी सुझाव दिया गया है।
 

 ट्रेस फ़्लैग 253 को सत्र स्तर पर सक्षम किया जा सकता है—इसके प्रभावों को केवल उस कनेक्शन तक सीमित करना—या अधिक व्यापक रूप से वैश्विक या स्टार्ट-अप ध्वज के रूप में। यह एक क्वेरी संकेत के रूप में भी कार्य करता है, लेकिन उनका उपयोग करने से सरल पैरामीटरकरण को रोकता है, जो यहां उल्टा होगा। Microsoft तकनीकी पेपर, योजना कैशिंग और SQL Server 2012 में पुनर्संकलन में सरल पैरामीटरकरण को रोकने वाली चीज़ों की एक आंशिक सूची है।
 

 ट्रेस फ्लैग के साथ 253 सक्रिय बैच संकलित होने से पहले , केवल तैयार स्टेटमेंट कैश्ड हैं:
 
डाटाबेस स्कोप्ड कॉन्फ़िगरेशन स्पष्ट प्रक्रिया_CACHE;जाओ-- एड-हॉक प्लान्स को कैश न करेंDBCC TRACEON (253);GOSELECT U.DisplayNameFROM dbo.Users as U जहां U.Reputation =2521;GOSELECT U.DisplayNameFROM dbo.Users AS U जहां U.Reputation =2827; GOSELECT U.DisplayNameFROM dbo.Users as U जहाँ U.Reputation =3144;GOSELECT U.DisplayNameFROM dbo.Users as U जहाँ U.Reputation =3151;GO-- कैश एड-हॉक प्लान फिर सेDBCC TRACEOFF ( 253);जाओ
 

 प्लान कैश क्वेरी केवल तैयार . की पुष्टि करती है कथन कैश्ड और पुन:उपयोग किया जाता है।
 

 केवल तैयार किया गया स्टेटमेंट कैश किया जाता है 
 
द अनचेचेबल बैच
 

 दूसरा विकल्प एक बयान शामिल करना है जो पूरे बैच को अयोग्य के रूप में चिह्नित करता है . उपयुक्त बयान अक्सर सुरक्षा से संबंधित या किसी तरह से संवेदनशील होते हैं।
 

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

 दो उपयुक्त रूप से संवेदनशील कथन और उदाहरण उपयोग नीचे दिखाए गए हैं (अब एक बैच में परीक्षण विवरण के साथ):
 
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;GO-- इस बैच में सभी स्टेटमेंट्स की कैशिंग रोकें।-- न तो KEY और न ही सर्टिफिकेट मौजूद होने की जरूरत है।-- कोई विशेष अनुमति की आवश्यकता नहीं है।-- GOTO का उपयोग स्टेटमेंट को सुनिश्चित करने के लिए किया जाता है। निष्पादित नहीं किया गया। प्रमाण पत्र केले द्वारा ओपन सिमेट्रिक कुंजी केला डिक्रिप्शन शुरू करें; प्रारंभ करें:/ * GOTOIF 1 =0 के बिना समान प्रभाव प्राप्त करने का दूसरा तरीका पासवर्ड के साथ आवेदन रोल बनाना शुरू करें =''; अंत; */ dbo से U.DisplayName चुनें। उपयोगकर्ता जहां यू जहां यू.प्रतिष्ठा =2521; U.Reputation =2827; U.Reputation =3144; U.DisplayNameFROM dbo.Users से U चुनें जहां U.Reputation =3151;GO
 

 तैयार सरल मानकीकरण . द्वारा बनाई गई योजनाएँ पैरेंट बैच को अप्राप्य के रूप में चिह्नित किए जाने के बावजूद अभी भी कैश्ड और पुन:उपयोग किया जाता है।
 

 केवल तैयार किया गया स्टेटमेंट कैश किया जाता है 
 

 कोई भी समाधान आदर्श नहीं है, लेकिन जब तक Microsoft इस समस्या के लिए एक प्रलेखित और समर्थित समाधान प्रदान नहीं करता, वे सबसे अच्छे विकल्प हैं जिनके बारे में मुझे पता है।
 
भाग 1 का अंत
 

 इस विषय पर कवर करने के लिए और भी बहुत कुछ है। भाग दो में सरल मानकीकरण . के दौरान असाइन किए गए डेटा प्रकारों को शामिल किया जाएगा कार्यरत है।