एसक्यूएल सर्वर के साथ अपने करियर में किसी बिंदु पर पैरामीटर स्नीफिंग बस कूद और हमला करता है?

Question

आज फिर, मेरे पास एक प्रमुख समस्या है जो SQL सर्वर 2005 में पैरामीटर स्नीफिंग प्रतीत होता है।

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

मैं अपने WHERE खंड के लिए एक मानदंड जोड़ने - इस कोड जेनरेट की गई है, इसलिए यह एक शाब्दिक निरंतर है:

WHERE DATA_DT_ID = 20081231 - कौन निरर्थक है क्योंकि सभी DATA_DT_ID 20,081,231 हैं अभी।

प्रदर्शन पॉट पर जाता है। 7 सेकंड से 1.5 मीटर पंक्तियों की तुलना में 2 घंटे और कुछ भी पूरा करने के लिए नहीं। एसएसएमएस में उत्पन्न एसक्यूएल दाएं चलाना - कोई एसपी नहीं।

मैं अब 12 साल से चलने के लिए SQL सर्वर का उपयोग कर रहा हूं और मुझे पैरामीटर स्नीफिंग के साथ इतनी सारी समस्याएं नहीं मिली हैं क्योंकि मेरे पास अक्टूबर से इस उत्पादन सर्वर पर है (बिल्ड 9.00.3068.00 बनाएं)। और हर मामले में, ऐसा इसलिए नहीं है क्योंकि यह पहली बार एक अलग पैरामीटर के साथ चलाया गया था या तालिका बदल दी गई थी। यह एक नई तालिका है और यह केवल इस पैरामीटर के साथ चलती है या WHERE खंड बिल्कुल नहीं है।

और, नहीं, मेरे पास डीबीए पहुंच नहीं है, और उन्होंने मुझे निष्पादन योजनाओं को देखने के लिए पर्याप्त अधिकार नहीं दिए हैं।

यह उस बिंदु पर है जहां मुझे यकीन नहीं है कि मैं इस प्रणाली को केवल कुछ वर्षों के अनुभव के साथ SQL सर्वर उपयोगकर्ताओं को संभालने में सक्षम होने जा रहा हूं।

अद्यतन यह बताता है कि हालांकि आंकड़े अद्यतित होने का दावा करते हैं, फुलस्कैन के साथ अद्यतन आंकड़े चलाना समस्या को साफ़ करता है।

अंतिम अद्यतन भी, सपा पुनः RECOMPILE और अद्यतन आंकड़ों के साथ उपयोग करने के साथ, यह पता चला क्वेरी एक एक वाम की नहीं बजाय शून्य चेक के साथ शामिल हों उपयोग करने के लिए एक अलग तरह से फिर से लिखा जाना था।

Answer 1

बहुत मदद नहीं है, लेकिन मैं अपना अनुभव साझा करूंगा।

पैरामीटर आते हैं और काट मुझे, जब मैं ज्यादातर prod डीबीए काम करने के लिए दूर जाने के बाद वापस डेवलपर डीबीए के लिए गया था करने के लिए SQL सर्वर के कुछ साल लग गए सूँघने। मैं इंजन के बारे में और अधिक समझता हूं, एसक्यूएल कैसे काम करता है, ग्राहक के लिए सबसे अच्छा क्या था और मैं एक बेहतर एसक्यूएल कोडर था।

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

मैं जटिल खोज कोड (सशर्त, के बहुत सारे) और जटिल रिपोर्टों जहां पैरामीटर चूक योजना प्रभावित के लिए इसे देखा। जब मैं देखता हूं कि अनुभवी डेवलपर्स इस कोड को कितना कम लिखेंगे, तो यह पैरामीटर स्नीफिंग का सामना नहीं करेगा।

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

पैरामीटर मास्किंग, एक ओवरहेड है हाँ, लेकिन यह नहीं बल्कि कंबल कंपाइल से, अनुकूलक मामले से क्वेरी मामले का मूल्यांकन करने के लिए अनुमति देता है। विशेष रूप से एसक्यूएल सर्वर 2005

SQL सर्वर 2008 में अज्ञात के लिए ऑप्टिमाइज़ करना भी मास्किंग के समान ही काम करता है। मेरा एसक्यूएल सर्वर एमवीपी सहयोगी और मैंने कुछ समय जांच की और इस निष्कर्ष पर पहुंचे।

Answer 2

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

असल में, यह समस्या को स्नीफ करने वाले पैरामीटर की तरह "महसूस" नहीं करता है, लेकिन "स्वस्थ" डेटाबेस समस्या से अधिक है।

यह आलेख वर्णन करता है कि कैसे आप पिछली बार के आँकड़े को अद्यतन किया गया निर्धारित कर सकते हैं: Statistics Update Time

Answer 3

मैं आंकड़ों की जांच के बारे में दूसरा टिप्पणी - मैं कई उदाहरण हैं जहां एक प्रश्न के प्रदर्शन विशेष रूप से एक चट्टान से गिर गया है क्योंकि देखा है आंकड़े पुराने हैं।

विशेष रूप से, यदि आपके पास अपने पीके में कोई तिथि है, और SQL सर्वर सोचता है कि केवल 10 या 100 रिकॉर्ड हैं जो एक विशिष्ट तारीख के बाद वास्तव में हजारों हैं, तो यह बहुत ही अक्षम क्वेरी योजनाओं का चयन कर सकता है क्योंकि यह सोचता है डेटासेट वास्तव में उससे बहुत छोटा है।

HTH,

• एंड्रयू

Answer 4

मैं बिल्कुल इस तरह एक उत्पादन मुद्दा था। एक संग्रहित प्रो नामक एप्लिकेशन में एक टैब नहीं दिखाया जाएगा। मैं विशिष्ट proc के लिए एक निशान चला गया और कॉल देखा। 30 सेकंड में आवेदन के समय और proc को पूरा होने के लिए करीब 40 से 50 सेकंड लगेंगे (जिस तरह से ट्रेस से कहा जाता है)

अगला कदम जो बयान स्कैन मैं प्रक्रिया के निष्पादन में नोटिस पैदा कर रहा था यह पता लगाने की थी। तो मैंने proc को स्क्रिप्ट किया, प्रक्रिया सिंटैक्स को हटा दिया और घोषित चरों को हटा दिया और क्वेरी विश्लेषक में भाग गया। यह 3 सेकंड में रैन !!!

मैं इस वहाँ किसी को भी answeres की तलाश में जानते हैं कि यह एसक्यूएल में हो सकता है बताने के लिए लिख रहा हूँ। यह पैरामीटर स्नीफिंग पैरामीटर से उपजी है। मैं इस थ्रेड को टी करने में सक्षम था क्योंकि मैंने कारण को दोषपूर्ण कैश किए गए प्रश्न योजना के रूप में इंगित किया था! मैंने उन पदों को पढ़ा है जहां उन्होंने कहा था कि यह एक विशिष्ट उपयोगकर्ताओं/मूल्य के साथ होता है। लेकिन यह किसी भी मूल्य के साथ हो सकता है और एक बार यह शुरू हो जाने पर, यह एक सतत बात हो सकती है।

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