Azure SQL Database – Review of T-SQL Tuesday #103

I’m a little bit sad about the outcome of my TSQL2sDay topic „write about all your experiences with Azure SQL Database“… only 2 people had written about what they were doing with that great product from Microsoft. But this will be a positive motivation for me to spread the words across the #SQLFamily even louder!!! 😉

I asked the SQL Server community on Junes‘ 2018 TSQL2sDay to write about all of their experiences (positive and negative), all their issues, all of their plans and/or challenges with the „Azure SQL Database“.  It seems that there are really fewer experiences within the community with those really good databases… ok „Azure SQL Managed Instance“ is an absolutely new product but the normal database as a service is an old service…
Looking forward for more session about Azure SQL Database

We rise by lifting others

At least two people had written a blog post (and commented on my TSQL2sDay invitation post):

There is Rob Farley who wrote about „The fear of the new“ in a more poetic way why are so many out there struggle with Azure SQL Database. And Kenneth Fisher also wrote about „Why not trying it ?“ and how to develop new processes, ideas, products and even opportunities by using Infrastructure-as-a-Service in the public cloud.

Thank you very much you two for participating in this months topic and the series of TSQL2sDay (initialized by @AdamMachanic).

More talks about Azure SQL Database to come

Now I’ll have to increase my efforts in talking about Azure SQL Databases in the future to make more rumour on this awesome product from Microsoft and all those great features like included backup and monitoring or built-in‘ automatic tuning options. You should definitely have a look at that product and give it a chance. It is very easy to deploy and manage it via Azure portal or Powershell Commandlets. You’ll enjoy the freed up time with other interesting and exciting things (or even with your friends and family) 😉

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.

Pay back to #sqlfamily community – T-SQL Tuesday #102

Riley Major invited us to this months TSQL2sDay – we should write about „Giving back to the community“ and some shall write about how they plan to start or people like me – who already started giving back – shall write about how we’re actually doing. So let me try to tell you my story about stepping out of the dark and getting into the #sqlfamily …

The lone Geek

My journey started about 6 years ago as I thought to myself that there must be a way to become stronger and get deeper knowledge about SQL server is able to. Also get around some problems with getting such specific training for an affordable effort/budget. I just wanted to know this „magic“ and started to google a little bit and came across some buzzwords which showed me a direction… which leads me to my registration at PASS Germany.

My first visit at the local PASS user group lasted for more than half a year but somewhen I did it 😉 After that, I visited the user group meetings on a regular base and then I heard about a community event called SQL Saturday… That’s where I wanted to be part of to strengthen my knowledge about SQL Server as a participant but never thought about changing to a speaker because I was so impressed with the knowledge, presentation and speaking…

PASS-DE - The Lone Geek

So I just joined several community events as SQL Saturdays, PASSCamp, SQLKonferenz and SQLGrillen from the easy side => as a participant. But somewhen it made „click“ in my head and I thought „Hey, if I’m already on-site why not helping and getting more in touch with those great guys/speakers?“ so I decide to write an email to Oliver Engels (Twitter) and Tillmann Eitelberg (Twitter) if I might volunteer during SQL Saturday Rheinland and “ Hurray they accepted…“

Become a First-Timer

So I started my „career“ as a volunteer on SQL Saturday Rheinland 2016 with filling bags, preparing booths and session rooms … which had made a lot of fun! I got in touch with more very friendly people of the German PASS chapter. #communityrocks

After a few weeks – also joined SQLGrillen – I made a decision for my own to submit a session for next year’s SQL Saturday and try some more opportunities to speak… in October 2016 I participated also as a volunteer at SQL Saturday Munich where I already felt the love of the #sqlfamily! It was so much fun being part of it and getting known by more and more people. So I also spoke to a Microsoft guy (Jan Schenk) who was responsible for my efforts creating the #Azure Meetup in Hamburg which I started in November 2016.

In 2017 was my first step out of the dark 😉 I was picked to speak twice at SQL Saturday Rheinland and once at SQLGrillen – my very first talks at a public event outside of my regional user group. I was very honoured, so much fun and it was a pleasure to be with such great SQL persons from all around the world. After those events, I can’t stop it and raised my goals for 2018 and further events. (Like speaking at an international event or a non-german user group)

Why? What do I get back from the community?

As I had written above there is so much fun and pleasure and more important to learn from all of the so great community people. For some people it might a good marketing effect to be within the community but why not… they sharing their knowledge with you and making it possible that such events can be organised. Ok, there might be one point… if their session is more about their own products or company and not the topic… that’s not fair!

For me the main part is sharing my knowledge and being part of that #sqlfamily… getting known to all the other, helping other to encourage to do their first presentation or organizing a user group. I love what I am doing! And if I’m able to help just one person to find his/her own way or solution… it makes me happy. 

Communitytreffen SQLGrillen 2017 - German and European #sqlfamily

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

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 =>

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.


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

Could not load file or assembly ‚Microsoft.SqlServer.Types, Version=, 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=, 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 =>

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