Kumulative MS SQL Server-Updates - Best Practices

Ich versuche, eine Vorstellung davon zu bekommen, welche empfohlenen Best Practices für die kumulativen SQL Server-Updates gelten .

Derzeit gehen wir von der Idee aus, "nichts zu tun, es sei denn, ein von der CU behobenes Problem tritt auf". Das funktioniert nach dem Ansatz "Wenn es nicht kaputt ist, beheben Sie es nicht", aber ich frage mich, ob das wirklich eine gute Idee ist, da so viele CUs Leistungsverbesserungen aufweisen. Wir möchten möglicherweise die CU zu den Patches hinzufügen, die während unserer regelmäßigen Wartungszyklen ein oder zwei Monate nach der Veröffentlichung der CU angewendet wurden.

Was machen andere und warum?

Als Aktualisierung der Frage, die sich auf die folgenden Antworten auswirkt, gab das SQL Server-Team von Microsoft am 24. März 2016 bekannt, dass das Servicemodell aktualisiert wird . Microsoft empfiehlt allen Benutzern, alle nach Januar 2016 veröffentlichten CUs zu installieren:

Ab Januar CU-Versionen wurden diese Warnmeldungen aktualisiert. Wir empfehlen nun die fortlaufende, proaktive Installation von CUs, sobald diese verfügbar sind. Sie sollten planen, eine CU mit dem gleichen Maß an Sicherheit zu installieren, mit dem Sie SPs (Service Packs) installieren möchten, sobald sie freigegeben werden. Dies liegt daran, dass CUs auf das Niveau von SPs zertifiziert und getestet sind. Außerdem weisen Microsoft CSS-Daten darauf hin, dass ein erheblicher Prozentsatz der Kundenprobleme häufig zuvor in einer freigegebenen CU behoben, jedoch nicht proaktiv angewendet wurde. Darüber hinaus enthalten CUs einen Mehrwert, der über Hotfixes hinausgeht. Diese können auch Support-, Protokollierungs- und Zuverlässigkeitsaktualisierungen enthalten, die das Gesamterlebnis verbessern.

Zusätzlich zu den Aktualisierungen von Nachrichten und Anleitungen haben wir das CU-Erfassungsmodell aktualisiert.

Akquisitionsänderungen:

• CUs wurden natürlich traditionell auf dem "Hotfix" -Server verfügbar gemacht (zusammen mit der "Warnsprache", die mit einem "QFE" oder "Hotfix" verbunden ist). Die Inkonsistenz hier ist, dass CUs keine wirklich einfachen schnellen Hotfixes mehr sind. Die enthaltenen Updates werden heute sowohl auf individueller als auch auf vollständiger Systemintegrationsebene gut getestet.
• Aus diesem Grund platzieren wir jetzt die neueste CU pro Mainstream-unterstützter Basislinie (2012 SP2 / SP3 und 2014 RTM / SP1 heute) auf microsoft.com/downloads, genau wie dies heute für Service Packs der Fall ist
• Darüber hinaus werden wir in Kürze alle CUs im Windows Update-Katalog veröffentlichen und warten, um die Erfassung und Verteilung zu erleichtern
• Auf dem Hotfix-Server werden in Zukunft nur vorläufige CU-On-Demand-Fixes platziert
• Um die Reibung zu verringern, müssen für das Herunterladen von CUs von microsoft.com/downloads keine E-Mails und URL angegeben / empfangen werden
• Wir prüfen auch das Angebot der neuesten CU als optionales Update für Microsoft Update, genau wie Service Packs heute

Ich bin ein großer Befürworter, mit dem neuesten kumulativen Update auf dem neuesten Stand zu bleiben, aber nur, wenn Ihr Test- / QS-Zyklus vollständige und ordnungsgemäße Regressionstests sicherstellen kann. Glenn Berry von SQLskills ist ebenfalls ein Befürworter dieses Ansatzes .

Microsoft empfiehlt, nur CUs anzuwenden, die Probleme beheben, die Sie betreffen, obwohl sie diese Haltung in letzter Zeit gelockert haben . Das Problem ist, dass Sie möglicherweise von einem oder mehreren dieser Probleme betroffen sind und es nicht wissen, oder dass Sie morgen betroffen sind, selbst wenn es Sie noch nicht getroffen hat. Werden Sie versuchen, das Problem hinter jedem einzelnen Fix in jeder einzelnen CU für Ihre Branche zu reproduzieren? Tun Sie dies kontinuierlich, um sicherzustellen, dass Sie immer noch nicht betroffen sind?

Ich bin ganz ehrlich: Ich hatte noch nie ein Problem damit, eine CU auf meine Instanzen anzuwenden. Tatsächlich war der CU-Release-Prozess viel zuverlässiger als der Service Pack-Release-Zyklus, und in vielen Fällen ( zuletzt mit SQL Server 2012 Service Pack 2 ) möchten Sie das Service Pack erst beim ersten Mal anwenden CU für diesen Zweig wurde trotzdem freigegeben. In diesem Fall gibt es einen vorläufigen Hotfix, um das Problem zu beheben, das nicht rechtzeitig behoben wurde, um den Service Pack-Code zu erstellen. Dies ist jedoch nicht immer der Fall.

Wir haben mit den CUs Schritt gehalten. Ungefähr 1 Monat nach der Veröffentlichung würden wir sie anwenden, unabhängig davon, ob ein von ihnen behobenes Problem aufgetreten ist oder nicht.

Nachdem wir jedoch auf ein großes Problem gestoßen waren, haben wir diese Praxis abgebrochen. In unserem Fall hat ein von uns installiertes Service Pack ein Problem mit der Volltextindizierung behoben, das aufgetreten ist. Ein paar Monate später, einer der CUs zurückgerollt , dass bestimmte fix. Dies verursachte für uns alle möglichen Probleme, die einige Nachforschungen erforderten, um herauszufinden, was passiert ist. Am Ende haben wir eine Arbeit codiert, die später vermasselt wurde, als eine neue CU etwas anderes kaputt machte ... Nettoergebnis: Der Server wurde von Grund auf bis zu einer bestimmten SP / CU-Ebene neu installiert und eingefroren.

Unsere Anwendungsleistung ist so, dass wir uns nicht mit neuen SQL-Leistungsverbesserungen befassen, die möglicherweise herauskommen. Das ist also kein Problem. Außerdem ziehen die Berichterstellung und andere Abfragen ständig gültige Ergebnisse zurück, sodass keine neuen Optimierungen erforderlich sind. Dies bedeutet, dass es sich um ein Sicherheitsproblem handeln muss, bevor wir zu diesem Zeitpunkt eine CU anwenden können.

Ich stimme Aaron voll und ganz zu: Tun Sie dies nur, wenn Ihr Test- / QS-Zyklus es richtig testen kann. Andernfalls würde ich klar steuern, es sei denn, es behebt ein Problem, mit dem Sie tatsächlich konfrontiert sind. Und selbst dann testen Sie jede kleine Facette mit realen Daten, um sicherzustellen, dass sie nicht etwas kaputt machen, von dem Sie abhängig sein könnten.