從Service Broker激活時的存儲過程緩慢

我已經編寫了一個存儲過程，它在從Management Studio執行時需要15分鐘。然而，當它從Service Broker啓動時，在4小時之後，它甚至沒有完成其一半的工作。從Service Broker激活時的存儲過程緩慢

從Service Broker運行SP時是否存在已知的性能問題？（也許Service Broker的運行事務中的SP和管理工作室不？）

我使用的是SQL Server 2005中

更新：

它出現的問題是執行一個存儲程序從另一個存儲過程。更具體地說，我有一個接收操作（導出或刪除）的存儲過程。然後該SP根據操作調用相應的SP（一個具有ETL過程，另一個刪除數據）。強制重新編譯這些SP似乎已經解決了這個問題。我想知道SQL Server是否應該爲每個子SP制定一個行動計劃，但獨立於調用它們的SP。在那種情況下，不需要重新編譯。

來源

2010-11-11 noup

請提供更多信息（例如程序的作用等） – 2010-11-15 20:05:28

我不知道Service Broker，但是對於一般的存儲過程故障排除，請查看this question給出的建議。他們幫助我解決了存儲過程中的一些問題。

您可以查看存儲過程在WhoIsActive例程中執行的操作，您可以獲取查詢計劃並研究在Management Studio中執行時是否與查詢計劃有任何區別，您可以嘗試使用OPTIMIZE FOR提示根除參數嗅探...

（參數嗅探是指提供其他參數時生成的查詢計劃不同。Service Broker是否將相同的參數傳遞到您在SP中傳遞的參數？）

祝您好運，如果您不成功，請在此發佈您的發現。

來源

2010-11-11 23:24:02 thomaspaulb

無所事事，程序也從Service Broker開始快速運行。我不知道（自動）更改是如何引起的。 Management Studio中的參數相同。無法讓WhoIsActive返回任何內容，但Who和Who2會返回結果。 – noup 2010-11-12 15:34:09

是的，我的SP也放慢了速度，然後快速「無中生有」。然後在一個月內，再次出現同樣緩慢的行爲。這很煩人，而且我還沒有把所有原因固定下來，但至少現在我現在可以開始尋找 - 而且你也是。我想知道你將來遇到這樣的問題時的經歷，我們可以互相學習。在這裏放下一行。 – thomaspaulb 2010-11-23 10:46:26

再次發生，這次用手動運行需要9秒的查詢。一些說明：我沒有使用交易;該進程在sp_who2中具有「後臺」狀態;正如我的更新中提到的那樣，我有一個SP1多次調用SP2（每次導出都需要完成） - 這次第三次調用SP2時出現緩慢。 – noup 2010-11-23 18:20:31

從Service Broker激活時的存儲過程緩慢

回答

相關問題