Risiken beim Upgrade auf SQL Server 2008 R2

Wir haben eine ganze Reihe von SQL-Servern, die von Version 2005 auf 2008 R2 aktualisiert werden müssen. Die Arbeiten sind für Mitte des Jahres geplant, da Microsoft die Unterstützung dafür beendet.

Die 2005 SQL Server sind alle SP3 und SP4 und laufen unter Windows Server 2003 (dessen Unterstützung bereits beendet wurde, wir haben jedoch eine Ausnahme von der Verlängerung um ein weiteres Jahr). Bei Bedarf können wir jedoch auch ein Server-Betriebssystem-Upgrade durchführen.

Diese Server umfassen Replikation (Transaktion), Protokollversand, Berichterstellungsdienste und einen Integrationsserver, auf dem SSIS-Pakete ausgeführt werden.

Meine Frage hier ist nicht wie, sondern ich möchte wissen, welche Risiken damit verbunden sind oder welche Vorabprüfungen durchgeführt werden können, bevor dieses Upgrade geplant wird.

Ist ein direktes Upgrade für diese Migration / dieses Upgrade ein besserer Plan als ein Side-by-Side-Upgrade?

Das ist eine wirklich große Frage, also lasst es uns ein bisschen auflösen.

Was kann ich im Voraus tun?

Beginnen Sie mit dem erforderlichen Lesen .

• 2008 R2 Abwärtskompatibilität
• 2008 Abwärtskompatibilität

Diese Links enthalten Links zu weiteren Informationen wie

• Veraltete SQL Server-Funktionen
• Nicht mehr verfügbare SQL Server-Funktionen
• Änderungen brechen
• Verhaltensänderungen an SQL Server-Funktionen

Lesen Sie jeden von ihnen, um zu sehen, welche wichtigen Dinge sich ändern. Achten Sie besonders auf die von Ihnen verwendeten Funktionen.

Außerdem sollten Sie den Upgrade Advisor verwenden . Es sucht nach installierten Komponenten und identifiziert diejenigen, die Sie entweder vor oder nach der Installation reparieren müssen.

Hier auf beiden Seiten gibt es viele Vor- und Nachteile.

An Ort und Stelle

Vorteile

• Viel einfacher. Alle Ihre Konfigurationen bleiben zum Beispiel gleich. Auch die Verbindungszeichenfolgen für Ihre Anwendungen müssen wahrscheinlich nicht geändert werden.
• Billiger. Kein zweiter Hardwaresatz erforderlich.

Nachteile

• Backout ist schwierig bis unmöglich. Wenn etwas schief geht, müssen Sie das Gerät ausschalten und beenden, da beim Backout ein ganz neuer Server erstellt und SQL neu installiert und anschließend die Sicherungen Ihrer Tabellen wiederhergestellt werden müssen.

Seite an Seite

Grundsätzlich sind die Vor- und Nachteile das Gegenteil von In Place.

Vorteile

• Sicherer - Wenn etwas schief geht, töten Sie die neue Version und fahren einfach mit der alten fort. Dann können Sie es später erneut versuchen.

Nachteile

• Es ist teurer, weil Sie wahrscheinlich auf neuen Servern einen neuen Satz von Instanzen erstellen müssen.
• Dies ist schwieriger, da Sie die Verbindungszeichenfolgen ändern, sicherstellen müssen, dass alle Konfigurationen gleich sind usw.

Jetzt können Sie die Kosten für das Nebeneinander verringern, indem Sie eine neue Instanz auf demselben Server erstellen, alles darauf verschieben und dann die alte Instanz deinstallieren. Es funktioniert und abhängig von Ihrer Situation könnte die beste Idee sein.

Ehrlich gesagt ist der Umzug von 2005 - 2008 R2 nicht so schlimm. Es ist nichts im Vergleich zu 2000 - 2005 oder 2008 R2 - 2012 (meistens SSIS-Änderungen). Ich würde sagen, mit sorgfältiger Planung und Lektüre sollten Sie in guter Verfassung sein.

Meine Frage hier ist also nicht, wie, sondern ich möchte das damit verbundene Risiko oder die Vorabprüfungen kennen, die vor der Planung dieses Upgrades durchgeführt werden können.

Sie sollten den Upgrade Advisor ausführen und die von ihm gemeldeten Probleme beheben, bevor Sie migrieren.

In meiner Antwort finden Sie eine ausführliche Liste der Schritte vor und nach dem Upgrade .

SQL Server, der von Version 2005 auf 2008R2 aktualisiert werden muss

Sie wählen einen Pfad aus, auf dem Sie wieder zu Feld 1 zurückkehren (da Sie innerhalb von 3 Jahren erneut ein Upgrade durchführen müssen). Siehe folgende Tabelle

Wird das Inplace-Upgrade ein besserer Plan oder nebeneinander für diese Migration / Aktualisierung sein?

Aufgrund meiner Erfahrung würde ich Ihnen empfehlen, eine Side-by-Side-Migration durchzuführen, da Sie eine neue Betriebssystem- und SQL-Version erhalten. Dies ist ein viel saubererer Ansatz, da Ihre alten Server immer noch verfügbar sind, nur für den Fall, dass Sie ein Failback durchführen möchten. Siehe: Sind In-Place-Upgrades von SQL Server so schlecht beraten wie früher? . Verstehen Sie mich nicht falsch, wenn ich eine Side-by-Side-Migration vorschlage. Es ist nur eine sicherere Seite, wenn es um Rollback geht.

IMO, wenn Sie sich um eine Migration bemühen, sollten Sie bis 2014 gehen, auch wenn Sie es im 10.0-Kompatibilitätsmodus ausführen.

Sie werden die Lizenz trotzdem bezahlen. In beiden Fällen sind auch der Aufwand für Regressionstests und die Lernkurve zwischen Entwickler und DBA von Bedeutung. Wenn Sie jetzt bei 2008R2 aufhören, müssen Sie die Übung in ein paar Jahren nur noch einmal wiederholen. 2008R2 hat bereits sein letztes Service Pack gesehen und wird in einigen Monaten (Wochen) 3 Vollversionen hinter der aktuellen Version sein.

Aus den gleichen Gründen empfehle ich meiner Organisation, von 2008R2 direkt auf 2016 umzusteigen. Ich gehe davon aus, dass wir mit den Tests beginnen werden, sobald 2016 RTM erreicht.

Übrigens stimme ich zu, dass ein Side-By-Side-Upgrade bevorzugt wird. Als ich diese Übung das letzte Mal gemacht habe, haben wir die "Pre-Production" -Version ungefähr einen Monat lang in einer Dev-Umgebung ausgeführt.