SQL सर्वर अस्थायी वस्तु कैशिंग

अस्थायी ऑब्जेक्ट कैशिंग

tempdb . पर प्रभाव को कम करने के लिए संरचना, SQL सर्वर पुन:उपयोग के लिए अस्थायी वस्तुओं को कैश कर सकता है। एक अस्थायी ऑब्जेक्ट को छोड़ने के बजाय, SQL सर्वर सिस्टम मेटाडेटा को बनाए रखता है, और तालिका डेटा को छोटा करता है। यदि तालिका 8MB या उससे छोटी है, तो काट-छाँट समकालिक रूप से की जाती है; अन्यथा आस्थगित ड्रॉप का उपयोग किया जाता है। किसी भी मामले में, छंटनी भंडारण आवश्यकता को एक (खाली) डेटा पृष्ठ, और आवंटन जानकारी को एक IAM पृष्ठ पर कम कर देता है।

कैशिंग अगली बार अस्थायी वस्तु बनाने की लगभग सभी आवंटन और मेटाडेटा लागतों से बचा जाता है। tempdb . में कम परिवर्तन करने के दुष्प्रभाव के रूप में एक पूर्ण ड्रॉप और रीक्रिएट चक्र की तुलना में डेटाबेस, अस्थायी ऑब्जेक्ट कैशिंग भी आवश्यक लेनदेन लॉगिंग की मात्रा को कम करता है।

कैशिंग हासिल करना

टेबल वैरिएबल और स्थानीय अस्थायी टेबल दोनों ही कैश किए जाने में सक्षम हैं। कैशिंग के लिए अर्हता प्राप्त करने के लिए, एक स्थानीय अस्थायी तालिका या तालिका चर चाहिए एक मॉड्यूल में बनाया जा सकता है:

• संग्रहीत कार्यविधि (एक अस्थायी संग्रहीत कार्यविधि सहित)
• ट्रिगर
• बहु-कथन तालिका-मूल्यवान फ़ंक्शन
• स्केलर यूज़र-डिफ़ाइंड फ़ंक्शन

एक बहु-कथन तालिका-मूल्यवान फ़ंक्शन का वापसी मान एक तालिका चर है, जिसे स्वयं कैश किया जा सकता है। तालिका-मूल्यवान पैरामीटर (जो तालिका चर भी हैं) को तब कैश किया जा सकता है जब पैरामीटर क्लाइंट एप्लिकेशन से भेजा जाता है, उदाहरण के लिए SqlDbType.Structured का उपयोग करके .NET कोड में। . जब स्टेटमेंट को पैरामीटर किया जाता है, तो टेबल-वैल्यू पैरामीटर स्ट्रक्चर को केवल SQL Server 2012 या उसके बाद के संस्करण में कैश किया जा सकता है।

निम्नलिखित नहीं कैश्ड होना:

• वैश्विक अस्थायी तालिकाएं
• तदर्थ SQL का उपयोग करके बनाई गई वस्तुएं
• गतिशील SQL का उपयोग करके बनाई गई वस्तुएं (उदा. EXECUTE . का उपयोग करके) या sys.sp_executesql )

कैश किए जाने के लिए, एक अस्थायी वस्तु अतिरिक्त रूप से नहीं होनी चाहिए :

• नाम बाधाओं (स्पष्ट नामों के बिना बाधाएं पूरी तरह से ठीक हैं)
• ऑब्जेक्ट बनाने के बाद "DDL" करें
• WITH RECOMPILE . का उपयोग करके परिभाषित मॉड्यूल में रहें विकल्प
• WITH RECOMPILE . का उपयोग करके कॉल किया जा सकता है EXECUTE . का विकल्प बयान

कुछ सामान्य भ्रांतियों को स्पष्ट रूप से दूर करने के लिए:

• TRUNCATE TABLE नहीं कैशिंग को रोकें
• DROP TABLE नहीं कैशिंग को रोकें
• UPDATE STATISTICS नहीं कैशिंग को रोकें
• आंकड़ों का स्वचालित निर्माण नहीं कैशिंग को रोकें
• मैनुअल CREATE STATISTICS होगा संचयन रोकें

एक मॉड्यूल में सभी अस्थायी वस्तुओं को अलग से उपयुक्तता को कैशिंग करने के लिए मूल्यांकन किया जाता है। एक मॉड्यूल जिसमें एक या अधिक अस्थायी ऑब्जेक्ट होते हैं जिन्हें कैश नहीं किया जा सकता है, वे अभी भी उसी मॉड्यूल के भीतर अन्य अस्थायी ऑब्जेक्ट्स के कैशिंग के लिए योग्य हो सकते हैं।

एक सामान्य पैटर्न जो अस्थायी तालिकाओं के लिए कैशिंग को अक्षम करता है, प्रारंभिक तालिका निर्माण विवरण के बाद अनुक्रमणिका का निर्माण है। ज्यादातर मामलों में इसे प्राथमिक कुंजी और अद्वितीय बाधाओं का उपयोग करके काम किया जा सकता है। SQL सर्वर 2014 और बाद में, हमारे पास INDEX का उपयोग करके सीधे तालिका निर्माण विवरण में गैर-अद्वितीय गैर-संकुल अनुक्रमणिका जोड़ने का विकल्प है खंड।

निगरानी और रखरखाव

हम देख सकते हैं कि कैश काउंटर DMV का उपयोग करके वर्तमान में कितने अस्थायी ऑब्जेक्ट कैश किए गए हैं:

 DOMCC चुनें। 

 एक उदाहरण परिणाम है:
 

 
 

 कैशे प्रविष्टि को उपयोग में . माना जाता है जब तक युक्त मॉड्यूल का कोई भाग निष्पादित हो रहा है। एक ही मॉड्यूल के समवर्ती निष्पादन के परिणामस्वरूप कई कैश्ड अस्थायी ऑब्जेक्ट बनाए जाएंगे। एक ही मॉड्यूल के लिए एकाधिक निष्पादन योजनाएं (शायद भिन्न सत्र SET . के कारण) विकल्प) एक ही मॉड्यूल के लिए कई कैश प्रविष्टियों को भी जन्म देगा।
 

 स्मृति के लिए प्रतिस्पर्धी जरूरतों के जवाब में कैश प्रविष्टियां समय के साथ पुरानी हो सकती हैं। कैश्ड अस्थायी वस्तुओं को भी हटाया जा सकता है (अतुल्यकालिक रूप से, एक पृष्ठभूमि सिस्टम थ्रेड द्वारा) जब पैरेंट मॉड्यूल की निष्पादन योजना को योजना कैश से हटा दिया जाता है।
 

 उत्पादन प्रणालियों के लिए समर्थित नहीं है (या किसी भी तरह से अनुशंसित), अस्थायी ऑब्जेक्ट कैश स्टोर को परीक्षण उद्देश्यों के लिए मैन्युअल रूप से पूरी तरह से साफ़ किया जा सकता है:
 
DBCC FREESYSTEMCACHE('Temporary Tables &Table Variables') MARK_IN_USE_FOR_REMOVAL के साथ; WAITFOR DELAY '00:00:05';
 

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

 तालिका चर tempdb  . में एक 'वास्तविक' उपयोगकर्ता तालिका द्वारा कार्यान्वित किए जाते हैं डेटाबेस (हालांकि एक टेबल नहीं है जिसे हम सीधे क्वेरी कर सकते हैं)। संबंधित तालिका का नाम "#" है जिसके बाद ऑब्जेक्ट आईडी का आठ अंकों का हेक्साडेसिमल प्रतिनिधित्व है। निम्न क्वेरी संबंध दिखाती है:
 
-- एक टेबल वेरिएबलDECLARE @Z AS टेबल (z पूर्णांक NULL); - संगत sys.tables प्रविष्टि चुनें टी। [नाम], ObjIDFromName =CONVERT (पूर्णांक, कन्वर्ट (बाइनरी (4)), राइट (टी। [नाम], 8), 2)), टी। [ऑब्जेक्ट_आईडी], टी। [ type_desc], T.create_date, T.modify_dateFROM tempdb.sys.tables जहाँ T.[नाम] LIKE N'#[0-9A-F][0-9A-F][0-9A-F][0 -9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]';
 

 एक नमूना परिणाम नीचे दिखाया गया है। ध्यान दें कि ऑब्जेक्ट नाम से परिकलित ऑब्जेक्ट आईडी वास्तविक ऑब्जेक्ट आईडी से कैसे मेल खाता है:
 

 
 

 उस स्क्रिप्ट को एड-हॉक SQL के रूप में चलाने से एक अलग tempdb उत्पन्न होगा प्रत्येक निष्पादन पर ऑब्जेक्ट आईडी (और ऑब्जेक्ट का नाम) (कोई कैशिंग नहीं)। एक ही स्क्रिप्ट को एक मॉड्यूल (जैसे एक संग्रहीत कार्यविधि) के अंदर रखने से तालिका चर को कैश किया जा सकेगा (जब तक कि डायनेमिक SQL का उपयोग नहीं किया जाता है), ताकि प्रत्येक निष्पादन पर ऑब्जेक्ट आईडी और नाम समान हो।
 

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

 जब एक अस्थायी तालिका का उपयोग तालिका चर के बजाय किया जाता है, तो मूल तंत्र अनिवार्य रूप से वही होता है, केवल कुछ अतिरिक्त नामकरण चरणों के साथ:जब एक अस्थायी तालिका कैश नहीं की जाती है , यह tempdb . में दिखाई देता है परिचित उपयोगकर्ता द्वारा आपूर्ति किए गए नाम के साथ, अंडरस्कोर का एक गुच्छा और अंतिम प्रत्यय के रूप में ऑब्जेक्ट आईडी का हेक्साडेसिमल प्रतिनिधित्व। स्थानीय अस्थायी तालिका तब तक बनी रहती है जब तक कि इसे स्पष्ट रूप से हटा नहीं दिया जाता है, या जब तक इसे बनाया गया दायरा समाप्त नहीं हो जाता। एड-हॉक SQL के लिए, इसका मतलब है कि जब सत्र सर्वर से डिस्कनेक्ट हो जाता है।
 

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

 मॉड्यूल के प्रारंभ और अंत में अतिरिक्त नामकरण संचालन में सिस्टम की एक छोटी संख्या शामिल होती है मेटाडेटा परिवर्तन . इसलिए कैश्ड अस्थायी तालिकाएँ अभी भी पुन:उपयोग की बहुत अधिक दरों के तहत कम से कम कुछ मेटाडेटा विवाद का अनुभव कर सकती हैं। फिर भी, कैश्ड अस्थायी तालिका का मेटाडेटा प्रभाव गैर-कैश्ड केस (हर बार तालिका बनाना और छोड़ना) की तुलना में बहुत कम है।
 

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

 जैसा कि पहले उल्लेख किया गया है, आंकड़े स्वचालित रूप से  . हो सकते हैं अस्थायी ऑब्जेक्ट कैशिंग के लाभों को खोए बिना अस्थायी तालिकाओं पर बनाया गया (एक अनुस्मारक के रूप में, मैन्युअल रूप से आंकड़े बनाना होगा  कैशिंग अक्षम करें)।
 

 एक महत्वपूर्ण चेतावनी यह है कि आंकड़े कैश्ड अस्थायी तालिका से संबद्ध रीसेट नहीं हैं  जब ऑब्जेक्ट को मॉड्यूल के अंत में कैश किया जाता है, या जब कैश्ड ऑब्जेक्ट को मॉड्यूल की शुरुआत में कैश से पुनर्प्राप्त किया जाता है। एक परिणाम के रूप में, एक कैश्ड अस्थायी तालिका पर आंकड़े एक असंबंधित पूर्व निष्पादन से छोड़े जा सकते हैं। दूसरे शब्दों में, आँकड़ों का बिल्कुल कोई संबंध नहीं हो सकता है  अस्थायी तालिका की वर्तमान सामग्री के लिए।
 

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

 अस्थायी ऑब्जेक्ट कैशिंग के लाभों को बरकरार रखते हुए सबसे व्यापक समाधान है:
 
 
मैन्युअल रूप से UPDATE STATISTICS मॉड्यूल के भीतर अस्थायी तालिका पर; और 
एक OPTION (RECOMPILE) अस्थायी तालिका का संदर्भ देने वाले बयानों के लिए संकेत
 
 

 स्वाभाविक रूप से ऐसा करने में एक लागत शामिल है, लेकिन यह अक्सर स्वीकार्य होता है। दरअसल, पहली जगह में स्थानीय अस्थायी तालिका का उपयोग करने का चयन करके, मॉड्यूल लेखक स्पष्ट रूप से कह रहा है कि योजना चयन अस्थायी तालिका की सामग्री के प्रति संवेदनशील होने की संभावना है, इसलिए पुनर्मूल्यांकन समझ में आ सकता है। आंकड़ों को मैन्युअल रूप से अपडेट करना सुनिश्चित करता है कि पुन:संकलन के दौरान उपयोग किए गए आंकड़े तालिका की वर्तमान सामग्री को दर्शाते हैं (जैसा कि हम निश्चित रूप से उम्मीद करेंगे)।
 

 यह कैसे काम करता है, इस बारे में अधिक जानकारी के लिए कृपया इस विषय पर मेरा पिछला लेख देखें।
 
सारांश और अनुशंसाएं
 

 मॉड्यूल के भीतर अस्थायी ऑब्जेक्ट कैशिंग tempdb में साझा आवंटन और मेटाडेटा संरचनाओं पर दबाव को बहुत कम कर सकता है। डेटाबेस। तालिका चर का उपयोग करते समय सबसे बड़ी कमी होगी क्योंकि इन अस्थायी वस्तुओं को कैशिंग और पुन:उपयोग करने में मेटाडेटा को संशोधित करना शामिल नहीं है (कोई नाम बदलने का संचालन नहीं)। आवंटन संरचनाओं पर विवाद अभी भी देखा जा सकता है यदि एकल कैश्ड डेटा पृष्ठ सभी तालिका चर के डेटा को रनटाइम पर रखने के लिए अपर्याप्त है।
 

 तालिका चर के लिए कार्डिनैलिटी जानकारी की कमी के कारण योजना गुणवत्ता पर प्रभाव OPTION(RECOMPILE) का उपयोग करके कम किया जा सकता है या ट्रेस फ्लैग 2453 (एसक्यूएल सर्वर 2012 के बाद से उपलब्ध)। ध्यान दें कि ये न्यूनीकरण केवल अनुकूलक को तालिका में पंक्तियों की कुल संख्या के बारे में जानकारी देते हैं।
 

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

 अगर डेटा वितरण . के बारे में जानकारी (घनत्व और हिस्टोग्राम) योजना चयन के लिए महत्वपूर्ण है, स्थानीय अस्थायी तालिका का उपयोग करें बजाय। अस्थायी टेबल कैशिंग के लिए शर्तों को पूरा करना सुनिश्चित करें, जिसका अर्थ अक्सर प्रारंभिक तालिका निर्माण विवरण के बाद इंडेक्स या आंकड़े नहीं बनाना है। इसे SQL सर्वर 2014 से INDEX . की शुरुआत के कारण और अधिक सुविधाजनक बनाया गया है CREATE TABLE का खंड बयान। 
 

 एक स्पष्ट UPDATE STATISTICS अस्थायी तालिका में डेटा लोड होने के बाद, और OPTION (RECOMPILE) एक मॉड्यूल के भीतर कैश्ड अस्थायी तालिकाओं के सभी अपेक्षित लाभों का उत्पादन करने के लिए तालिका को संदर्भित करने वाले बयानों पर संकेत की आवश्यकता हो सकती है।
 

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

 इष्टतम अस्थायी ऑब्जेक्ट कैशिंग tempdb . को कम करने के लिए पर्याप्त नहीं हो सकता है सभी मामलों में स्वीकार्य स्तरों पर विवाद, यहां तक ​​​​कि जहां अस्थायी वस्तुओं का उपयोग केवल पूरी तरह से उचित होने पर ही किया जाता है। इन-मेमोरी टेबल वेरिएबल्स या गैर-टिकाऊ इन-मेमोरी टेबल का उपयोग ऐसे मामलों में लक्षित समाधान प्रदान कर सकता है, हालांकि हमेशा ट्रेड ऑफ किए जाने होते हैं, और कोई भी समाधान वर्तमान में सभी मामलों में सर्वश्रेष्ठ विकल्प का प्रतिनिधित्व नहीं करता है।