我的任务是调查现有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调用。这可能会迫使你实施瞬态错误处理，但在你的情况下这可能是可管理的。
祝你好运！