损坏的 Azure SQL 存储过程只能通过 drop recreate 来修复

Question

如果这是重复的，请原谅我。我能找到的最接近的是Random timeout running a stored proc - drop recreate fixes，但我不确定那里关于重新编译存储过程的答案是否适用。

我有一个最新版本的 Azure SQL 数据库，它有大量来自 Azure Web 应用程序前端的流量。我有一个夜间远程作业，它运行批处理以在 Azure SQL 数据库上重建索引，因为这似乎对控制数据库大小和性能有很大帮助。

通常，重建索引大约需要 20 分钟。昨晚2小时后超时。该批次中的错误处理程序没有记录任何错误。

重建索引开始后不久，一个特定的存储过程开始对每个调用它的客户端超时。使用相同表的其他存储过程没有任何问题。当我发现问题时，我可以通过将存储过程更改为立即返回来缓解所有超时和挂起的进程。当我再次更改存储过程以使其正常运行时，问题立即再次出现。我的理解是更改存储过程会迫使它重新编译，但这并没有解决它。

最终，我完全放弃并使用原始代码重新创建了该过程，问题得到了解决。

这个过程和它使用的架构已经完全稳定了好几个月。程序本身非常简单：

CREATE Procedure [dbo].[uspActivityGet] (@databaseid uniqueidentifier) AS
begin
    SET NOCOUNT ON;
    --There may be writing activities to the table asynchronously, do not use nolock on tblActivity - the ActivityBlob might be null in a dirty read.
    select top 100 a.Id, h.HandsetNumber, a.ActivityBlob, a.ActivityReceived
    from dbo.tblDatabases d with(nolock) join dbo.tblHandsets h with(nolock) on d.DatabaseId = h.DatabaseId join dbo.tblActivity a on h.Id = a.HandsetId
    where d.DatabaseId = @databaseid and a.ActivitySent is null
    order by a.ActivityReceived
end

虽然程序会挂起并出现类似这样的超时：

exec dbo.uspActivityGet 'AF3EA01B-DB22-4A39-9E1C-D096D2DF1215'

在查询窗口中运行相同的选择会迅速成功地返回：

declare @databaseid uniqueidentifier; set @databaseid = 'AF3EA01B-DB22-4A39-9E1C-D096D2DF1215'
select top 100 a.Id, h.HandsetNumber, a.ActivityBlob, a.ActivityReceived
from dbo.tblDatabases d with(nolock) join dbo.tblHandsets h with(nolock) on d.DatabaseId = h.DatabaseId join dbo.tblActivity a on h.Id = a.HandsetId
where d.DatabaseId = @databaseid and a.ActivitySent is null
order by a.ActivityReceived

有什么想法可以防止这种情况在未来发生吗？谢谢。

编辑 - 添加执行计划截图

编辑 - 添加用于查看正在运行的进程的查询。有很多，猜测大约有 150 个，处于挂起状态，它们都用于同一个存储过程 - uspActivityGet。此外，Data IO Percentage 在高峰需求时间通常运行 20 - 40% 时一直处于最大值。我不记得等待类型是什么。这是用于查看的查询。

select * from sys.dm_Exec_requests r with(nolock) CROSS APPLY sys.dm_exec_sql_text(r.sql_handle)  order by r.total_elapsed_time desc

编辑 - 今晚又发生了。这是问题期间相同过程的执行计划。再次删除并创建过程后，执行计划恢复正常，问题得到解决。

在问题期间，执行相同查询的 sp_executesql 大约需要 5 分钟，我相信这代表了正在发生的事情。大约有 50 个 uspActivityGet 实例因等待类型 SLEEP_TASK 或 IO_QUEUE_LIMIT 而暂停。

也许下一个问题是为什么索引重建或其他夜间维护会对执行计划执行此操作？

Answer 1

线索在查询和麻烦的执行计划中。见Poor Performance with Parallelism and Top

正常的执行计划似乎非常有效，只要相关架构没有改变，就不需要重新编译。我还想避免此查询中的并行性。我在查询中添加了以下两个选项，以确保这两点都得到保证，一切都再次得到满足。

OPTION (KEEPFIXED PLAN, MAXDOP 1)