2
由於前幾天，支持我們的網站SQL服務器（微軟的SQL Server 2005）已經開始偶爾timeouting。它發生在幾乎每隔一兩小時的看似隨機的時間。通常需要大約10分鐘，在此期間我們會看到數百個超時請求。在正常情況下，我們大部分的查詢時間不到50ms。只需要很長時間的查詢就是一個例外。間歇性SQL超時
我已經有效地殺了一天試圖找出至少一些沒有任何實際進展。通常，服務器負載約爲10-20％，發生超時時，我們看不到任何增加的CPU負載。另外，在暫停期間沒有什麼特別的事情發生，沒有過度的網絡爬蟲，沒有繁重的後臺任務，沒有增加網絡流量，沒有增加連接數量等。簡單地說，一切看起來都如常。
沒有取得任何進展，我們決定重新啓動它（因爲我們是在它安裝最新的SP），這似乎已經解決了這一問題。已經有六個多小時沒有發生任何事故。此外，CPU負載已經下降到10％以下。
它似乎像如果SQL Server「惡化」加班。也許，一些內部結構（一些緩存或統計）已經成形並引起偶爾的問題。我沒有任何其他解釋。
當我監控服務器，我注意到（和很幸運一次出現時的超時正在發生）的唯一的事，我看見幾個長時間運行的查詢等待CXPACKET。但我瞭解到，這很可能只是其他一些問題的後果。我編寫了一個監視SQL請求的腳本，希望下次發生這種情況時，我會獲得更多信息。
有沒有人有類似的經歷？我不是SQL Server專家。歡迎任何建議。
我只是投這個移至serverfault - 一個好的DBA或服務器管理員應該能夠幫助這個。這就是說 - 你看過服務器上運行的事務嗎（任何打開的序列化事務？）你是否使用了sp_lock和sp_who來查看鎖和進程，看看它是否是鎖定問題？當問題再次出現時，您是否已經讓系統上的分析器運行以提供更多信息？ – 2010-02-22 22:10:17
我寫的腳本基本上監視sys.dm_exec_requests和sys.dm_exec_sessions並查找阻塞請求。但是，它只是在我們重新啓動服務器之後，似乎它不會再發生。之前，我嘗試使用活動監視器，但它太慢而且太麻煩。 – 2010-02-22 22:20:08