2009-10-14 28 views
0

在我繼承的代碼中,我有一個SqlDataSource,它有一個相當複雜的select語句,對於某些SelectParameters,總是超時(「Timeout expired。超時時間已經過去了,服務器沒有響應。「)。SqlDataSource超時。 OK在管理工作室

當我在管理工作室中使用相同的參數運行完全相同的查詢時,查詢永遠不會超時,並且總是不到一秒。

有沒有人有一個想法是什麼問題可以在這裏?我無法理解它。

回答

1

只是在黑暗中拍攝:參數實際上並不相同。在SSMS中,您爲查詢傳遞ASCII參數,而在ADO.Net中,您傳遞的是Unicode參數。當myValue是字符串時,SqlCommand.Parameters.AddWithValue("@myParam", myValue)將添加NVARCHAR類型的參數。由於如果您有SELECT ... FROM ... WHERE myField = @myParam且myField是Ascii(VARCHAR)並且@myParam是Unicode(NVARCHAR),因此在SQL中有te轉換規則,那麼執行必須執行表掃描,不能在myField上使用索引,從而與SSMS相比會導致非常好的性能執行。正如我所說,這只是黑暗中的一個鏡頭,但卻是一個常見的陷阱,並且相當微妙地進行調試。

+1

我喜歡在黑暗中拍攝,這是一個非常有說服力的。 我確實在SqlDataSource上設置了SelectParameters的DbType/Type,並沒有幫助。另外請注意,SqlDataSource並不總是超時;只是爲了某些參數。對於那些,它一直超時,而管理工作室沒有。 – Stefan 2009-10-14 21:12:52

+0

如果您對1000個確信(不是,額外0不是拼寫錯誤)的查詢在SSMS和ADO.Net中是相同的,則應該比較執行計劃(Profiler可以向您顯示ADO的圖形執行計劃。 Net語句,捕獲計劃XML事件)。如果計劃不同(所以不是某些ADO.Net客戶端行爲不當),那麼您可能需要查看的地方是SET選項。看看sys.dm_exec_sessions的ADO.Net連接和SSMS連接並比較它們,看看不同的SET,然後檢查MSDN是否涉及不同的SET – 2009-10-14 21:20:56

+0

是的,它們是相同的(從SQL Profiler複製它)。 而你是對的......這是設置選項。我改變了「事務隔離級別」,它不再超時。我希望我可以把你和KM都作爲答案,因爲他也是在正確的軌道上。但最終,你最後的評論確實幫助我解決了這個問題,所以回答你。謝謝! – Stefan 2009-10-15 14:08:12

1

可能是鎖定/阻止,如果人們在數據庫中工作,您的選擇可能會等到他們的事務完成。根據數據庫中的其他事務,超時將被擊中或未命中。

在管理工作室中,運行SET SHOWPLAN_ALL ON,然後運行您的查詢。在輸出中尋找「SCAN」。如果你有表或索引掃描,你更可能成爲鎖定/阻止的受害者,因爲你必須處理整個索引/表,並且任何鎖定行的人都會迫使你等待。

當你運行應用程序,並且屏幕不刷新快Management Studio中運行以下命令:

EXEC sp_lock 

它會給你的任何鎖定目前正在進行的一些基本信息。

+0

無論我是否在Management Studio中,鎖定都不會發生嗎?我在Management Studio中多次運行查詢;它永遠不會超時。使用SqlDataSource,它始終如此。或者是否有一些設置強制SqlDataSource始終等待鎖而Mangement Studio根本不會? – Stefan 2009-10-14 21:03:43

+0

@Stefan,編輯你的問題說_it總是超時從SqlDataSource運行,但從來沒有從管理studio_,這是一個重要的線索。 – 2009-10-14 21:13:08

+0

好的,完成了。謝謝! – Stefan 2009-10-14 21:16:58

0

嘗試以下,也許這將闡明這是怎麼回事:

  1. 在SQL事件探查器,捕捉到其中的複雜SQL語句轉換確切聲明,並在Viual Studio中運行它。

  2. 當有問題的sql語句正在運行時,請在管理工作室中檢查activity monitor。它可以給你一個想法,什麼可能會阻止SQL。

  3. 重要的是要看看還有哪些東西在同一時間運行。應用程序是多線程的嗎? sql連接在使用後立即關閉/處理(如果沒有,它可能不會及時關閉)?多個線程使用相同的sql連接嗎?

相關問題