标签: patching

微软昨天发布了SQL Server 2017 CU10 KB4342123 (14.0.3037.1)。我尝试查看包含的修补程序列表，但没有看到任何对最近发布的远程代码执行漏洞修补程序KB4293805 CVE-2018-8273 (14.0.3035.2)安全更新的引用。

我们如何确定 SQL Server 2017 CU10 是否包含安全修补程序 KB4293805 CVE-2018-8273？

CU10 的更高版本号是否足以确定这一点？

注意：我已经在 CU9 上安装了 CVE-2018-8273 修复程序。

我的大多数 SQL Server 都使用 2016 SP2。安全小组已确定我需要应用更高版本的安全更新，由于今年 SP2 不再受支持，我计划将其修补到 SP3。

问题是我从未真正修补过 SQL Server，并且想知道应用该服务包时应遵循什么好的流程。我在网上看到了一些，大致相同，但只是需要一些关于最佳方法的意见。

通过在线查看这些流程，我遇到的一些问题是：

• 我假设 SQL Server 实例需要重新启动。这是安装补丁时自动完成的吗？
• 是否需要停止实例上的所有活动？即，是否需要关闭与实例通信的所有应用程序服务？
• SQL 代理也应该停止吗？

场景：SQL Server 2014 CU6。1 个 AG 与 2 个数据库（兼容性级别 100）。Windows Server 2012 R2 上具有 3 个节点的故障转移群集。节点 1 和节点 2 上的主要可用性副本。节点 3 上的次要可用性副本（无投票）。异步提交、手动故障转移、可读辅助。节点 3 用于在这 2 个数据库上运行报告（在节点 1 和 2 的 AG 外部运行的 8 个数据库中）。

问题：希望将这些从 SQL 2014 修补到 SP1 和最新的 CU。不是我的构建，到目前为止还没有使用 AG 或 FC 的经验。我的“测试”环境也用于开发，所以没有错误的余地。

问题：

修补 3 个节点的最佳顺序是什么？

我是否首先必须从我正在修补的节点上的 AG 中删除数据库？

修补辅助节点时是否需要将其取出？

没有这方面的经验，我在文档中找不到明确的答案（可能不支持？）：https ://msdn.microsoft.com/en-us/library/dn178483( v=sql.120) .aspx

在对 sql server 2016 SP1 应用累积更新时，需要停止大量服务和应用程序才能继续进行更新。

其中包括虚拟机的核心，即 VMware Tools 核心服务。

停止此应用程序的所有实例以继续更新是否安全？

什么是安全的方法？

我们有一个 SQL Server：

Microsoft SQL Server 2017 (RTM-CU14-GDR) (KB4494352) - 14.0.3103.1 (X64) 2019 年 3 月 22 日 22:33:11 Windows Server 2016 Datacenter 10.0 上的企业版（64 位）（内部版本 14393：）（虚拟机管理程序）

尝试安装“SQL Server 2017 累积更新包 18 - KB4527377” https://www.microsoft.com/en-us/download/details.aspx?id=56128

安装程序做了 15 分钟的事情，安装和更新文件，停止/启动服务，看起来会成功，但最后它显示：

需要采取的行动：

使用以下信息解决错误，然后再次尝试安装过程。

功能失败原因：

该功能的设置过程中发生错误。

错误详情：

安装 SQL Server 数据库引擎服务实例功能时出错
注册表中的用户日志目录无效。
验证实例配置单元下的 DefaultLog 键是否指向有效目录。
错误代码：0x851A0044 访问https://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=14.0.3257.3&EvtType=0xD8FB5EBA%400x97A656BB%401306%4068&E vtType=0xD8FB5EBA%400x97A656BB% 401306%4068获取故障排除帮助。

是什么阻止了 CU18 安装？

某些 SQL Server 更新发生在维护时段之外，这导致服务器重新启动。我怎样才能阻止这种情况在未来再次发生？

以下是我在查看 Windows 更新设置时可以看到的内容：

我的 SQL 服务器场因修补操作系统级别和 SQL 服务器级别而被忽略（因为它们是关键系统，很难发生中断）。

一种选择是在一个月内将我们的 AOAG 集群的辅助节点修补到最新的补丁，然后在下个月业务同意安排在几个小时内进行故障转移。然后我可以修补新的辅助节点（旧的主节点）。这意味着节点在一个月内不会处于相同的补丁级别......这是“不，不”吗？

我在可用性组的辅助节点上应用了 Service Pack 4。它失败了，所以我将辅助节点的整个 VM 恢复到早期版本，现在数据不同步。

我有主动和被动两个节点。我尝试手动恢复数据移动。但它失败了。你能在这里提出什么建议吗？

如果您没有听说过，最近发现了一组相关漏洞，这些漏洞影响了过去十年中销售的几乎所有处理器。您可以在 InfoSec.SE 上找到有关崩溃/幽灵漏洞的更多技术细节。

作为 MongoDB DBA，我需要了解什么？

潜在的性能影响是什么？什么是正确的修补指南？云提供商针对此漏洞采取了哪些措施？

相关问题：

• 作为 MS SQL DBA，我需要了解有关崩溃/幽灵漏洞的哪些信息？

我知道Brent 的帖子为什么没有人在这方面修补他们的 SQL Server ..... 和我的一位朋友一起，请假设一个这样的场景，其中近 100 个 SQL Server 从未打过补丁。假设任何用户都没有报告过错误或性能问题。那么，我的朋友是否有一种很酷的方法来识别所有服务器 - 他不知道 - 并且很少有服务器可能已经遇到了一些错误？换句话说，如何在 100 个 SQL Server 中主动发现错误？

一个计划是阅读那些错误的发行说明，其中错误可以使用服务器触发器在发生的基础上（可能是）......在本地表中捕获......在中央位置的SSIS。

但是，这个计划似乎值得吗？

特别关注那些可能会对数据产生影响的错误。（仅供参考，具有纯度的 DBCC CheckDB 运行无错误）。或者一些可能的业务损失。

最后假设，确实在某些 SQL Server 中检测到了一些错误 - 那么，当多年来用户没有报告任何问题时，如何以及为什么将它们视为“威胁”？

如果我在 SQL Server 2012 SP1 中应用累积更新 3，在应用 CU 3 之前是否还需要执行累积更新 1 和 2？而且，您如何知道 SQL Server 中已经应用了哪些 CU 或修补程序？

我的任务是将 SQL Server 2012 从 SP3 之前的版本 (11.0.5623.0) 一直更新到 SP3 CU2。我可以在没有重新启动之前安装这两个补丁吗？我在谷歌上找到的所有文件都表明只有在文件被锁定时才需要重新启动。

出于我无法解决的原因，我们正在寻找WSUS和SCCM 的替代方案来自动化 SQL CU 修补（特别是在 SQL 2017+ 上）

有一些简洁的 Powershell 解决方案，例如Adam Bertram 的这个解决方案，我通过相关帖子在 Windows 上自动修补 SQL Servers 中找到

我知道有很多商业解决方案，谷歌很容易找到。我正在寻找我们可以在内部管理的解决方案。

我也在寻找其他方法来考虑。经过广泛搜索，我什至可以想象的唯一其他方法是在服务器重新启动时运行的 SQL 作业（服务器修补通常在重新启动时定期发生）），它将在共享文件夹中查找最新的 CU，如果未安装则应用它。但我没有发现除上述之外的任何解决方案。

是否有任何自动化 SQL CU 补丁的方法，但我还没有找到示例？

如果 SQL 作业修补可行，是否有任何示例？