In der SQL Server-Community gab es einige anhaltende Kontroversen darüber, wie sinnvoll es ist, Service Packs (SP) und kumulative Updates (CU) für SQL Server zu installieren. Es gibt verschiedene grundlegende Positionen, die Organisationen typischerweise zu diesem Thema einnehmen, wie unten aufgeführt:
- Die Organisation installiert regelmäßig Service Packs und kumulative Updates
- Die Organisation installiert Service Packs, aber keine kumulativen Updates
- Die Organisation installiert keine Service Packs oder kumulativen Updates
Der erste Fall ist eine Organisation, die versucht, mit einem gründlichen Test- und Implementierungsverfahren sowohl mit SQL Server Service Packs als auch mit kumulativen Updates für SQL Server einigermaßen aktuell zu bleiben. Das ist meiner Meinung nach die beste Politik. Meiner Ansicht nach ist Ihre Organisation viel besser bedient, wenn Sie sowohl mit Service Packs als auch mit kumulativen Updates auf dem neuesten Stand bleiben (solange Sie über die Test- und Implementierungsverfahren und die erforderliche Infrastruktur verfügen, um diese Richtlinie zu unterstützen).
Der zweite Fall ist eine Organisation, die (möglicherweise mit einiger Verzögerung) SQL Server Service Packs installiert, aber aus irgendeinem Grund keine kumulativen Updates für SQL Server installiert. Das ist nicht so gut wie der erste Fall, aber viel besser als der dritte Fall.
Im dritten Fall installieren einige Organisationen aus welchem Grund auch immer niemals SQL Server Service Packs oder kumulative Updates für SQL Server. In einigen Fällen bleiben sie tatsächlich für die Lebensdauer der Instanz auf dem ursprünglichen RTM-Build (Release to Manufacturing) der Hauptversion von SQL Server, die sie ausführen. Dies ist aus mehreren Gründen die am wenigsten wünschenswerte Richtlinie.
Microsoft hat eine Richtlinie, Codezweige (entweder den RTM-Zweig oder einen nachfolgenden Service Pack-Zweig) für eine bestimmte Version von SQL Server zurückzuziehen, wenn sie zwei Zweige alt ist. Als beispielsweise SQL Server 2008 R2 Service Pack 2 veröffentlicht wurde, wurde der ursprüngliche RTM-Zweig (unabhängig von der CU-Ebene) eingestellt und zu einem „nicht unterstützten Service Pack“. Das bedeutet, dass es für diesen Zweig keine Hotfixes oder kumulativen Updates mehr geben wird und dass Sie während eines Supportfalls nur eingeschränkte Unterstützung bei der Fehlerbehebung von Microsoft CSS erhalten, bis Sie ein unterstütztes Service Pack auf Ihrer Instanz installieren.
Gründe, warum die SQL Server-Wartung verschoben wird
In einigen Fällen ist einer Organisation möglicherweise nicht bewusst, wie SQL Server normalerweise mit einer Kombination aus Service Packs, kumulativen Updates und Hotfixes gewartet wird. Viele Unternehmen haben starre Top-Down-Richtlinien für die Wartung und Wartung von Produkten wie SQL Server, die die regelmäßige Installation von SPs und/oder CUs durch Datenbankadministratoren ausschließen. Sie können auch daran gehindert sein, ihre SQL Server-Instanzen zu warten, weil sie Datenbanken von Drittanbietern verwenden, die nur mit bestimmten herstellerspezifischen Versionen und Service Pack-Stufen von SQL Server vom Hersteller unterstützt werden.
Viele Organisationen haben auch verständlicherweise Angst davor, entweder eine SQL Server-Instanz oder eine Anwendung, die von dieser Instanz abhängt, zu beschädigen. Ihnen fehlen möglicherweise auch die Zeit und die Ressourcen, um nach der Installation eines aktualisierten SQL Server-Builds auf einer Instanz in einer Testumgebung ein angemessenes Maß an Anwendungs- und Systemtests durchzuführen. In einigen Fällen haben sie möglicherweise keine dedizierte Testumgebung (was ein separates, großes Problem darstellt).
Einige Organisationen verfügen in ihrer Produktionsumgebung möglicherweise nicht über eine funktionierende Hochverfügbarkeitslösung (z. B. herkömmliches Failover-Clustering, Datenbankspiegelung oder Verfügbarkeitsgruppen). einen Neustart des Datenbankservers und verursachen einen relativ langen Ausfall. Sie haben möglicherweise tatsächlich eine Hochverfügbarkeitslösung im Einsatz, testen sie jedoch selten mit einem Produktions-Failover und haben möglicherweise weniger Vertrauen in ihre Funktionsweise und Zuverlässigkeit.
Gründe für die regelmäßige Wartung von SQL Server
Nachdem Sie einige der häufigsten Gründe aufgelistet haben, warum Organisationen sich entscheiden, SQL Server nicht regelmäßig zu warten, ist es an der Zeit, einige dieser Argumente anzusprechen. Erstens ist Unwissenheit darüber, wie SQL Server normalerweise von Microsoft gewartet wird, keine gültige Entschuldigung mehr. Microsoft hat einen SQL Release Services-Blog, in dem sowohl Service Packs als auch kumulative Updates für SQL Server angekündigt werden. Matthias Bernt erläuterte die allgemeine Wartungsstrategie für SQL Server in seinem Beitrag:Ein geänderter Ansatz für Service Packs, mit weiteren Einzelheiten zum Ansatz des inkrementellen Wartungsmodells von SQL Server, der in diesem Microsoft-Knowledgebase-Artikel verfügbar ist.
Die komprimierte Version des Wartungsmodells besteht darin, dass einzelne SQL Server-Probleme mit Hotfixes behoben werden. Sie müssen sich an Microsoft CSS wenden und einen Supportfall öffnen, um Zugriff auf einen einzelnen Hotfix zu erhalten (es sei denn, es handelt sich um einen sicherheitsbezogenen Hotfix, der von Microsoft Update veröffentlicht wird). Abhängig von Ihrem Umfang des bezahlten Supports bei Microsoft kann dies ein relativ mühsamer und zeitaufwändiger Prozess sein. Es besteht auch das Problem, dass die meisten SQL Server-Kunden höchstwahrscheinlich nicht einmal von vorhandenen Hotfixes wissen, die nicht als Teil eines kumulativen SQL Server-Updates veröffentlicht wurden. Das bedeutet, dass die meisten Kunden wahrscheinlich nicht regelmäßig einzelne Hotfixes beziehen und bereitstellen werden.
Kumulative Updates sind Zusammenfassungen einer Reihe von Hotfixes (in der Regel zwischen 10 und 50 Hotfixes), die alle acht Wochen veröffentlicht werden. Diese kumulativen Updates sind tatsächlich kumulativ (wie der Name schon sagt), sodass Sie alle zuvor veröffentlichten Hotfixes für Ihre Version und Ihren Zweig (RTM, SP1, SP2 usw.) des Codes erhalten, wenn Sie ein kumulatives Update installieren. Das bedeutet, dass die gängige Aussage über Organisationen, „nur kumulative Updates anzuwenden, um bestimmte Probleme zu beheben, die sie haben“, im wirklichen Leben nicht besonders gültig ist.
Wenn Sie beispielsweise den RTM-Build von SQL Server 2012 Service Pack 1 (11.0.3000) ausgeführt haben und sich entschieden haben, das kumulative Update 3 (11.0.3349) von SQL Server 2012 Service Pack 1 zu installieren, weil es einen Hotfix für einen bestimmten enthält Problem, auf das Sie tatsächlich gestoßen sind, würden Sie tatsächlich alle Hotfixes für SP1 CU1, SP1 CU2 und SP1 CU3 erhalten, was weit über 100 Hotfixes ausmachen würde.
Wie Microsoft zu kumulativen Updates sagt:„Da die Builds kumulativ sind, enthält jede neue Fixversion alle Hotfixes und alle Sicherheitsfixes, die in der vorherigen Fixversion von SQL Server 2012 SP 1 enthalten waren. Wir empfehlen, dass Sie erwägen, die neueste Fixversion anzuwenden, die diesen Hotfix enthält.“ Grundsätzlich bedeutet dies, dass Sie, wenn Sie ein bestimmtes, relevantes Problem entdecken, das in einem früheren CU behoben wurde, fortfahren und das neueste relevante CU auf dem System bereitstellen sollten (das auch diesen Hotfix enthält).
Ein Argument, das ich häufig darüber höre, warum Organisationen keine kumulativen Updates bereitstellen, ist, dass „sie nicht vollständig regressionsgetestet sind wie Service Packs, also werden sie nicht bereitgestellt.“ Dieser Standpunkt hat eine gewisse Gültigkeit, aber es gibt auch ein weit verbreitetes Missverständnis, dass kumulative Updates lediglich Komponententests ohne jegliche Regressionstests sind. Dies ist nicht der Fall.
Die Microsoft-Dokumentation zu kumulativen Updates weist darauf hin, dass, da sie „inkrementelle Regressionstests während des gesamten Entwicklungszyklus anwenden, gefolgt von zwei Wochen gezielter Tests innerhalb des 8-wöchigen Veröffentlichungsfensters, die mit CUs verbundenen Qualitätssicherungsprozesse die einzelner Hotfixes übertreffen“. Das bedeutet, dass Sie tatsächlich ein geringeres Risiko eingehen, wenn Sie ein CU bereitstellen, das inkrementell regressionsgetestet wurde und außerdem zwei Wochen gezielt getestet wurde, als wenn Sie einen einzelnen Hotfix bereitstellen würden, der nur einheitengetestet wurde.
In den letzten sechs bis sieben Jahren habe ich persönlich viele, viele kumulative Updates und Service Packs auf einer großen Anzahl von Systemen bereitgestellt, auf denen SQL Server 2005 bis SQL Server 2012 ausgeführt wird, und ich bin noch auf keine größeren Probleme gestoßen. Ich habe auch noch nichts von weit verbreiteten Problemen gehört, die bei dieser Art von Arbeit in Blogs, auf Twitter usw. gemeldet wurden. Es könnte sein, dass ich (und alle, die ich kenne) einfach Glück hatten, oder vielleicht sind kumulative Updates und Service Packs nicht ganz so so riskant, wie manche Leute glauben (solange Sie sie richtig testen und einsetzen).
Die Bedeutung eines Test- und Implementierungsplans
Sofern Sie nicht vorhaben, während der gesamten Lebensdauer Ihres Systems irgendeine Art von Serverwartung oder Anwendungsupdates durchzuführen (was wie ein unwahrscheinliches Unterfangen erscheint), müssen Sie wirklich eine Art Test- und Implementierungsverfahren und einen Plan entwickeln, den Sie als Teil befolgen würden keine Änderungen am Server vorzunehmen.
Dieser Plan mag relativ einfach beginnen, wird jedoch komplexer und umfassender, wenn Sie mehr Erfahrung mit der regelmäßigen Wartung Ihrer SQL Server-Instanzen haben und die Lektionen anwenden, die Sie bei jeder Bereitstellung lernen. Idealerweise würden Sie diesen Plan bei jeder Änderung am System befolgen, aber das ist möglicherweise nicht in jedem Einzelfall möglich.
Hier sind einige erste Schritte und Tests, die in einem solchen Plan enthalten sein sollten.
- Installieren Sie die CU auf einer virtuellen Testmaschine
- Wird die CU ohne Probleme oder Fehler installiert?
- Erfordert die CU-Installation einen Systemneustart?
- Werden alle relevanten SQL Server-Dienste nach der Installation neu gestartet?
- Funktioniert SQL Server nach der Installation anscheinend richtig?
- Installieren Sie die CU auf mehreren Entwicklungssystemen
- Wird die CU ohne Probleme oder Fehler installiert?
- Funktioniert SQL Server anscheinend während der normalen täglichen Nutzung richtig?
- Funktionieren Ihre Anwendungen während des Unit-Tests korrekt?
- Installieren Sie die CU in einer gemeinsam genutzten QA- oder Integrationsumgebung
- Haben Sie einen bestimmten Implementierungsplan und eine Checkliste für die Installation befolgt?
- Bestehen alle Anwendungen, die SQL Server verwenden, Rauchtests?
- Bestehen alle Anwendungen die Ihnen zur Verfügung stehenden automatisierten Tests?
- Bestehen alle Anwendungen detailliertere manuelle Funktionstests?
- Installieren Sie die CU in Ihrer Produktionsumgebung
- Verwenden Sie nach Möglichkeit eine fortlaufende Upgrade-Strategie
- Verwenden Sie während der Bereitstellung eine detaillierte Schritt-für-Schritt-Checkliste
- Aktualisieren Sie Ihre Checkliste mit vergessenen Punkten und gewonnenen Erkenntnissen
Schlussfolgerung
Was ich hier zu erreichen hoffe, ist, mehr Datenbankprofis dazu zu bringen, sich einer Denkweise zuzuwenden, in der sie ihre SQL Server-Instanzen tatsächlich regelmäßig warten möchten, anstatt zu zögern oder Angst davor zu haben, dies zu tun. Dies kann am Anfang mit einem erheblichen Mehraufwand verbunden sein, da Sie möglicherweise andere Personen in Ihrer Organisation davon überzeugen müssen, sich Ihren Plänen anzuschließen. Möglicherweise müssen Sie andere Teile der Organisation dazu drängen, bessere Testpläne zu entwickeln, und Sie müssen eine Checkliste für die Implementierung erstellen. Sie müssen auch eine Genehmigung des Unternehmens für Wartungsfenster einholen (die bei fortlaufenden Upgrades relativ kurz sein sollten), damit Sie tatsächlich regelmäßig Updates auf Ihren Produktionssystemen bereitstellen können.
Als Gegenleistung für diese zusätzliche Arbeit haben Sie ein besser gewartetes System, das in Zukunft weniger wahrscheinlich auf Probleme stößt. Sie befinden sich in einer vollständig unterstützten Konfiguration von Microsoft und haben mehr Vertrauen in Ihre Hochverfügbarkeitstechnologie(n), da Sie diese tatsächlich regelmäßig anwenden werden. Sie werden auch wertvolle Erfahrungen sammeln, wenn Sie all dies planen und implementieren, was Ihre Fähigkeiten zur Fehlerbehebung in Zukunft verbessern wird.
