
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

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.