症状
假设已安装 Microsoft SQL Server 2014、2016或2017。 你可能会遇到以下一个或多个问题：
-
SQL Server 实例无响应，出现 "未生成计划程序" 错误。 您可能需要重新启动服务器才能恢复。
-
事务回退可能需要很长时间才能完成。 在大多数情况下，重新启动实例将使数据库恢复速度比回退快得多。 请注意，回滚可能需要很长时间才能完成的原因有很多，请参阅下面的 "更多信息" 部分，了解有关在尝试重启之前监视回退的详细信息。
-
你可能会在旋转锁（如 SOS_OBJECT_STORE）上看到高等待。
解决方案
在 SQL Server 的以下累积更新中修复了此问题：
SQL Server 的每个新的累积更新均包含以前的累积更新中包含的所有修补程序和所有安全修补程序。 查看 SQL Server 的最新累积更新：
SQL Server 的 Service pack 信息
此更新在 SQL Server 的以下 service pack 中已修复：
Service Pack 具有累积性。 每个新 Service Pack 除了包含所有新修复程序外，还包含以前 Service Pack 中的所有修复程序。 我们建议为该服务包应用最新的服务包和最新的累积更新。 在安装最新的 Service Pack 之前，不需要安装以前的 Service Pack。 使用以下文章中的表1查找有关最新服务包和最新累积更新的详细信息。
更多信息
回滚可能需要很长时间（如长时间运行的事务）的原因有多种，例如事务日志文件中的大量 VLFs、速度较慢的 i/o 等。 为了验证本文所述的问题是否是缓慢回退的根本原因，我们建议使用以下技术监视回退操作的进度：
-
从 sys.dm_exec_requests中，标识其命令设置为 "已终止/回滚" 的 session_id，并确保会话将累积 IO 和 CPU 时间来指示进度。 如果 IO 未更改，则可能表明你遇到了本文中所述的问题。
-
查询 sys.dm_tran_database_transactions 使用如下查询标识回退的当前状态：
选择 getdate （）作为 CurrentTime、database_transaction_next_undo_lsn、database_transaction_begin_lsn、t.transaction_id、database_transaction_begin_time、database_transaction_log_record_count、db_name （t.database_id）
从 sys.dm_tran_database_transactions t
加入 sys.dm_exec_requests s 在 t.transaction_id = s.transaction_id
其中 t.database_id = db_id （' <数据库 Name'）和 s.session_id =<Session_id执行回滚操作>
注意：
在上述查询中，
database_transaction_next_undo_lsn 是要撤消的下一条记录的 lsn。 database_transaction_begin_lsn 是事务日志中事务的开始记录的 lsn。
database_transaction_next_undo_lsn 应减少此查询的每个快照。 当 database_transaction_next_undo_lsn 达到 database_transaction_begin_lsn 时，回退将成功完成。
此处的目标是在预先确定的间隔内拍摄上一个查询的几个快照，然后使用该间隔内 database_transaction_next_undo_lsn 中处理的 LSNs 的增量，并推断所花费的时间，以便估计 database_transaction_next_undo_lsn 达到 database_transaction_begin_lsn所需的时间。
如果回滚在每个快照之间以相当的速率前进，我们建议允许回退自行完成，而无需重新启动 SQL Server 实例。
有关长时间运行的恢复的详细信息，请参阅以下文章：
状态
Microsoft 已确认这是在“适用范围”部分中列出的 Microsoft 产品存在的问题。
参考
了解 Microsoft 用于描述软件更新的 术语。
