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'
GOKopieren 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
RECOVERYwieder 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.
