已知問題？：SQL Server 2005的存儲過程失敗，出現一個參數

您的基本SP用默認參數來完成：已知問題？：SQL Server 2005的存儲過程失敗，出現一個參數

ALTER PROCEDURE [usp_debug_fails] 
    @DATA_DT_ID AS int = 20081130 
WITH RECOMPILE 
AS 
BEGIN 
    /* 
     Usage: 
     EXEC [usp_debug_fails] WITH RECOMPILE 
    */ 
    -- Stuff here that depends on DATA_DT_ID 
END

同一個SP與當地是硬編碼。

ALTER PROCEDURE usp_debug_works] 
WITH RECOMPILE 
AS 
BEGIN 
    /* 
     Usage: 
     EXEC [usp_debug_works] WITH RECOMPILE 
    */ 

    DECLARE @DATA_DT_ID AS int 
    SET @DATA_DT_ID = 20081130 
    -- Stuff here that depends on DATA_DT_ID 
END

你可以看到我放在（冗餘，即使）WITH RECOMPILE選項，以避免參數嗅探（這是從來沒有必要在發展，其中這件事情的罰款）

的作品完成了一個罰款一兩分鐘，另一方永遠不會完成 - 只要坐在那裏幾個小時。

這個問題從來沒有發生過的開發服務器（構建9.00.3282.00）上，生產服務器是建立9.00.3068.00

我已經去除了各種代碼從特效，試圖坐下來最小版本仍然存在問題，並且一直非常小心地保持SP的兩個版本除了那一個參數以外都是相同的。

我有很多其他SPs採取參數，他們確實運行良好。我還有DROP ped和re CREATE編輯SP。

任何想法？

是的，我有一個DBA看着它，我沒有SHOWPLAN或生產的任何有用的權利，看看是否有阻塞（如果一個人的計劃導致鎖升級我猜 - 再次，唯一的區別是參數）

我已經審查了所有的SQL Server構建信息，並沒有看到有關這個的已知問題，所以直到我弄明白或者DBA將其計算出來時，我有點卡住了。

UPDATE

這也未能完成（這實際上是對這些SP的正常形態 - 我只是把默認的，使其更容易在測試過程中來回切換）

ALTER PROCEDURE [usp_debug_fails] 
    @DATA_DT_ID AS int 
WITH RECOMPILE 
AS 
BEGIN 
    /* 
     Usage: 
     EXEC [usp_debug_fails] 20081130 WITH RECOMPILE 
    */ 
    -- Stuff here that depends on DATA_DT_ID 
END

然而這一個完成（其可能工作作爲一種解決方法，雖然我對這些SP的25修改其全部具有相同的形式）：

ALTER PROCEDURE [usp_debug_fails] 
    @DATA_DT_ID_in AS int 
WITH RECOMPILE 
AS 
BEGIN 
    /* 
     Usage: 
     EXEC [usp_debug_fails] 20081130 WITH RECOMPILE 
    */ 

    DECLARE @DATA_DT_ID AS int 
    SET @DATA_DT_ID = @DATA_DT_ID_in 
    -- Stuff here that depends on DATA_DT_ID 
END

來源

2008-12-18 Cade Roux

不要緊，默認值是什麼？你可以去掉代碼並逐個添加它以查看它何時鎖定？ – n8wrl 2008-12-18 19:59:08

嘗試屏蔽輸入參數。

我猜重編譯不工作，因爲指定的默認值（編輯：或在第一次調用發送的參數）在編譯時被嗅探。所以，重新編譯沒有效果。

我已經看到估計計劃之間的巨大差異，只需將默認值從說，零到NULL，或沒有一個。

ALTER PROCEDURE [usp_debug_mightwork] 
    @DATA_DT_ID AS int = 20081130 
AS 
BEGIN 
    DECLARE @IDATA_DT_ID AS int 
    SET @IDATA_DT_ID = @DATA_DT_ID 
    -- Stuff here that depends on IDATA_DT_ID 
END

我認爲this article解釋...

...參數值時編譯或重新編譯聞...

編輯：

New link on query plans and parameters。它仍然是參數嗅探是否指定了默認值。

上的GetRecentSales存儲過程指定WITH RECOMPILE選項上面並沒有消除基數估計誤差

來源

2008-12-18 20:06:30 gbn

參數遮罩似乎正常。但是，默認情況似乎不是主要原因 - 我已經用迄今已知的內容更新了我的問題。 – 2008-12-18 20:32:36

添加更多鏈接 – gbn 2008-12-19 04:58:52

防止嗅探參數，或者你是敬酒時統計變化。我有500+ SPS和所有的人都開始：

DECLARE @_Param1 ..., @_ParamN

--- prevent pameter sniffing
SELECT @_Param1 = @Param1, @_ParamN = @ParamN

來源

2008-12-20 15:12:40 wqw

已知問題？：SQL Server 2005的存儲過程失敗，出現一個參數

回答

相關問題