मैंने अपने शोध से अब तक यही सीखा है।
.NET उन कनेक्शन सेटिंग्स में भेजता है जो प्रबंधन स्टूडियो में लॉग इन करने पर आपको मिलने वाली सेटिंग्स के समान नहीं होती हैं। यदि आप Sql Profiler के साथ कनेक्शन को सूँघते हैं तो आप यहाँ देख सकते हैं:
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
मैं अब उन सेटिंग्स को प्रत्येक क्वेरी के ऊपर पेस्ट कर रहा हूं जो मैं एसक्यूएल सर्वर में लॉग इन करते समय चलाता हूं, यह सुनिश्चित करने के लिए कि सेटिंग्स समान हैं।
इस मामले के लिए, मैंने डिस्कनेक्ट करने और पुन:कनेक्ट करने के बाद प्रत्येक सेटिंग को अलग-अलग करने की कोशिश की, और पाया कि arithabort को बंद से चालू करने से समस्या क्वेरी 90 सेकंड से 1 सेकंड तक कम हो गई।
सबसे संभावित स्पष्टीकरण पैरामीटर सूँघने से संबंधित है, जो एक तकनीक है जो एसक्यूएल सर्वर सबसे प्रभावी क्वेरी योजना को चुनने के लिए उपयोग करता है। जब आप कनेक्शन सेटिंग्स में से किसी एक को बदलते हैं, तो क्वेरी ऑप्टिमाइज़र एक अलग योजना चुन सकता है, और इस मामले में, यह स्पष्ट रूप से एक खराब योजना चुनता है।
लेकिन मैं इस पर पूरी तरह आश्वस्त नहीं हूं। मैंने इस सेटिंग को बदलने के बाद वास्तविक क्वेरी योजनाओं की तुलना करने की कोशिश की है और मुझे अभी तक अंतर में कोई बदलाव नहीं दिख रहा है।
क्या एरिथबॉर्ट सेटिंग के बारे में कुछ और है जिसके कारण कुछ मामलों में क्वेरी धीमी गति से चल सकती है?
समाधान सरल लग रहा था:बस सेट arithabort को संग्रहीत कार्यविधि के शीर्ष पर रखें। लेकिन इससे विपरीत समस्या हो सकती है:क्वेरी पैरामीटर बदलें और अचानक यह 'चालू' की तुलना में 'बंद' के साथ तेज़ी से चलता है।
कुछ समय के लिए मैं यह सुनिश्चित करने के लिए 'रीकंपाइल के साथ' प्रक्रिया चला रहा हूं कि योजना हर बार पुन:उत्पन्न हो जाए। इस विशेष रिपोर्ट के लिए यह ठीक है, क्योंकि इसे पुन:संकलित करने में शायद एक सेकंड का समय लगता है, और यह उस रिपोर्ट पर बहुत अधिक ध्यान देने योग्य नहीं है जिसे वापस आने में 1-10 सेकंड लगते हैं (यह एक राक्षस है)।
लेकिन यह अन्य प्रश्नों के लिए एक विकल्प नहीं है जो बहुत अधिक बार चलते हैं और कुछ ही मिलीसेकंड में जितनी जल्दी हो सके वापस लौटने की आवश्यकता होती है।
