2009-11-17 104 views
3

我通過Linq-to-SQL調用存儲過程。這個存儲過程簡單地處理我已經插入到另一個表中的數據。大型數據集上,我得到一個超時異常:增加LINQ to SQL存儲過程調用的超時時間

"Timeout expired. The timeout period elapsed prior to completion of the operation 
or the server is not responding." 

我不能做任何事情,以加快存儲過程 - 它只是從一個表移動到另一個數據。我並不特別想增加數據庫連接字符串中的超時時間 - 這是需要很長時間的唯一事情。

這不是一個網絡應用程序;該存儲過程是在正常Windows服務中的後臺線程中調用的。後臺線程由WCF調用啓動,客戶端定期輪詢後臺線程的結果。

不幸的是,即使存儲過程看起來運行良好,存儲過程花費的時間太長,並且GetDataContext().spRunStoredProcedure()調用將拋出TimeoutException

我可以增加僅用於此存儲過程調用的超時嗎?或者有沒有辦法讓存儲過程返回「我還沒死」,以防止連接超時?

回答

13

在DataContext上,將.CommandTimeout屬性設置爲更高的秒數值。 SQL Server的default是30秒,您可以將其設置爲0以使其不超時。

+1

嗨BK我們如何在連接字符串中爲所有存儲過程調用設置它 – MaxRecursion 2013-02-08 12:46:30

3

由於它是關於移動數據,並且由於它實際上需要很長時間纔會超時:它可能是一種解決方案,將它從Web上移開,並使其成爲預定的SQL工作?

除此之外,確實沒有無法優化的查詢;特別是那些超時的人。增加超時並不是一個很好的解決方案。即使將數據從一個表格移動到另一個表格通常也很倉促。看看你的索引,你如何選擇數據,你的鎖和統計數據。在啓用了執行計劃的情況下,在Management Studio中運行一個通常很長的查詢,並查看大部分負載(通常可以確定爲一個或兩個瓶頸因素),並查看是否有任何可以執行的操作關於他們。

+0

你是對的,但是在公司工作的人不知道該怎麼做,要自豪地承認,或者只是缺乏資金或雄心去理清它。最後一種選擇是人們不知道他們在做什麼,並且在嘗試與這樣的公司合作時會導致嚴重的問題。我同意這是正確的答案,但是..正如我們所看到的,只需要2秒就可以增加時間並假裝從未存在的問題。 – ppumkin 2013-11-04 16:10:24

+1

@ppumkin:當然,第二段主要是針對原始問題中的註釋*「我無法做任何事情來加速存儲過程」* – 2013-11-04 20:26:17

+0

哦,對。我錯過了這一部分 - 我遇到這個問題的唯一原因是因爲我正在處理存儲過程,而另一方想保持私密性,但我必須在前端實施。他們不知道如何優化速度。他們使用'LIKE%term%'搜索數百萬條記錄,並想知道爲什麼查詢需要45〜90秒。當我寫這篇文章的時候我有一段糟糕的時刻,但我認爲你的第二段在當時是高度相關的。我能做什麼 - 智能感知現在需要長達90秒.... *嘆息* – ppumkin 2013-11-04 20:31:51