1

我创建了一个存储过程,它发送一封电子邮件,并意外地在其内部调用了存储过程,从而创建了一个无限循环。在执行存储过程的几秒钟内,我意识到我做了什么并修复了循环,但它已经创建了 517 个进程。我杀死了所有的 SPID,但它们陷入了 KILLED/ROLLBACK 状态。

这段代码向我展示了这些过程:

select session_id,handle.percent_complete, *
from sys.dm_exec_requests handle   
outer apply sys.fn_get_sql(handle.sql_handle) spname
where cast(handle.start_time as date) = '2022-01-10' 

spname.text 显示所有 SPID 的“xp_sysmail_format_query”。两天过去了,517个进程全部卡在这个回滚状态,进度为0%。我们仍然可以使用我们所有的业务应用程序并执行查询,除了EXEC msdb.dbo.sp_send_dbmail在启动测试电子邮件时,执行卡住并且必须取消。这不好,因为不会发送任何自动生成的电子邮件警告,并且所有其他 sql 电子邮件功能都被阻止。我不确定目前还有哪些其他工作被阻止。

这是一个大问题,我找不到解决方案。我已经阅读了所有我能找到的关于这个的帖子。除了重新启动 SQL 服务器之外,我已经尝试了所有我能想到的方法。一些帖子指出重新启动 SQL 服务器可以解决此问题,而某些状态不重新启动它,或者任务将在重新启动时恢复到终止/回滚状态。我尝试使用 statusonly 再次杀死 spid,但这只是告诉我它们处于完成 0% 的回滚状态。

我应该重新启动服务器,这会解决任何问题吗?除了将数据库恢复到超过 2 天的备份并丢失整个企业在过去几天所做的所有工作之外,还有其他解决方案吗?

任何帮助将不胜感激。

4

1 回答 1

1

尽管它很健壮,但有时(幸运的是很少)SQL Server 在终止进程时让我们别无选择,以采用 IT 口头禅,即在回滚未及时完成时再次将其关闭。

当交易使用外部方法或函数时,这可能会更加普遍,尤其是电子邮件因此而臭名昭著。

尽管它不受欢迎,但它通常是时间上最便宜的,当低垂的水果选择用尽时,应该尽快在诊断过程中考虑一个选择。

于 2022-01-17T15:14:34.393 回答