我的任务是调查现有ETL的超时错误。我想访问以前ETL运行的日志，以确定超时发生的位置。ETL位于Azure上，一项任务不断失败。
不断失败的任务有效地启动了SQL Server上的存储过程。我想知道我是否有可能使用一些日志和统计数据来进行调查。我知道存储过程中使用的表，所以希望这能给我一个起点。但本质上，我是在寻找以下信息。
-
超时发生在哪个表
-
是什么原因导致超时，即是否死锁
-
哪些其他进程(即存储过程)使用受影响的表。
我可以在SQL Server中使用哪些功能来进行挖掘。如有任何帮助，我们将不胜感激。
不断失败的任务有效地启动了SQL Server 上的存储过程
我建议对该过程进行微调，并尝试更新该过程中涉及的表的统计信息。这应该可以解决大部分的超时问题。。
发生超时的表格
azure日志分析中应该记录错误
是什么导致超时，即它是死锁吗
超时不是死锁
超时的大多数原因与执行过程/查询不力有关。。在我们的案例中，我们可以通过调整所涉及的查询并更改超时设置来度过这个超时
Sharingan，
存储过程中的步骤不会导致超时。调用SP的客户端有一个超时值，如果SP花费的时间超过这个值，它就会"认为"出了问题。这并不意味着SP的体系结构错误，也不意味着它实际上发生了故障。
一种方法是创建一个日志记录表，并在存储过程中，在开始时从该表中删除所有行(这是一个TEMP表，每次SP运行时都会清除)。然后，在该过程的每个步骤之前，在日志记录表中插入一行类似于"Starting employee ETL…"的内容，以及在步骤"Completed Employee 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调用。这可能会迫使您实现瞬态错误处理，但在您的情况下这可能是可以管理的。
祝你好运！