जब प्रदर्शन स्टूडियो

Question

में एक ही कॉल किया जाता है तो एक एसक्यूएल फ़ंक्शन को .NET ऐप बनाम कहा जाता है, तो प्रदर्शन अंतर क्यों होते हैं। हमें हमारे परीक्षण और देव वातावरण में एक समस्या होती है जो कई बार धीरे-धीरे चलती है एक नेट आवेदन से। जब हम सीधे प्रबंधन स्टूडियो से इस फ़ंक्शन को कॉल करते हैं तो यह ठीक काम करता है।

यहाँ मतभेद जब वे प्रोफाइल रहे हैं: आवेदन से:
सीपीयू: 906
पुस्तकें: 61853
लिखता है: 0
अवधि: 926

SSMS से:
सीपीयू: 15
पढ़ता है: 11243
लिखते हैं: 0
अवधि: 31

अब हमने यह निर्धारित किया है कि जब हम फ़ंक्शन को पुन: संकलित करते हैं तो प्रदर्शन जो हम उम्मीद कर रहे हैं उस पर प्रदर्शन देता है और जब हम एसएसएमएस से इसे चलाते हैं तो हमें जो मिलता है उससे मेल खाता है। यादृच्छिक अंतराल पर दिखाई देने पर यह फिर से धीमा हो जाएगा।

हमने इसे प्रोड में नहीं देखा है लेकिन वे कुछ हद तक हो सकते हैं क्योंकि साप्ताहिक आधार पर सबकुछ फिर से इकट्ठा किया जाता है।

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

संपादित करें -
हम अंत में यह और varables पैरामीटर सूंघने से निपटने के लिए पुनर्गठन चाल ... क्या हम यहाँ किया था का एक टुकड़ा किया है प्रकट होता है से निपटने के लिए सक्षम थे: धन्यवाद आपकी मदद के लिए।

 -- create set of local variables for input parameters - this is to help performance - vis a vis "parameter sniffing" 
    declare @dtDate_Local     datetime 
      ,@vcPriceType_Local    varchar(10) 
      ,@iTradingStrategyID_Local  int 
      ,@iAccountID_Local    int 
      ,@vcSymbol_Local    varchar(10) 
      ,@vcTradeSymbol_Local   varchar(10) 
      ,@iDerivativeSymbolID_Local  int 
      ,@bExcludeZeroPriceTrades_Local bit 

    declare @dtMaxAggregatedDate  smalldatetime 
      ,@iSymbolID    int 
      ,@iDerivativePriceTypeID int 

    select @dtDate_Local     = @dtDate 
      ,@vcPriceType_Local    = @vcPriceType 
      ,@iTradingStrategyID_Local  = @iTradingStrategyID 
      ,@iAccountID_Local    = @iAccountID 
      ,@vcSymbol_Local    = @vcSymbol 
      ,@vcTradeSymbol_Local   = @vcTradeSymbol 
      ,@iDerivativeSymbolID_Local  = @iDerivativeSymbolID 
      ,@bExcludeZeroPriceTrades_Local = @bExcludeZeroPriceTrades 

Answer 1

आमतौर पर यह इसलिए होता है क्योंकि आपको अपने एसएसएमएस कनेक्शन में एक अलग निष्पादन योजना मिल रही है। अक्सर पैरामीटर स्नीफिंग मुद्दों से संबंधित होते हैं, जहां योजना एक विशिष्ट मान के साथ उत्पन्न होती है जो पैरामीटर के अन्य मानों के लिए उप इष्टतम होती है। यह भी बताता है कि क्यों पुनर्मूल्यांकन इस मुद्दे को हल करेगा। इस धागे में एक अच्छा स्पष्टीकरण है Parameter Sniffing (or Spoofing) in SQL Server

Answer 2

मुझे संग्रहित प्रक्रियाओं के साथ समान समस्या थी, और मेरे लिए यह 'पैरामीटर स्नीफिंग' बन गया। Google यह देखता है कि यह आपकी समस्या का हल करता है, मेरे लिए यह तय करने के बाद नाटकीय गति-अप था।

मेरे मामले में, मैंने इसे पारित किए गए प्रत्येक पैरामीटर के लिए स्थानीय चर घोषित करके इसे ठीक किया, और उसके बाद स्थानीय चर को उस पैरामीटर मान पर असाइन किया, और शेष प्रो प्रोसेसिंग के लिए स्थानीय चर का उपयोग किया ... किसी भी कारण से, यह पैरामीटर स्नीफिंग को हराया।

Answer 3

संभावित कारण पुराने आंकड़े और/या पैरामीटर स्नीफिंग है जो एक कैश किए गए क्वेरी प्लान को फिर से उपयोग करने के लिए उप-इष्टतम है।

एसएसएमएस पूर्व-महत्वाकांक्षी बयानों को उत्सर्जित करता है जो आप नहीं देखते हैं, जिससे सबमिट की गई क्वेरी हर बार फिर से संकलित की जाती है, इस प्रकार गलत कैश योजना का उपयोग करने की संभावना समाप्त हो जाती है।

यह सभी आंकड़े अपडेट हो जाएगा और विचारों और संग्रहीत procs ताज़ा (लेकिन एक उत्पादन मशीन पर चलाने के बारे में सावधान रहना होगा):

EXEC sp_updatestats 

EXEC sp_refreshview 

EXEC sp_msForEachTable 'EXEC sp_recompile ''?'''