SQL Server调查超时错误

Question

我的任务是调查现有ETL的超时错误。我想访问先前ETL运行的日志以确定超时发生的位置。 ETL位于Azure上，一项任务仍然失败。

持续失败的任务，有效地启动SQL Server上的存储过程。我想知道我是否可以使用一些日志和统计数据来进行调查。我知道存储过程中使用的表，所以这有希望给我一个起点。但基本上我是在追求以下信息。

1. 出现超时的表格

2. 是什么导致超时，即它是一个死锁

3. 还有哪些进程，即存储过程使用受影响的表。

我可以在SQL Server中使用哪些功能来进行挖掘。任何帮助，将不胜感激。

Answer 1

  

持续失败的任务，有效地启动SQL Server上的存储过程

我建议微调这个程序，并尝试更新此程序中涉及的表的统计数据。这应该照顾大部分时间..

  

超时发生的表格

天蓝色日志分析中应记录错误

  

是什么导致超时，即它是一个死锁

超时不是僵局

超时的大部分原因都与执行不佳的程序/查询有关。在我们的案例中，我们可以通过调整所涉及的查询并更改超时设置来超过此时间

Answer 2

Sharingan，

存储过程中的步骤不会导致超时。调用SP的客户端具有超时值，如果SP花费的时间超过该值，则“认为”出现了错误。这并不意味着您的SP架构错误，或者它实际上失败了。

一种方法是创建一个日志表，并在存储过程中，在开头删除该表中的所有行（它是每次SP运行时清除的TEMP表）。然后在该过程的每个步骤之前，在您的日志记录表中插入一行，例如“Starting employee ETL ...”，然后在“Completed Employee ETL ...”步骤之后。

您还可以检查每个步骤后是否发生错误，并将错误消息写入此表。这有效地成为您自己的日志。

IF @@ERROR <> 0
BEGIN
   -- Add Error_Message to your table
END

如果调用进程没有正确设置超时值，您可能会看到SP实际上已完成（通过检查您的日志），但客户端错误地认为出现了错误，因为已超出超时值。客户端的超时错误不会阻止SQL Server继续工作。

例如，您可以尝试从SSMS单独运行存储过程吗？如果这样可以解决问题，那么区分它是SQL还是客户端（如Azure Logic App）或启动ETL过程的任何内容都很重要。您可能需要制作/模拟传递给SP的任何参数，但这在SSMS中应该很容易。

您还可以将一个大SP分解成一堆较小的SP，并向您的ETL客户端添加更多步骤，而不是一个巨大的SP调用。这可能会迫使您实施瞬态错误处理，但在您的情况下这可能是可以管理的。

祝你好运！