0

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

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

  1. 超时发生在哪个表

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

  3. 其他哪些进程（即存储过程）使用受影响的表。

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

4

2 回答 2

0

写轮眼，

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

一种方法是创建一个日志记录表，并在您的存储过程中，在开始时从该表中删除所有行（这是一个每次运行 SP 时都会清除的 TEMP 表）。然后在该过程的每个步骤之前，在您的日志记录表中插入一行，其中包含“正在启动员工 ETL...”，并在“已完成员工 ETL...”步骤之后。

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

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

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

例如，您可以尝试从 SSMS 自行运行存储过程吗？如果这可行，您就可以追踪问题，但重要的是区分它是 SQL，还是您的客户端（如 Azure 逻辑应用程序），或者任何启动 ETL 过程的东西。您可能需要制造/模拟传递给 SP 的任何参数，但这在 SSMS 中应该很容易。

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

祝你好运！

于 2017-11-10T18:29:15.823 回答
0

不断失败的任务有效地启动了 SQL Server 上的存储过程

我建议微调此过程并尝试更新此过程中涉及的表的统计信息。这应该可以解决大多数超时问题。

超时发生在哪个表

azure log analytics 中应该记录错误

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

超时不是死锁

超时的大多数原因与执行不良的过程/查询有关。在我们的例子中，我们可以通过调整所涉及的查询并更改超时设置来克服超时

于 2017-10-19T10:22:23.200 回答