我的任務是調查現有ETL的超時錯誤。我想訪問以前ETL運行的日誌以確定發生超時的位置。 ETL位於Azure上，一個任務保持失敗。SQL Server調查超時錯誤
保持失敗的任務有效地啓動SQL Server上的存儲過程。我想知道是否可以使用一些日誌和統計數據來做我的調查。我知道存儲過程中使用的表，所以這將有希望給我一個起點。但基本上我是在收到以下信息。
什麼表的超時發生
是什麼原因導致超時，即它是一個死鎖
什麼其他進程即存儲過程中使用受影響的表。
我可以在SQL Server中使用哪些功能來進行挖掘。任何幫助，將不勝感激。
，保持失敗的任務，有效地揭開序幕的存儲過程SQL Server上
我建議微調此程序並嘗試更新爲參與這一procedure.This表應該照顧統計大多數超時的..
什麼表出來的時候發生
療法Ë應在蔚藍的日誌分析中記錄錯誤
是什麼原因導致的超時時間，即它是一個僵局
超時不是死鎖
大多數超時的原因與表現不佳的程序/查詢。在我們的案例中，我們能夠通過調整所涉及的查詢並改變超時設置來克服這個問題。
Sharingan，
存儲過程中的步驟不會導致超時。調用SP的客戶端有一個超時值，如果SP花費的時間比它長，它就會「認爲」有問題。這並不意味着你的SP架構錯誤，或者它實際上失敗了。
一種方法是創建一個日誌表，並在存儲過程中，在開始時從該表中刪除所有行（每次運行SP時都會清除一個TEMP表）。然後在該過程的每一步之前，在日誌表中插入一行，如'正在啓動員工ETL ...'，以及'完成的員工ETL ...'步驟之後。
您還可以檢查每個步驟後是否發生錯誤，並將錯誤消息寫入此表。這有效地成爲您自己的日誌。
IF @@ERROR <> 0
BEGIN
-- Add Error_Message to your table
END
如果調用進程沒有正確設置超時值，你可能會看到SP實際完成（通過檢查你的日誌），但客戶端錯誤地認爲什麼是錯的，因爲超時值已超過。客戶端的超時錯誤不會阻止SQL Server繼續工作。
您可以嘗試從SSMS自行運行存儲過程，例如？如果這種方法有效，那麼您就可以追蹤問題了，但區分它是SQL還是客戶端，比如Azure Logic應用程序，或者啓動ETL過程的任何東西都很重要。您可能需要編譯/模擬傳遞到SP中的任何參數，但在SSMS中應該很容易。
您也可以將一個大SP分成一組較小的SP，並向您的ETL客戶端添加更多步驟，而不是一個龐大的SP調用。這可能會迫使你實施瞬態錯誤處理，但在你的情況下這可能是可管理的。
祝你好運！