In meinem letzten Beitrag Azure SQL Datenbanken – Getting started! bin ich auf die Erstellung und Verwaltung einer Azure SQL Datenbank eingegangen. Heute möchte ich mich mit der Migration einer on-premise SQL Server Datenbank nach Azure SQL befassen. Der vorliegende Beitrages beschäftigt sich insbesondere mit folgenden Punkten:
- Prüfung, ob die zu migrierende Datenbank kompatibel mit der aktuellen Azure SQL Version ist
- Verschiedene Varianten für die Durchführung der Migration
Als zu migrierende Datenbank habe ich die gute alte Northwind auf einem SQL Server 2008 R2 hergenommen 🙂
Prerequisites
Wiederum ist allererste Voraussetzung eine Registrierung in Azure sowie eine gültige Azure Subscription. Weitere Informationen dazu gibt es unter Azure-Anmeldung – Konto und Abrechnung.
Weiterhin gehe ich davon aus, dass bereits ein logischer SQL Server in Azure existiert. (Die Erstellung ist im Beitrag Azure SQL Datenbanken – Getting started! beschrieben.)
Folgendes Tutorial kann ich als Lektüre empfehlen: Migrieren einer SQL Server-Datenbank zu Azure SQL-Datenbank.
Für die Vorbereitung und Durchführung der Migration sind diese beiden Tools erforderlich:
- Data Migration Assistant
- Kommandozeilentool SqlPackage
Vorbereitung der Migration
Vor der eigentlichen Durchführung der Migration wollen wir prüfen, ob Kompatibilitätsprobleme existieren. Dafür wird der Data Migration Assistant (DMA) verwendet. Der DMA muss dabei nicht auf dem SQL Server laufen. Es ist ein beliebiger Client möglich, es muss bloß eine Verbindung zum on-premise SQL Server bestehen, auf dem die zu migrierende Datenbank liegt. Ein Zugang zu Azure ist für diesen Schritt nicht erforderlich.
Als Ergebnis wird ein Report mit allen Kompatibilitätsproblemen erstellt:
Der Report ist geclustert nach folgenden Kategorien:
- Migrationsblocker
- Verhaltensänderungen
- veraltete Features
Migrationsblocker müssen behoben werden, bevor die Migration durchgeführt werden kann. Ein Beispiel für einen Blocker habe ich auch gleich parat: Datenbank-Benutzer, die auf Windows Benutzer oder Gruppen gemappt sind, werden durch Azure SQL nicht unterstützt. Das ergibt durchaus Sinn, da Azure SQL nur folgende Authentifizierungsarten unterstützt:
- SQL Authentication
- Azure Active Directory Authentication
Die betreffenden Datenbank-Benutzer müssen daher vor der Durchführung der Migration gelöscht werden. (Sie können gern danach wieder angelegt werden, wenn die Datenbank auch weiterhin on-premise verwendet werden soll. SQL Management Studio bietet die Generierung entsprechender SQL Scripts mittels weniger Klicks an.)
Durchführung der Migration
Für die Durchführung der Migration stehen uns verschiedene Varianten zur Auswahl.
Variante 1: Verwendung des Befehlszeilenprogramms „SQLPackage“
Schritt 1: Exportieren der Datenbank in eine BACPAC-Datei
Dafür wird das Kommandozeilentool SqlPackage verwendet. Das Tool muss nicht auf dem SQL Server laufen, sondern ein beliebiger Client mit installierter SQL Client Konnektivität (kommt z.B. mit SQL Management Studio mit) und Verbindung zum SQL Server reicht völlig aus. Für den Export ist wie schon beim Data Migration Assistant nur eine Verbindung zum Quell-SQL-Server erforderlich, nicht aber zu Azure.
Hier ein Beispiel für den Befehlsaufruf:
sqlpackage.exe /Action:Export /ssn:MeinSQLServer /sdn:Northwind /tf:Northwind.bacpac
Der erste Versuch war übrigens bei mir mit der Fehlermeldung "Table <Tabellenname> does not have a clustered index. Clustered indexes are required for inserting data in this version of SQL Server" fehlgeschlagen. Ein Nachschauen in der Quell-Datenbank bestätigte die Meldung: einige der Tabellen in der Northwind-Datenbank haben zwar einen Primärschlüssel, dieser ist aber als nicht gruppierter ("nonclustered") Index angelegt und es gibt auch sonst keinen gruppierten Index in der Tabelle. Zur Lösung des Problems blieb mir nichts weiter übrig, als die fehlenden gruppierten Indizes manuell in der Datenbank zu erstellen. (Was mich etwas stutzig macht, ist allerdings die Tatsache, dass der Data Migration Assistant dieses Problem nicht bereits entdeckt hatte.)
Danach lief der Import erfolgreich durch:
Schritt 2: Importieren der BACPAC-Datei in eine Azure SQL-Datenbank
Dafür wird wiederum das Kommandozeilentool SqlPackage verwendet. Für den Import ist nun allerdings eine Verbindung zu Azure notwendig. Das bedeutet insbesondere auch, dass die dafür erforderlichen Firewall-Einstellungen vorgenommen worden sein müssen. (Bei Bedarf können diese in meinem Beitrag Azure SQL Datenbanken – Getting started! nachgelesen werden.)
Hier wieder ein Beispiel für den Befehlsaufruf:
SqlPackage.exe /a:
import
/tcs:
"Data Source=communardo-test.database.windows.net;Initial Catalog=Northwind;User Id=<admin_user_account>;Password=<password>"
/sf:Northwind.bacpac
Beim ersten Versuch hatte ich wiederum einen Fehlschlag, da auf dem Azure SQL Server bereits eine Datenbank gleichen Namens vorhanden war. Ich habe auch keinen Parameter für den Import mit sqlpackage gefunden, der mir das Überschreiben der vorhandenen Datenbank ermöglicht hätte. Also wählte ich kurzerhand einen anderen Datenbanknamen.
Danach lief der Import ohne Probleme durch:
Variante 2: Verwendung von SQL Management Studio
Auch im SQL Management Studio wird inzwischen die Migration nach SQL Azure angeboten:
Bei genauerem Hinsehen ist erkennbar, dass intern offensichtlich auch SQLPackage und *.bacpac-Dateien verwendet werden:
Microsoft empfiehlt allerdings die Verwendung des Befehlszeilenprogramms „SQLPackage“. Als Begründung werden "maximale Flexibilität und eine gute Leistung" angegeben.
Variante 3: Verwendung des Data Migration Assistant (DMA)
Der DMA bietet außer "Assessment" auch die Option "Migration" an:
Allerdings wird bei Target server type nur "SQL Server on Azure Virtual Machines" (und nicht "Azure SQL Database") angeboten. Damit kann diese Variante mit unserem Szenario (Azure SQL Database = logischer SQL Server im Azure) nicht eingesetzt werden.
Variante 4: Verwenden der Transaktionsreplikation
Diese Variante ist die aufwändigste. Sie kann Verwendung finden, wenn es nicht tragbar ist, die zu migrierende SQL Server-Datenbank während der Migration aus der Produktion herauszunehmen. Für mein Evaluierungs-Szenario war dies nicht zutreffend.
… zu guter Letzt
Abschließend mache ich natürlich noch die Probe auf's Exempel, ob meine Datenbank auch wirklich korrekt migriert wurde, und bei einem ersten Blick kann ich keine Unstimmigkeiten entdecken. Es sind alle Datenbank-Objekte vorhanden und eine Abfrage auf eine der Tabellen zeigt mir auch die erwarteten Daten an:
Mein persönliches Fazit: Die Migration einer on-premise SQL Server Datenbank nach Azure SQL ist kein Hexenwerk. Ich kann die Verwendung des Befehlszeilenprogramms „SQLPackage“ mit gutem Gewissen empfehlen 🙂