Azure SQL 上存储过程中的执行超时过期问题

Question

我在 Azure SQL 上执行存储过程时遇到问题。顺便说一句，程序很大，平均执行时间约为 30-40 秒。

有一个主数据库和一个副本。

我的 API 与副本数据库配合使用，除此之外，还有一些同步服务正在将其他数据源的一些数据同步到该数据库。

问题是我在运行存储过程时有时会遇到超时。当我请求一些应该由同步服务触及的数据时，就会发生这种情况。另一方面，如果我从 API 代码将 SQL 作为原始 SQL 运行，则效果很好。

我很困惑为什么会发生这种情况，并且不知道如何继续，但我必须保持存储过程运行。

有什么想法可以解决超时问题吗？

更新： 仅当我尝试获取最后一天的数据时，才会出现此问题。 例如，昨天存储过程的调用停留在日期上：

declare
    @stratDate datetime2 = '2023-11-14 00:00',
    @endDate datetime2 = '2023-11-15 23:59:59'
exec procedure_name @stratDate, @endDate

但是今天工作正常，并且日期也有同样的问题：

    @stratDate datetime2 = '2023-11-15 00:00',
    @endDate datetime2 = '2023-11-16 23:59:59'

如果我将今天的日期范围延长到 2 天，我将获得数据而不会出现任何问题

    @stratDate datetime2 = '2023-11-14 00:00',
    @endDate datetime2 = '2023-11-16 23:59:59'

再次强调，不带过程的原始 SQL 查询始终在任何日期都有效。

Answer 1

尝试增加连接字符串的超时并确保实现重试逻辑。

请确保主副本和辅助副本具有相同的服务级别。在辅助节点上执行以下查询，以确定辅助节点是否具有较高的资源利用率，如果是这种情况，请尝试扩展辅助节点上的服务层。

SELECT * FROM sys.dm_db_resource_stats ORDER BY end_time DESC;

使用下面的脚本来确定查询等待时间，并查看两个区域之间的等待时间有何差异。

DROP TABLE IF EXISTS #before;

 SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms],
        [signal_wait_time_ms]
 INTO #before
 FROM sys.[dm_db_wait_stats];

 -- Execute test query here

 SELECT *
 FROM [dbo].[YourTestQuery]

  -- Finish test query

DROP TABLE IF EXISTS #after;

 SELECT [wait_type], [waiting_tasks_count], [wait_time_ms], [max_wait_time_ms],
        [signal_wait_time_ms]
 INTO #after
 FROM sys.[dm_db_wait_stats];

 -- Show accumulated wait time

 SELECT [a].[wait_type], ([a].[wait_time_ms] - [b].[wait_time_ms]) AS [wait_time]
 FROM [#after] AS [a]
 INNER JOIN [#before] AS [b] ON
  [a].[wait_type] = [b].[wait_type]
 ORDER BY ([a].[wait_time_ms] - [b].[wait_time_ms]) DESC;

如果您在辅助副本上看到名为 ASYNC_NETWORK_IO 的普遍等待，则可能是因为将结果集发送到其他区域时出现网络延迟。

我们为您提供的建议可能看起来很原始，但事实是查询存储在 Azure 异地复制配置的辅助副本上不可用，因为辅助副本是只读的，而查询存储需要对数据库的写入访问权限。不过，您还可以使用 Azure 门户中的 Query Performance Insight 功能来分析辅助副本的查询性能。