當它基於的存儲過程在幾秒內返回結果時，爲什麼SSRS報告會超時？

我有一個呈現從存儲過程返回的數據的報告。使用事件探查器，我可以從報告服務中調用存儲過程。當它基於的存儲過程在幾秒內返回結果時，爲什麼SSRS報告會超時？

該報告失敗，說明報告超時，但我可以從SSMS執行存儲過程，並在五到六秒內將數據返回。

請注意，在示例測試運行中，只有兩行返回到報表以進行呈現，但在存儲過程中，它可能已經處理了數千甚至數百萬條記錄，以便將傳回給報告服務的結果進行比較。

我知道存儲過程可以更優化，但我不明白爲什麼SSRS會超時當執行似乎只需要幾秒鐘，從SSMS執行。

此外還出現了另一個問題。如果我重新創建存儲過程，報告將再次呈現完美呈現。這很好，除非在很短的時間內，報告再次開始超時。

超時的返回似乎與新數據被添加到報表運行的主表中有關。在我測試的例子中，插入了一百條新記錄就足以搞砸報告。

我更正確地想象它不是報告是根本原因。這是從SSRS執行時導致超時的存儲過程。

一旦它再次超時，我最好的解決方法是到目前爲止重新創建存儲過程。這似乎不是一個理想的解決方案。

這個問題似乎也只在我們的生產環境中發生。我們的測試和開發平臺似乎沒有出現同樣的問題。雖然開發和測試沒有與生產相同的記錄量。

來源

2008-10-25 BlackMael

正如您所描述的，問題似乎來自存儲過程中某些部分執行計劃的變體。看看使用的表上保留了哪些統計數據，以及添加新行如何影響它們。

如果你在一列的範圍末尾添加很多行（想想有關添加autonumbers，或時間戳），對於列的直方圖會迅速變得過時。通過執行UPDATE STATISTICS語句，您可以強制立即從 T-SQL進行更新。

來源

2008-10-25 22:10:37

有時候將WITH RECOMPILE選項添加到存儲過程的CREATE語句幫助中。當過程探索的記錄數量以原始執行計劃不是最優的方式發生變化時，這是有效的。

來源

2008-10-28 13:06:14 kristof

基本上我迄今爲止所做的所有工作都是爲了更好地優化存儲過程，似乎至少暫時解決了這個問題。

我仍然想知道從SSMS和SSRS調用存儲過程之間有什麼區別。

來源

2008-10-28 19:24:29 BlackMael

我也有這個問題，SPROC需要幾秒鐘才能運行，但SSRS只是超時。

我從我自己的經驗中發現，有幾種不同的方法可以解決這個問題。

參數嗅探！當您從SSRS執行存儲過程時，它將「嗅探」出您的參數，以瞭解您的SPROC如何使用它們。然後，SQL Server將根據其研究結果生成執行計劃。這是第一次執行SPROC時的好處，但您不希望每次運行報告時都這樣做。所以我在SPROC的頂部聲明瞭一組新的變量，這些變量只存儲查詢中傳遞的參數，並在整個查詢中使用這些新參數。

例子：

CREATE PROCEDURE [dbo].[usp_REPORT_ITD001] 
@StartDate DATETIME, 
@EndDate DATETIME, 
@ReportTab INT 
AS 

-- Deter parameter sniffing 
DECLARE @snf_StartDate DATETIME = @StartDate 
DECLARE @snf_EndDate DATETIME = @EndDate 
DECLARE @snf_ReportTab INT = @ReportTab

...這意味着，當你SPORC由SSRS執行它只是看着你的查詢中傳遞的參數排第幾，而不是整個的你查詢。這在SSRS中大大減少了執行時間。

如果你的存儲過程有很多被聲明爲變量（DECLARE @MyTable AS TABLE）臨時表，這些都是在服務器上真正強化（在內存方面）生成報表時。相反，通過使用散列臨時表（SELECT MyCol1, MyCol2 INTO #MyTable），SQL Server會將臨時表存儲在服務器上的TempDB中，而不是存儲在系統存儲器中，從而使報告生成更加密集。

來源

2011-01-13 11:05:47

當它基於的存儲過程在幾秒內返回結果時，爲什麼SSRS報告會超時？

回答

相關問題