Daten sind unsere Leidenschaft!

Put your data to the cloud Teil 1

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

Wie bei jedem Hype entsteht schnell ein Begriffs-WirrWarr, daher möchte ich zunächst die Verwendung der Begrifflichkeiten klären.

Für die klassische on-premise Datenbank möchte ich den Begriff „SQL Server Datenbank“ verwenden. Da Azure verschiedene Möglichkeiten bietet, eine Datenbank in der Cloud zu halten, ist es wichtig die verschiedenen angebotenen Techniken klar auseinander zu halten.

Somit soll „SQL Server on Azure VM“ für den Betrieb einer SQL-Server Datenbank in einer virtuellen Maschine, die in Azure läuft stehen (IaaS). Und „Azure SQL-Datenbank“ für den Betrieb einer SQL-Datenbank (eben ohne „Server“) in Azure (PaaS oder DBaaS). Es wird schnell ersichtlich, dass in diesem Fall eben kein vollständiger „SQL-Server“ und keine VM mit Betriebssystem zur Verfügung stehen.

Wie somit aus dem Titel bereits erkennbar, soll dieser Artikel die Migration einer on-premise Benutzerdatenbank einer „SQL-Server Datenbank“ in eine Azure SQL-Datenbank beschreiben. Eine Migration einer „SQL-Server Datenbank“ in einen „SQL Server on Azure VM“, ist im Prinzip vergleichbar eines Updates von einer SQL-Server Datenbank. Und er kann auch mit den gleichen Methoden wie Backup/Restore, ETL bzw. SSIS, Copy/Clone, Replikation … und bis zur Verwendung von „Always Availability Groups“ durchgeführt werden.

Steps

Die grundlegenden Steps einer Migration in eine Azure SQL-Datenbank unterscheiden sich im Vergleich zu anderen Migrationen nicht,

Sie sind im Wesentlichen:

  • Data Quality + Data Cleansing
    (Ja, dieser Step beschreibt sicherlich die „heile Welt“ und nicht die wirkliche und findet daher meist nicht statt. Im Sinne der Migration kann es aber nur Vorteile haben, nicht auch alle „Datenleichen“, technischen Schulden und Altlasten durch die Migration zu schleppen.)

  • Ermitteln der Kompatibilität bzw. der Kompatibilitätsprobleme

  • Lösen der Kompatibilitätsprobleme
    (Dies ist der spannendste, kreativste und oft auch aufwendigste Step. Er entscheidet daher auch über die weiteren Szenarien der Migration. Außerdem führt dieser Step manchmal doch noch zu einer – zumindest teilweisen – Durchführung von Step 1 (Data Quality + Data Cleansing)).

  • Ermitteln und Übertragen der Metadaten wie Rollen, User, Rechte usw.

  • „eigentliche“ Migration, bzw. das Übertragen von Schema und Daten

  • Datenbank-Eigenschaften der Azure SQL-Datenbank einstellen

Tools

Da die Migration nach Azure zurzeit noch Microsoft-lastig ist, und Tools von anderen Anbietern erst langsam eine Anbindung an Azure bieten, sollen die Hauswerkzeuge von Microsoft hier genügen:

  • SQL Server Management Studio (SSMS)

  • SQL Server Data Tools für Visual Studio (SSDT)

  • SQL Server Integration Service (SSIS)

  • Data Migration Assistant (DMA)

Da von Seiten Microsofts die Entwicklung rund um Azure kontinuierlich ist, sollten immer die neuesten und aktuellsten Versionen der Tools verwendet werden.

Szenarien

Prinzipiell kommen zur Migration von kompletten SQL-Server Datenbanken nach Azure, wie bereits kurz erwähnt, das Migrieren der Datenbank in einen SQL-Server, der in einer virtuellen Maschine auf Azure läuft und das Migrieren in eine Azure SQL-Datenbank in Betracht. Da die Migration im ersten Fall wie eine Migration von einem SQL-Server zu einem anderen SQL-Server zu sehen ist, kann dies auch mit den gleichen Techniken durchgeführt werden (Stichworte siehe oben).

Interessanter wird’s bei der Migration in eine Azure SQL-Datenbank, also die Nutzung als Dienst bzw. Service in der Cloud (PaaS bzw. DBaaS).

Zur Ermittlung der Kompatibilität kann zunächst mit dem Data Migration Assistant (DMA) ein Assessment durchgeführt werden. Das Ergebnis des Assessments ist eine Liste mit Erläuterungen und Lösungsmöglichkeiten zur „SQL Server feature parity“ (Feature Übereinstimmung) und der „Compatibility issues“ (Kompatibilitätsproblemen). Dieses Ergebnis und die Komplexität der Lösungsmöglichkeiten entscheiden dann über das konkrete weitere Vorgehen.

Im Detail wird versucht, eine transaktionsgesicherte Kopie der Quelldatenbank solange zu „tunen“, bis die Migrationsblocker beseitigt sind. Je nach Umfang und Aufwand sind zwei grundlegende Vorgehensweisen denkbar:

  • Bearbeiten der Kopie der Quelldatenbank mit skriptbaren T-SQL Befehlen und anschließendem Export von Schema und Daten aus der bearbeiteten Kopie der Datenbank und Import in die Azure SQL Datenbank

  • Oder bei umfangreicheren Änderungen: Laden der DB in ein Visual Studio (mit SQL Server Data Tools) Datenbank-Projekt und Bearbeitung der Issues innerhalb des Projektes

Natürlich sind eine Reihe andere Vorgehensweisen ebenso denkbar, wie z.B. eine Kombination der beiden genannten Vorgehensweisen oder die Nutzung der Integration Services (SSIS) oder anderer ETL-Prozesse. Auch hier könnten die einzelnen Skripte und entwickelten Routinen des Visual Studio Datenbank-Projektes wieder verwendet werden.

Konkretes

Sind die Kompatibilitätsprobleme „überschaubar“ und kann die zu erreichende Kompatibilität mit ebenso „überschaubaren“ T-SQL-Skripten erreicht werden, lässt sich wie folgt vorgehen:

  1. Erstellen einer transaktionsgesicherten Kopie der zu migrierenden Quelldatenbank

  2. Erstellen von T-SQL-Skripten zur Erlangung der notwendigen oder benötigten Kompatibilität

  3. Erneutes Überprüfen der Kompatibilität und Funktionsübereinstimmung mit dem Data Migration Assistant

  4. Schleife über die Punkte 2. und 3., bis die zu erreichende notwendige Kompatibilität und Funktionsübereinstimmung hergestellt ist

  5. Export von Schema und Daten in eine BACPAC-Datei. Eine BACPAC-Datei ist eine ZIP-Datei mit der Erweiterung BACPAC. Sie enthält die Metadaten und Daten aus einer SQL Server-Datenbank. Eine BACPAC-Datei kann im Azure Blob Storage oder im lokalen Speicher an einem lokalen Standort gespeichert werden und dann in die Azure SQL-Datenbank importiert werden. Die BACPAC-Datei kann mit dem Management Studio (SSMS) oder dem Befehlszeilen-Werkzeug „SqlPackage.exe“ erstellt werden. Die Verwendung des Tools „SqlPackage“ bietet meist eine bessere Skalierbarkeit und Leistung beim Im-und Export der BACPAC-Dateien.

  6. Import der BACPAC-Datei in die Azure SQL-Datenbank. Dies kann über das Azure Dashboard oder wieder über das Befehlszeilen-Werkzeug „SqlPackage.exe“ durchgeführt werden. Neben den o.g. Vorteilen bei Verwendung von „SqlPakage“ kommt beim Import ein weiterer Vorteil hinzu: die BACPAC-Datei kann direkt von einem lokalen Speicherplatz aus importiert werden. Bei Verwendung des Azure Dashboards muss – zumindest derzeit noch – die BACPAC-Datei über einen Azure Blob Storage bereitgestellt werden.

  7. Einstellen des Kompatibilitätslevels der Azure SQL-Datenbank mit den T-SQL Befehlen „ALTER DATABASE Compatibility Level“ und/oder „ALTER DATABASE SCOPED CONFIGURATION“.

  8. Ein- und Erstellen der Metadaten wie User, Rechte, Eigenschaften und dergleichen

  9. Test, test, test ….

Der 2. Teil dieses Artikels beschreibt die etwas komplexeren Kompatibilitätsprobleme und beinhaltet auch Schemaänderungen und/oder Änderungen in den Funktionalitäten. Die Fortsetzung folgt am 30. Juni hier im its-people Blog.

Das könnte Sie auch interessieren

Bleiben Sie informiert:

its-people hilft Ihnen...

Weitere Blogthemen: