Migration einer on-premise SQL Server Datenbank in Azure SQL

In mei­nem letz­ten Beitrag Azure SQL Datenbanken – Getting star­ted! bin ich auf die Erstellung und Verwaltung einer Azure SQL Datenbank ein­ge­gan­gen. Heute möchte ich mich mit der Migration einer on-premise SQL Server Datenbank nach Azure SQL befas­sen. Der vor­lie­gende Beitrages beschäf­tigt sich ins­be­son­dere mit fol­gen­den Punkten:

• Prüfung, ob die zu migrie­rende Datenbank kom­pa­ti­bel mit der aktu­el­len Azure SQL Version ist
• Verschiedene Varianten für die Durchführung der Migration

Als zu migrie­rende Datenbank habe ich die gute alte Northwind auf einem SQL Server 2008 R2 her­ge­nom­men 🙂

Prerequisites

Wiederum ist aller­erste Voraussetzung eine Registrierung in Azure sowie eine gül­tige Azure Subscription. Weitere Informationen dazu gibt es unter Azure-Anmeldung – Konto und Abrechnung.

Weiterhin gehe ich davon aus, dass bereits ein logi­scher SQL Server in Azure exis­tiert. (Die Erstellung ist im Beitrag Azure SQL Datenbanken – Getting star­ted! beschrie­ben.)

Folgendes Tutorial kann ich als Lektüre emp­feh­len: Migrieren einer SQL Server-Datenbank zu Azure SQL-Datenbank.

Für die Vorbereitung und Durchführung der Migration sind diese bei­den Tools erfor­der­lich:

• Data Migration Assistant
• Kommandozeilentool SqlPackage

Vorbereitung der Migration

Vor der eigent­li­chen Durchführung der Migration wol­len wir prü­fen, ob Kompatibilitätsprobleme exis­tie­ren. Dafür wird der Data Migration Assistant (DMA) ver­wen­det. Der DMA muss dabei nicht auf dem SQL Server lau­fen. Es ist ein belie­bi­ger Client mög­lich, es muss bloß eine Verbindung zum on-premise SQL Server bestehen, auf dem die zu migrie­rende Datenbank liegt. Ein Zugang zu Azure ist für die­sen Schritt nicht erfor­der­lich.

Als Ergebnis wird ein Report mit allen Kompatibilitätsproblemen erstellt:

Der Report ist geclus­tert nach fol­gen­den Kategorien:

• Migrationsblocker
• Verhaltensänderungen
• ver­al­tete Features

Migrationsblocker müs­sen beho­ben wer­den, bevor die Migration durch­ge­führt wer­den kann. Ein Beispiel für einen Blocker habe ich auch gleich parat: Datenbank-Benutzer, die auf Windows Benutzer oder Gruppen gemappt sind, wer­den durch Azure SQL nicht unter­stützt. Das ergibt durch­aus Sinn, da Azure SQL nur fol­gende Authentifizierungsarten unter­stützt:

• SQL Authentication
• Azure Active Directory Authentication

Die betref­fen­den Datenbank-Benutzer müs­sen daher vor der Durchführung der Migration gelöscht wer­den. (Sie kön­nen gern danach wie­der ange­legt wer­den, wenn die Datenbank auch wei­ter­hin on-premise ver­wen­det wer­den soll. SQL Management Studio bie­tet die Generierung ent­spre­chen­der SQL Scripts mit­tels weni­ger Klicks an.)

Durchführung der Migration

Für die Durchführung der Migration ste­hen uns ver­schie­dene Varianten zur Auswahl.

Variante 1: Verwendung des Befehlszeilenprogramms „SQLPackage“

Schritt 1: Exportieren der Datenbank in eine BACPAC-Datei

Dafür wird das Kommandozeilentool SqlPackage ver­wen­det. Das Tool muss nicht auf dem SQL Server lau­fen, son­dern ein belie­bi­ger Client mit instal­lier­ter SQL Client Konnektivität (kommt z.B. mit SQL Management Studio mit) und Verbindung zum SQL Server reicht völ­lig aus. Für den Export ist wie schon beim Data Migration Assistant nur eine Verbindung zum Quell-SQL-Server erfor­der­lich, 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 übri­gens bei mir mit der Fehlermeldung "Table <Tabellenname> does not have a clus­te­red index. Clustered inde­xes are requi­red for inser­ting data in this ver­sion of SQL Server" fehl­ge­schla­gen. Ein Nachschauen in der Quell-Datenbank bestä­tigte die Meldung: einige der Tabellen in der Northwind-Datenbank haben zwar einen Primärschlüssel, die­ser ist aber als nicht grup­pier­ter ("non­clus­te­red") Index ange­legt und es gibt auch sonst kei­nen grup­pier­ten Index in der Tabelle. Zur Lösung des Problems blieb mir nichts wei­ter übrig, als die feh­len­den grup­pier­ten Indizes manu­ell in der Datenbank zu erstel­len. (Was mich etwas stut­zig macht, ist aller­dings die Tatsache, dass der Data Migration Assistant die­ses Problem nicht bereits ent­deckt hatte.)

Danach lief der Import erfolg­reich durch:

Schritt 2: Importieren der BACPAC-Datei in eine Azure SQL-Datenbank

Dafür wird wie­derum das Kommandozeilentool SqlPackage ver­wen­det. Für den Import ist nun aller­dings eine Verbindung zu Azure not­wen­dig. Das bedeu­tet ins­be­son­dere auch, dass die dafür erfor­der­li­chen Firewall-Einstellungen vor­ge­nom­men wor­den sein müs­sen. (Bei Bedarf kön­nen diese in mei­nem Beitrag Azure SQL Datenbanken – Getting star­ted! nach­ge­le­sen wer­den.)

Hier wie­der 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 ers­ten Versuch hatte ich wie­derum einen Fehlschlag, da auf dem Azure SQL Server bereits eine Datenbank glei­chen Namens vor­han­den war. Ich habe auch kei­nen Parameter für den Import mit sql­pa­ckage gefun­den, der mir das Überschreiben der vor­han­de­nen Datenbank ermög­licht hätte. Also wählte ich kur­zer­hand einen ande­ren Datenbanknamen.

Danach lief der Import ohne Probleme durch:

Variante 2: Verwendung von SQL Management Studio

Auch im SQL Management Studio wird inzwi­schen die Migration nach SQL Azure ange­bo­ten:

Bei genaue­rem Hinsehen ist erkenn­bar, dass intern offen­sicht­lich auch SQLPackage und *.bacpac-Dateien ver­wen­det wer­den:

Microsoft emp­fiehlt aller­dings die Verwendung des Befehlszeilenprogramms „SQLPackage“. Als Begründung wer­den "maxi­male Flexibilität und eine gute Leistung" ange­ge­ben.

Variante 3: Verwendung des Data Migration Assistant (DMA)

Der DMA bie­tet außer "Assessment" auch die Option "Migration" an:

Allerdings wird bei Target ser­ver type nur "SQL Server on Azure Virtual Machines" (und nicht "Azure SQL Database") ange­bo­ten. Damit kann diese Variante mit unse­rem Szenario (Azure SQL Database = logi­scher SQL Server im Azure) nicht ein­ge­setzt wer­den.

Variante 4: Verwenden der Transaktionsreplikation

Diese Variante ist die auf­wän­digste. Sie kann Verwendung fin­den, wenn es nicht trag­bar ist, die zu migrie­rende SQL Server-Datenbank wäh­rend der Migration aus der Produktion her­aus­zu­neh­men. Für mein Evaluierungs-Szenario war dies nicht zutref­fend.

… zu guter Letzt

Abschließend mache ich natür­lich noch die Probe auf's Exempel, ob meine Datenbank auch wirk­lich kor­rekt migriert wurde, und bei einem ers­ten Blick kann ich keine Unstimmigkeiten ent­de­cken. Es sind alle Datenbank-Objekte vor­han­den und eine Abfrage auf eine der Tabellen zeigt mir auch die erwar­te­ten Daten an:

    

Mein per­sön­li­ches 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 emp­feh­len 🙂