SQL Server Upgrade Methoden

Als erfahrene:r Datenbankspezialist:in stehen Sie womöglich immer wieder vor anstehenden Updates und neuen Releases von SQL Server. Teilweise sind diese Upgrades auf neuere Versionen unumgänglich, da ältere Versionen ein Ablaufdatum hinsichtlich des Supports haben und ab Datum XY nicht mehr betreut werden. Daher empfehlen wir immer, von alten Versionen auf neue Versionen umzusteigen. Für die besagten Upgrades stehen viele verschiedene Methoden zur Auswahl. Mit diesem Beitrag möchten wir Ihnen bei der Auswahl der richtigen Methode helfen und stellen sie Ihnen im Detail näher vor.

Prozess

Die Auswahl der richtigen Methode partizipiert vor allem von Ihren Geschäftszielen. Entweder, Sie führen ein SQL Server Upgrade durch, welches so wenig Ausfallzeit wie möglich mit sich bringt (was in diesem Fall dann eine Kosteneinsparung darstellen würde), oder Sie führen alternativ ein Upgrade mit einem sehr geringen Aufwand durch. Das würde dann zu einer Zeiteinsparung führen. Vielleicht sind aber auch beide Faktoren für Sie von Bedeutung - Kosten und Zeit.

Wie bereits angemerkt, gibt es viele Möglichkeiten, wie Sie Ihren SQL Server updaten können. Die von Ihnen gewählte Methode bestimmt das Risiko. Das Risiko bei einer zeiteinsparenden Variante ist, dass zwar das System schneller aktualisiert wird und beispielsweise ein Datenverlust eher ein seltener Fall sein wird. Allerdings wird dann auf der Kostenseite ein ordentliches Plus zu sehen sein, da sie ggf. mehr Aufwände für Hardware und Lizenzen haben. Bei der anderen Option haben Sie eine kostengünstigere Variante, die allerdings mit einem größeren Risiko behaftet ist. Oftmals können Sie im Fehlerfall kein Rollback nach dem Update durchführen.

Wie Sie sehen, haben Sie hier die Qual der Wahl. Dabei sollte die Wahl der Upgrade-Methode gut überlegt und anhand der aktuellen Geschäftssituation ausgewählt werden.

Diese folgenden Methoden zum Aktualisieren und Migrieren werden in der Branche am Häufigsten verwendet:

Sicherung und Wiederherstellen
Attach and Detach
Differenzielle Wiederherstellung großer Datenbanken
In-Place-Upgrade
Paralleles Upgrade (ohne Hochverfügbarkeit)
Laufendes Upgrade (mit Hochverfügbarkeit)

SQL Server Upgrade vs. SQL Server Migration

Viele denken, dass ein Upgrade und eine Migration ein und dieselbe Funktion sind. Doch weit gefehlt. Ein Upgrade und eine Migration werden oft im Kontext verwendet, beschreiben jedoch zwei unterschiedliche Szenarien in der Arbeit mit Datenbanken.

Ein Upgrade von SQL Server kann zum Beispiel eine Aktualisierung der Edition bedeuten. Beispielsweise. besitzen Sie gerade SQL Server 2019 Standard und möchten upgraden auf SQL Server 2019 Enterprise. Ein Upgrade bedeutet aber auch, dass Sie zum Beispiel von einer veralteten SQL Server Version wie 2016 auf die neuere, unterstützte Version 2019 aktualisieren. Das hat vor allem den Hintergrund, dass der Support bei älteren Versionen ab einem bestimmten Datum X eingestellt wird. Daher empfehlen wir immer, Ihre SQL Server möglichst aktuell und auf neueren Versionen laufen zu lassen.

Die Migration bedeutet im Gegenzug kein Upgrade auf eine neue SQL Server Version. Es bedeutet im Grunde, dass Sie eine Datenbank von Instanz A auf Instanz B verschieben (migrieren). Dies kommt beispielsweise bei einer Hardware- oder Betriebssystemaktualisierung vor. Oder sie hosten zu viele Datenbanken auf einer einzelnen SQL Server Instanz und wollen daher den Workload auf andere Instanzen verteilen. Hier empfiehlt sich eine Migration zur Lastenaufteilung. Weiterhin kann ein Upgrade auf eine neuere SQL Server Version eine Migration mit sich ziehen, jedoch wird diese dann durch das Upgrade bedingt.

SQL Server Upgrade mit Sicherung und Wiederherstellung

Bei dieser Methode handelt es sich um die gängigste Methode zur Aktualisierung der Datenbanken während einer Migration. Meist eignen sich Datenbanken mit weniger als 50GB für diese Upgrade-Methode. Allerdings ist diese auch abhängig von den bestehenden Ressourcen Ihrer virtuellen Maschine.

Angenommen Sie planen ein Upgrade einer SQL Server 2017 (dev Version) auf eine SQL Server 2019 (dev Version) inklusive Datenbankmigration. Dabei haben Sie 10 Dev-Datenbanken auf der SQL Server Instanz. Der Name der virtuellen Maschine lautet SQLVM1. SQL Server 2017 (dev Version) ist auf SQLVM1\SQL2017 installiert. Jede Entwicklungsdatenbank ist kleiner als 50GB und Sie haben entschieden, die Sicherungs- & Wiederherstellungsmethode zu verwenden.

Da es sich um eine Entwicklungsdatenbank handelt, ist die Dauer der Ausfallzeit kein sonderlich großes Problem. Wir starten mit der Sicherung der Datenbanken auf SQLVM1\SQLDev, indem wir einen SQL Server Agent Job mit einem Jobstep ”Do Backups” erstellen welcher folgendes Skript ausführt:

BACKUP DATABASE [Db1] TO DISK = N'C:\MSSQL\SQLBackups\Db1.bak' 
GO
BACKUP DATABASE [Db2] TO DISK = N'C:\MSSQL\SQLBackups\Db2.bak' 
GO

Mainzer Datenfabrik - SQL Server Upgrade Methoden

Danach erstellen wir den weiteren Agent Job zur Wiederherstellung der Datenbanken auf SQLVM1\SQL2019 und lassen ihn folgendes Skript ausführen:

RESTORE DATABASE [Db1] FROM  DISK = N'C:\MSSQL\SQLBackups\Db1.bak' 
GO
RESTORE DATABASE [Db2] FROM  DISK = N'C:\MSSQL\SQLBackups\Db2.bak' 
GO

Deinstallieren Sie nach einer ausführlichen Prüfung des Datenbankupgrades die alte SQL Server 2017 Instanz. Benennen Sie die neue Instanz (SQLVM1\SQL2019) in SQLVM1\SQLDev um.

SQL Server Upgrade mit Datenbanken Attach and Detach

Dies ist ebenfalls eine simple Methode zum Upgrade von Datenbanken während einer Migration. Allerdings zählt diese Variante nicht zu den empfohlenen Best-Practices. Im Grunde funktioniert die Attach & Detach Methode ähnlich zur eben beschriebenen Sicherungs- & Wiederherstellungsmethode. Für kleinere Datenbanken gilt Backup & Restore als sicherere Methode.

Das Szenario beschreibt sich so, dass sich Ihre QA Datenbankinstanz “SQLQA” auf einem älteren physischen Rechner befindet. Den besagten Rechner möchten Sie nun komplett ersetzen. In der SQLQA Instanz befinden sich 8 QA-Datenbanken mit einer Größe von weniger als 30GB. Die Dauer der Ausfallzeit ist nicht sonderlich wichtig, trotzdem sollte der Auftrag innerhalb eines Werktags erledigt sein, da morgen schon bereits die QA Datenbank benötigt werden könnte. Die Datenbanken sollen per Detach & Attach auf eine neue virtuelle Maschine “SQLVM2” verschoben werden. Ein Upgrade auf eine neuere SQL Server Version ist nicht notwendig.

Zunächst installieren Sie die SQL Server Instanz SQLQA2 auf der VM SQLVM2. Setzen Sie nun für jede Datenbank auf SQLQA folgenden Detach-Befehl ab:

USE [master] 
GO 
ALTER DATABASE [DB1] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO 
EXEC master.dbo.sp_detach_db @dbname = N 'DB1'
GO

Kopieren Sie anschließend die .mdf-, .ndf- und .ldf-Dateien auf den neuen Speicherort in SQLVM2. Danach führen Sie den folgendem Attach-Befehl für jede Datenbank auf der SQLVM2\SQLQA2 Instanz aus.

USE [master]
GO
CREATE DATABASE DB1  
     ON (FILENAME = 'C:\SQLBackups\DB1_Data.mdf'), (FILENAME = 'C:\SQLBackups\DB1_Log.ldf')
     FOR ATTACH ;

War die Migration erfolgreich, können Sie den physischen Rechner herunterfahren und außer Betrieb nehmen.

Wie bereits angemerkt, zählt diese Methode zu einer recht risikoreichen Methode. Beispielsweise können Unterschiede in der SQL Server Sortierung zwischen Quell- & Zielserver auftreten. Das führt dann wiederum zu einem Problem bei der Durchführung des Attach-Befehls. Auch auf Grund von Berechtigungsproblemen kann diese Methode fehlschlagen. So z.B. wenn der Service Account keine ausreichenden Berechtigungen auf den Ordner im Filesystem hat, in dem die kopierten Dateien abgelegt wurden. Weiterhin gehen beim Attach- & Detach Prozess auch hin und wieder Dateien verloren oder werden beschädigt.

Vor-Ort Upgrades vs. differenzielle Wiederherstellungs-Upgrades

Wir haben haben uns im oberen Bereich mit Upgrade-Methoden von Datenbanken mit weniger als 50GB beschäftigt. Doch was ist, wenn unsere Datenbanken größer als 50GB sind? Diesem Szenario gehen wir nun nach und schauen, welche hier die geeignetste Methode für ein SQL Server Upgrade darstellt. Konkret beschäftigen wir uns mit zwei Methoden:

Differenzielle Wiederherstellung für große Datenbanken
In-Place-Upgrade

Differenzielle Wiederherstellung

Das folgende Szenario gestaltet sich so, dass Sie eine Datenbank mit 500 GB im einfachen Wiederherstellungsmodus besitzen. Einmal die Woche, am Sonntagabend, wird ein vollständiges Backup durchgeführt. Die anderen Nächte werden differenzielle Backups durchgeführt. Diese große Datenbank befindet sich auf SQL Server 2012 als Quellserver. Sie haben nun einen weiteren SQL Server 2017 als Ziel und möchten die Datenbank vom Quell- auf den Zielserver migrieren. Die Netzwerkbandbreite zwischen beiden Rechenzentren liegt bei 10 GB und das einzig mögliche Migrationsfenster ist Samstagmorgen. Durch ein SLA ist eine weitere Anforderung, dass die Migration inkl. anschließendem Test innerhalb von 2 Stunden durchgeführt werden muss.

Da wir gewissenhafte und sorgfältige DBAs sind, haben wir bereits einige Zeit vor der Migration verschiedene Tests, Sicherungen, Kopien und Wiederherstellungen durchgeführt. Hilfreich ist es, bereits im Voraus so viel Arbeit wie möglich zu erledigen, damit es nicht kurz vor knapp stressig wird. Dokumentieren Sie dabei unbedingt Ihre Vorgänge und Ergebnisse.

Sie erstellen einen Dateikopier-Job, der nach dem vollständigen Sicherung am Sonntagabend gestartet wird. Am Montagmorgen überprüfen Sie, ob die Sicherungsdatei auf dem Zielserver verfügbar ist.
Führen Sie Montagnacht auf dem Zielserver aus eine geplante Wiederherstellung der letzten vollständigen Datenbanksicherung durch, ohne die Datenbank selbst wiederherzustellen. (RESTORE DATABASE WITH NORECOVERY)
Kopieren Sie die von Dienstag - Freitag die weiteren Backups auf den Zielserver und stellen Sie diese wieder her, ohne die Datenbank selbst wiederherzustellen.
Am Samstagmorgen sollten Sie gegen 7 Uhr (eine Stunde vor dem Wartungsfenster) eine differenzielle Sicherung auf dem Quellserver durchführen. Diese sollte gegen 8 Uhr erfolgreich durchgeführt sein.
Setzen Sie Ihre Datenbank schreibgeschützt um keine Daten zu verlieren und nutzen Sie das Wartungsfenster, um die geplante Wiederherstellung durchzuführen.
Kopieren Sie die letzte Differenzdatei manuell auf den Zielserver und stellen diesen mit RECOVERY wieder her.
Bringen Sie den Kompatibilitätsmodus auf den aktuellsten Stand.
Somit sollte die Datenbank auf eine neue SQL Server Version aktualisiert worden sein.
Verknüpfen Sie ihre Anwendungen mit der aktualisierten Datenbank.
Führen Sie anschließend umfangreiche Tests der Anwendungen durch und starten Sie einen vollständigen Back-Up Job auf dem Zielserver.

Diese Methode funktioniert in den meisten Fällen, wenn es sich um weniger komplexe Angelegenheiten handelt, aber große Datenbanken betroffen sind. Methoden wie die Sicherungs- & Wiederherstellung oder die Attach- & Detach Methode fallen hier raus, da sie die Anforderung der Durchführung eines Upgrades innerhalb von 2 Stunden nicht nachkommen können.

SQL Server Inplace Upgrade

Hier handelt es sich um eine Methode, die nicht bei Migrationen verwendet werden kann, da alle Aktionen hier auf einem Server stattfinden. Daher auch der Name “In-Place” Upgrade. Bei der In-Place Methode handelt es sich tatsächlich um die günstigste und schnellste Upgrade Option, allerdings auch gleichzeitig um die riskanteste. Wir empfehlen sie ausdrücklich nicht in Produktionsanwendungen anzuwenden, da die SQL Server Instanz umgehend aktualisiert wird und sollte etwas schief gehen, kein Rollback mehr möglich ist. Es werden automatisch alle Systemobjekte der System- & Benutzerdatenbanken aktualisiert. Abhilfe können Sie hier schaffen, indem Sie eine Datenbanksicherung inkl. gleicher Konfiguration und Services auf einem anderen Server mit einer älteren SQL Server Version durchführen. Oftmals entscheiden sich Firmen mit wenig Budget für Hard- & Softwarelizenzen für diesen Schritt. Sollte das Upgrade jedoch fehlschlagen, ist der Kostenapparat für eine Rückkehr zur alten Version deutlich höher.

Szenario: Angenommen Sie führen ein neues Produkt ein und schließen mit einem Anbieter darüber ein Proof of Concept ab. Dafür müssen Sie die Anwendung auf SQL Server 2012, SQL Server 2014 und SQL Server 2016 testen. Da Sie allerdings nur über begrenzte finanzielle Ressourcen verfügen, entscheiden Sie sich für die Installation der Anwendung inkl. aller Datenbanken auf SQL Server 2012. Sie führen nun ein Upgrade auf SQL Server 2014 durch, führen die gleichen Tests aus und wiederholen das mit SQL Server 2016.

Ausführung: Sie sparen theoretisch damit Zeit beim Sichern und Wiederherstellen der Datenbanken. In dieser Methode ist es nicht notwendig, Jobs, Anmeldungen und verknüpfte Dienste zu skripten um sie auf einem anderen Server wieder einzuspielen. Geht beim Upgrade etwas schief, liegt es an Ihnen, den Server von Grund auf neu aufbauen. Folgend können Sie dann vorgehen:

Wenden Sie alle erforderlichen Windows Updates & Patches auf einem vorhandenen Windows Server an.
Installieren Sie SQL Server 2012 und alle Service Packs.
Stellen Sie eine Verbindung zu Anbietertools her.
Erstellen Sie alle erforderlichen Datenbanken.
Führen Sie Tests durch.
Starten Sie den SQL Server 2014 Installationsassistenten und wählen die Option zum direkten Upgrade aus.
Folgende Warnung erscheint:

Installieren Sie alle verfügbaren Service Packs
Ändern Sie den Kompatibilitätsgrad der Datenbank
Führen Sie Tests durch und dokumentieren Sie ausreichend.
Wiederholen Sie nun den Vorgang mit SQL Server 2016.
Starten Sie den Installationsassistenten von SQL Server 2016
Wählen Sie das direkte Upgrade aus und ignorieren Sie alle Warnungen.
Wenden Sie auch hier wieder alle Service Packs an.
Ändern Sie den Kompatibilitätsgrad der Datenbank.
Führen Sie letzte Tests durch und dokumentieren Sie alles ausreichend.

Letztlich bleibt nur die Hoffnung, dass alles einwandfrei verläuft und keine Probleme auftreten. Auch hier ist zu sagen, dass diese Anwendungen Teil von SQL Server sind und nicht über Drittanbieter bezogen werden müssen.

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:

Deaktivieren Sie die Protokollversandaufträge auf SQL1 und SQL2.
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.

BACKUP LOG [DB3]   TO DISK = 'C:\SQLBackups\DB3.trn' WITH NORECOVERY;

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

Führen Sie die Jobs zum Kopieren und Wiederherstellen auf SQL2 manuell aus und stellen sie sicher, dass alle Logs angewendet wurden.
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.

RESTORE LOG DB3 FROM DISK = 'C:\SQL2012\SQL2\LogShip\DB3.trn' WITH RECOVERY

Erstellen Sie eine vollständige Sicherung von DB3 auf dem sekundären Server SQL2.
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.
Setzen Sie den Kompatibilitätsgrad der DB3 auf 140 mit folgendem Code:

USE [master] 
GO 
ALTER DATABASE [DB3] SET COMPATIBILITY_LEVEL = 140 
GO

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.
Sie können nun den Protokollversand wieder aktivieren.
Installieren Sie dafür die SQL Server 2017 Instanz SQL4 in der Domäne 1. Dies ist der neue sekundäre SQL Server.
Erstellen Sie nun einen Transaktionsprotokollversand von SQL3 nach SQL4.

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:

RESTORE DATABASE [DB3] WITH RECOVERY;

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:

Bauen Sie die Netzwerkbandbreite zwischen beiden Servern und dem zweiten Rechenzentrum auf das Maximum aus.
Fügen Sie den Verfügbarkeitsgruppen den Disaster Recovery Server SQL3 als drittes asynchrones Replikat hinzu.
Aktualisieren Sie SQL3. SQL1 und SQL2 laufen dabei synchron.
Aktualisieren Sie anschließend SQL2. Während des Upgrades sind SQL1 und SQL3 synchron.
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.
Aktualisieren Sie im Nachgang SQL1 und stellen die Verfügbarkeitsgruppe wieder her. Synchronisieren sie nach dem Upgrade wiederum mit SQL2
Bei Bedarf können Sie nun auch noch ein Failover von AG1 und AG2 auf SQL1 durchführen.

Fazit

In diesem umfangreichen Artikel haben wir Ihnen verschiedene mögliche Optionen zum Upgrade Ihrer veralteten SQL Server Versionen auf neuere, unterstützte Versionen vorgestellt. Letztlich sind alle Methoden eine Option für Sie, jedoch sollten Sie zwingend im Vorgang alle Eventualitäten überprüfen, Kosten und Nutzen abwägen und entsprechend Ihrer RPO und RTO Faktoren die Entscheidung für oder gegen eine Methode treffen.

Als zertifizierte Spezialisten auf diesem Gebiet, können wir Ihnen bei der Entscheidungshilfe, oder aber auch bei der Durchführung einer Migration oder einem Upgrade zur Seite stehen. Unsere Experten stehen Ihnen für ein unverbindliches Beratungsgespräch gerne zur Verfügung. Kontaktieren Sie uns dafür ganz einfach über unser Kontaktformular.