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

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

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) 😉

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

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. 😉

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

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

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

PASSCamp 2017 – mein erstes Mal

Im Oktober 2017 wurde ich von Oliver Engels und Tillmann Eitelberg gefragt, ob ich auf dem PASSCamp was über Azure SQL Database insbesondere die neue Managed Instance (damals noch im Private Preview) erzählen bzw den Teilnehmern etwas zeigen kann… ja, wollte ich gerne… aber konnte und durfte ich dann doch leider nicht, da es kaum Informationen und Dokumentationen gabe und vor allem leider keine wirklich nutzbare Umgebung für die Teilnehmer des PASSCamps. So wurde es „nur“ ein halbtägiger Workshop zu Azure SQL Database.

Bjoern Peters auf dem PASSCamp 2017

Aufgrund dessen, dass dies mein erster Workshop gewesen ist, war ich sehr unsicher wie lange die Zeit für HandsOn und Vortrag tatsächlich ist… natürlich habe ich zuhause alles mehrfach durchgespielt und hatte eine zeitliche Vorstellung von dem Ganzen, aber irgendwie ist es vor Ort dann leider doch etwas anders gelaufen als erwartet… Sorry dafür!

Auf jeden Fall hat mir mein erster Vortrag auf dem PASSCamp sehr viel Spaß gemacht!

PASSCamp – Welch eine Ehre für mich!

Zur Vorgeschichte 😉 Damals – anno 2012 – durfte ich meinen damaligen Kollegen zum PASSCamp schicken und hörte absolut nur Positives, sowohl über Qualität und Inhalte als auch über die Sprecher und die ganze Veranstaltung. Im folgenden Jahr durfte ich dann selber daran teilnehmen und wurde nicht enttäuscht! Es war für uns beide die erste Erfahrung mit der PASS bzw der SQL Server Community sogar mit solch einer Art der Veranstaltung… wir waren restlos begeistert…

Man sagt ja, dass manche Wege verschlungen sind und man sich nicht ohne Grund ein zweites Mal trifft… in meinem Fall war es dann Conny, welche meinen Weg auf dem Rückweg nach Hause mehrfach kreuzte und ich so auch später den „Zugang“ zur Regionalgruppe der PASS in Hamburg fand (Wir reden und wundern uns manchmal immer noch über diese Heimfahrt). Über die Teilnahme an den regelmäßigen Treffen der Regionalgruppe lernte ich dann später auch die SQLSaturdays in Deutschland kennen und somit den Anfang von meinem aktuell Weg in der Community. Ich kann nur soviel sagen, dass ich bisher nicht einen Schritt davon bereue! Aber der Reihe nach…

Oliver Engels kicks off PASSCamp 2017

Für mich – als DBA – war das PASSCamp immer ein Highlight im Kalender aufgrund der Aktualität der Inhalte und Qualität der Sprecher, in Verbindung mit einem großartigen Ambiente in entspannter Umgebung mit vielen interessierten Menschen gemeinsam lernen!

Daher war die Einladung als Sprecher zum PASSCamp auch eine große Überraschung und ich habe mich sehr darüber gefreut, dass ich dort sprechen durfte. In 2013 für mich nicht vorstellbar, einmal selber dort vor der Gruppe zu stehen und mein Lieblingsthema vortragen, aber anscheinend lohnt sich beständiger Einsatz (dadurch der MVP-Award und dadurch einen „Vorteil“) als Grundlage für das Vertrauen und die Einladung. Vielen Dank für Oliver und Tillmann für ihren Einsatz und die ganzen Mühen solch eine Veranstaltung zu organisieren!

DANKE PASSCamp und SQLPASS_de

Bild-Quelle : Dirk Hondong (aka SQLPaparazzo) – Danke Dirk

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.