SQL連接超時

我們一直在我們的某個網站上面臨奇怪的連接超時。SQL連接超時

我們的環境由IIS 7 Web服務器（在Windows Server 2008 R2標準版上運行）和SQL Server 2008數據庫服務器組成。

當調試引發超時的網站功能，我們注意到，連接本身需要毫秒即可完成，但SqlCommand，它調用數據庫的存儲過程，掛起執行過程中幾分鐘，然後引發超時異常。

另一方面，當我們直接在數據庫上運行存儲過程時，只需2秒即可正確完成執行。

我們已經嘗試了以下內容：

修改執行超時的web.config文件

修改的web.config文件

修改授權cookie超時sessionState超時網站上的代碼

修改SqlCommand超時對web.config文件
修改了con在IIS上的網站性能nection超時
修改於IIS
應用程序池關閉時間限制託運的應用程序池空閒超時在IIS
經過上的SQL Server性能的執行超時（它被設置爲0，無限）
與其他參數

我們感謝所有幫助測試的存儲過程直接在數據庫上。

Nirav

來源

2011-08-29 nirav

集ARITHABORT ON – SQLMenace

[慢速的應用，快速的SSMS？瞭解性能祕訣]（http://www.sommarskog.se/query-plan-mysteries.html） –

當它只是掛你有沒有檢查知道你想要訪問的表上的鎖？ –

我已經受夠了，這是爲用戶提供搜索功能的存儲過程同樣的問題。我嘗試了一切，包括ARTIHABORT等.SP加入了許多表格，因爲用戶可以搜索任何東西。 SP的許多參數都是可選的，這意味着SP中的默認值爲NULL。沒有工作。

我通過確保我的ADO.NET代碼僅在用戶選擇值時添加了參數來「修復」它。 SP的執行時間從幾分鐘到幾秒不等。我假設SQL Server只有在將具有實際值的參數傳遞給SP時才更好地處理執行計劃。

請注意，這是對SQL Server 2000中

來源

2011-08-29 16:20:49 HardCode

是的..我檢查了所有的東西......仍然沒有手槍...... – nirav

幾年前我從SQL2000遷移一個應用程序來SQL2008的時候也有類似的問題。

我將OPTION (RECOMPILE)添加到數據庫中存在問題的所有存儲過程的末尾。在我的情況下，它必須處理調用存儲過程之間非常不同的參數。強制proc重新編譯會迫使SQL提出一個新的執行計劃，而不是嘗試使用緩存的版本，而這個版本可能不適合新的參數。

如果你還沒有做到，請檢查你的索引。沒有什麼能夠像缺乏急需的索引一樣殺死數據庫性能。這是一個很好的鏈接（http://sqlfool.com/2009/04/a-look-at-missing-indexes/），將顯示缺少索引的查詢。

來源

2011-12-06 07:10:13

超級超級晚的建議，但可能會來方便他人：一個典型的問題，我看到的和相當適用於Java是以下幾點：

你有一個查詢這需要一個字符串作爲參數。該字符串是數據庫中varchar（N）列的搜索條件。但是，您在查詢中將字符串參數作爲Unicode（nvarchar（N））提交。這將導致全表掃描並將每個字段值轉換爲Unicode以進行適當的比較，以避免潛在的數據丟失（如果SQL Server將輸入參數轉換爲非Unicode，則可能會丟失信息）。

簡單的測試：運行查詢兩次（爲簡單起見，我假定這是一個SP）：

exec spWhatever 'input' 
exec spWhatever N'input'

看看他們如何表現。此外，您可能需要查看SSMS中活動監視器上最近昂貴的查詢部分，並詢問執行計劃，以澄清情況。

乾杯，埃裏克

來源

2013-04-25 03:47:22

SQL連接超時

回答

相關問題