Wie weit ist es bei der Validierung einer SQL Service Pack-Installation?

Wenn ich ein Service Pack auf einen Produktions-SQL-Server anwende, habe ich normalerweise ein geplantes Ausfallzeitfenster von etwa 30 Minuten.

Nachdem Sie zuvor gebissen wurden und festgestellt haben, dass eine erforderliche Voraussetzung wie ein Patch nicht vorhanden ist, kann dies Ihr Ausfallzeitfenster um einige Minuten verlängern ( und Sie möglicherweise über das Fenster führen oder eine Neuplanung erzwingen ).

Wenn sich das Update in der Planungsphase befindet, verschiebe ich das Service Pack auf den Server und teste es über "Verwendete Dateien prüfen " oder "Aktualisierungsbereit". Ich brich das Update zu diesem Zeitpunkt ab und bin mir so sicher, dass ich während des Updates das geplante Ausfallzeitfenster nicht überschreite.

Sie können von beiden Bildschirmen aus abbrechen. Da sich die Schaltfläche "Aktualisieren" unter "Bereit zum Aktualisieren" an derselben Stelle befindet wie die Schaltfläche "Weiter>" unter "Verwendete Dateien überprüfen", kann ein versehentlicher Doppelklick versehentlich ein Update starten. während der Validierung.

Meine Frage:

Sollte ich die Validierung bei "Verwendete Dateien prüfen" oder "Aktualisierungsbereit" beenden? Habe ich bis zum Ende von "Überprüfen der verwendeten Dateien" alles überprüft, was ich kann? Erhöht der Wert von "Bereit zum Aktualisieren" die Validierung?

— James Jenkins
quelle

Wenn Sie noch keinen Testserver haben, auf dem Sie solche Verfahren testen können, müssen Sie diese zuerst einrichten, bevor Sie weitere Upgrades durchführen.

— Mast

Antworten:

Sollte ich die Validierung bei "Verwendete Dateien prüfen" oder "Aktualisierungsbereit" beenden? Habe ich bis zum Ende von "Überprüfen der verwendeten Dateien" alles überprüft, was ich kann?

Klicken Sie einfach auf NEXTund wenden Sie das Service Pack an. Sie können diesen Vorgang ignorieren. Die Überprüfung files in use processbesteht darin, ein Szenario zu behandeln, in dem der Endbenutzer nach dem Anwenden des Service Packs keinen Neustart durchführen möchte. In diesem Fall müssen Sie sicherstellen, dass alle derartigen Prozesse gestoppt sind. In jedem Fall empfehle ich jedoch dringend, den Windows-Computer / Knoten zu starten, auf den Sie sich bewerben Service Pack.

Das einzige, was passieren kann, ist, dass Sie nach einem erfolgreichen Upgrade den Windows-Computer starten müssen. Dies als solches wird NICHT dazu führen, dass SP fehlschlägt

Erhöht der Wert von "Bereit zum Aktualisieren" die Validierung?

Das Ready-to-Update zeigt Ihnen im Grunde alle Funktionen, die Sie aktualisieren möchten, und nicht mehr. Sie müssen updatehier klicken , es bringt keinen Mehrwert, sondern zeigt Ihnen nur, welche Konfiguration Sie gewählt haben

— Shanky
quelle

Es tut mir leid, es sieht so aus, als ob meine Frage nicht klar war. Ich habe nicht gefragt, ob ich auf verwendete Dateien warten soll, und ich wende das Service Pack derzeit NICHT an. Ich bestätige, dass es vor dem Start des Updates zu einem späteren Zeitpunkt keine Probleme mehr geben wird, wenn eine geplante Ausfallzeit vorliegt.

— James Jenkins

Ich wurde darauf hingewiesen, dass das Timing dieser Antwort zwar etwas von meinem Szenario abweicht. Es zeigt an, dass es keinen Mehrwert gibt, wenn Sie zum Fenster "Bereit zum Aktualisieren" gehen. Ich kann an jedem Punkt unter "Verwendete Dateien prüfen" mit den gleichen Ergebnissen anhalten, was das eigentliche Update betrifft. Ich akzeptiere es, danke.

— James Jenkins

Die ideale Situation besteht darin, einen Server zu haben, der in Bezug auf Betriebssystem und andere Software genau der Produktionsumgebung entspricht, auf der Sie zuerst das Update durchführen können. So wissen Sie alles, was benötigt wird.

Dies ist vorzugsweise eine VM, die Sie als Snapshot erstellen können. Wenn Sie also auf ein Problem stoßen und dieses beheben, können Sie zum Snapshot zurückkehren und erneut mit Ihrer aktualisierten Prozedur beginnen. Wiederholen Sie diesen Vorgang, bis der Aktualisierungsvorgang funktioniert und Sie die Neustartanforderungen und dergleichen kennen. Planen Sie dann, den Vorgang in der Produktion zu wiederholen.

Eine Ihrer Entwicklungs- / Test-VMs ist möglicherweise ideal dafür, wenn Sie sie haben (dh wenn Ihr Entwicklungs- / Test- / Release-Prozess nicht nur "Code zerschlagen und direkt in die Produktion werfen"!). Auf diese Weise behandeln Sie das Service Pack im Wesentlichen genauso wie eine Ihrer eigenen Fehlerbehebungen oder Feature-Releases. Dies bedeutet, dass Sie einen vollständigen Regressionstest für Ihre Anwendung durchführen können, nachdem das Service Pack auf die Testumgebung angewendet wurde (um sicherzustellen, dass der MS-Port vorhanden ist Es wurden keine Fehler oder Änderungen am undefinierten Verhalten eingeführt, von denen Ihre Anwendung abhängt - oder die keinen Fehler behoben haben, von dem Ihr Code abhängt!).

Offensichtlich könnte dieses "Ideal" zeitaufwändiger sein als andere Optionen ...

— David Spillett
quelle

Wenn ein von der Produktion getrenntes Testsystem vorhanden ist, aktualisieren Sie zuerst den Test und dann die Produktion. Das Problem tritt normalerweise auf älteren Servern auf, die kein Testsystem haben. In Wirklichkeit kann jedoch jeder Server aus der Patch- / Update-Liste fallen, und Sie werden es erst herausfinden, wenn Sie so etwas wie ein Service Pack ausführen. Ich denke, wir alle versuchen, Kontrollen durchzuführen, damit dies nicht passiert, aber Murphy kommt und eine Unze Prävention ... Gibt es eine Chance, ein Problem zwischen den beiden Bildschirmen zu finden?

— James Jenkins

@JamesJenkins Kannst du einen Schnappschuss des "älteren Servers" machen, ihn irgendwo als VM hochfahren, darauf testen und ihn dann wegwerfen, wenn du fertig bist? Natürlich muss Hardware verfügbar sein, aber wenn Sie sie wegwerfen können, wenn Sie fertig sind, viel weniger als das Duplizieren der gesamten Serverflotte.

— jpmc26

@ jpmc26 müssten Sie nicht auch das Betriebssystem duplizieren und sicherstellen, dass in beiden Versionen dieselben Patches vorhanden sind?

— James Jenkins

@ JamesJenkins Ich meinte einen vollständigen Schnappschuss der gesamten Maschine. Das würde das Betriebssystem einschließen.

— jpmc26

@JamesJenkins: Ich habe in der Vergangenheit den VMWare-Konverter verwendet, um eine laufende physische Maschine zum Testen auf eine VM zu kopieren, und ich gehe davon aus, dass ähnliche Tools für HyperV usw. existieren. Natürlich kann es zu Lizenzproblemen kommen, je nachdem, wie die Windows- und SQL Server-Lizenzvereinbarungen Ihres Unternehmens sind.

— David Spillett

Um Ihre Frage zu beantworten, können Sie die Validierung der verwendeten Dateien überspringen. Es hindert Sie nie daran, fortzufahren, und dient nur dazu, Sie zu informieren, wenn Sie AFTERWARDS möglicherweise neu starten müssen.

Es gibt noch viele weitere Situationen, in denen Sie immer noch neu starten müssen und es Ihnen nicht sagt (normalerweise im Zusammenhang mit .NET Framework), sodass Sie immer neu starten werden, egal was passiert. Wenn Sie jetzt nicht neu starten, müssen Sie dies im nächsten Monat tun, wenn das nächste Paket herauskommt, da dies ein Patch-Blocker ist.

Aber um den Elefanten im Raum anzusprechen, selbst wenn Sie nur einen oder zwei Server patchen, sollten Sie mehr Zeit als 30 Minuten einplanen. 60-120 Minuten sind ungefähr richtig, insbesondere wenn Sie über AGs / FCIs / Spiegelung / Replikation und Unternehmensfunktionen verfügen. Wenn Sie ein paar Dutzend Server haben, können Sie diese auf ungefähr vier Stunden komprimieren, da Sie zu diesem Zeitpunkt teilweise automatisieren und es ziemlich selten vorkommt, dass alle mit völlig unterschiedlichen Problemen ausfallen.

Der Grund, warum Sie mehr Zeit benötigen, ist, dass Sie nie wissen, was mit einem ESX-Host, einem vorübergehend langsamen SAN oder den Fehlern im Jahr 2012, die angeblich kürzlich durch langsame Update-Installationen behoben wurden, los ist. Oder Sie haben irgendwie vergessen, zuerst SSISDB von einer AG zu entfernen, und jetzt ist es abgespritzt und Sie müssen es reparieren. Oder die wiederholten Fehler von MS, die Instanzen mit Filestream vermasselt haben, sodass Sie vor dem erneuten Anwenden des Updates zu Software gehen und eine Reparatur durchführen müssen. Oder Sie müssen warten, bis die AG nach dem Patchen (problemlos 30 Minuten auf einem ausgelasteten Server), dem Failover und dem Replikat wieder synchron ist.

Welche grundlegenden Gesundheitsprüfungen haben Sie automatisiert? Pro Server dauert es einige Minuten, bis alle AG-Richtlinienprüfungen ausgeführt sind. Wenn Sie es von Hand machen, ist es mehr; Validierung von DQS MDS SSRS SSAS sind alle wieder aufgetaucht und werfen keine dummen Fehler.

Ich kann ziemlich sicher sagen, dass es zwar nützlich ist, zuerst die Qualitätssicherung zu testen, es jedoch viele, viele Male gab, in denen ein Patch nur in PROD fehlgeschlagen ist, weil irgendwo irgendwo jemand etwas anderes getan hat.

Auf jeden Fall ist die Liste nicht endlos, aber es sind definitiv mehr als 30 Minuten. Sie möchten nicht auf die Uhr schauen, während Sie versuchen, eine Katastrophe zu beheben, nur weil Sie mit einem kurzen Zeitlimit unterbewertet sind. Ich verstehe, dass Manager es hören wollen - und deshalb erhalten DBAs das große Geld, weil wir Nein sagen müssen.

— Cody Konior
quelle