Marco Bandner

In den vorigen Teilen dieser Blog-Serie zur Migration des Microsoft SQL Server Data Warehouse von Version 2012 auf Version 2014 lag der Schwerpunkt in der Vorbereitung der Migration. In diesem Teil gehen wir auf die Migration der Datenbanken ein. Das Data Warehouse besteht dabei aus den beiden Hauptdatenbanken Backroom und Frontroom im Terabyte Bereich.

Das Vorgehen bei der Migration der SQL Server Datenbanken ist sehr stark abhängig vom jeweiligen Migrationstyp. Daher ist Dieser frühzeitig festzulegen und in der Planung entsprechend zu berücksichtigen, wie wir bereits in Teil 3 – der Analysephase – vorgestellt hatten.

Die Datenbank Migrationen sind zwingende Voraussetzung, bevor die eigentlichen Migrationen der Integration Services Solutions (ETL Pakete) starten können.

Es sind drei Migrationstypen denkbar, jeder weißt verschiedene Vor- und Nachteile auf:

Die Neuinstallation:
Bei der Neuinstallation wird der zu migrierende Server vollständig neu aufgesetzt. Es kann hierzu auch eine andere bzw. neue Maschine verwendet werden. Der Vorteil dieses Migrationstyps liegt darin, dass nach erfolgreicher Migration ein sauberes System des SQL Servers 2014 vorliegt. Es sind also keinerlei Reste der vorigen Version 2012 vorhanden, welche sich eventuell als störend erweisen könnten (bspw. alte DLLs oder Assemblies).

Zu den Nachteilen gehören:

  • der Aufwand für die Installation und Konfiguration des neuen Systems
  • der Aufwand für die Sicherung und das Wiedereinspielen der Daten nach der Neuinstallation
  • ebenso muss die Wiederherstellung bestimmter Konfigurationen vom Alt- auf das Neusystem sichergestellt werden
  • die Downtime, falls die Neuinstallation auf der gleichen Maschine erfolgen soll. Dieser Nachteil entfällt, falls auf eine neue Maschine migriert werden sollte.

Parallelinstallation:

In diesem Fall wird die Migration des SQL Servers 2012 auf 2014 zwar auf der gleichen Maschine vorgenommen, aber auf einer neuen Instanz in Version 2014. Hierzu werden neben die bestehende Installation in Version 2012 die zu migrierenden SQL Server Services in Version 2014 installiert. Nach erfolgreicher Installation und Konfiguration der neuen Instanz können die Datenbanken umgeschwenkt werden. Dies kann durch ein detach der Datenbank-Dateien auf dem Altsystem und einem anschließenden attach auf dem neuen System in Version 2014 erfolgen. Der Vorteil liegt hier vor allem in der sehr kurzen Downtime.

Nachteile dieser Variante:

  • Durch die Installation des SQL Server 2014 entsteht eine neue zusätzliche Instanz. Diese Instanz kann nicht als Default-Instanz genutzt werden. Daher muss explizit auf sie verwiesen werden, was zu Folgeaufwänden und Folgerisiken führt.
  • Erhöhter Storage-Bedarf durch die parallele Installation der SQL Server 2012 und 2014 – Co-Existenz der Sourcen der SQL Server 2012 und 2014
  • Hinzu kommt, dass die Installation des SQL Server 2012 für die migrierten Sourcen nicht mehr nutzbar ist, da dies ein (nicht mögliches) Downgrade erfordern würde.

Inplace-Upgrade:

Beim Inplace-Upgrade erfolgt die Migration des SQL Servers, indem die Version 2014 sinnbildlich über die 2012er-Instanz darüber installiert wird. Die Sourcen und Datenbanken werden hierbei automatisch migriert. Die Vorteile liegt darin, dass die Migration automatisch erfolgt, bestehende Konfigurationen übernommen werden und die Instanz weitergenutzt werden kann (als Default oder Named). Des Weiteren ist nur eine geringe Downtime einzuplanen.

Nachteile des Inplace-Upgrades:

  • Nach dem Upgrade ist kein Rückschwenk bzw. Fallback auf Version 2012 möglich. Aus diesem Grund sind vollständige Sicherungen des Server-Betriebssystems des SQL Servers 2012 inkl. der Datenbanken notwendig.
  • Prinzipiell denkbar wäre auch eine Verunreinigung von Windows, da das Inplace-Upgrade teilweise über die bestehenden Sourcen der Version 2012 installiert. Wir hatten diesbezüglich bisher jedoch noch keine negativen Erfahrungen gemacht.

In unserem Kundenprojekt wurde als Migrationstyp im Rahmen der SQL Server Migration das Inplace-Upgrade festgelegt. Grund war, dass es sich hierbei um das schnellere und auch einfachere Verfahren handelt. Eventuelle Risiken wurden im Vorfeld minimiert, da im Migrationsprojekt ein intensiver Parallelbetrieb sowie eine regelmässige Qualitätssicherung auf einer produktionsnahen Abnahmeumgebung eingeplant wurden. Aktuelle Backups des Betriebssystems, des SQL Servers und der Datenbanken standen ohne Zusatzaufwand zur Verfügung, da diese vom IT-Dienstleister regelmässig von der Produktivumgebung erstellt wurden. Somit war auch die Möglichkeit der Wiederherstellung des Produktivsystems im Problemfall sichergestellt.

Das Inplace-Upgrade sowie die damit automatisch verbundene Migration der Datenbanken verlief ohne Schwierigkeiten. Das Compatibility Level der Datenbanken wurde durch die Migration nicht erhöht. Nach einigen Wochen problemlosen Produktiv-Betrieb wurde das Compability Level von 2012 auf 2014 erhöht:

.CompabilityLevel

Auch hier konnten keine Probleme festgestellt werden – nach nun über einem Jahr produktiven Betrieb.

 

Überblick über die Blog-Serie:

  1. Projekt und Überblick
  2. Organisation und Projektplanung
  3. Analysephase
  4. Client Arbeitsumgebungen
  5. Datenbanken
  6. Integration Services