2013-03-05 145 views
2

我們正在獲取我們數據庫的超時問題。所以我嘲笑了SQL Server Profiler,並看到SQLQueryNotificationService每秒運行一次,持續時間很長。我檢查了Service Broker,並且創建了一堆SQLQueryNotificationService隊列。我不認爲我們創建了這些隊列中的任何一個,還有一堆存儲過程,比如這些SqlQueryNotificationStoredProcedure-15c5b84b-42b0-4cfb-9707-9b1697f44127。請讓我知道如何放棄它們?如果我放棄它們,是否對數據庫有任何影響?請告訴我。我很欣賞任何建議。sql查詢通知服務問題

+0

超時的性質是什麼?嘗試連接時是否超時?或者某些查詢運行時間過長?數據庫性能涉及很多因素,例如網絡大小/性能/延遲,表大小,索引,查詢吞吐量,客戶端連接等。我認爲在跳轉到之前退出並檢查整個系統是明智的做法您需要開始清除內部存儲過程的結論。 – mellamokb 2013-03-05 21:11:41

+0

有時超時會在調用存儲過程時發生,有時甚至不會被調用。上個月沒有任何問題,相同的代碼工作正常。本月我們開始注意到這個超時問題。我們沒有更改任何存儲過程或任何查詢。 – nav100 2013-03-05 21:17:05

+2

當您的表隨着時間的推移而逐漸增大時,這是一種非常常見的模式。您需要舉一個具體示例並嘗試解決超時問題。例如,如果您有一個存儲過程從具有數千行的表中讀取數據,並且需要在少於30秒內完成,請考慮索引過濾中使用的列(即'WHERE'子句)。您還可以增加客戶端代碼中的超時長度 - 超時[完全是客戶端](http://blogs.msdn.com/b/khen1234/archive/2005/10/20/483015.aspx),通常無限期地延長。 – mellamokb 2013-03-05 21:19:41

回答

3

您是否有運行ASP.Net網站或創建Sql Server Cache依賴關係的其他應用程序?它是Sql Server Service Broker隊列,它執行WAITFOR ...語句,等待大約一分鐘(60000毫秒),然後再次執行。通常不應該導致問題,它不應該阻止或延遲您的「正常」查詢或存儲過程。但是,我曾經看到它對我造成了一些問題 - 當從建立緩存依賴關係的相同Web應用程序執行時,其中一個存儲過程發生超時(或者在120秒內返回,這是不可接受的)。完全相同的存儲過程在相同的帳戶下使用相同的參數執行,但是從Management Studio運行良好,沒有任何問題。它是SQL Server 2005 SP4。

SQL事件探查器顯示,在我的存儲過程的執行過程中(並且始終在相同的INSERT INTO ...語句之後),它的執行被中斷,而不是它的語句有那個WAIT FOR .... Sql查詢通知,在一分鐘內完成,然後是另一個WAIT FOR ...開始,並在59秒內完成 - 只有在事件探查器向我顯示我的存儲過程完成之後。持續時間爲119000,這幾乎是兩分鐘。

這是如果該查詢通知加入我的存儲過程中的事務。

幫助:重新編譯違規的存儲過程。我只是改變了它的腳本,做了一些小的語法修改的ALTER語句。之後沒有問題。

+0

是的,現在是時候進行思考,爲什麼它有幫助,首先是錯在哪裏。 – demp 2013-05-28 16:04:27