हमारे पैरामीटर सूँघने वेबिनार श्रृंखला से प्रश्नोत्तर:

पिछले दो बुधवार, हमने पैरामीटर संवेदनशीलता मुद्दों का इलाज करने वाली दो-भाग वाली वेबिनार श्रृंखला की मेजबानी की है:

• संग्रहीत कार्यविधियां, पैरामीटर, समस्याएं…
  किम्बर्ली एल. ट्रिप और आरोन बर्ट्रेंड
  24 जनवरी
  क्या आप चूक गए? इसे देखने के लिए अभी पंजीकरण करें!

• SentryOne का उपयोग करके पैरामीटर सूँघने से निपटना
  आरोन बर्ट्रेंड, किम्बर्ली एल. ट्रिप, और एंडी मॉलन
  31 जनवरी
  क्या आप चूक गए? इसे अभी देखें!

दोनों वेबिनार के दौरान कुछ प्रश्न आए, और मैंने सोचा कि मैं उन्हें संकलित कर दूंगा और यहां उनका उत्तर दूंगा (कुछ उत्तर वेबिनार के दौरान एंडी से आए थे)।

हमने हाल ही में एक मुद्दे में देखा है, हम देख रहे हैं कि योजनाएं बहुत जल्दी कैश से बाहर हो रही हैं। हम आपके द्वारा वर्णित कुछ भी नहीं कर रहे हैं (DBCC FREEPROCCACHE आदि।); क्या स्मृति दबाव के कारण भी ऐसा हो सकता है?

हां, स्मृति दबाव एक कारक हो सकता है (इस पोस्ट को देखें), और मुझे पता है कि इस संबंध में SQL सर्वर के मेमोरी प्रबंधन के साथ संभावित समस्याओं की कुछ जांच भी हैं।

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

क्या होगा यदि आप OR . का उपयोग करते हैं AND . के बजाय जहां क्लॉज में , क्या समस्या बनी रहेगी?

आमतौर पर यदि आप OR . का उपयोग करते हैं इस प्रकार के पैटर्न में, आपको हर बार सभी पंक्तियाँ मिलेंगी, जब तक कि हर एक पैरामीटर पंक्तियों को फ़िल्टर करने वाले मानों से भर न जाए। यह क्वेरी के शब्दार्थ को "इन सभी चीज़ों को सत्य होना चाहिए" से "इनमें से कोई भी एक चीज़ सत्य हो सकती है" में बदल देता है। फिर भी, पैरामीटर के पहले सेट के लिए संकलित की गई योजना अभी भी कैश की जाएगी और भविष्य के निष्पादन के लिए बनी रहेगी, चाहे आपके खंड AND का उपयोग करें या OR ।

क्या वह 1=1 है एक अच्छा दृष्टिकोण ध्वजांकित करें? केवल प्रदान किए गए मापदंडों को जोड़ना बेहतर नहीं है और इसलिए बदसूरत 1=1 . से बचें ?

1 = 1 SQL सर्वर द्वारा वस्तुतः अनदेखा किया जाता है, लेकिन सभी सशर्त खंडों को AND . के साथ जोड़ने की अनुमति देता है ताकि आपको *पहले* वाले के साथ अलग व्यवहार न करना पड़े। यहाँ विकल्प है:

SET @IncludedWhereClauseYet bit = 0;
SET @sql = N'SELECT cols FROM dbo.Table';
 
IF @param1 IS NOT NULL
BEGIN
  IF @IncludedWhereClauseYet = 0
  BEGIN
    SET @sql += N' WHERE ';
    SET @IncludedWhereClauseYet = 1;
  END
  ELSE
  BEGIN
    SET @sql += N' AND ';
  END
  SET @sql += N' @param1 = @param1';
END
 
IF @param2 IS NOT NULL
BEGIN
  IF @IncludedWhereClauseYet = 0
  ...
END
...

1=1 आपको हमेशा AND . के साथ किसी भी खंड को उपसर्ग करने की अनुमति देकर, आपको सरल बनाने की अनुमति देता है . उपरोक्त कोड बन जाता है:

SET @sql = N'SELECT cols FROM dbo.Table WHERE 1 = 1';
 
IF @param1 IS NOT NULL
BEGIN
  SET @sql += N' AND @param1 = @param1';
END
 
IF @param2 IS NOT NULL
BEGIN
  SET @sql += N' AND @param2 = @param2';
END

आप शायद सभी शर्तों से बचने के लिए एक अलग प्रारंभिक खंड का उपयोग कर सकते हैं, जैसे WHERE PrimaryKey > 0 या WHERE PrimaryKey IS NOT NULL , और उसके बाद प्रत्येक अनुवर्ती खंड AND . से प्रारंभ हो सकता है . लेकिन 1 = 1 , जबकि बदसूरत, हानिरहित है, और IMHO एक *वास्तविक* लेकिन अर्थहीन खंड जोड़ने से कम बदसूरत नहीं है, सिवाय इसके कि एक *वास्तविक* खंड योजना को प्रभावित कर सकता है।

याद रखें कि जब आप टी-एसक्यूएल के साथ टी-एसक्यूएल कोड का निर्माण कर रहे हैं, तो आपके पास सोचने के लिए "बदसूरत" के दो पहलू हैं - कभी-कभी आप ऊपर दिए गए कोड का समस्या निवारण करेंगे, और कभी-कभी आप उस क्वेरी का समस्या निवारण करेंगे जो इससे निकलती है यह। एक के लिए दूसरे की बलि देने में सावधान रहें।

क्या?! मैं पूरी तरह से चूक गया हूं ... WITH RECOMPILE . मैंने सोचा था कि यह योजना को खाली कर देता है, लेकिन यह केवल इस निष्पादन के लिए इसे अकेला छोड़ देता है ... यह जानना बहुत महत्वपूर्ण है!

बस सुनिश्चित करें कि आप कमियों से भी अवगत हैं।
पॉल व्हाइट की यह बेहतरीन पोस्ट देखें।

क्या OPTION OPTIMIZE FOR @parametername UNKNOWN . है अब हाल के SQL संस्करणों में पसंद नहीं किया जाता है?

मुझे नहीं लगता कि यह आधुनिक संस्करणों में किसी भी बेहतर या बदतर है जब इसे पहली बार SQL Server 2008 में पेश किया गया था। जहां तक ​​​​मुझे पता है, यहां तक ​​​​कि अनुकूलक और कार्डिनैलिटी अनुमानक के सभी परिवर्तनों के साथ, वह बिट अभी भी उसी तरह व्यवहार करता है।

क्या सर्वर पर कोई लोड है, अगर मैं SentryOne में प्रक्रिया आँकड़े और क्वेरी आँकड़े कैप्चर करना सक्षम करता हूँ?

प्रक्रिया और क्वेरी आँकड़े संग्रह डिफ़ॉल्ट रूप से चालू होना चाहिए। सभी डेटा संग्रह एक लागत के साथ आता है, लेकिन SQL संतरी इस बारे में काफी सावधान है कि संग्रह द्वारा कितनी लागत खर्च की गई है।

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

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

क्या यह सच नहीं है कि INCLUDE . के रूप में आवश्यक कुछ कॉलम जोड़ना s वास्तव में सूचकांक को और अधिक प्रभावी नहीं बनाते हैं क्योंकि कुंजी लुकअप को समाप्त नहीं किया जाएगा? मैं सोच रहा हूं कि प्रतिशत तब तक नहीं बदलना चाहिए जब तक कि आप वास्तव में कुंजी लुकअप को समाप्त नहीं कर देते।

कड़ाई से, हाँ, यह सच है। SELECT * . का उपयोग करके मूल क्वेरी एक सर्वोपरि खराब उदाहरण थी और एक सूचकांक में निराशाजनक संख्या में कॉलम गायब हैं। मैं जो बात कहने की कोशिश कर रहा था, वह यह है कि इंडेक्स एनालिसिस टैब आपको (ए) क्वेरी को बेहतर बनाने और (बी) इंडेक्स को कवर करने के लिए प्रोत्साहित करता है। स्कोर आपको या तो दोनों को करने के लिए लुभाने के लिए है - यदि आप क्वेरी बदलते हैं तो आपको कम कॉलम चाहिए, इंडेक्स क्वेरी को कवर करने के करीब भी आता है। यदि आप एक नया, अलग, कवरिंग इंडेक्स बनाने जा रहे हैं, तो आपके पास यह भी जानकारी होगी कि इस विशिष्ट क्वेरी को कवर करने के लिए कौन से कॉलम आवश्यक हैं। तकनीकी रूप से, आप सही कह रहे हैं, एक जोड़ने से कॉलम शामिल है, लेकिन फिर भी 4 अन्य लोगों के लिए लुकअप की आवश्यकता है, इससे यह विशिष्ट क्वेरी बेहतर प्रदर्शन करने वाली नहीं है, और यह इंडेक्स को बेहतर बनाने वाला नहीं है, लेकिन यह इंगित करता है कि आप ' फिर से करीब आ रहा है। आशा यह है कि आप केवल एक शामिल कॉलम को जोड़ने पर ही नहीं रुकेंगे और बाकी को अनदेखा कर देंगे। हम नहीं जानते कि आप कब रुकने वाले हैं, इसलिए मुझे नहीं पता कि इसका एक सटीक समाधान है - हम निश्चित रूप से निराश नहीं करना चाहते हैं उपयोगकर्ताओं को अपनी अनुक्रमणिका को उनके प्रश्नों के लिए बेहतर अनुकूल बनाने से रोकता है।

हम केवल एक अंतिम नाम पैरामीटर का उपयोग करते हुए पहले नाम पैरामीटर और अंतिम नाम पैरामीटर का उपयोग करके एक कथन के तहत प्रश्नों को क्यों देख रहे हैं?

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

इतना सब कहने के बाद, जब हम शीर्ष SQL स्क्रीन के लिए वर्तमान में उड़ान के दौरान परिवर्तनों को पूरा करते हैं, तो हम इस समूह व्यवहार को ठीक करने की कोशिश करेंगे।

क्या योजना गाइड का उपयोग करने के बारे में कोई दस्तावेज है? मुझे वर्तमान में यह नहीं पता कि यह कैसे करना है।

यह कुछ और है जिसके बारे में मैं ब्लॉग करना चाहता हूं, लेकिन इस बीच Microsoft के पास कुछ विषय हैं (और साइडबार में सभी संबंधित लिंक देखें)।

क्या मुझे क्वेरी इतिहास चार्ट प्राप्त करने के लिए कुछ सक्षम करने की आवश्यकता है?

नहीं, इसे SentryOne क्लाइंट एप्लिकेशन के सभी आधुनिक संस्करणों पर सक्षम किया जाना चाहिए। यदि आप इसे नहीं देख रहे हैं, तो Tools > Reset Layout आज़माएं; अगर वह काम नहीं करता है, तो [email protected] पर संपर्क करें।

क्या ऐसे मामले हैं जब एक योजना प्रतिगमन एक बुरा विचार पाया जाता है जब क्वेरी स्टोर का उपयोग करके अंतिम ज्ञात अच्छी योजना को मजबूर किया जाता है? क्या यह आपके द्वारा दिखाए गए कथन को बदलकर उन मुद्दों को छुपाएगा जिन्हें बेहतर तरीके से संबोधित किया जाता है?

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

SentryOne हमेशा डेटा या पैरामीटर को कैप्चर नहीं कर रहा है, इसलिए मेरे पास पर्याप्त जानकारी नहीं है। मैं कैसे सुनिश्चित करूं कि SentryOne हर समय पैरामीटर और निष्पादन योजनाओं को कैप्चर करे?

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

क्या मैं जानकारी के लिए क्वेरी कर सकता हूं ताकि मैं रिपोर्ट को स्वचालित और जेनरेट कर सकूं?

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

हम कैसे तय करते हैं कि OPTION (RECOMPILE) use का उपयोग कब करना है , जैसा कि हर दिन हमें अलग-अलग मापदंडों के लिए अलग-अलग प्लान मिलते हैं?

मैं कहूंगा कि उन प्रश्नों से शुरू करें जो पैरामीटर संवेदनशीलता के साथ सबसे अधिक उतार-चढ़ाव करते हैं। यदि मेरे पास कोई प्रश्न है जिसमें कभी-कभी 2 सेकंड लगते हैं लेकिन कभी-कभी 30 लगते हैं, और दूसरा जो 4 सेकंड से 6 सेकंड तक होता है, तो मैं पहले वाले पर ध्यान केंद्रित करने जा रहा हूं।

कौन सा उपयोग करना बेहतर है, OPTION (RECOMPILE) या QUERYTRACEON , पैरामीटर सूँघने के मामले में।

मुझे पसंद है OPTION (RECOMPILE) दो कारणों से। एक, यह स्व-दस्तावेजीकरण है; कोड को पढ़ने वाले किसी को भी आश्चर्य नहीं होगा कि यह क्या कर रहा है, लेकिन कोड पढ़ने वाले सभी लोगों ने 4136 जैसे TF नंबरों को याद नहीं किया होगा। दूसरा, इसके लिए उन्नत अनुमतियों की आवश्यकता नहीं है - QUERYTRACEON का उपयोग करके देखें। चपरासी के रूप में।

क्या सामान्य से अधिक समय लेने वाली प्रक्रियाओं पर सतर्क करना या रिपोर्ट करना संभव है? उच्च गणना प्रक्रियाओं में सबसे अधिक रुचि।

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

Microsoft स्वचालित योजना सुधार सहित Azure SQL डेटाबेस के लिए स्वचालित ट्यूनिंग को डिफ़ॉल्ट बना रहा है। क्या यह आपको एक अच्छा विचार लगता है?

जब तक मैं (या कुछ ग्राहक) इसके साथ खिलवाड़ नहीं कर लेते, मैं निर्णय सुरक्षित रखूंगा। नश्वर लोगों के लिए यह तय करना कि धुन कैसे बनाई जाए, काफी चुनौतीपूर्ण है; नश्वर लेखन सॉफ़्टवेयर आपके लिए ट्यून करने के लिए कम से कम चुनौतीपूर्ण लगता है, यदि ऐसा नहीं है। जब एंडी ने इस प्रश्न को देखा, तो उसने मुझे बताया कि इसने उसे SQL Server 2000 की याद दिला दी - मार्केटिंग पिच यह थी कि यह इतना आत्म-ट्यूनिंग था कि हमें अब डीबीए की आवश्यकता नहीं होगी। वह दावा अच्छी तरह से वृद्ध नहीं हुआ है।

क्वेरी इतिहास चार्ट पर दो बिंदुओं का चयन करने और तुलना करने में सक्षम होना अच्छा होगा।

मैं सहमत हूं।
हमारे साथ बने रहें।