लिंक संग्रहित प्रक्रिया टाइमआउट लेकिन एसएसएमएस त्वरित

Question

मेरे पास एक संग्रहित प्रक्रिया है जिसे मैं LinqToSQL का उपयोग कर कॉल कर रहा हूं। मैं कुछ खास नहीं कर रहा हूं, उदा।

MyDataContext db = new MyDataContext() 

var results = db.storedProcedure(param1, param2, param3) 

// Do stuff 

जब मैं सटीक पैरामीटर का उपयोग करके संग्रहीत प्रक्रिया चलाता हूं तो मुझे 2 से 6 सेकंड के बीच परिणाम मिलते हैं। डेटाबेस एक दूरस्थ डेटाबेस है।

हालांकि, जब मैं संग्रहित प्रक्रिया चलाता हूं तो यह (डीबगिंग के बाद ....) 275 सेकेंड लेता है!

: सामान्य परिस्थितियों में यह निम्न अपवाद देता है [Win32Exception (0x80004005): प्रतीक्षा प्रचालन का समय समाप्त]

[SqlException (0x80131904): समय समाप्त समाप्त हो गई है। ऑपरेशन के पूरा होने से पहले समय समाप्ति अवधि समाप्त हो गई है या सर्वर प्रतिक्रिया नहीं दे रहा है।] सिस्टम। डेटा.क्लक्लिएंट। एसकएलकनेक्शन.ऑनरर (एसक्यूएलएक्सप्शन अपवाद, बूलियन ब्रेककनेक्शन, एक्शन 1 wrapCloseInAction) +1753346 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action 1 wrapCloseInAction) +5295154 सिस्टम। डेटा। SQL क्लाइंट TdsParser .ThrowExceptionAndWarning (TdsParserStateObject stateObj, बूलियन callerHasConnectionLock, बूलियन asyncClose) +242 System.Data.SqlClient.TdsParser.TryRun (runBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, बूलियन & dataReady) 1682 System.Data .SqlClient.SqlDataReader.TryConsumeMetaData() +59 System.Data.SqlClient.SqlDataReader.get_MetaData() +90 System.Data.SqlClient.SqlCommand.Finish ExecuteReader (SqlDataReader डी एस, RunBehavior runBehavior, स्ट्रिंग resetOptionsString) 365 System.Data.SqlClient.SqlCommand.RunExecuteReaderTds (CommandBehavior cmdBehavior, RunBehavior runBehavior, बूलियन returnStream, बूलियन async, Int32 टाइमआउट, टास्क & कार्य, बूलियन asyncWrite) 1325 सिस्टम .Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, runBehavior runBehavior, बूलियन returnStream, स्ट्रिंग विधि, TaskCompletionSource`1 पूरा होने, Int32 टाइमआउट, टास्क & कार्य, बूलियन asyncWrite) 175 System.Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, RunBehavior runBehavior, बूलियन रिटर्नस्ट्रीम, स्ट्रिंग विधि) +53 सिस्टम। डेटा। SQL क्लाइंट। SQLCommand.ExecuteReader (कमांड व्यवहार व्यवहार, स्ट्रिंग विधि) +134 सिस्टम। डेटा। SQLlie nt.SqlCommand.ExecuteDbDataReader (कमांड व्यवहार व्यवहार) +41 System.Data.Common.DbCommand.ExecuteReader() +12 System.Data.Linq.SqlClient.SqlProvider.Execute (अभिव्यक्ति क्वेरी, QueryInfo queryInfo, IObjectReaderFactory फैक्ट्री, ऑब्जेक्ट [] parentArgs, ऑब्जेक्ट [] userArgs, ICompiledSubQuery [] subQueries, ऑब्जेक्ट lastResult) +1306 System.Data.Linq.SqlClient.SqlProvider.ExecuteAll (अभिव्यक्ति क्वेरी, QueryInfo [] queryInfos, IObjectReaderFactory फैक्ट्री, ऑब्जेक्ट [] उपयोगकर्ता आर्ट्यूमेंट्स, ICompiledSubQuery [] subQueries) +118 System.Data.Linq.SqlClient.SqlProvider.System.Data.Linq.Provider.IProvider.Execute (अभिव्यक्ति क्वेरी) +342 System.Data.Linq.DataContext.ExecuteMethodCall (ऑब्जेक्ट इंस्टेंस, MethodInfo methodInfo, ऑब्जेक्ट [] पैरामीटर) +83

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

क्या किसी ने इससे पहले और किसी भी विचार को ठीक करने का तरीका अनुभव किया है?

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

हमेशा की तरह, यह कल ठीक काम कर रहा था!

अग्रिम धन्यवाद।

Answer 1

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

हालांकि, मुख्य बात यह है कि दोनों विधियों के पास एक अलग निष्पादन योजना है - यही कारण है कि एसएसएमएस की तुलना में वेबसाइट पर एक ही चीज़ (यादृच्छिक रूप से) अधिक समय ले सकती है।

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

अंत में हम संग्रहित प्रक्रिया में रिकॉम्पली के साथ उपयोग करते थे - इसलिए निष्पादन योजना का कोई कुशल पुन: उपयोग नहीं होता है, लेकिन हमने किसी भी अंतर को ध्यान में नहीं देखा और समस्या तब से नहीं हुई है।

Answer 2

मेरे लिए यह समस्या एक लूप था जो Linq.Table < > पर निर्भर था।)()। विकास पर्यावरण पर, अंतर्निहित क्वेरी लगभग तुरंत है, लेकिन उत्पादन में इसमें कुछ सेकंड लग गए। एसक्यूएल प्रोफाइलर को हुकिंग ने खुलासा किया कि क्वेरी लूप के प्रत्येक पुनरावृत्ति के साथ निष्पादित की गई थी, इसलिए उन "कुछ सेकंड" को जोड़ना शुरू हो गया, और अंत में समाप्त हो गया।

मेरे लिए समाधान स्थानीय चर में गणना() परिणाम असाइन करना था, और लूप में इसका उपयोग करना था, ताकि गणना() ने प्रत्येक पुनरावृत्ति के साथ क्वेरी को फिर से निष्पादित नहीं किया। मुझे लगता है कि अन्य लोगों को इस मुद्दे का अनुभव होगा यदि वे अंतर्निहित लिंक पूर्ण कार्यों पर भरोसा करते हैं जो धीमे प्रश्नों को फिर से निष्पादित करेंगे।