Upgrade zu einer neueren SQL Server Version

Bei der Arbeit mit SQL Server kommen wir früher oder später immer an den Punkt, dass alte Versionen überholt und von einer neueren Version abgelöst werden. Tatsächlich ist es dann an der Zeit, Upgrades vorzunehmen und Daten in die neuere Version zu migrieren, da der Support der alten Versionen nach und nach eingestellt und somit nicht mehr bedient wird. Die Modernisierung der Datenbestände ist hier die Devise.

Wie Sie SQL Server ganz einfach von einer alten auf eine neue Version upgraden können, erklären wir Schritt für Schritt in dieser Anleitung. Zusätzlich gehen wir auf die notwendige Datenmigration mit dem SQLSyncer ein.

Zur Vorbereitung

Bevor wir starten, überprüfen wir alle notwendigen Voraussetzungen für das Upgrade auf eine neuere SQL Server Version.

In diesem Zuge betrachten wir auch alle unterstützten Technologien, die unser Upgradeszenario begleiten. In der nachfolgenden Liste führen wir alle seit März 2019 unterstützte Quell- & Zielversionen auf:

SQL Server QuellversionenSQL Server Zielversionen
SQL Server 2005SQL Server 2014
SQL Server 2008, SQL Server 2008 R2SQL Server 2016
SQL Server 2012SQL Server 2017 unter Linux
SQL Server 2014SQL Server 2017 unter Windows
SQL Server 2016 

Nachfolgend gehen wir auf einzelne Upgradeszenarien ein und welche Migrationsoptionen mit den neuen Versionen unterstützt werden.

SQL Server 2005

→ Upgrade auf SQL Server 2014, 2016 und 2017

  • Unterstützung durch den SQLSyncer
  • Backup and Restore – Backups von SQL Server 2005 können in SQL Server 2014, 2016 und 2017 wiederhergestellt werden
  • Bulk load – Tabellen können von SQL Server 2005 auf SQL Server 2014, 2016 und 2017 kopiert werden

SQL Server 2008 oder SQL Server 2008 R2

→ Upgrade auf SQL Server 2014, 2016 und 2017 

  • Unterstützung durch den SQLSyncer
  • Backup and Restore – Backups von SQL Server 2008 und 2008 R2 können in SQL Server 2014, 2016 und 2017 wiederhergestellt werden
  • Datenbankspiegelung – Die Datenbankspiegelung wird unterstützt, insofern auf dem Quellserver SQL 2008 mindestens SP3 oder höher (SP2 oder höher auf 2008 R2) und auf dem Zielserver SQL Server 2014, 2016 oder 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2014, 2016 oder 2017 somit zur Hauptinstanz wird, ist die SQL Server 2008 (2008 R2) Instanz der Spiegel und erhält keine weiteren Änderungen der Hauptinstanz.
  • Protokollversand – Der Protokollversand wird unterstützt, insofern primär auf SQL Server 2008 SP3 oder höher (SP2 oder höher auf 2008 R2) und sekundär SQL Server 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2014, 2016 oder 2017 somit zur Hauptinstanz wird, ist die SQL Server 2008 (2008 R2) Instanz sekundär und erhält keine weiteren Änderungen der Hauptinstanz.
  • Bulk load – Tabellen können von SQL Server 2008 oder SQL Server 2008 R2 auf SQL Server 2014, 2016 und 2017 kopiert werden

SQL Server 2012

→ Upgrade auf SQL Server 2014, 2016 und 2017 

  • Unterstützung durch den SQLSyncer
  • Backup and Restore – Backups von SQL Server 2012 können in SQL Server 2014, 2016 und 2017 wiederhergestellt werden
  • Availability Group – Always On Availability Gruppen werden unterstützt, wenn auf dem primären Replikat SQL Server 2012 SP2 oder höher und auf dem sekundären Replikat SQL Server 2014, 2016 oder 2017 ausgeführt werden. Wenn ein Failover ausgeführt und ein SQL Server 2017 zur primären Instanz wird, wird die SQL Server 2012 Instanz sekundär und kann keine Änderungen von der primären SQL Server 2014, 2016 oder 2017 Instanz empfangen.
  • Datenbankspiegelung – Die Datenbankspiegelung wird unterstützt, insofern auf dem Quellserver SQL 2012 mindestens SP1 oder höher und auf dem Zielserver SQL Server 2014, 2016 oder 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2014, 2016 oder 2017 somit zur Hauptinstanz wird, ist die SQL Server 2012 Instanz der Spiegel und erhält keine weiteren Änderungen der Hauptinstanz.
  • Protokollversand – Der Protokollversand wird unterstützt, insofern primär auf SQL Server 2012 SP1 oder höher und sekundär SQL Server 2014, 2016 oder 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2014, 2016 oder 2017 somit zur Hauptinstanz wird, ist die SQL Server 2012 Instanz sekundär und erhält keine weiteren Änderungen der Hauptinstanz.
  • Bulk load – Tabellen können von SQL Server 2012 auf SQL Server 2014, 2016 und 2017 kopiert werden

SQL Server 2014

→ Upgrade auf SQL Server 2017 und 2016 

  • Unterstützung durch den SQLSyncer
  • Backup and Restore – Backups von SQL Server 2014 können in SQL Server 2016 und 2017 wiederhergestellt werden
  • Transaktionsreplikation – Die Transaktionsreplikation von SQL Server 2014 auf SQL Server 2017 wird unterstützt
  • Availability Group – Always On Availability Gruppen werden unterstützt, wenn auf dem primären Replikat SQL Server 2014 und auf dem sekundären Replikat SQL Server 2016 oder 2017 ausgeführt werden. Wenn ein Failover ausgeführt und ein SQL Server 2016 oder 2017 zur primären Instanz wird, wird die SQL Server 2014 Instanz sekundär und kann keine Änderungen von der primären SQL Server 2016 oder 2017 Instanz empfangen.
  • Datenbankspiegelung – Die Datenbankspiegelung wird unterstützt, insofern auf dem Quellserver SQL 2014 und auf dem Zielserver SQL Server 2016 oder 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2016 oder 2017 somit zur Hauptinstanz wird, ist die SQL Server 2014 Instanz der Spiegel und erhält keine weiteren Änderungen der Hauptinstanz.
  • Protokollversand – Der Protokollversand wird unterstützt, insofern primär auf SQL Server 2014 und sekundär SQL Server 2016, 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2016 oder 2017 somit zur Hauptinstanz wird, ist die SQL Server 2014 Instanz sekundär und erhält keine weiteren Änderungen der Hauptinstanz.
  • Bulk load – Tabellen können von SQL Server 2014 auf SQL Server 2016 und 2017 als Massenkopie kopiert werden

SQL Server 2016

→ Upgrade auf SQL Server 2017

  • Unterstützung durch den SQLSyncer
  • Backup and Restore – Backups von SQL Server 2016 können in SQL Server 2017 wiederhergestellt werden
  • Transaktionsreplikation – Die Transaktionsreplikation von SQL Server 2016 auf SQL Server 2017 wird unterstützt.
  • Availability Group – Always On Availability Gruppen werden unterstützt, wenn auf dem primären Replikat SQL Server 2016 und auf dem sekundären Replikat SQL Server 2017 ausgeführt werden. Wenn ein Failover ausgeführt und ein SQL Server 2017 zur primären Instanz wird, wird die SQL Server 2016 Instanz sekundär und kann keine Änderungen von der primären SQL Server 2017 Instanz empfangen.
  • Datenbankspiegelung – Die Datenbankspiegelung wird unterstützt, insofern auf dem Quellserver SQL 2016 und auf dem Zielserver SQL Server 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2017 somit zur Hauptinstanz wird, ist die SQL Server 2016 Instanz der Spiegel und erhält keine weiteren Änderungen der Hauptinstanz.
  • Protokollversand – Der Protokollversand wird unterstützt, insofern primär auf SQL Server 2016 und sekundär SQL Server 2017 ausgeführt wird. Wenn ein Failover durchgeführt und SQL Server 2017 somit zur Hauptinstanz wird, ist die SQL Server 2016 Instanz sekundär und erhält keine weiteren Änderungen der Hauptinstanz.
  • Bulk load – Tabellen können von SQL Server 2016 auf SQL Server 2017 als Massenkopie kopiert werden

Für unser Migrationsprojekt benötigen wir weitere Features, die wir vorbereitend jetzt herunterladen:

Im nächsten Schritt stehen wir unmittelbar vor dem Migrationsprozess. Wichtig ist, vorher eine umfassende Bestandsaufnahme der zu migrierenden Datenbanken durchzuführen, sie hinsichtlich eventuell aufkommender Risiken zu untersuchen und Probleme zu beheben. Bei beispielsweise heterogenen Migrationen (Oracle → Azure) müssen Schemata konvertiert werden, da sie im ursprünglichen Zustand nicht kompatibel mit der Zielumgebung sind. Bei einer homogenen Replikation (SQL Server – SQL Server) ist das nicht notwendig.

Um ebendiese Risiken zu untersuchen und überhaupt zu finden, scannen wir unsere vorhandenen Instanzen auf Details und Funktionen die die Migration positiv unterstützen. Dafür verwenden wir die Anwendung MAP Toolkit, welche wir bestenfalls bereits heruntergeladen und installiert haben.

Discover Phase 

→ Wir öffnen das MAP Toolkit und wählen im linken Bereich “Database” aus. Nachfolgend erstellen wir eine Inventardatenbank über den Button “create/select database”.

Nachdem wir die Inventardatenbank “MyPCInventory” erstellt haben, sammeln wir unsere Daten aus der erstellten Datenbank über einen Klick auf den SQL Server Discovery Button “collect inventory data”. Danach gelangen wir in den Iventory and Assessment Wizard der uns als Assistent durch den Prozess leitet. Nun wählen wir das Szenario aus, in dem wir SQL Server und SQL Server with Database Details anklicken und mit weiter bestätigen. Wir werden nun aufgefordert, die Methodenoptionen auszuwählen, die Computer durchzusuchen, auf denen Microsoft Produkte gehostet werden.

Wir geben die Anmeldeinformationen für die Systeme ein, die wir untersuchen möchten und klicken auf ‘Weiter’. Anschließend legen wir noch die Reihenfolge der Anmeldeinformationen fest.

Haben wir alle benötigten Infos eingegeben und die Reihenfolge festgelegt, werden wir nun aufgefordert, die Anmeldeinformationen für alle zu durchsuchenden Computer anzugeben. Diese können wir individuell für jeden Computer verwenden oder die Liste aller Computeranmeldeinformationen verwenden. Nach einer kurzen Überprüfung der Auswahl bestätigen wir und lassen den Assistenten die Inventardatenbank erstellen. Abschließend erhalten wir den Abschlussbericht zur Datenerfassung.

→ Berichterstellung und Datenerfassung 

Nach der Datenerfassung in der Inventardatenbank gelangen wir wieder auf unseren Hauptscreen zurück und können uns alle bisher abgeschlossenen Datenbankermittlungen erneut anschauen. Über das Feld ‘Options’ haben wir zusätzlich noch die Möglichkeit, Berichte über die SQL Server Bewertung und Datenbankdetails erstellen zu lassen. Wir klicken auf ‘Generate SQL Server Assessment Report’ und warten einen kurzen Augenblick bis wir die Bestätigung der Berichterstellung erhalten haben. Der entsprechende Bericht öffnet sich, sobald wir das Aktionsfenster geschlossen haben.

→ Beurteilung

Nachdem wir nun unsere Datenquellen identifiziert haben, müssen wir als nächstes die Aktualisierung der lokalen SQL Server Instanz auf eine neuere Version bewerten. Das hilft dabei, die Änderungen und Lücken zwischen der Quell- & Zielinstanz besser verstehen zu können. Wir verwenden hierbei den Data Migraton Assistant (SQLSYNCER) um unserer Quelldatenbank zu bewerten, bevor wir auf eine neuere SQL Server Version upgraden.

Bewertungsphase 

Bevor wir mit der Migration starten, bewerten wir zunächst unsere Datenbanken hinsichtlich Kompatibilität, Kapazität und Funktionen. Dafür verwenden wir den Data Migration Assistant und führen ein Datenbanken-Assessment durch.

  1. Über das ‘+’ erstellen wir ein neues Assessment-Projekt und legen SQL Server als Quelle und Ziel fest.
  2. Legen Sie die Zielversion von SQL Server fest, auf die Sie upgraden möchten
  3. Wählen Sie eine oder beide Bewertungsoptionen aus (Kompatibilitätsprobleme / Funktionsempfehlungen)
  4. Geben Sie im nächsten Schritt den Namen der SQL Server Instanz an, zu der eine Verbindung hergestellt werden soll.
  5. Wählen Sie den Authentifizierungstyp und Verbindungseigenschaften und klicken auf ‘verbinden’.
  6. Fügen Sie nun Quellen, bzw. zu bewertende Datenbanken aus
  7. Starten Sie die Bewertung

Die Dauer der Bewertung kann von der Anzahl der hinzufügten Datenbanken und den Schematagrößen abhängig sein. Ergebnisse werden Datenbankspezifisch angezeigt, sobald sie verfügbar sind. Mit einem Klick auf die jeweilige Datenbank, können Sie sich dann die einzelnen Bewertungen anzeigen lassen.

Folgende Kriterien sollten Sie beachten:

  • Kompatibilitätsprobleme
  • Verhaltensänderungen
  • veraltete Funktionen
  • Leistung
  • Speicher
  • Sicherheit
  • Funktionsempfehlungen (In-Memory-OLTP, Columnstore, Stretch Database, Always Encrypted, Dynamic Data Masking, Transparent Data Encryption)

Nachdem die Datenbankbewertungen abgeschlossen sind, können Sie den Bericht als JSON- oder CSV-Datei exportieren und individuell analysieren.

Führen Sie eine heterogene Migration durch, Sie die Schemata so konvertieren, dass sie in der neuen Zielumgebung funktionieren. Ist die Migration homogen, also von SQL Server zu SQL Server, ist eine Konvertierung nicht notwendig.

Migration 

Für die Migration unserer Daten von einer veralteten SQL Server Version in eine neue, nutzen wir die Migrationsanwendung SQLSyncer.

Um mit der Migration zu beginnen, starten wir den SQLSyncer. Zunächst müssen wir eine neue Konfiguration für die Migration anlegen. Dafür klicken wir auf dem Startbildschirm die mittlere Schaltfläche ‘Configuration’ an. Alternativ geht dies auch über den Menü-Punkt auf der linken Seite der Anwendung.

Der SQLSyncer leitet uns nun durch den Konfigurationsprozess.

  1. Configuration-Name: Wir legen den Namen fest, mit dem die Konfiguration in Zukunft identifiziert werden soll. Dieser Name ist frei wählbar.

Mit einem Klick auf den Pfeil nach rechts, oder durch das Drücken der Tab-Taste geht es weiter in den Einstellungen.

2. Connection Properties: SQLSyncer braucht nun die Informationen zum Quell- & Zielserver, zwischen denen die Migration stattfinden soll. Dafür geben wir den Hostnamen oder die IP-Adresse, sowie den SQL Port und den Servertyp jeweils ein.

3. Transfer Properties: Mit den Transfer Properties legen wir fest, ob wir Datenbanken migrieren oder synchronisieren möchten. Zusätzlich können wir bei der Migration bestimmen, ob nur Tabellenstrukturen oder auch der Inhalt migriert werden soll.

4. Authentication Properties: Um die Migration überhaupt durchführen zu können, müssen wir uns entsprechend mit einem Login authentifizieren. Wir haben die Wahl zwischen dem SQL Server User Login oder der Active-Directory. Wichtig!: Sowohl auf dem Quell- als auch auf dem Zielserver müssen ausreichende Berechtigungen (sysadmin) vorhanden sein.

5. Select Databases, Tables, Views, Procedures & Functions: Nachfolgend legen wir individuell unsere Migrationsobjekte fest. Dabei wählen wir Datenbanken, einzelne Tabellen, Sichten, Prozeduren und Funktionen beliebig für die Migration aus. Über die Multiple Choice Auswahl können wir auch mehrere Objekte auswählen.

6. Schedule: Mit einer Schedule weisen wir nun den SQLSyncer an, die Migration entweder einmalig, periodisch, zu einem bestimmten Zeitpunkt oder nach einer vorangegangenen Migration durchzuführen. Wählen wir keine der angebotenen Optionen aus, führen wir die Migration am Ende selbst manuell aus.

7. Notification: Ist die Migration der Datenbanken beendet, können wir uns von SQLSyncer über die Ergebnisse benachrichtigen lassen. Auch hier haben wir wieder die Wahl. Wir können uns sowohl per Email als auch per Slack Nachricht über den Ergebnisausgang der Datenbankmigration unterrichten lassen.

9. Steps: Im letzten Schritt des Konfigurationsprozess bekommen wir die Möglichkeit neben unser angelegten Konfiguration weitere Schritte bzw. Aktionen inklusive einer Reihenfolge hinzuzufügen. Über ‘Create’ erstellen wir den finalen Prozess und gelangen umgehend auf den ‘Excecution’ Screen.

Execution / Migration

In der Execution Oberfläche sehen wir nun die Übersicht unserer eben angelegten Konfiguration. Um die Migration nun zu starten, müssen wir uns erneut authentifizieren. Dafür verwenden wir dieselbe Authentifizierung wie in der Konfiguration festgelegt. Weiterhin haben wir noch die Chance, letzte Änderungen vorzunehmen, indem wir über ‘Properties’ die Detaileinstellungen einsehen können. Zum Start klicken wir auf den Button ‘Start’ und lassen die Datenbankmigration durchführen.

Dass die Migration durchgeführt wird sehen wir zum Einen an den ‘Running Configurations’ und zum Anderen an dem sich aufbauenden Progressbalken. Ist die Migration beendet, lassen wir uns über ‘Show History’ die Ergebnisse anzeigen. Mit einem Klick auf den Konfigurationsnamen gelangen wir in die detaillierten Ergebnisprotokolle.

Nach der Migration / Auswertung

Um zu testen, ob die Migration erfolgreich war, sollten wir nun einige Anwendungen und Funktionen ausführen. Dafür überprüfen wir, ob die Daten in der neuen Zielumgebung verfügbar sind. In Einzelfällen müssen individuelle Änderungen an den Anwendungen vorgenommen werden, falls das nicht der Fall ist.

Der DEA (Data Experimentation Assistant) unterstützt uns in der Auswertung der SQL Server Zielumgebung. → Installieren des DEA-Tools

Ausführen von Capture Traces 

  1. Klicken auf das “Kamera Symbol” um eine neue Aufnahme zu starten
  2. Eingabe von Trace-Namen, Dauer, SQL Server Instanz, Datenbankname und Freigabespeicherort
  3. Start

Ausführen von Replay Traces

  1. Wählen Sie New Replay
  2. Eingabe von Wiedergabenamen, Name des Controller-Computers, Pfad der Quell-Trace-Datei auf dem Controller, SQL Server Instanzname, Speicherpfad der Ziel-Trace-Datei
  3. Start

Ausführen von Analysis Report 

  1. Wählen Sie Analysis Reports 
  2. Herstellen einer Verbindung zum SQL Server, auf dem die Berichtsdatenbanken gespeichert sind
  3. Wählen Sie ‘new Report’
  4. Eingabe von Berichtsnamen und Pfaden der Ablaufverfolgung für Quell- & Zielserverinstanzen
  5. Start

Nachdem wir einen Analysebericht erstellt haben, überprüfen wir ihn hinsichtlich Versions- und Buildinformationen auf dem Zielserver. Der Schwellenwert zeigt uns hier die Toleranzen der A / B-Testanalyse an. Mit einem Klick auf die einzelnen Abfragen lassen wir uns letzen Endes die Leistungszusammenfassungen, Fehler- und Abfrageplaninformationen anzeigen und können sie individuell evaluieren. Die Phase nach der Migration ist entsprechend wichtig für uns, da sich hier noch Schwierigkeiten in der neuen Zielumgebung optimieren und in Einklang bringen lassen.