MS SQL Server累积更新-最佳做法

我试图了解SQL Server累积更新推荐的最佳做法。

目前，我们秉承“除非CU解决的问题是我们遇到的问题，否则请不要做”的想法。这可以通过“如果还没有解决，就不要解决”的方法来实现，但是我想知道这是否真的是一个好主意，因为许多CU都具有性能增强功能。我们正在考虑将CU添加到CU发布后一两个月的定期维护周期中所应用的补丁中。

别人做什么，为什么？

作为影响以下答案的问题的更新，Microsoft的SQL Server团队于2016年3月24日宣布，他们正在更新其服务模型。Microsoft建议所有用户安装2016年1月之后发布的所有CU：

从CU的1月发行版开始，这些警告消息已更新，我们现在建议对CU进行持续，主动的安装。您应该计划以与计划安装SP（Service Pack）发布时相同的置信度来安装CU。这是因为CU已通过SP级别的认证和测试。此外，Microsoft CSS数据表明，以前通常在已发布的CU中解决了很大比例的客户问题，但并未主动应用。更重要的是，CU包含除修补程序之外的附加值。这些还可能包含可支持性，日志记录和可靠性更新，以增强整体体验。

除了消息和指导更新之外，我们还对CU采集模型进行了更新。

购置变更：

• 当然，传统上，CU通常在“ Hotfix”服务器上可用（伴随着与“ QFE”或“ Hotfix”相关联的“警告语言”）。这里的矛盾之处在于，CU不再是真正简单的快速修补程序。所包含的更新已在当今的单个以及整个系统集成级别进行了良好的测试。
• 因此，我们现在在microsoft.com/downloads上按照主流支持的基准（今天是2012 SP2 / SP3和2014 RTM / SP1）放置最新的CU，就像今天对Service Pack所做的那样
• 此外，我们很快将所有CU释放并维护到Windows Update目录中，以方便获取和分发
• 仅临时CU“按需”修复程序将放置在向前移动的修复程序服务器上
• 为了减少摩擦，从microsoft.com/downloads下载CU不需要提供/接收电子邮件和URL
• 我们也正在评估提供最新的CU作为Microsoft Update上的可选更新，就像今天的Service Packs一样。

我大力提倡保持最新的最新更新，但前提是您的测试/质量检查周期可以确保针对此进行完整且适当的回归测试。SQLskills的 Glenn Berry 也是这种方法的支持者。

微软自己的建议是仅应用可解决影响您的问题的CU，尽管他们最近已放松了这一立场。问题是您可能会受到其中一个或多个问题的影响并且不知道，或者明天您可能会受到影响，即使尚未受到影响。您是否要尝试并重现分支机构每个CU中每个修复程序背后的问题？您是否要连续进行此操作以确保您仍然不受影响？

我会很诚实：我从未遇到将任何CU应用于实例的问题。实际上，它们的CU发布过程比Service Pack发行周期要可靠得多，并且在许多情况下（包括最近使用的SQL Server 2012 Service Pack 2），您不希望在第一个应用程序之前应用Service Pack。无论如何，该分支的CU已被释放。在这种情况下，有一个临时修补程序可以解决无法及时生成Service Pack代码的问题，但这并不总是正确的。

我们过去经常跟上CU。发布后大约1个月，无论是否遇到问题，我们都会应用它们。

但是，遇到一个大问题后，我们停止了这种做法。在我们的案例中，我们安装了一个Service Pack，解决了我们遇到的全文索引问题。几个月后，其中一个CU 还原了该特定修复程序。这给我们带来了各种各样的问题，需要大量的研究才能弄清楚发生了什么。我们结束了对工作的编码，然后当新的CU破坏了其他东西时又将其搞砸了……最终结果：服务器从头重新安装到特定的SP / CU级别并冻结了。

我们的应用程序性能使我们不必担心可能会出现的任何新SQL性能增强，因此这不是问题。此外，报告和其他查询会不断拉回有效结果，因此不需要任何新的调整。这意味着在我们此时考虑应用CU之前，这必须是安全问题。

我完全同意亚伦（Aaron）的观点：只有在您的测试/质量检查周期可以正确测试它的情况下，才这样做， 否则我会说清楚，除非它可以解决您实际遇到的问题。即使这样，也要使用真实数据对其进行测试，以确保它们不会破坏您可能依赖的东西。