एसपी 15 मिनट ले रहा है लेकिन निष्पादित रिटर्न के दौरान एक ही क्वेरी 1-2 मिनट

Question

में परिणामस्वरूप मूल रूप से मेरे पास यह अपेक्षाकृत लंबी संग्रहीत प्रक्रिया है। मूल निष्पादन प्रवाह यह है कि यह SELECTS INTO# हस्ताक्षर के साथ घोषित temp तालिकाओं में कुछ डेटा है और फिर इन तालिकाओं के माध्यम से एक कर्सर चलाता है जो CREATE का उपयोग करके बनाई गई तीसरी अस्थायी तालिका में 'रनिंग कुल' उत्पन्न करता है। इसके बाद परिणामस्वरूप अस्थायी तालिका कुछ समूह के बाद परिणाम उत्पन्न करने के लिए डीबी में अन्य तालिकाओं के साथ जुड़ गई है। समस्या यह है कि यह एसपी 1-2 मिनट में परिणाम लौटने तक ठीक चल रहा था। और अब अचानक 12-15 मिनट लग रहा है। यदि मैं एसपी से क्वेरी निकालता हूं और मैन्युअल रूप से उसी पैरामीटर को सेट करके प्रबंधन स्टूडियो में निष्पादित करता हूं तो यह 1-2 मिनट में परिणाम देता है लेकिन एसपी बहुत लंबा लगता है। कोई विचार क्या हो रहा है। मैंने क्वेरी और एसपी दोनों की वास्तविक निष्पादन योजनाएं उत्पन्न करने की कोशिश की लेकिन यह कर्सर की वजह से इसे उत्पन्न नहीं कर सका। कोई विचार नहीं है कि एसपी इतनी देर क्यों लेता है जब क्वेरी नहीं होती है?

Answer 1

यह पैरामीटर-स्नीफिंग का पदचिह्न है। इसके बारे में एक और चर्चा के लिए यहां देखें; SQL poor stored procedure execution plan performance - parameter sniffing

आपके संभावित प्रक्रिया में रिकॉम्प्ली के साथ जोड़ने सहित कई संभावित फ़िक्स हैं, जो लगभग आधे समय तक काम करते हैं।

ज्यादातर स्थितियों के लिए ठीक सिफारिश की (हालांकि यह आपकी क्वेरी और sproc की संरचना पर निर्भर करता है) नहीं आपके प्रश्नों में सीधे अपने पैरामीटर का उपयोग, बल्कि उन्हें स्थानीय चर में संग्रहीत करने और उसके बाद में उन चर का उपयोग करने के लिए है अपने प्रश्नों।

Answer 2

मैं सुझाव दूंगा कि समस्या temp तालिका (# उपसर्ग) के प्रकार से संबंधित है। इस temp तालिका उस डेटाबेस सत्र के लिए डेटा रखती है। जब आप इसे अपने ऐप के माध्यम से चलाते हैं तो अस्थायी तालिका हटा दी जाती है और फिर से बनाई जाती है।
एसएसएमएस में चलते समय आपको मिल सकता है यह सत्र डेटा रखता है और इसे बनाने के बजाय तालिका को अद्यतन करता है। आशा है कि मदद करता है :)

Answer 3

मुझे लगता है कि यह संभवतः कैशिंग करने के लिए नीचे हो सकता है। यदि आप संग्रहीत प्रक्रिया को दो बार चलाते हैं तो यह दूसरी बार तेज़ होता है?

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

वैकल्पिक रूप से आप लोगों को अनुकूलन का सुझाव देने के लिए संग्रहीत प्रक्रिया पोस्ट कर सकते हैं।

Answer 4

sproc recompiling की कोशिश किसी भी संग्रहीत क्वेरी योजना

exec sp_recompile 'YourSproc' 

तो समझदार पैरामीटर का उपयोग करने के देखभाल करने के अपने sproc चलाने खाई करने के लिए।

क्वेरी निष्पादित करने के दो तरीकों के बीच वास्तविक निष्पादन योजनाओं की तुलना करें।

यह किसी भी आंकड़े को पुनः संयोजित करने योग्य भी हो सकता है।

Answer 5

शुरुआत के लिए यह ऐसा नहीं लगता है कि एसक्यूएल कई अस्थायी तालिकाओं (स्मृति में आयोजित किया जा सकता है, या tempdb पर जारी रखा जा सकता है - जो कुछ भी SQL सर्वर निर्णय लेता है, के उपयोग के आधार पर भी बहुत अच्छा प्रदर्शन करने जा रहा है।), और कर्सर का उपयोग।

मेरा सुझाव यह देखना होगा कि क्या आप कर्सर-दृष्टिकोण के बजाय स्प्रोक को सेट-आधारित क्वेरी के रूप में फिर से लिख सकते हैं जो बेहतर प्रदर्शन प्रदान करेगा और ट्यून और अनुकूलित करने के लिए बहुत आसान होगा। स्पष्ट रूप से मुझे नहीं पता कि आपका स्पोक क्या करता है, यह संकेत देने के लिए कि यह आपके लिए कितना आसान/व्यवहार्य है।

क्यों एसपी क्वेरी से अधिक समय ले रहा है - कहने में मुश्किल है। जब आप प्रत्येक दृष्टिकोण का प्रयास करते हैं तो सिस्टम पर वही भार होता है? यदि कोई हल्का भार होता है तो आप स्वयं क्वेरी को चलाते हैं, तो जब आप भारी भार के दौरान एसपी चलाते हैं तो यह बेहतर होगा।

इसके अलावा, यह सुनिश्चित करने के लिए कि वास्तव में एसपी की तुलना में क्वेरी तेज है, आपको डेटा/निष्पादन योजना कैशिंग को रद्द करने की आवश्यकता है जो बाद के रनों के लिए एक क्वेरी तेज कर देता है।आप का उपयोग कर बाहर कैश को साफ़ कर सकते हैं:

DBCC FREEPROCCACHE 
DBCC DROPCLEANBUFFERS 

लेकिन केवल उत्पादन पर नहीं एक देव/परीक्षण डाटाबेस सर्वर पर ऐसा करते हैं,। फिर क्वेरी चलाएं, आंकड़े रिकॉर्ड करें (उदा। प्रोफाइलर से)। फिर से कैश साफ़ करें। एसपी चलाएं और आंकड़ों की तुलना करें।

Answer 6

1) जब आप पहली बार क्वेरी चलाते हैं तो इसमें अधिक समय लग सकता है। एक और बिंदु यह है कि यदि आप किसी भी कोरलेटेड उप क्वेरी का उपयोग कर रहे हैं और यदि आप मानों को हार्डकोड कर रहे हैं तो इसे केवल एक बार निष्पादित किया जाएगा। जब आप इसे हार्डकोड नहीं कर रहे हैं और प्रक्रिया के माध्यम से इसे चलाते हैं और यदि आप इनपुट मान से मूल्य प्राप्त करने का प्रयास कर रहे हैं तो इसमें अधिक समय लग सकता है।

2) दुर्लभ मामलों में यह नेटवर्क यातायात के कारण हो सकता है, जहां भी हमें उसी इनपुट डेटा के लिए क्वेरी निष्पादन समय में स्थिरता नहीं होगी।

Answer 7

मैं पैरामीटर स्नीफिंग में भी देखता हूं। पैरामीटर को अलग-अलग पैरामीटर को संभालने की आवश्यकता हो सकती है।

Answer 8

मैं आमतौर पर "प्रिंट getdate() + '- step'" का उपयोग करके समस्या निवारण समस्याओं को प्रारंभ करता हूं। यह मुझे सबसे अधिक समय ले रहा है को कम करने में मदद करता है। आप क्वेरी विश्लेषक से इसे कहां से चला सकते हैं और उस समस्या को कम कर सकते हैं जहां समस्या है।

Answer 9

मुझे भी एक समस्या का सामना करना पड़ा जहां हमें कुछ अस्थायी तालिकाओं को बनाना था और फिर उन्हें छेड़छाड़ करना नियमों के आधार पर कुछ मूल्यों की गणना करना था और अंत में गणना की गई मानों को तीसरी तालिका में डालना था। यदि एसपी में रखा गया तो यह सब लगभग 20-25 मिनट ले रहा था। तो इसे अनुकूलित करने के लिए हमने स्पैम को 3 अलग-अलग स्पैम में तोड़ दिया और अब कुल समय लगभग 6-8 मिनट था। बस पूरी प्रक्रिया में शामिल चरणों और विभिन्न एसपी में उन्हें तोड़ने के तरीकों की पहचान करें। निश्चित रूप से इस दृष्टिकोण का उपयोग करके पूरी प्रक्रिया द्वारा लिया गया समग्र समय कम हो जाएगा।

Answer 10

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

ALTER PROCEDURE [dbo].[Sp_GetAllCustomerRecords] 
@customerId INT 
AS 
declare @customerIdTemp INT 
set @customerIdTemp = @customerId 
BEGIN 
SELECT * 
FROM Customers e Where 
CustomerId = @customerIdTemp 
End 

इस दृष्टिकोण