क्या sp_executesql को डिफ़ॉल्ट रूप से कॉन्फ़िगर / उपयोग किया जा सकता है?

Question

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

लेकिन जब मैं ट्रेस करता हूं, तो मैं बहुत सारे प्रश्नों के साथ लिपटा हुआ देख सकता हूं sp_executesql। पूरे एप्लिकेशन समाधान में कमांड भी नहीं है sp_executesql।

तो मुझे आश्चर्य हुआ कि क्या ऐसा कोई कॉन्फ़िगरेशन है जो मुझे अभी तक नहीं पता है जो सॉफ़्टवेयर को डिफ़ॉल्ट रूप से sp_executesql के साथ प्रश्नों को लपेटने के लिए मजबूर करता है?

इस व्यवहार का क्या कारण हो सकता है?

Answer 1

SQL कथनों के साथ लिपटा जाने sp_executesqlका कारण SqlCommand.Commandtypeसंपत्ति की सेटिंग और कमांड में किसी भी पैरामीटर को पारित करना है।

SqlCommand cmd = new SqlCommand("proc1", con);
cmd.CommandType = CommandType.StoredProcedure;                
cmd.Parameters.AddWithValue("@param1", 1);
con.Open();
cmd.ExecuteNonQuery();
con.Close();

उपरोक्त कोड इस T-SQL के साथ समाप्त होता है:

exec proc1 @param1=1

SqlCommand cmd = new SqlCommand("proc1", con);
cmd.CommandType = CommandType.Text;                
cmd.Parameters.AddWithValue("@param1", 1);
con.Open();
cmd.ExecuteNonQuery();
con.Close();

यह कोड निम्नलिखित T- SQL के निष्पादन के साथ समाप्त होता है:

exec sp_executesql N'proc1',N'@param1 int',@param1=1

जोड़ 23.12.15: एक CommandType.Textकमांड का उपयोग करना , परिणाम समान हैं: जैसे ही कमांड ऑब्जेक्ट में एक पैरामीटर जोड़ा जाता है, .NET पूरी क्वेरी को इसमें लपेट देगा sp_executesqlऔर मापदंडों को पास करेगा।

जोड़: गहरा गोता sp_executesqlलगाने के बाद, .NET क्लास के इस व्यवहार को पूरी तरह से समझने के लिए पैरामीटर सूँघना और योजना बनाना उच्च क्रम क्वेरी संकलन और योजनाओं की संख्या से बचने के लिए पूरी तरह से समझ में आता है। तो यह मूल रूप से एक बेहतर SQL सर्वर प्रदर्शन सुनिश्चित करने के लिए डिज़ाइन किया गया है, जबकि यह एक ही समय में कुछ प्रश्नों (पैरामीटर सूंघने का मुद्दा) के खराब प्रदर्शन को जन्म दे सकता है जो कि प्रारंभिक बनाए गए क्वेरी प्लान की तुलना में विभिन्न पैरामीटर मानों के साथ उपयोग किए जाते हैं।

देख:

• https://blogs.technet.microsoft.com/mdegre/2011/11/06/what-is-parameter-sniffing/
• http://sqlmag.com/database-performance-tuning/don-t-fear-dynamic-sql
• http://www.sqlskills.com/blogs/kimberly/exec-and-sp_executesql-how-are-they-different
• http://www.brentozar.com/archive/2013/06/optimize-for-unknown-sql-server-parameter-sniffing/
• https://sqlblog.org/2011/09/17/bad-habits-to-kick-using-exec-instead-of-sp_executesql

उपरोक्त नमूना .NET फ्रेमवर्क 4.5 और SQL सर्वर 2008 डेवलपर संस्करण का उपयोग करके बनाया गया था।

Answer 2

यदि यह एक .NET अनुप्रयोग है, तो यह SqlCommand.ExecuteReader () कहे जाने का परिणाम है । मुख्य SqlCommand वर्ग पृष्ठ के अनुसार , ExecuteReader के तहत "रिमार्क्स" अनुभाग में विधि वर्णन की ग्रिड में, यह कहता है:

निष्पादित आदेश पंक्तियों को वापस करते हैं। वृद्धि के प्रदर्शन के लिए, ExecuteReader Transact-SQL sp_executesql सिस्टम संग्रहीत कार्यविधि का उपयोग करके आदेशों को आमंत्रित करता है । इसलिए, ExecuteReader का वह प्रभाव नहीं हो सकता है जो आप चाहते हैं यदि Transact-SQL SET स्टेटमेंट जैसे कमांड निष्पादित करने के लिए उपयोग किया जाता है।

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