在 Azure 逻辑应用中执行存储过程失败并出现网关超时

Posted 2023-02-19

【中文标题】在 Azure 逻辑应用中执行存储过程失败并出现网关超时

【英文标题】：Execute stored procedure within Azure Logic App fails with Gateway Timeout

【发布时间】：2018-03-26 23:48:09

【问题描述】：

我一直在尝试开发一个 Azure 逻辑应用程序，它可以从 FTP 服务器导入文件，并使用 Azure SQL 服务中的存储过程来解析内容。

目前我一直在努力从逻辑应用程序执行这个存储过程；存储过程最多可能需要 10 分钟才能执行。

我一直在尝试一些解决方案，在 Azure Logic App 中设置 Execute Stored Procedure 操作： - 添加执行存储过程作为异步超时 (PT1H) 的操作 - 用一个检查返回码的 do-until 循环包围它。

这些解决方案似乎都不能解决问题。在开发此 Azure 逻辑应用程序时，还有其他我可以尝试的吗？

【参考方案1】：

如果你可以通过减少JOIN下表中的数据负载来减少SP的时间，那么你可以使用分页来实现通过Logic App的成功执行。

例如，假设您有一个像sp_UpdateAColumn 这样的存储过程，它根据tableB 和tableC 和tableD 的JOIN 更新tableA 上的列

现在这确实运行了，但需要 2 多分钟才能完成，因为 tableA 中有大量行。

您可以通过说在 tableA 上创建一个新列 isUpdated 来减少此 SP 的时间，即布尔值，默认值为 =0

那么如果你使用

SELECT TOP 100 * FROM tableA WHERE isUpdated =0

而不是整个 tableA 在 JOIN 那么您应该能够在两分钟内更新 100 行。

因此，如果您将 SP 的定义从 sp_UpdateAColumn 更改为 sp_UpdateAColumnSomeRows(pageSize int) 然后在这个 SP 中，您需要做的就是在使用 TableA 的 JOIN 中使用 (SELECT TOP (SELECT pageSize ) * FROM tableA WHERE isUpdated =0) 代替。

现在您需要确保调用此新 SP 的次数足以处理所有记录，为此您需要在逻辑应用程序中使用 do-until 循环（用于 TableA/pazeSize 次中的总行数）并在里面调用您的 SP这个循环。

尝试调整 PageSize 参数以找到最佳分页大小。