Wenn sich Wege trennen, entstehen neue Möglichkeiten

Ich nehme zum 1. Mai Abschied von Atos und wechsle zur Kramer und Crew und möchte euch hiermit einen Rückblick über meinen Weg mit Atos (Atos Origin) geben. Was ich erlebt, gelernt und miterlebt habe, es waren nicht nur unbedingt angenehme Jahre. Aber alles der Reihe nach…

Meine ersten Jahre bei Atos als Junior DBA

Alles begann im Mai 2007, als ich nach einer kurzen Zeit in einer Auffanggesellschaft, meine Stelle als Junior Datenbank Administrator in Hamburg antreten durfte. Ich kannte bis dahin eigentlich nur den SQL Server aus meiner vorherigen Anstellung, sollte nun aber auch zum Beispiel IBM DB2 betreuen, wo in der Anfangszeit mein Schwerpunkt liegt sollte. Im Laufe der ersten Jahre kam dann auch noch MySQL und eine ganze Menge Enterprise Application Integration (EAI) mit TIBCO hinzu, so dass der SQL Server erst einmal in den Hintergrund gerückt wurde.

Nach einigen Projekten, Neu-Ausrichtungen und personellen Veränderungen hatte ich wieder die Verantwortung für zahlreiche Kunden-SQL-Server. So konnte ich die unterschiedlichen Bereiche und Anwendungsfälle in den unterschiedlichsten Ausprägungen mitgestalten und auch letztendlich betreuen. Aber auch hier gab es dann ein „Kommen und Gehen“, zahlreiche Kollegen nahmen im Laufe der Jahre Abschied, einige Studenten nahmen Platz und bereicherten den Alltag und brachten neue Sichtweisen, Kunden kamen und verschwanden, wuchsen oder fusionierten, so änderten sich immer wieder die Anforderungen und Aufgabenstellungen.

meine Entwicklung und Wachstum über die Jahre

Wie das manchmal in größeren Firmen der Fall ist, war es bei Atos früher etwas schwierig immer die Schulung zu bekommen, die man gerne gehabt hätte… daher habe ich für mich entschieden, dass ich mich selber um einen gewissen Teil der Weiterbildung kümmere und habe mich ~2012 der PASS Deutschland angeschlossen und mich online um entsprechende Schulungen, Beiträge, Foren und so weiter gekümmert. Ich habe so einen für mich neuen Weg und eine komplett neue Welt (die Community) entdeckt.

Die SQL Server Community hat mir dann in der Regionalgruppe Hamburg andere Seiten und Features am SQL Server aufgezeigt, mir das Wissen vermittelt, was mich auch in meiner Arbeit weiter gebracht hat. Als ich dann erstmalig 2013 auf das PASS Camp nach Seeheim (FFM) konnte, war das wie eine andere Welt, die ich so bisher nicht gekannt habe. Der Zusammenhalt, das Expertenwissen, die Menge der „Gleichgesinnten“ war einfach überwältigend… auch wenn ich das erst später so realisiert habe. Auch wenn ich nach dem PASS-Camp längere Zeit nicht wirklich in der Community aktiv war (manche Dinge müssen eben erst etwas reifen 😉 ), brachte mich mein eingeschlagener Weg wieder mit der Community zusammen und brachte mich erneut weiter nach vorne.

Ohne meine großartigen Kollegen, den offenen Umgang miteinander, die gegenseitige Unterstützung wäre ich nicht an meinem jetzigen Punkt bzw wäre es wahrscheinlich gar nicht zu diesem Wechsel gekommen. Meiner Einschätzung nach geht es nicht ohne den Support aus einem Team und einen „Mentor“. In diesem Sinne möchte ich von Herzen bei all meinen Hamburger Kollegen bedanken, dass sie sich immer meine Stories angehört und meine Arbeit übernommen haben, wenn ich für die Community unterwegs war. Und vor allem Thorsten Moeller, dass er meine Pläne und Aktivitäten immer im Rahmen seiner Möglichkeiten unterstützt und gefördert hat! Daher fällt mir mein Abschied in gewisser Weise auch schwer…

Community-Engagement – neue Ziele, neue Wege

Als ich Ende 2016 das Azure Meetup in Hamburg „gründete“, war dies erst einmal für mich ein großer Schritt in eine neue Welt bzw in neue Gefilde. Ich war bisher immer nur Teilnehmer, also Nutzer vieler anderer Kümmerer (#SharingIsCaring). Jetzt wollte ich selber die Fäden in die Hand nehmen und meinen Teil dazu beitragen, dass andere meinen Weg gehen können, sich eigenständig weiterbilden, mit anderen Gleichgesinnten unterhalten, ein Netzwerk auf-/ausbauen, einfach mit den Aufgaben wachsen!

Auch nach mehr als zwei Jahren leite ich nun dieses Meetup und es macht immer noch wahnsinnig viel Spaß, sich um die unterschiedliche Themenbereiche in der Microsoft Cloud zu kümmern und der Community hier immer wieder spannende Sprecher und Vorträge zu organisieren. Durch diesen Einsatz in der Microsoft Community wuchs auch mein nationales bzw europäisches Engagement, siehe z.B. meine Vorträge auf dem SQLSaturday in Wien und Linz. Oder letztendlich die Anerkennung meiner Aktivitäten durch Microsoft mit der Ernennung zum Microsoft Most Valuable Professional (MVP). Es ist eine Ehre Teil dieser weltweiten Community zu sein (was hoffentlich auch noch länger so bleibt)!

Wie oben schon geschrieben, bin ich Atos hier sehr dankbar, denn hätte Atos (Origin) damals nicht den Stein ins Rollen gebracht, hätte ich mich nicht auf diese Weise entwickelt und wäre so gewachsen. Es macht einfach unheimlich Spaß und hat im Endeffekt auch dazu geführt, dass ich nun mein Aufgabengebiet zu einem anderen Arbeitgeber verlege und Abschied nehme von Atos.

mehr Data, mehr Cloud, mehr Community – neue Herausforderungen

Ich wechsel also morgen zu einem (im Vergleich zu Atos) kleinen Systemhaus namens Kramer und Crew mit Sitz in Köln. Hier werde ich um die komplette Microsoft Data Platform kümmern dürfen/können und werde gemeinsam mit meinen Kollegen und Kunden an spannenden Cloud-Projekten arbeiten! Auch wenn diese Entscheidung dazu führt, im Vergleich zu den letzten 12 Jahren die ich bei Atos war, dass ich mehr auf der Straße unterwegs bin (#ConsultantLife), so wird mich dieser Weg auch wieder persönlich weiter bringen… menschlich sowie fachlich. Über Details in meinem neuen Umfeld kann ich derzeit noch nichts mitteilen, hierzu werde ich sicherlich zu gegebener Zeit noch einmal einen „Fazit“-Blogbeitrag schreiben. Die letzten Gespräche, Vorstellungen und Pläne/Ideen sind sehr vielversprechend und herausfordernd, ich weiß auf jeden Fall, dass ich viel lernen werde, viel umsetzen kann und das alles mit viel Spaß!

Das klingt erst einmal nach viel viel Arbeit, aber keine Sorge ich bleibe der Community erhalten (sowohl der PASS aka Data-Platform als auch Azure). Im Mai werde ich auf jeden Fall mit einem Vortrag Teil der „Technology Conference Hamburg“ sein, ebenso beim SQLSaturday im Rheinland. Und natürlich gibt es weiterhin das Azure Meetup in Hamburg… also muss ich hiervon keinen Abschied nehmen 😉

Wie sagt man so schön, „man sieht sich immer zweimal“… in diesem Sinne, wünsche ich allen eine erfolgreiche Zukunft und vielen Dank für die angenehme und konstruktive Zusammenarbeit, wir sehen uns garantiert irgendwann einmal wieder… entweder beruflich, auf einer Community Veranstaltung oder im privaten Garten…

Wie mit Azure starten – interessante Einstiegsmöglichkeiten

Heute kam hier die Frage von einem Kollegen auf, nach wie kann ich mich wo informieren, womit sollte ich anfangen, wenn ich mich zukünftig mit Azure auseinandersetzen möchte/soll/muss. Da ich ihm dazu einen nicht allzu kurzen Text geschrieben habe, dachte ich mir, dass das für meine Blog-Leser auch interessant sein könnte und möchte den Text hier in einer etwas ausführlicheren Form veröffentlichen. 😉

Erstmal muss man sich über die Fülle an Möglichkeiten Gedanken machen, was es da nicht alles für verschiedene Produkte, Services, Plattformen, Hersteller, Anbieter und vielem mehr gibt… Also was möchte/soll man machen… meist kommt man ja mit einer Public Cloud aus geschäftlichen Gründen in Berührung, wie bei meinem Kollegen. Beispielsweise der Web-Entwickler, der wird sich eher damit beschäftigen mit welchen Services in welcher Ausprägung und vor allem wie seine Webseite/-Applikation dem Kunden/Anwender zur Verfügung stellen kann. Der Business-Intelligence (BI) Berater wird sich vielleicht eher mit den Möglichkeiten einer Dynamics-Umgebung und wie er diese Daten worüber wohin wie am Besten dem Management präsentieren kann.

Nehmen wir meinen Kollegen, der bisher sich mit dem SQL Server in allen Ausprägungen und Fazetten on-premise beschäftigt hat… der fragte mich:

Hallo Björn,
[...]
wollte bei Dir mal nachfragen
was für Literatur / Links Du mir
zum Thema MSSQL und Azure empfehlen kannst
[...]

Azure ist einfach sehr vielfältig 😉

In diesem Fall kann man natürlich erst einmal eingrenzen, dass er sich mit Datenbanken beschäftigen möchte und zwar in der Hauptsache mit der Azure SQL Database und vielleicht noch dem Azure SQL Datawarehouse, sowie allen notwendigen Services wie zum Beispiel Netzwerke. Hier muss jeder für sich entscheiden, welcher Lerntyp er ist… erst lesen/anschauen und dann machen oder erst einmal durch ausprobieren wie weit man ohne Hilfe kommt, um dann nachzulesen. Ich bin eher der Typ ausprobieren und dann lesen, wobei bei neuen Haushaltsgeräten… 😉
Ich schätze meinen Kollegen eher als den „Ausprobierer“ ein…

Idealerweise fängt man klein an bzw dort an, was man unter Umständen schon von seiner bisherigen Tätigkeit kennt. Also hier eine einfache virtuelle Maschine mit Windows Server und einem SQL Server… diese kann man erst einmal über ein Tutorial aus der Microsoft-Dokumentation erstellen, entweder über das Azure-Portal oder mittels Powershell. Hierzu stellt Microsoft bzw die Community entsprechende Dokumentationen (Schritt-für-Schritt-Anweisungen) zur Verfügung, anhand derer man sehr einfach die ersten Erfolge sehen kann.

Beispielsweise => Bereitstellen eines virtuellen Windows-Computers mit SQL Server im Azure-Portal

Praktischer Start mit Azure

Wenn man aber nun – wie oben vorgeschlagen – mit der praktischen Arbeit beginnen möchte, wird man schnell feststellen, dass man einen Account für Azure benötigt… dies geht für die ersten privaten Gehversuche am einfachsten mit einem kostenfreien Azure-Account. Diesen kann man sich ganz schnell selber erstellen und erhält darüber hinaus auch noch viele kostengünstige Angebote für Azure Services und teilweise sogar bestimmte Services dauerhaft kostenfrei. So kann man die ersten Übungen bzw das gerade gelernte selber – ohne großes Risiko – ausprobieren und antesten.

So stellt Microsoft zum Beispiel – über diesen „Free-Account“ – jedem Nutzer eine Azure SQL Database, virtuelle Windows und Linux-Maschinen oder auch eine Azure Cosmos DB für die ersten 12 Monate kostenfrei zur Verfügung! Weitere Services wie Azure Data Factory, der Azure Kubernetes Service oder Cognitive Services sind in begrenztem Umfang dauerhaft kostenfrei verfügbar. Reinschauen lohnt sich auf jeden Fall !!!

Vertiefung des Azure KnowHows

Wenn man dann seine erste Maschine deployed hat und auch schon ein wenig in der Dokumentation gestöbert hat, so kann man sich später über das vielfältige Service-Angebot von Microsoft informieren, in dem man sich die kostenfreie Schulungen auf Microsoft Learn anschaut! Hier kann man sich die entsprechenden Produkte bzw Lernziele aussuchen und einfach loslegen…

Videos, Dokumentationen, Schritt-für-Schritt-Anleitungen und Demos / Labs bringen einem die Produkte sowie Services theoretisch näher. So erhält man einen ersten Einblick in die Vorgehensweise und Möglichkeiten der Microsoft Public Cloud Azure. Im Endeffekt hilft aber nichts anderes als wirklich ausprobieren und zu testen, hierzu müsste man sich dann entweder selber oder mit dem Kunden entsprechende Test-Szenarien überlegen und testen, testen, testen…

Auch in der Public Cloud bleiben die alten „Weisheiten“ meist gültig, auch wenn man gewissen alte Denkstrukturen überwinden muss und auf den ersten Blick vieles unübersichtlich und teuer wirkt! Hier heißt es dann weiter bzw um die Ecke denken, um dem Kunden entsprechende Angebote und Solutions präsentieren zu können. Aber für einen ersten Einstieg sind die oben genannten Plattformen auf jeden Fall sehr hilfreich!

Viel Spaß beim Lernen und Ausprobieren!

Azure SQL Database – Challenges, Pros and Cons, Issues (T-SQL Tuesday #103 Invite)

Azure SQL Database - Challenges, Pros and Cons, Issues (T-SQL Tuesday #103 Invite)
Brent Ozar wrote in #100 of TSQL2sday about his predictions which he had made already in 2013 and that he now thinks that Azure SQL Database (Managed Instance) might be the new default database for all kind of services (instead of VMs). Already Azure SQL Database is some kind of „state of the art“ database as a service for all types of applications and its demand is growing day by day. More and more companies are migrating their databases to public cloud databases and so our daily business changes…

Write what you think about Azure SQL Database

So this is my call for the June 2018 TSQL Tuesday: Tell me/us if you or your company has already started testing of Azure SQL Database or Azure SQL Managed Instance or if you’re already using it. Tell us all about it:
  • What was your migration tool?
  • How did you plan that migration?
  • Were there any assessments before the migration?
  • Which problems occurred during your test-phase?
  • Which problems occurred during your migration?
  • Was there any automation around the migration?
  • Which scripting language was used for what? Powershell or Azure CLI?
  • Is there any automation right now during normal operation?
  • Any issues, special requirements or anything else around using Azure SQL Database?
  • How do you monitor the database?
  • How do you do database maintenance?
  • Do you use the builtin tuning options?
Simply write about all of your experiences with Azure SQL Database or Azure Managed Instance. Even if you don’t see a future for Azure SQL Databases write about it everything is welcome!

This is a T-SQL Tuesday, so there are official rules.

  1. Publish your contribution on Tuesday, June 12th, 2018. Let’s use the “it’s Tuesday somewhere” rule.
  2. Include the T-SQL Tuesday Logo and have it link to this post.
  3. Please comment below with a link to your post.
  4. Tweet about your post using #tsql2sday.
  5. If you’d like to host in the future, contact Adam Machanic.

Azure SQL Database Migration – Teil 2 – Data Migration Assistant

In meiner Serie zur Datenbank Migration vom on-premise SQL Server zur Azure SQL Database kommt heute der zweite Teil, die Migration mit dem „Data Migration Assistant„. Diese Migration ist relativ einfach, wenn man sich ein wenig vorbereitet hat und seine Datenbank-Struktur ein wenig kennt. Aber für einen „normalen“ Datenbank-Administrator sollte dieser Weg überhaupt kein Problem darstellen, da es sich ebenfalls um einen geführten Weg handelt und gut beschrieben ist. Meinen Teil zur Beschreibung der Vorgehensweise möchte ich mit diesem Beitrag leisten, vielleicht hilft meine Dokumentation in Wort und Bild jemanden bei der Datenbank-Migration.

Strukturen und Daten einzeln migrieren

Natürlich sollte man sich auch hier die gleichen grundlegenden Gedanken über die anzuwendende Strategie vor der Migration machen, darauf gehe ich hier aber nicht weiter ein und verweise dafür nur auf meinen vorherigen Blogbeitrag => Azure SQL Database Migration – Teil 1

Der Data Migration Assistant ist ein zusätzliches Tool, welches Microsoft kostenfrei zum Download zur Verfügung stellt. Dieser Assistent bietet eine Vielzahl von Mehrwert im Vergleich zur Migration mit dem SQL Server Management Studio, da er auch Kompabilitätsprobleme erkennt und frühzeitig aufzeigen kann. In der Microsoft Dokumentation steht folgender einleitender Text als Erläuterung zum DMA:

Die Daten Migration Assistant (DMA) können Sie zum Aktualisieren auf eine moderne Datenplattform durch das Erkennen von Kompatibilitätsproblemen zu Fragen, die in der neuen Version von SQL Server und Azure SQL-Datenbank-Funktionalität auswirken können. DMA empfiehlt, Leistung und Zuverlässigkeit Verbesserungen für Ihre zielumgebung und können Sie Ihr Schema, Daten und nicht enthaltene Objekte vom Quellserver auf dem Zielserver zu verschieben.

Quelle: Microsoft Doc => https://docs.microsoft.com/de-de/sql/dma/dma-overview

erste Schritte mit dem Data Migration Assistant

Azure SQL Database Migration via Data Migration Assistant - Schritt 1 - New Connection

Die Struktur-Analyse

Das Assessment ist zwar auch in der Migration enthalten, kann aber auch vorab separat ausgeführt werden. Hierzu legt man beispielsweise zuerst ein neues Projekt an, wählt dann die zu analysierenden Optionen aus und nachdem man die Zugangsdaten des Quell-SQL Servers angeben hat, kann die Analyse starten. Entweder das Ergebnis ist in allen Prüfungen grün und man umgehend mit Migration starten oder man muss vor der Migration erst einmal überprüfen, ob man die gefundenen Probleme irgendwie beseitigen kann. Im schnlimmsten Fall können die Datenbanken nicht migriert werden. Aber bitte beachten, dass der Data Migration Assistant auch von on-premise zu on-premise migrieren kann und somit auch eine Analyse vor der Migration von zum Beispiel SQL Server 2012 auf 2016 durchführen kann.

Azure-SQL-Database-Migration-via-Data-Migration-Assistant-Analyse

Die eigentliche Migration

Da diese Analyse aber nicht bei Auswahl der Migrationsfunktion ausgeführt wird, so sollte man doch diese Analyse vor dem Migrations-Schritt einmal durchgeführt haben. Auch hier muss man ein neues Projekt anlegen und die Quell-Umgebung definieren, um dann dem ersten „Stolperstein“ zu begegnen…

ACHTUNG !!! Bevor man mit der Migration einer on-premise SQL Datenbank zu einer Azure SQL Database beginnen kann, muss diese Ziel-Datenbank als leere Hülle auf dem Ziel-Server vorhanden sein, erst dann kann man diese als Ziel für die Migration mit dem Data Migration Assistant auswählen.

Nun kann endlich mit der Auswahl der zu analysierenden Objekte innerhalb der Datenbank begonnen werden… hier haben Sie die Qual der Wahl und müssen die zu migrierenden Objekte auswählen. In der Regel nimmt man alle Objekte innerhalb der Quell-Datenbank, bei partiellen und/oder Test-Migrationen kann man natürlich auch nur einzelne Objekte anklicken und dann migrieren. Der Data Migration Assistant erstellt dann erst einmal ein TSQL-Skript um die gesamte Datenbank-Struktur in der Ziel-Architektur herzustellen, dieses Skript kann man auch für späteren Verwendungszwecke abspeichern. Erst wenn das Datenbank Schema erfolgreich deployed wurde, wird der Button für die eigentliche Migration freigegeben und man endlich mit Migration der Daten beginnen. Über den Verlauf der einzelnen Migrationsschritte (jede Tabelle kann dabei überwacht werden bzw wird als Progressbar mit Ergebnis dargestellt) wird man fortlaufend informiert, leider auch über auftretenden Probleme, wie es bei mir der Fall war.

Auch hier ein weiterer Stolperstein (der zumindest in der Version 3.4 vorhanden ist) über den man sich natürlich Gedanken machen sollte… Meine Demo-Umgebung ist SQL Server 2017 und das Ziel ist eine Azure SQL Database, beides wird laut Webseite vom Data Migration Assistant unterstützt, dennoch erhielt ich eine Fehlermeldung, dass gewisse Assemblies nicht in der richtige Version vorliegen würden…

The pipeline failed to query metadata for table xyz

Could not load file or assembly ‚Microsoft.SqlServer.Types, Version=13.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91‘ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

Could not load file or assembly ‚Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91‘ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Azure SQL Database Migration via Data Migration Assistant

Nachdem ich dann aber das aktuelle Microsoft System CLR Types für SQL Server 2016 und 2017 nachträglich bzw zusätzlich auf meiner Testumgebung installiert hatte und ich die Migration erneut gestartet habe, lief die Migration der Daten erfolgreich durch. 😉

Azure SQL Database Migration via Data Migration Assistant - erfolgreiche Migration aller Daten

Wer jetzt genau hinschaut, kann feststellen, dass ich beim zweiten Migrationslauf nicht alle Objekte (67 statt 71) ausgewählt habe, denn es waren bereits Tabellen erfolgreich migriert worden, so dass es nicht notwendig war alles neu zu machen (ausserdem wollte ich das mal testen 😉 )

Fazit zur Migration mit dem Data Migration Assistant

Durch die Möglichkeit der vorherigen Analyse und somit dem Aufzeigen von bestehenden Problemen und der Möglichkeit nur einzelne Objekte zu migrieren, kann ich diese Vorgehensweise nur empfehlen. Allerdings muss man auch sagen, dass diese Variante der Migration nichts für kurze Ausfallzeiten ist, nur für die ersten Test-Migrationen… die endgültigen Produktions-Migration würde ich mit anderen Varianten der Migration durchführen wollen, dazu aber in weiteren Folgen dieser Serie mehr. 😉

Azure SQL Database Migration – Teil 1 – SQL Server Management Studio

Heute möchte ich auf die einfache und schnelle Möglichkeit eingehen, wie man mit vorhandenem Wissen und vorhandenen Tools (hier dem SQL Server Management Studio) eine Datenbank mit wenigen Klicks nach Azure migrieren kann. Immer mehr Unternehmen möchten Ihre Daten in die Cloud auslagern, um die on-premise Kosten zu reduzieren und flexibler auf Anforderungen reagieren zu können. Hierzu müssen die Datenbanken in die Cloud migriert werden, was auf unterschiedlichste Art und Weise zu realisieren ist. In diesem Blogbeitrag gehe ich nicht auf die Einschränkungen und Vorbedingungen einer Migration ein, es soll hier nur um die reine Migration gehen. Heute im ersten Teil der Serie „Azure SQL Database Migration“ um die Migration einer on-premise SQL Server Datenbank in eine Azure SQL Database mit dem SQL Server Management Studio (SSMS).

Wege der Datenbank Migration in die Cloud

Erst einmal muss man klären, wie lang die maximale Ausfallzeit sein darf… also wie lange man maximal für die Migration brauchen darf, denn davon ist abhängig welche Methode man wählt. Natürlich ist es auch wichtig zu beachten wie groß eine Datenbank ist, ob man diese in einem Zug migrieren kann oder nicht. Hier in meinem Beispiel geht es um die „Adventureworks“-Datenbank mit gerade einmal 272 MB, aber es gibt auch Applikationen bzw deren Datenbanken die eine Größe von mehr als 1 TB erreichen, da sollte jedem klar sein, dass man ein Backup-File von ~200MB schneller in die Cloud kopiert hat als ~800GB… da muss man sich andere Gedanken machen. Hier nun einige gängige Methoden:

  • Backup/Restore
    • mittels SSMS (TSQL/GUI)
    • mittels Powershell
  • Azure Migration Assistant
  • Azure Database Migration Service
  • Transaktions-Replikation

Je nach Anforderung an die Datenbank und das mögliche Zeitfenster sollte man hieraus wählen. Hier starte ich mit der Azure SQL Database Migration aber im SQL Server Management Studio über die grafische Oberfläche was vielen DBAs geläufig sein sollte. Über die Auswahl der zu migrierenden Datenbank (rechte Maus) das Kontextmenü öffnen und über „Tasks > Deploy Database to Microsoft Azure SQL Database“ den Assistenten öffnen.

Azure SQL Database Migration via SSMS

Nun muss man im ersten Fenster den Ziel Server in der Microsoft Azure Cloud angeben, sowie den neuen Datenbank-Namen, so wie einen Laufwerkspfad an dem das temporäre Backup (bacpac) abgelegt werden kann. (Achtung Größe => freier Plattenplatz). Man sieht schon, dass man zumindest einen SQL Server in Azure angelegt haben sollte, damit man hier weiter kommt. Wie man diesen Server initial anlegt, könnt ihr hier nachlesen => https://www.sql-aus-hamburg.de/einstieg-azure-sql-database-mit-powershell-teil-1/

Azure SQL Database Migration via SSMS - Bild 2 Azure SQL Database Migration via SSMS - Bild 3 Azure SQL Database Migration via SSMS - Bild 4

Die letzten drei Screenshots zeigen die vorgenommenen Einstellungen wie Azure SQL Server Connection String mit Angabe des Ziel-Datenbanknamen und der gewählten Performance-Klasse der Azure SQL Database (in meinem Beispiel Basic mit maximal 2GB) und einem Ablagepfad für das temporäre Bacpac-File, die anschließende Zusammenfassung sowie die abgearbeitenten einzelnen Schritte der Migration. Ich möchte noch den Hinweis geben, dass bei größeren Datenbank ein großer Zeitgewinn erreicht werden kann, also die Migration schneller erfolgen kann, wenn man inital ein möglichst hohes Performance-Level für die Ziel-Datenbank wählt. Dadurch erhält mein ein wesentlich bessere IO-Verhalten bzw einen höheren Durchsatz in der Datenbank und die Daten können schneller in die Datenbank geschrieben werden.

Azure SQL Database Migration via SSMS - Bild 5

Nach Abschluss der Migration (siehe oben) kann man umgehend wieder auf das eigentliche Performance-Level der Azure SQL Database gehen, damit erhält man im Azure Portal das folgende Bild, die neue Datenbank wird sichtbar mit dem Status „online“ und dem gewählten Performance-Level (hier „Basic“).

Azure SQL Database Migration via SSMS - Bild 7

Fazit nach der Azure SQL Database Migration mit dem SSMS

Die Migration über die GUI des SSMS ist einfache und schnelle Möglichkeit einzelne Datenbanken von on-premise SQL Server in die Cloud durchzuführen. Es sind nur wenige Klicks bis man eine erste Übersicht hat und nur eine geringe Anzahl an Konfigurationsparameter, die notwendig sind um mit der Migration zu starten. Die Laufzeit der Migration ist abhängig von der Größe der Datenbank und dem gewählten Ziel-Performance-Level, so dass auch hier eine Entscheidung leicht fällt. Für die Migration mehrer Datenbanken und „komplexeren“ Umgebungen ist die Methode allerdings nicht zu empfehlen, hierzu werde ich weitere Blogbeiträge schreiben.

In diesem Blogbeitrag von Chris Pietschmann zur Azure SQL Database Migration mit dem SQL Server Management Studio kann man weitere Hinweise und Informationen finden.

Migrate Between Azure SQL Database and SQL Server