KB4338890 - 修复:SQL Server 2014、2016 和 2017 中出现“未生成计划程序”错误和SQL Server无响应

应用对象
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

症状

假设已安装 Microsoft SQL Server 2014、2016 或 2017。  可能会遇到以下一个或多个问题:

  • SQL Server 实例无响应,并出现“未生成计划程序”错误。 可能需要重启服务器才能恢复。
  • 事务回滚可能需要很长时间才能完成。 在大多数情况下,重启实例将使数据库恢复的速度比回滚快得多。 请注意,回滚可能需要很长时间才能完成的原因有很多,请参阅下面的“详细信息”部分,了解有关在尝试重启之前监视回滚的详细信息。
  • 你可能会在旋转锁(如SOS_OBJECT_STORE)上看到高等待时间。

解决方法

此问题在以下SQL Server累积更新中已修复:

2017 SQL Server累积更新 9

SQL Server 2016 SP2 的累积更新 2

关于SQL Server的累积更新:

SQL Server的每个新累积更新都包含以前的累积更新中包含的所有修补程序和所有安全修补程序。 查看SQL Server的最新累积更新:

SQL Server 2017 的最新累计更新

SQL Server 2016 年的最新累积更新

SQL Server 2014 年的最新累积更新

SQL Server的 Service Pack 信息

以下 Service Pack 中修复了此更新,适用于SQL Server:

Service Pack 3 for SQL Server 2014

关于SQL Server的 Service Pack:

Service Pack 具有累积性。 每个新 Service Pack 除了包含所有新修复程序外,还包含以前 Service Pack 中的所有修复程序。 建议为该服务包应用最新的 Service Pack 和最新的累积更新。 在安装最新的 Service Pack 之前,不需要安装以前的 Service Pack。 使用以下文章中的表 1 查找有关最新 Service Pack 和最新累积更新的详细信息。

如何确定SQL Server及其组件的版本、版本和更新级别

详细信息

回滚可能需要很长时间的原因有很多,例如长时间运行的事务、事务日志文件中的大量 VLF、I/O 速度缓慢等。为了验证本文中所述的问题是否是回滚速度缓慢的根本原因,我们建议使用以下技术来监视回滚操作的进度:

  • sys.dm_exec_requests中,确定其命令设置为“KILLED/ROLLBACK”的session_id,并确保会话正在累积 IO 和 CPU 时间,指示进度。 如果 IO 未更改,则可能表明你遇到了本文中所述的问题。
  • 查询 sys.dm_tran_database_transactions ,以使用如下所示的查询标识回滚的当前状态:

注意

  • SELECT 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)
  • FROM sys.dm_tran_database_transactions t
  • JOIN sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id ('<数据库名称') ,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 处理的 LSN 的增量,并推断所花费的时间,以估计 database_transaction_next_undo_lsn 到达 database_transaction_begin_lsn所需的时间。

如果回滚在每个快照之间以体面的速度进行,我们建议允许回滚自行完成,而无需重启SQL Server实例。

有关长时间运行的恢复的详细信息,请参阅以下文章:

状态

Microsoft 已确认在 "适用于" 部分中所列的 Microsoft 产品中存在问题。

参考资料

了解 Microsoft 用于描述软件更新的术语