提问人：Spring Elk 提问时间：11/16/2023 最后编辑：Spring Elk 更新时间：11/17/2023 访问量：80
Azure SQL 上的存储过程中的执行超时过期问题
Execution timeout expired issue in a stored procedure on Azure SQL
问：
我在 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 查询始终在任何日期都有效。
答：
1赞
Alberto Morillo
11/17/2023
#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 门户中的“查询性能见解”功能来分析次要副本的查询性能。
评论