症状
假设在 SQL Server 2017 中的 Linux 上配置了 Alwayson 可用性组（AG）功能。 使用 yum 命令将辅助副本更新到累积更新18（CU18）时，你会发现脚本升级可能失败，并出现以下错误消息：
DateTime SpidNum 无法在数据库 ' DatabaseName ' 中更新系统对象，因为它是只读的。
Datetime SpidNum CHECKDB for 数据库' DatabaseName '已完成，日期日期（本地时间）上没有错误。 这只是一条信息性消息;无需用户操作。
DateTime SpidNum升级数据库 [DatabaseName] 中的订阅设置和系统对象。
DateTime SpidNum无法更新数据库 "DatabaseName"，因为数据库是只读的。
DateTime SpidNum执行 sp_vupgrade_replication 时出错。
DateTime SpidNum将升级脚本状态保存到 "SOFTWARE\Microsoft\MSSQLServer\Replication\Setup"。
DateTime SpidNum保存升级脚本状态时出错。
DateTime SpidNum数据库"DatabaseName"正在将脚本 "upgrade_ucp_cmdw_discovery" 从 level LevelNum升级到 level LevelNum。
DateTime SpidNum数据库"DatabaseName"正在将脚本 "msdb110_upgrade" 从 level LevelNum升级到 level LevelNum。
DateTime SpidNum开始执行 PRE_MSDB。SQL
DateTime SpidNum错误：3930，严重性：16，状态：1。
DateTime SpidNum无法提交当前事务，并且无法支持写入日志文件的操作。 回退交易。
DateTime SpidNum错误：912，严重性：21，状态：2。
DateTime SpidNum数据库"DatabaseName"的脚本级别升级失败，因为升级步骤 "msdb110_upgrade" 遇到错误3930，状态1，严重级别为16。 这是一个很严重的错误情况，可能会干扰正常操作，数据库将脱机。 如果在升级"DatabaseName"数据库期间发生错误，它将阻止整个 SQL Server 实例启动。 检查以前的错误日志条目以查找错误，采取相应的纠正措施并重新启动数据库，以便脚本升级步骤运行完成。
DateTime SpidNum错误：3417，严重性：21，状态：3。
DateTime SpidNum无法恢复 master 数据库。 SQL Server 无法运行。 从完整备份还原 master，修复它，或重建它。 有关如何重建 master 数据库的详细信息，请参阅 SQL Server 联机丛书。
DateTime SpidNum由于服务器关闭，SQL 跟踪已停止。 跟踪 ID = "1"。 这只是一条信息性消息;无需用户操作。
状态
Microsoft 已经确认这是一个列于“适用范围”部分的 Microsoft 产品问题。
解决方案
在 SQL Server 的以下累积更新中修复了此问题：
关于 SQL Server 的累积更新：
SQL Server 的每个新的累积更新均包含以前的累积更新中包含的所有修补程序和所有安全修补程序。 查看 SQL Server 的最新累积更新：
参考
了解 Microsoft 用于描述软件更新的术语。
