Put your data to the cloud Teil 2

Migrieren einer SQL Server-Datenbank in eine Azure SQL-Datenbank, Teil 2

Sind die Kompatibilitätsprobleme etwas komplexer und beinhalten auch Schemaänderungen und/oder Änderungen in den Funktionalitäten (einzelne Datenbankserver oder Betriebssystem Funktionen, die in Azure nicht zur Verfügung stehen, müssen anderweitig abgebildet werden) sollte aus Gründen der besseren Projektierung ein Visual Studio Datenbankprojekt aufgebaut werden.

In diesem Fall lässt sich wie folgt vorgehen:

1. Erstellen eines neuen Datenbank-Projektes in „Visual Studio“ mit den SQL-Server Data Tools. In Visual Studio lässt sich über den SQL Server Objekt Explorer ein neues Datenbank Projekt erstellen.

2. Im „Import Database“ Dialog dann die notwendigen Einstellungen treffen. Dabei sollte in den „Import Settings“ die Option „Import application-scoped objects only“ ausgewählt sein und der Import von „referenced logins“, „permissions“ und database settings“ nicht. Danach sind dann die Datenbankstrukturen und Objekte in das Projekt zu importieren.

3. Die Zielplattform in den Projekt-Einstellungen setzen. Microsoft Azure SQL Database V12, oder die gewünschte Plattform.

4. Ein „Snapshot“ des Projektes erstellen. Dies hilft später in jeder Phase des Projektes mit der Möglichkeit, die Änderungen zu analysieren (Schema Compare).

5. Über einen „Build-Prozess“ des Projektes oder die Ergebnisse aus dem Data Migration Assistant die entsprechenden Änderungen an Schema, Struktur und Funktionen identifizieren.

6. Die entsprechenden Änderungen innerhalb des Projektes entwickeln.

7. Über einen „Publish“ des Projektes eine neue angepasste Kopie der Quelldatenbank (Target Plattform für den Publish hierfür anpassen) erstellen. Es sollte mindestens einmal eine Datenbankkopie der Struktur erstellt werden, in der dann die eventuell notwendigen Änderungen in den Daten durchgeführt werden.

8. Über eine Schleife der Punkte 3. bis 7. die zu erreichende und notwendige Kompatibilität entwickeln und Funktionalität bereitstellen.

9. Die im Ziel erstellte und kompatible Datenbankkopie nach Azure übertragen. Dies kann wie oben beschrieben über den Export und Import mit BACPAC-Dateien erfolgen oder über das Management Studio (SSMS)

10. Auch hier folgt dann das Einstellen des Kompatibilitätslevels der Azure SQL-Datenbank mit den T-SQL Befehlen „ALTER DATABASE Compatibility Level“ und/oder „ALTER DATABASE SCOPED CONFIGURATION“.

11. Ebenso das Ein- und Erstellen der Metadaten wie User, Rechte, Eigenschaften und dergleichen

12. Und natürlich Test, Test, test …

Test, test, test … steht natürlich für eine ausreichende Validierung der Migration und soll darauf hinweisen, möglichst bald das Testteam mit einzubeziehen.

Es gilt hierbei zu beachten, dass die zwei beschriebenen Vorgehensweisen (Teil 1 und Teil 2) nicht die einzig möglichen sind. Ist z.B. eine „problemlose“ Migration/Update nach SQL-Server 2016 möglich, ist meist auch eine einfache Migration nach Azure mit einem Export/Import oder sogar einem Wizard im SSMS möglich. Oder ist die Toleranz betreffend der Ausfallzeiten sehr gering, ist eventuell eine Migration mit Hilfe einer transaktionsbasierten Replikation erforderlich.

Die Ausfallzeiten lassen sich über die Skalierung bei Verwendung von SqlPackage.exe sowie einer beim Import zeitweisen Erhöhung des Service Tiers (Servicelevel) und der Database Transaction Units (DTUs, Leistungsstufen) für die Azure SQL-Datenbank verringern.

Ebenso können die Ausfallzeiten verringert werden, indem einzelne Objekte wie indizierte Views oder ältere Verlaufsdaten nicht migriert werden, sondern nach der Migration neu erstellt werden. Auch das Partitionieren von Tabellen und Indizes sowie das Deaktivieren von automatischen Tasks zur Statistik und Performance gehören dazu. Dies kann alles nach der Migration in der Azure SQL-Datenbank neu erstellt oder wieder eingeschaltet werden.

Bei umfangreicheren Änderungen an Struktur und den Daten während der Migration sollten Größe und Leistung der TempDB und Transaktions-DB überwacht und frühzeitig optimiert werden.

Im Netz, bei Microsoft und den verschiedenen Foren und Blocks finden sich reichlich Informationen, Beispiele und Hinweise, so dass ich hier nicht die einzelnen Links angeben möchte. Zumal sie bei der derzeitig sehr dynamischen Weiterentwicklung von Azure zum Teil eine sehr geringe Halbwertszeit haben.

Es sollte immer die Entstehungszeit und die Versionsstände der verwendeten Informationen und Tools abgeglichen und reflektiert werden. So ist zum Beispiel oft ein „SQL Azure Migration Wizard (SAMW)“ zu finden, der aber zwischenzeitlich komplett vom o.g. DMA ersetzt wurde.