SQL Server Upgrade Methoden

Paralleles SQL Server Upgrade mit Protokollversand

Mit Unternehmenswachstum wachsen meist auch Datenbanken und die Komplexität der vorhandenen Anwendungen steigt ebenfalls an. Vermutlich wird es dadurch auch an ausreichend Zeit mangeln, Datenbanken zu aktualisieren und zu migrieren. Trotzdem erwarten Kunden, dass Anwendungen im Notfall innerhalb weniger Zeit wieder verfügbar sind. Um dem Problem entgegenzuwirken ist eine Investition in Disaster Recovery und Business Continuity sehr hilfreich. Welche SQL Server Upgrade Methode hierbei die richtige ist, erklären wir nachfolgend.

Im oberen Abschnitt haben wir bereits 4 solcher Upgrade Methoden vorgestellt. Die folgende Methode ist deutlich komplexer und empfiehlt sich eher mit fortgeschrittenem Kenntnisstand. Bei einem parallelen SQL Server Upgrade wird ein SQL Server entweder auf eine neue SQL Server Instanz auf demselben oder auf einem anderen Computer aktualisiert.

Beim Protokollversand handelt es sich um ein gängiges Tool in SQL Server, was bereits seit über Jahrzehnten im Einsatz bezüglich Disaster Recovery ist. Das Prinzip vom Protokollversand ist simpel. Es gibt einen primären und einen sekundären Server. Der primäre Server stellt eine SQL Server Datenbank mit Lese- & Schreibaktivitäten für alle Benutzer zur Verfügung. Transaktionsprotokolle aus der primären Datenbank werden über SQL Server Agent Aufträge auf einer sekundären Datenbank auf einem sekundären Server angewendet. Die Datenbank auf dem sekundären Server kann sich hierbei entweder in einem Stand-By oder No-Recovery Modus befinden. Im Stand-By Modus kann die Datenbank als schreibgeschützte Kopie und für Berichtzwecke mit lesendem Zugriff verwendet werden und führt bei Bedarf auch Transaktionsprotokolle aus. Der No-Recovery-Modus lässt hingegen keine Lesevorgänge in der sekundären Datenbank zu. Lediglich Transaktionsprotokolle können hierauf angewendet werden.

Szenario: Sie haben zwei SQL Server 2012 Enterprise Edition. SQL1 ist der primäre Server in der Domäne 1 und SQL2 ist der sekundäre SQL Server in der Domäne 2. Das Betriebssystem auf beiden Servern ist Windows Server 2012 R2. Ein Transaktionsprotokollversand wird für die Datenbank DB3 mit rund 500GB Volumen von SQL1 auf SQL2 eingerichtet. Die besagte Datenbank DB3 verwendet die Funktionen Datenbankkomprimierung und Datenbanksnapshot, die nur in der Enterprise Edition von SQL Server 2012 verfügbar sind. Nun tritt der Fall ein, dass der Support sich langsam dem Ende zuneigt und Sie nun Ihre SQL Server auf die 2017 Standard Edition upgraden möchten. Natürlich möchten Sie auch von neuen Features der aktuelleren Version profitieren.

Lösung: Sie entscheiden sich für eine die Side-by-Side Upgrade Methode mit einer Protokollversandkonfiguration. SQL Server 2017 wird auf vom aktuellen Windows-Betriebssystem Windows Server 2012 R2 unterstützt. Somit muss das Betriebssystem nicht aktualisiert werden. Sie starten mit dem Upgrade von SQL2. Sollte etwas schief gehen, können Sie über ein Rollback die Anwendung mit der Datenbank DB3 auf der SQL Server 2012 Instanz SQL1 verbinden.

Bei der Vorbereitung des Upgrades stellen Sie fest, dass ein Upgrade der SQL Server 2012 Enterprise Edition auf SQL Server 2017 Standard Edition nicht funktionieren kann, da es sich um ein Upgrade von einer höheren auf eine niedrigere Edition handelt. Dafür installieren Sie nun eine weitere Instanz namens SQL3 auf der SQL Server 2017 Standard Edition.

Folgende Schritte helfen Ihnen dabei, Datenbanken mithilfe des SQL Server Protokollversands zu migrieren:

1. Deaktivieren Sie die Protokollversandaufträge auf SQL1 und SQL2.
2. Erstellen Sie auf SQL1 eine Transaktionsprotokollsicherung der Datenbank DB3 ohne Recovery. Wenn eine Protokollsicherung mit der Option “NoRecovery” durchgeführt wird, wird die DB3 Datenbank auf SQL1 in den Wiederherstellungsmodus versetzt und kann nicht verwendet werden.

Im folgenden Vergleich lässt sich die vorherige und aktuelle Situation gut erkennen:

3. Führen Sie die Jobs zum Kopieren und Wiederherstellen auf SQL2 manuell aus und stellen sie sicher, dass alle Logs angewendet wurden.
4. Kopieren sie nun manuell das letzte Log-Backup, dass sie von DB1 angefertigt haben und stellen sie es auf SQL2 DB3 wieder her (mit Recovery). Damit sollte die Datenbank DB3 auf SQL2 im Status “online” sein.

5. Erstellen Sie eine vollständige Sicherung von DB3 auf dem sekundären Server SQL2.
6. Stellen Sie DB3 auf SQL3 wieder her. Da sich SQL2 und SQL3 auf demselben Server befinden, brauchen Sie die Sicherungsdatei nicht kopieren. Das erspart Ihnen einiges an Zeit.
7. Setzen Sie den Kompatibilitätsgrad der DB3 auf 140 mit folgendem Code:

6. Verbinden Sie Ihre Anwendung mit SQL3.DB3 und testen Sie diese ausgiebig. SQL3 ist nun Ihre neue primäre Instanz. Es kommt zu einer Ausfallzeit, sobald die letzte Protokollsicherung von DB3 auf SQL1 erstellt wurde. Hintergrund ist, dass die Protokollsicherung sich in einem nicht wiederherstellbaren Modus befindet. Die Ausfallzeit endet, sobald die Anwendung erfolgreich mit SQL3.DB3 verbunden wurde.
7. Sie können nun den Protokollversand wieder aktivieren.
8. Installieren Sie dafür die SQL Server 2017 Instanz SQL4 in der Domäne 1. Dies ist der neue sekundäre SQL Server.
9. Erstellen Sie nun einen Transaktionsprotokollversand von SQL3 nach SQL4.

10. Deinstallieren Sie anschließend SQL1 und SQL2.

Vor- & Nachteile von Log-Shipping

• Die meisten Daten können im Voraus auf den Zielserver verschoben werden. Somit ist mit weniger Ausfallzeit während der Umstellung zu rechnen.
• Es ist vor allem hilfreich für sehr große Datenbanken, dessen Quell- & Zielinstanzen auf unterschiedlichen Domänen laufen.
• Im Vergleich zum direkten Datenbank-Upgrade auf demselben Server, stehen mit der Protokollversandmethode einige Notfallpläne zur Verfügung.
• Die Datenbank auf der alten primären Datenbank ist weiterhin im Wiederherstellungsstatus verfügbar. Somit können Sie beim Fehlschlagen des Upgrades ein Rollback durchführen und die alte Datenbank wieder online bringen:

• Die sekundäre Protokolldatenbank ist eine schreibgeschützte Kopie der Produktionsdatenbank. Sie kann für Berichtsabfragen ausführen und auslagern. Damit sparen Sie den Druck auf die primäre Datenbank ein.
• Eine primäre Datenbank kann den Versand an mehrere sekundäre Server protokollieren.

• Es gib kein automatisches Failover. Sie müssen es manuell durchführen.
• Einige Ausfallzeiten sind unvermeidlich.
• Zusätzliche Lizenzkosten für Hard- & Software, da ein weiterer SQL Server benötigt wird.
• Der Transaktionsprotokollversand muss für jede Datenbank eingerichtet werden.

Minimierung der Ausfallzeit für SQL Server Upgrades

In manchen Betrieben und Unternehmen, die mit Datenbanken arbeiten, können Ausfallzeiten enorm geschäftsschädigend und vor allem geschäftskritisch sein. Wir sprechen von Datenbanken, die eine Hochverfügbarkeit mit sich bringen und rund um die Uhr, 24 Stunden am Tag, 7 Tage die Woche und 365 Tage im Jahr betriebsbereit sein müssen. Redundanz ist hier das magische Wort. Firmen investieren daher Unsummen in den Ausbau dieser Redundanz innerhalb ihrer IT Infrastruktur. Trotz allem müssen auch hier Upgrades von SQL Servern durchgeführt werden, gerade wenn es sich um eine veraltete Version handelt. Wie Sie dieses Upgrade durchführen können, bestmöglich ohne Ausfallzeit, beschreiben wir nun im folgenden und letzten Abschnitt zu diesem Thema.

Um eine Entscheidung hinsichtlich der für Sie besten Methode treffen zu können, empfehlen wir vorher die Kennzahlen ihrer RPO (Recovery Point Objective) und RTO (Recovery Time Objective) zu bewerten.

→ In einem Disaster Recovery Szenario ist das Recovery Point Objective (RPO) die Zeitspanne, für die ein Datenverlust akzeptiert wird. Recovery Time Objective hingehen beschreibt die Zeitspanne, die zum Neustart des Systems benötigt wird. Die Kombination aus beiden Kennzahlen beschreibt die Gesamtwiederherstellungszeit.

Wie bereits im vorherigen Abschnitt beschrieben, bietet sich für diese Situation der Protokollversand als beste Notlösung an, da wir hier einen sekundären Server haben, der als Backup fungiert. Mit den Transaktionsprotokollsicherungen werden kontinuierlich Sicherungen in der sekundären Datenbank wiederhergestellt. Im Falle eines Ausfalls muss somit die sekundäre Datenbank manuell online gebracht werden und die Protokollsicherung auf dem besagten Sekundärserver wiederhergestellt werden.

Der Vorteil an Hochverfügbarkeitslösungen ist, dass sollte ein Primärsystem von einem Ausfall betroffen sein, übernimmt das Sekundärsystem die primäre Rolle. Benutzeranwendungen werden nahtlos an das neue Primärsystem weitergeleitet. Somit werden Sie mit nahezu keiner Ausfallzeit konfrontiert.

Je mehr Datenverlust ein Unternehmen verkraften kann, desto weniger kostet die Wiederherstellungslösung. Beispielsweise dauert die Sicherungs- & Wiederherstellungsmethode einer sehr großen Datenbanken als Upgrade sehr lange. Da hier aber mit einer Ausfallzeit gerechnet wird und dies auch vom Kunden/Unternehmen/Anwender akzeptiert wird, muss nicht in Hochverfügbarkeitslösungen und Disaster Recovery investiert werden. Im Gegensatz dazu können Hochverfügbarkeitslösungen Datenverlust in nur wenigen Minuten wiederherstellen. Somit sparen Sie sich hierbei die Wiederbeschaffungskosten der Daten.

Side-by-Side Upgrade vs. Rolling-Upgrade

Nun stellen wir zwei Upgrade-Methoden gegenüber. Die Side-by-Side Upgrade-Methode und das Rolling-Upgrade.

Das Side-by-Side Upgrade benötigt 2 SQL Instanzen, die sich entweder auf demselben VM-Host oder unterschiedlichen Hosts befinden können. Eine der beiden Instanzen hat eine aktuellere Version von SQL Server. Zunächst stoppen Sie die Anwendung auf dem alten SQL Server, erstellen eine Sicherung und stellen die Datenbank auf der neuen Instanz wieder her (oder verwenden den Protokollversand). Anschließend verbinden Sie die Anwendung mit der neuen SQL Server Instanz. In diesem Fall sind beide Datenbankinstanzen aktiv und verfügbar. Es kann jedoch zu Ausfallzeiten kommen. Anmeldungen, SQL Server Objekte, Jobs und Benutzerdatenbanken müssen per Skript auf dem Zielserver neu erstellt werden. Der Vorteil ist hier, dass bei einem möglichen Fehlschlagen des Upgrades, Sie einfach ihre alte Instanz reaktivieren können.

Mit dem Rolling-Upgrade werden ebenfalls 2 SQL Instanzen benötigt. Sowohl der primäre als auch der sekundäre Server sind vor dem Upgrade synchron. Durch Verfügbarkeitsgruppen haben Sie die Möglichkeit fortlaufende Upgrades durchzuführen und die Anwendung somit immer aktiv und verfügbar zu halten. Damit wären Anwendungen, Jobs, Benutzerdatenbanken und Co. immer aktiv. Ist die Anwendung mit dem primären Knoten verbunden, wird der sekundäre Knoten aktualisiert. Ist der sekundäre Knoten gleich oder höher als der primäre, laufen Transaktionen vom primären zum sekundären Knoten, obwohl sie ggf. sich gerade in der Warteschlange befinden. Hierbei sprechen wir von einem automatischen Failover.
Sie können jedoch auch einen asynchronen Modus verwenden, sollten Sie kein automatisches Failover wünschen. Das Failover kann auch manuell zur sekundären Instanz durchgeführt werden. Hierfür führen Sie das Upgrade auf der sekundären Instanz durch und stellen sicher, dass alle Transaktionen angewendet werden, um Datenverlust zu vermeiden. Anschließend wird sich die Rolle der sekundären Instanz automatisch auf die primäre Instanz ändern. Transaktionen auf der alten Instanz werden dann nur durchgeführt, wenn beide Instanzen wieder synchron laufen und die SQL Server Versionen identisch sind.

Upgrade Szenario / Beispiel

Angenommen Sie besitzen einen SQL Produktionsserver mit 10 geschäftskritischen Datenbanken mit einer Größe von 5 - 500 GB. Sie haben eine Verfügbarkeitsgruppe auf 2 Knoten eingerichtet. Die Knoten heißen SQL1 und SQL2. Die Verfügbarkeitsgruppen nennen sich AG1 und AG2. Sie haben erfolgreich Datenbanken gruppiert, für die Sie ein Failover durchführen müssen. Damit stellen Sie sicher, dass die Anwendung eine Verbindung herstellt und ohne Probleme auf dem sekundären Server ausgeführt wird. Auf beiden SQL Servern befindet sich das neuste Windows-Betriebssystem und die SQL Server 2016 Version. SQL2 (das sekundäre Replikat der Verfügbarkeitsgruppe) wird im asynchronen “Commit”-Modus ausgeführt. Die Disaster Recovery läuft auf einem Disaster Recovery Server SQL3 in einem anderen Rechenzentrum in einem anderen geografischen Standort. Protokollsicherungen und Wiederherstellungen erfolgen im 5-Minuten Takt. Nun steht ein Upgrade der Datenbanken auf SQL Server 2017 an und Sie müssen eine Hochverfügbarkeit aufrechterhalten. Sie gehen folgendermaßen vor:

1. Bauen Sie die Netzwerkbandbreite zwischen beiden Servern und dem zweiten Rechenzentrum auf das Maximum aus.
2. Fügen Sie den Verfügbarkeitsgruppen den Disaster Recovery Server SQL3 als drittes asynchrones Replikat hinzu.
3. Aktualisieren Sie SQL3. SQL1 und SQL2 laufen dabei synchron.
4. Aktualisieren Sie anschließend SQL2. Während des Upgrades sind SQL1 und SQL3 synchron.
5. Ist SQL2 aktualisiert und synchronisiert, führen Sie zunächst ein Failover von AG1 und AG2 auf SQL2. Dabei übernimmt SQL2 die Rolle der primären Verfügbarkeitsgruppe. Ihre Anwendungen verbinden sich mit SQL2 und SQL3 startet die Synchronisation mit SQL2. SQL1 kann nicht synchronisiert werden, da die SQL Server Version niedriger ist als die des primären Knotens.
6. Aktualisieren Sie im Nachgang SQL1 und stellen die Verfügbarkeitsgruppe wieder her. Synchronisieren sie nach dem Upgrade wiederum mit SQL2
7. Bei Bedarf können Sie nun auch noch ein Failover von AG1 und AG2 auf SQL1 durchführen.