-1

有一個生產問題,其中的一個存儲過程聲明花費過多時間 - 上平均需要15-20秒,但在當天的一個花了超過100秒。SQL Server 2012的存儲過程花費過多時間

它發生在上週,週一再次重複了這個星期太 - 週二。我們檢查了數據庫上的負載一切都是一致的,週一或週二沒有大量的數據。

同一個DB上的所有其他存儲過程按預期工作。但只有這個存儲過程觸及幾個額外的表需要太多的時間。重新索引後,只有它恢復正常。此存儲過程在內部調用其他幾個存儲過程和函數。

什麼可能是錯的?

它不能被什麼東西給網絡的影響只在一個存儲過程有關。

它不可能是什麼關係數據庫負載或CPU利用率的影響只在一個存儲過程。

有它只能運行在週一週二或沒有計劃的作業。

+0

這聽起來像你需要更多的信息。我建議使用SQL事件探查器來運行跟蹤,以查看在遇到性能問題時是否可以確定發生了什麼。 –

+0

是的執行計劃將提供重要信息,以查看造成瓶頸的原因。如果你分享我可以幫助審查。 –

回答

0

我想看看活動看看什麼進程正在大多數CPU和使用SQL事件探查器查看資源的查詢多少花費。既然您確定存儲過程需要太多的CPU,那麼您必須檢查查詢的執行方式。
在查詢分析器中,啓用顯示實際執行計劃。這是我將檢查如何執行查詢,是否使用索引或表掃描,排序算法等。它顯示哪些功能消耗最多的CPU。如果它是讀取查詢,我將檢查這些表並查看錶內部是如何分割的以及檢索數據需要多少次傳遞。如果是寫查詢,那麼我將檢查行/表鎖和日誌。如果將恢復模式從簡單更改爲完整,寫入操作可能需要相當長的時間。
如果您已經完成了執行計劃,請在此處使用存儲過程粘貼執行圖片,以便我可以看到實際放慢執行的情況。
通過更改您的SQL查詢,索引,查詢提示和表分區來修復它們。