Azure SQL – Change your Skills – DataSaturday #6 Malta

Gestern durfte ich meinen Vortrag im Rahmen des DataSaturday #6 auf Malta halten, dabei ging es um die Veränderungen im Leben eines DBAs, wenn er sich damit konfrontiert sieht, dass seine SQL Server und/oder Datenbanken in die Microsoft Cloud Azure migriert werden sollen. Ich wollte mit diesem Vortrag die Ängste minimieren und aufzeigen, dass es sich bei Azure SQL eben auch “nur” um einen SQL Server bzw einen SQL Datenbank handelt.

Abweichend von allen anderen Veranstaltungen hatte sich Dennes (und sein Team) etwas neues im Ablauf einfallen lassen, die Session hatte keine 60 Minuten sondern 90 Minuten. Die ersten 15 Minuten wurden als Interview oder Einleitung genutzt, der Host stellte den nächsten Sprecher vor, dazu hatte man ein kleines Video produziert und individuelle Fragen zum jeweiligen Lebenslauf vorbereitet. Dann kam der eigentliche Vortrag über volle 60 Minuten, gefolgt von weiteren 15 Minuten für Fragen und Antworten der Teilnehmer oder der Host konnte selber entsprechende Fragen stellen. Alles in allem eine gelungene Lösung, die den Talk eher wie ein Gespräch leitete und allen ein wenig “Druck” nahm und man sich (hoffentlich auch als Teilnehmer) mehr dazugehörig fühlte.

Mein Host war Deepthi Goguri, es hat mir viel Spaß bereitet diese Session gemeinsam mit Ihr zu halten. Auch wenn dies nicht mein erster Vortrag auf Englisch war, so bin ich doch immer noch ein wenig nervöser… finde ich die richtigen Worte im richtigen Moment, spreche ich alles richtig aus… Durch die ruhige und freundliche Art von Deepthi wurde auch ich ruhiger und konnte mich ein wenig besser auf die Session vorbereiten. Half zwar nicht darüber hinweg, dass ich wieder einmal mehr erzählen und zeigen wollte, als ich Zeit zur Verfügung hatte, daran muss ich dringend arbeiten! Vor zwei Jahren hatte ich mich mit Rob Sewell unterhalten, dass ich meine Komfortzone dringend verlassen möchte => nicht nur Vorträge auf Deutsch zu halten, sondern auch einmal mit Englisch starten wolle und ob er mich bei meinem englischen Start – als Mentor sozusagen – unterstützen könne. Und dann kam Corona und alles kam anders… ich bin einfach mal gesprungen und habe es gewagt… womit wieder wir beim Thema wären 😉

It is just a SQLServer - dont be afraid of moving you databases into Azure

Einfach mal trauen und ausprobieren

Deepthi fragte mich gestern, was ich den Teilnehmern denn empfehlen würde, wenn der Auftraggeber oder Arbeitgeber mit der Migration in die Cloud starten wolle. Hier kann ich allen Interessierten nur empfehlen, keine Angst zu haben, nur weil der SQL Server nicht mehr im eigenen Rechenzentrum steht, sondern jetzt in einem Rechenzentrum von Microsoft, heißt dies nicht, dass Microsoft all die Arbeit übernimmt und man – als Datenbank-Administrator – nichts mehr zu tun hat… ok, man muss etwas neues lernen und etwas anders denken, aber es ist immer noch ein SQL Server mit seinen Datenbanken!
Die ersten Schritte könnten die folgenden sein:

  • einen Azure Free Account anlegen
  • einfach mal bspw. eine kostenfreie Linux VM deployen und ausprobieren, wie man dort einen SQL Server installiert
  • oder eine Azure SQL Database, um zu sehen welche Schritte man hier gehen muss, um dies zu erreichen
  • und natürlich all die großartigen Ressourcen von Microsoft Learn – Learning Paths and Modules mit vielen Inhalten und Übungen – erarbeiten
    Azure Fundamentals – AZ-900
    Azure Data Fundamentals – DP-900
  • wenn man dann Fragen zu den einzelnen Optionen hat, dann kann man auch die sehr nützliche Dokumentation lesen, die auch mir, sehr oft hilft gewisse Themen besser zu verstehen.

zahlreiche Lern-Unterstützung zu Azure SQL verfügbar

Microsoft – hauptsächlich in Form von Anna Hoffman und Bob Ward – stellt auch sehr viele interaktive Lernmaterialien zur Verfügung, die man sich in Form von Workshops, Labs oder Youtube Videos erarbeiten kann! Es gibt Material für mehrere Wochen durchgängiges Lernen rund um den SQL Server und/oder Azure SQL… egal ob Azure SQL Database oder die Managed Instance oder auch als SQL Server VM in Azure. Hier heißt es einfach mal starten und ausprobieren, keine Scheu… es ist keine Magie, sondern eigentlich recht einfach, da man sich alles selber zusammenstellen kann, wie man es benötigt 😉

Microsoft Learn: Azure SQL fundamentals learning path
aka.ms/azuresqlfundamentals
Select the Azure SQL Workshop
aka.ms/sqlworkshops
How to choose tool
aka.ms/chooseazuresql
Azure SQL documentation
aka.ms/azuresqldocs
More videos from our team
aka.ms/dataexposed

Change your Skills - Learning - Ressourcen-Overview

Hier geht es zu meinen Slides aus diesem Vortrag:
Azure SQL – Change your skills to become a cloud DBA

und wer jetzt noch etwas zu Azure SQL Database lesen möchte, der kann dies natürlich entweder in meinem Blog hier tun oder in dem relativ neuen Post zu Azure SQL von Deepthi 😉

Azure SQL Database – Hyperscale – jetzt im Public Preview

Auf der #MSIgnite wurde ein neues Feature bzw eine neue Variante von Azure SQL Database vorgestellt : Hyperscale!

Mit diesem neuen Produkt bietet Microsoft seinen Kunden eine Datenbank-Engine, welche schneller und flexibler auf plötzliche Daten-Wachstumsraten reagieren kann als die bisherigen. Mit Hyperscale kommen bisher bei on-premise SQL Servern unbekannte Technologien zum Einsatz, da diese sich erst realisieren ließen durch die Cloud-typische Trennung von Services, Netzwerk und Storage. Durch eben diese Trennung können neue Ansätz realisiert werden, welche – wie bei Azure SQLDB Hyperscale – neue Prozessstrukturen ermöglichen, hier wird nicht direkt in das Transaction-Log in einem Storage geschrieben, sondern erst einmal in einen Log-Services ähnlichem einer Queue im Servicebus. Dieser LogService übernimmt dann sozusagen die Verteilung der Daten in Richtung Storage, Secondary ComputeNodes und Page Servers.

Der Log-Service – Drehscheibe

AzureSQLDB Hyperscale PublicPreview - LogService

Der Log Service kümmert sich um die Datensicherheit, er ist dafür verantwortlich, dass die Daten sowohl für die Log-Sicherung also das Point-in-Time-Restore zur Verfügung stehen, als auch für die weitere Speicherung in den Compute Nodes sowie den Page Servern, aber wie im Detail…
Der Dateneingang auf dem Primary ComputeNode speichert jegliche Daten erst einmal auf einem Azure Premium Storage Device (welches schon dem Log-Service unterliegt), somit ist eine schnelle und sichere Speicherung der Daten sichergestellt. Der Log-Service nimmt diese Daten und verteilt sie dann an die Logsicherung (LTR & PiTR) und die weiteren ComputeNodes (some kind of LogShipping) und eben auch an die PageServer, welche die eigentliche Datenspeicherung übernehmen.

Der Datenspeicher – Page Server

AzureSQLDB Hyperscale PublicPreview - PageServers

Die Page Server übernehmen die Daten vom Log-Service um diese dann über spezielle Caching-Speicher auf lokale SSD-Platte zu speichern bzw später dann auf dem “normalen” Azure Storage endgültig zu persitieren. Die PageServer sind im Grunde nichts anderes als die alt bekannten Datafiles auf einem on-premise SQL Server, denn auch die Datenbereitstellung in einer Hyperscale-Umgebung erfolgt über diese Page-Server, diese speichern nicht nur die Daten sondern stellen sie auch wieder zur Verfügung. Im Falle eines plötzlichen Datenwachstums können diese Page-Server sehr schnell und effizient skaliert werden, so dass zügig ein Vielfaches an Speicherplatz zur Verfügung gestellt werden kann.

Fazit – Azure SQL Database Hyperscale

Die Kombination und Trennung der einzelnen Funktionen machen einen sehr performanten Eindruck und lassen hoffen, dass sich diese Produkt am Markt etabliert. Auf jeden Fall ermöglicht es endlich Datenspeicherungen in der Cloud von mehr als 4-8 TB, welche bisher bei AzureSQLDB als Grenze galten. Manche Kunden bzw Solutions kommen eben leider nicht mit diesem “geringen” Datenmengen aus… aber gerade die Trennung der Funktionen ermöglichen ein schnelles und flexibles Skalieren der Lösung, ob im Storage-Bereich oder bei den eigentlichen Compute-Nodes. So kann man mittels Hyperscale sehr flexibel und schnell auf wechselnde Anforderungen reagieren und entsprechend seine Datenbank-Umgebung anpassen und auch nur im Ansatz an Performance zu verlieren, da alle Funktionen von einander getrennt sind. Man kann die Speicherkapazitäten ohne Downtime variabel gestalten aber auch die Read-Compute-Nodes in Menge oder Größe varieren, so dass man z.B. auf einen Käuferansturm (mehr Lese-Operationen) schnell reagieren kann.

Mehr Informationen zu diesem neuen Public Preview und der Roadmap findet ihr wie immer im Microsoft Blog und den Dokumentationen.

https://azure.microsoft.com/en-us/blog/tag/azure-sql-database/

Dokumentation – Azure SQL Database

Beitragsfoto von Jon Tyson über Unsplash

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

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