本文可帮助你排查和解决 SQL Server 的累积更新(CU)或 Service Pack(SP)在执行数据库升级脚本时报告错误 574 的问题。
现象
应用 CU 或 SP 时,安装程序可能会报告以下错误:
等待数据库引擎恢复句柄失败。 有关可能的原因,请查看 SQL Server 错误日志。
查看 SQL Server 错误日志时,可能会注意到以下错误消息:
Error: 574, Severity: 16, State: 0.
CONFIG statement cannot be used inside a user transaction.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'sqlagent100_msdb_upgrade.sql' encountered error 574, state 0, severity 16.
This is a serious error condition which might interfere with regular operation and the database will be taken offline.
If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting.
Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 3417, Severity: 21, State: 3.
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 15173, state 1, severity 16
原因
更新过程可能会在事务中运行一些升级脚本。 这些更新脚本的设计假设是用户不会更改系统对象和关联的权限。 如果无意中对系统对象或权限进行任何更改,其中一些脚本可能会失败,并且关联的事务可能成为孤立事务并保持打开状态。 在此方案中,当安装程序稍后执行用于 sp_configure
设置某些配置值的升级脚本时,会发生错误 574。 设置失败的实际原因应通过查看错误 574 之前记录的条目来确定。
例如,如下所示的脚本可能会导致错误 574:
BEGIN TRAN
USE MASTER;
GO
EXEC sp_configure 'recovery interval', '4';
RECONFIGURE WITH OVERRIDE;
COMMIT TRAN
解决方法
若要解决此问题,请执行以下步骤:
使用 跟踪标志 902 启动 SQL Server。 有关详细信息,请参阅 使用跟踪标志 902 启动 SQL Server 的步骤。
打开 SQL Server 错误日志并查看错误 574 之前的消息以标识失败的事务(请参阅以下示例 模式)。
根据“潜在原因和解决方案”部分中的信息修复失败的事务。
从 启动参数 项中删除跟踪标志 902 并重启 SQL Server。
SQL Server 启动且没有跟踪标志 902 后,将再次执行升级脚本。
- 如果 SP/CU 升级脚本成功完成,可以检查 SQL Server 错误日志和启动文件夹以验证。
- 如果升级脚本再次失败,请检查 SQL Server 错误日志中是否存在其他错误,并排查新错误。
示例模式:向系统角色授予权限时出现问题
2020-08-17 09:38:12.09 spid11s Adding user 'hostname\svc_sqlagent' to SQLAgentUserRole msdb role...
2020-08-17 09:38:12.09 spid11s
2020-08-17 09:38:12.09 spid11s Granting login access'##MS_SSISServerCleanupJobLogin##' to msdb database...
2020-08-17 09:38:12.10 spid11s A problem was encountered granting access to MSDB database for login '(null)'. Make sure this login is provisioned with SQLServer and rerun sqlagent_msdb_upgrade.sql
2020-08-17 09:38:12.10 spid11s A problem was encountered granting access to MSDB database for login '(null)'. Make sure this login is provisioned with SQLServer and rerun sqlagent_msdb_upgrade.sql
2020-08-17 09:38:12.10 spid11s
2020-08-17 09:38:12.10 spid11s Adding user '##MS_SSISServerCleanupJobLogin##' to SQLAgentUserRole msdb role...
潜在原因和解决方案
用户选项会导致事务失败。
解决方案:连接到 SQL Server,使用 用户选项 服务器配置选项文档确定可能导致问题的选项,并删除冲突的设置。
例如,Microsoft支持已看到IMPLICIT_TRANSACTIONS设置导致设置失败的实例。 或者,如果无法识别冲突的用户选项,请使用 SQL Server Management Studio (SSMS) 中的以下脚本删除所有用户选项:
EXEC sp_configure 'user options', '0' GO RECONFIGURE WITH OVERRIDE; GO
孤立用户导致事务失败。
解决方案:使用以下查询检查孤立用户:
SELECT dp.type_desc, dp.SID, dp.name AS user_name FROM sys.database_principals AS dp LEFT JOIN sys.server_principals AS sp ON dp.SID = sp.SID WHERE sp.SID IS NULL AND authentication_type_desc = 'INSTANCE';
有关如何解决孤立用户的详细信息,请参阅“孤立用户疑难解答”(SQL Server)。
孤立作业导致事务失败。
解决方案:使用以下查询检查孤立作业:
SELECT sj.name AS Job_Name, sl.name AS Job_Owner FROM msdb.dbo.sysjobs_view sj LEFT JOIN master.dbo.syslogins sl ON sj.owner_sid = sl.sid WHERE sl.name <> 'sa' ORDER BY sj.name
此处显示 NULL 值的任何记录都表示适用的代理作业的所有者是孤立的。 编辑作业并将所有者更改为有效的登录名。