South Florida Data Geeks Saturday 2021

Am heutigen Samstag durfte ich wieder einen Vortrag halten, dieses Mal ging es um die halbe Welt in das wunderschön warme und entspannte Süd-Florida, zur Data Geeks Community. Diese veranstalten bereits im elften Jahr ihren “SQL Saturday”, an dem normalerweise ~700 Teilnehmer vor Ort sind und sich mit Themen rund um die Microsoft Data Platform auseinandersetzen und in ihrer Freizeit zu den unterschiedlichen Themen sich informieren und lernen. Dieses Jahr wurden weltweit alle Data Platform Sprecher aufgerufen Ihre Sessions einzureichen, 92 Sprecher sind diesem Ruf gefolgt und haben es den Organisatoren nicht leicht gemacht aus den 180 eingereichten Themen-Vorschlägen die interessantesten und spannendsten Vorträge auszuwählen. Ich hatte mehrere Themen zu Azure SQL Databases und Azure Arc Data Services eingereicht

Für mich war es das erste Mal, dass ich in Florida dabei war, und hoffentlich nicht das letzte Mal, denn es war mir eine große Freude meinen Teil dazu beitragen zu können. In meiner Session am heutigen Samstag ging um die Unterschiede zwischen den Skills eines Datenbank-Administrators der “nur” on-premise SQL-Server betreibt und einem DBA, der nur/auch in der Cloud unterwegs ist. In dieser Session habe ich aufgezeigt, welche Services in der Azure Cloud für den SQL Server DBA gibt und wie sich sein Arbeitsumfeld und seine Tätigkeiten entsprechend verändern, welche Topics er in Zukunft mitbetreuen muss und wie er sich darauf vorbereiten kann.

Change your skills – from an onpremise DBA to a cloud DBA

Nach meiner kurzen Vorstellung wer ich bin und was ich mache, habe ich erst einmal einen kurzen Überblick gegeben, welche unterschiedlichen Services uns Microsoft in Azure für den Betrieb von SQL Server Datenbanken bereitstellt, wie sich diese Services von den on-premise unterscheiden. Für die einfachste Art und Weise der Migration von on-prem nach Azure eignet sich die normale Azure virtual Machine für die 1:1 Migration eines SQL Servers, sollte man nur eine einzelne Datenbank benötigen, so würde man sicherlich die Azure SQL Single Database wählen, wenn es aber eben doch eine vollständige SQL Server Instanz sein soll (aber eben ohne VM drum herum) dann wählt man die Azure SQL Managed Instance.

Da dies aber nicht alles ist und man doch gelegentlich Kompromisse machen muss oder es spezielle Anforderungen gibt, gibt es eben auch “Grauzonen” oder eben auch spezielle Lösungen wie z.B. die Azure SQL Hyperscale. In meinem Vortrag bin ich auf die Unterschiede eingegangen, bevor ich auf die Unterschiede zur lokalen SQL Server Umgebung eingegangen bin. Was also der zukünftige SQL Server DBA ebenfalls können sollte bzw mit welchen Themen er sich zukünftig beschäftigen sollte.

Azure SQL - Übersicht über die verfügbaren Services in Azure zum SQL Server
Vielen Dank an Anna und Bob für diese Slides 😉

Nachdem alle nun wussten, welche Services sie später betreuen können/müssen, konnte ich auch darauf eingehen, welche Unterschiede es von on-premise zu Azure gibt und welche zusätzlichen Schwerpunkte man betrachten muss. Hier war auf jeden Fall der Unterschied bzw die Unterschiede im Backup-Verfahren zu nennen, hier muss man sich unter Umständen gar nicht mehr drum kümmern oder eben doch, was vom gewählten Service abhängt. Die Azure SQL DB beispielsweise bietet auch die Möglichkeit der Unterstützung bei der Index-Optimierung von Indexen, das Datenbank-Monitoring verändert sich ebenfalls, da Azure sehr viele Daten selber sammelt und diese dem Nutzer im Portal darstellbar macht. Und große inhaltliche Veränderungen bzgl Verfügbarkeit kommen auf den Datenbank-Administrator im Bereich Netzwerk und Security zu, hier gibt doch recht viel zu beachten und konfigurieren, was immer auf die Anforderungen des Unternehmens bzw der Applikation ankommt.

Meine Präsentation

https://www.sql-aus-hamburg.de/wp-content/uploads/2021/08/Change-your-skills-from-an-onpremise-DBA-to-a-cloud-DBA-DataGeeks.pdf

Zu guter Letzt bin ich noch auf die Lern-Möglichkeiten eingegangen, die Microsoft kostenfrei zur Verfügung stellt um sich auf diese neuen Herausforderungen einstellen bzw vorbereiten zu können, welche Lernmodule, Lernpfade, Labs oder Workshops es gibt. In der folgenden Auflistung möchte ich die einzelnen Links entsprechend zur Verfügung stellen, ebenso wie meine Slides zu diesem Vortrag.

Lernen und Trainieren rund um Azure SQL

Ich möchte mich bei allen Teilnehmern und den Organisatoren für diese gelungene und sehr interessante Veranstaltung und natürlich ihr Vertrauen bedanken!

Azure SQL Database – Allgemeines – Refresh Teil 1

Ich betrachte die weiteren Beiträge als einen persönlichen Refresh meiner Kenntnisse über die Azure SQL Database und all ihre zahlreichen Features. Es war nach längerer Zeit mal wieder notwendig sich im Detail damit zu beschäftigen und für mich und meine eigenen Erfahrungen mit dem Lernen zeigen, dass “aufschreiben” sehr gut hilft, sich Inhalte und wichtige Punkte zu verinnerlichen. Also werde ich einfach die nächsten (wenn auch vielleicht kürzeren) Blogpost dafür verwenden, euch an meinem “Refresh” teil haben zu lassen. Dies ist in sofern auch relevant, als dass Microsoft Produktgruppe im Laufe der vergangenen Monate nicht untätig war und zahlreiche neue Features präsentiert hat bzw Optimierungen an den bereits vorhandenen vorgenommen hat. (Danke dafür 😉 )

Grundlegendes zu Azure SQL Database

Es geht also im Grunde erst einmal um den Azure Service, der uns eine SQL Server Datenbank bereitstellt, hierzu gibt es zahlreiche Möglichkeiten im Deployment bzw in der Ausprägung. Beginnend natürlich mit der Auswahl des benötigten Service (aka “Was brauche ich bzw meine Applikation?”)… beginnend mit der Frage, wieviele Datenbanken benötigt meine (neue oder vorhandene) Applikation wirklich? Sollte es sich um eine eigene Neu-Entwicklung handelt, hat man ggfs noch Einfluss auf gewisse Funktionalitäten, bei bereits exisitierenden Eigenentwicklungen oder Kaufprodukten ist dies schwerlich möglich. Beispiel VMWare… hier werden in der Regel mindestens 3 Datenbanken benötigt, beim Sharepoint noch viel mehr, bei einem CRM-System vielleicht nur eine.

Aber zum Verständnis, es geht hierbei nicht darum, dass z.B. mein Mandantenfähiges CRM pro Mandanten eine eigene Datenbank anlegt sondern darum, dass pro Mandant nur eine (!) Datenbank benötigt wird, also keine “Cross-Database” Abfragen benutzt werden.

Sollte man hier also eine Aussage treffen können, ist man einen Schritt weiter und kann zumindest einmal eine Entscheidung treffen, dass Azure SQL Database das richtige Produkt ist, nun kommt der vielleicht schwierigste Punkt, der sich aber (unter Umständen) nachträglich gut anpassen lässt.

Aber die Überschrift heißt ja, Grundlegendes zu Azure SQL Database… Mircosoft stellt uns in Azure einen Platform-as-a-Service Datenbank Dienst zur Verfügung, der auf dem SQL Server basiert, hier kommt immer die letzte stabile Version zum Einsatz, wir als Administratoren müssen uns hier um wenig Gedanken machen, da Microsoft uns schon sehr viel abnimmt, wie zum Beispiel Upgrades, Backup oder Monitoring, zu den einzelnen Punkten komme ich später noch einmal. Ebenso in Sachen “Hochverfügbarkeit” müssen wir uns keine Gedanken machen, alle Azure SQL Database Services (je nach SKU und Deployment) kommen auf mindestens 99,99% Verfügbarkeit und lassen sich so auch für kritische und performante Business-Applikation verwenden.

Wie wir es vom SQL Server kennen, können auch in der Cloudrelationale als auch nicht relationale Datenstrukturen verwendet werden, genauso wie In-Memory-Technolgien.

Auswahl-Möglichkeiten für alle Anforderungen

Der Azure Service Azure SQL Database lässt sich in unterschiedlichen Ausprägungen und Leistungsklassen “mieten”, so dass man nahezu jeder Anforderung gerecht werden kann.

  • Einzel- oder Pool-Datenbank
  • Hyperscale
  • Serverless

Jedes einzelne Deployment lässt sich noch unterteilen in die verschiedene Performanceklassen, welche ich später auch noch näher erläutern werde. Hier spielen Aspekte wie CPU, RAM, Datenbank-Größe und Nutzungsdauer eine Rolle, um eine optimale Entscheidung treffen zu können.

Azure SQL Database - Darstellung des Azure Portals - Auswahl der unterschiedlichen Services

Deployment-Unterschiede einer Azure SQL Database

Sollte man also zu der Entscheidung kommen, dass man nur eine Datenbank benötigt, dann ist die Azure SQL Single-DB (oder Singleton) das Optimale. Hierbei stellt uns Azure eine einzelnen Datenbank auf einer gesharten Umgebung zur Verfügung, die aber so abgeschottet bzw isoliert läuft, dass man sich keine Gedanken machen muss, dass hier etwas passiert (also keine Fremdzugriffe von ausserhalb ihrer eigenen Datenbank). Hierbei erhält jede Azure Single DB eigene Compute-Ressourcen und kann diese dann entsprechend exklusiv nutzen.

Hat man zum Beispiel mehrere kleine Datenbanken, die zu unterschiedlichen Zeiten unterschiedliche Auslastungen haben, so kann man sich genau für eine Azure SQL Elastic Pool entscheiden, hierbei werden mehrere Einzel-Datenbanken in einen Pool konfiguriert, die sich dann – je nach Nutzungsverhalten und Workload – die geteilten Compute-Ressourcen teilen können.

Je nach Anforderungen der Applikation oder des Businesses können sowohl Einzel- als auch Elastic-Pool Datenbanken dynamisch skaliert werden, um so die Leistung der Datenbanken an die zu verarbeitende Workload anzupassen.

Microsoft unterscheidet in diesen Performanceklassen in Serverless oder Server-based, wobei Server-based auch noch einmal unterteilt wird in “General Purpose / Universell” und “Business Critical / Unternehmens-kritisch” und darin auch noch weiter in die Möglichkeiten die Compute-Ressourcen auszuwählen, in vCore- oder DTU-basiert. Bei den Elastic-Pools gibt es aktuell kein Serverless-Deployment, aber die Unterscheidungen in GeneralPurpose und BusinessCritical sowie die Einteilung in DTU (Data Transaction Units) und vCores.

Azure SQL Database - Darstellung des Azure Portals - Auswahl der Performance-Klassen von Elastic Pools

Zu Verfügbarkeiten, Monitoring und Backup von Azure SQL Datenbanken komme ich in einem der weiteren Blogbeiträge.

Housekeeping einer Azure SQL DB Managed Instance

Ich habe mich heute etwas intensiver mit der “neuen” Azure SQL Database – Managed Instance beschäftigt und dabei ging es auch um das Housekeeping, welches man in regelmäßigen Abständen auf allen SQL Servern durchführen sollte. Überlicherweise nehme ich hierfür die Skripte von Ola Hallengren, welche in regelmäßigen Abständen aktualisiert und erweitert werden. Aufgrund der weit verbreiteten, weltweiten Nutzung kann man hier auch davon ausgehen, dass die Funktionalität und Stabilität absolut produktionswürdig ist und können daher ohne Bedenken auch in Produktionsumgebungen eingesetzt werden.

Für einen Workshop und natürlich aus eigenem Interesse habe ich einen einfachen Weg gesucht, wie ich das Housekeeping in einer Managed Instance realisieren kann, daher habe ich einfach nur das normale Skript von der Webseite runtergeladen und in das SQL Management Studio eingefügt. Kurz überprüft, ob die Einstellungen in dem Skript valide sind und ausgeführt.

Zu meinem Erstaunen lief das Skript ohne Probleme einfach durch und meldete eine erfolgreiche Ausführung, ein kurzer Blick in die SQL Server Agent Jobs brachte die nächste Überraschung da die zu erstellenden Jobs auch tatsächlich vorhanden waren. Ok, die Backup-Jobs fehlten, aber darum brauche ich mich in einer Managed Instance nicht zu kümmern, da dies automatisch erfolgt.

Managed Instance - Housekeeping - Ola Hallengren - SQL Server Agent Jobs

Als ich jetzt auch noch die Jobs nacheinander gestartet hatte und diese alle einwandfrei durchliefen, war ich nahezu platt. Also ich kann die Ola Hallengren Housekeeping Jobs nur empfehlen, sowohl onprem, als auch in irgendeiner virtuellen Maschine oder eben in der Azure SQL Database Managed Instance! Beim Schreiben dieses Beitrages habe nocheinmal direkt in das Skript geschaut, ob es irgendeine “Magic” gibt, die dafür sorgt, dass die Backup-Jobs nicht angelegt werden und tatsächlich hat Ola hier großartige Arbeit geleistet. Wenn man sich dann auch die Dokumentation auf der Webseite anschaut, wird man feststellen, dass er tatsächlich auch auflistet, dass die Managed Instance offiziell unterstützt wird.

Also worauf wartet ihr, nutzt die Ola Hallengren Housekeeping Jobs (aka Maintenance Jobs) auch für eure SQL Server!

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.