重建索引任務中斷存儲過程的調用

我有一個維護計劃，每天早上營業時間之前在我的SQL Server 2008服務器上運行。它幾年前已經實施，以幫助解決一些性能問題。我看到的問題是，在重建索引完成之後，其中一個數據庫中將存在一個存儲過程，它將從運行9秒運行到運行7分鐘。重建索引任務中斷存儲過程的調用

的解決方案，我已經找到解決它是打開SQL Management Studio並運行：

EXEC sp_recompile N'stored_proc_name'; 
EXEC stored_prod_name @userId=579

我運行之後，SP自我修復，並回到下9秒運行。

我已經嘗試了幾種不同的路徑來自動執行此操作，但它只會在我通過管理工作室從計算機運行它時才起作用。我嘗試將它包裝在一個C＃可執行文件中，該文件在重建索引作業完成後運行了幾分鐘，但沒有奏效。在重建索引作業完成後，我也嘗試創建一個SQL作業以在服務器上運行它，但那也不起作用。它必須從管理工作室運行。

於是，兩個問題：

我怎樣才能阻止打破我的SP重建索引，或者，
如何或爲何我的速戰速決只會在非常特殊的情況下工作任何想法？

謝謝，邁克

來源

2014-06-09 Mike

您是經過快速修復還是經過更徹底的解決方案之後？您應該調整proc以避免計劃問題。有一些常見的解決方案，比如'OPTION（RECOMPILE）'和'OPTIMIZE FOR UNKNOWN'。 – usr

實際上，這並不是說「重建索引」任務是打破存儲過程。正是它導致查詢計劃緩存失效，並且在此之後，一個新的查詢計劃變得緩存了偏差數據，導致大部分工作使用了次優查詢計劃。 –

這聽起來像是標準參數嗅探/基於參數的查詢計劃緩存。這裏的訣竅通常是使用OPTIMIZE FOR/UNKNOWN提示 - 無論是導致問題的特定參數，還是僅用於所有參數。這使得分佈偏差的參數值不太可能對系統的其他值產生負面影響。一個更極端的選項（在使用命令文本時更有用，在使用存儲過程時不太有用）是將值直接嵌入到TSQL中，而不是使用參數。這...有影響，但是，應該謹慎使用。

在你的情況，我懷疑，並說：

OPTION (OPTIMIZE FOR (@userId UNKNOWN))

到您的查詢的結束將修復它。

來源

2014-06-09 18:02:30

重建索引任務中斷存儲過程的調用

回答

相關問題