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.

SQLDays 2018 in München – Nachtrag – Pause aka Restore

Im Rahmen meines Vortrages auf den SQLDays in München hatte ich versucht einen Workaround zu “Wie spare ich Geld? Ich droppe einfach die Datenbank!”… hierzu möchte ich gerne ein Update posten.
Aber der Reihe nach, denn erst einmal möchte ich mich recht herzlich bei der ppedv Event bedanken für die Einladung nach München, zum anderen bei den zahlreichen Teilnehmern, die meine Session besucht haben! Ich hoffe ihr habt alle etwas aus meiner Session mitgenommen und könnt diese Ideen und Anregungen in eurem Alltag umsetzen bzw integrieren.

Unsplash - Photo by kevin Xue - THANK YOU

Powershell – Workaround um Kosten zu sparen

In meiner Demo ist das Wiederherstellen nach dem “Drop Database” leider fehlgeschlagen, so dass ich in meiner Demo nicht zeigen konnte wie man aus dem logischen SQL Server das gespeicherte “Last Deleted Database” entnehmen kann, um daraus einen Restore zu erzeugen. Ich habe diese Code-Zeilen bisher immer nur einmal ausgeführt, also Demo-Umgebung frisch aufsetzen, die Skripte nur auf Syntax überprüfen und hoffen das alles gut geht 😉 Dieses mal hatte ich meine Skripte eben doch einmal vorher ausgeführt, dadurch entstand schon ein Eintrag für “DeletedDatabases”… und somit gab es eben mehr als einen Eintrag und der Restore wußte nicht auf welches Datum er zurück gehen sollte…

# Do not continue until the cmdlet returns information about the deleted database.
if(![string]::IsNullOrEmpty($deleteddatabase)) {
Write-Host "Now restoring database $databasename_backup ..." -foregroundcolor "DarkYellow"
Restore-AzureRmSqlDatabase -FromDeletedDatabaseBackup `
-ResourceGroupName $resourcegroupname `
-ServerName $servername_backup `
-TargetDatabaseName $databasename_backup `
-ResourceId $deleteddatabase.ResourceID `
-DeletionDate $deleteddatabase.DeletionDate `
-Edition "Standard" `
-ServiceObjectiveName "S0"
}

Bin ich so bisher noch gar nicht drüber gestolpert, aber als ich dann nach der Session das Skript und den Output mir noch einmal angesehen habe…

SQLDays AzureSQLDB DeletedDatabases - Scriptproblem

Ich könnte mir vorstellen, dass es noch eine sichere oder sinnvollere Lösung gibt, aber als Ansatz bzw vorübergehende Lösung kann man das erst einmal so machen 😉
Es gibt zumindest zwei Möglichkeiten…

Möglichkeit 1

Aus meiner Sicht am einfachsten, aber unter Umständen nicht sicher, dass tatsächlich das Datum des letzten Löschvorganges übernommen wird, da das Skript zuvor keinen Einfluss auf die Sortierung der Ergebnisse nimmt.

# Do not continue until the cmdlet returns information about the deleted database.
if(![string]::IsNullOrEmpty($deleteddatabase)) {
Write-Host "Now restoring database $databasename_backup ..." -foregroundcolor "DarkYellow"
Restore-AzureRmSqlDatabase -FromDeletedDatabaseBackup `
-ResourceGroupName $resourcegroupname `
-ServerName $servername_backup `
-TargetDatabaseName $databasename_backup `
-ResourceId $deleteddatabase[0].ResourceID `
-DeletionDate $deleteddatabase[0].DeletionDate `
-Edition "Standard" `
-ServiceObjectiveName "S0"
}

Syntaktisches korrekt, funktioniert auf jeden Fall, ABER eben keine 100%ige Gewissheit, dass auch tatsächlich der gewünschte Zeitpunkt ausgewählt wird.

Möglichkeit 2

Etwas “umständlicher”, aber auf jeden Fall sicherer, denn wir wählen explizit das zu letzt hinzugefügte Datum aus.

# Do not continue until the cmdlet returns information about the deleted database.
if(![string]::IsNullOrEmpty($deleteddatabase)) {
Write-Host "Now restoring database $databasename_backup ..." -foregroundcolor "DarkYellow"
Restore-AzureRmSqlDatabase -FromDeletedDatabaseBackup `
-ResourceGroupName $resourcegroupname `
-ServerName $servername_backup `
-TargetDatabaseName $databasename_backup `
-ResourceId ($deleteddatabase.ResourceID | Select-Object -Last 1) `
-DeletionDate ($deleteddatabase.DeletionDate | Select-Object -Last 1) `
-Edition "Standard" `
-ServiceObjectiveName "S0"
}

Syntaktisches korrekt, funktioniert auf jeden Fall, ABER eben keine 100%ige Gewissheit, dass auch tatsächlich der gewünschte Zeitpunkt ausgewählt wird.

SQLDays-AzureSQLDB-DeletedDatabases-Script-optimized

Nun kann ich auch die SQLDays 2018 in München auf jeden Fall als Erfolg verbuchen, da ich wieder etwas an meinen Demos optimieren konnte und den Teilnehmern doch noch zeigen kann, wie dieses Skript funktioniert. In den nächsten Tage werde ich meine Demo-Skripte auf Github entsprechend aktualisieren, damit jeder davon profitieren kann!

Hier findet Ihr/sie nicht nur meine Skripte sondern auch meine Slides als PDF.

Skripte und Slides zu den SQLDays 2018 von SQL_aus_HH auf Github

Azure SQL Database – Lasttest der TempDB

Auf Facebook wurde ich gefragt, wie leistungsstark denn die “TempDB” einer Azure SQL Database wäre bzw sehr man diese belasten könne… also was liegt näher als die “TempDB” mit einem Lasttest zu verproben. Also habe ich über die Suchmaschine meines Vertrauens eine einfache und schnelle Möglichkeit gesucht, wie man explizit die “TempDB” belasten kann. Bei SQLServerCentral bin ich dann fündig geworden => Load Generator for TempDB

CREATE PROC EXERCISE_TEMPDB_SILLY AS
   SET STATISTICS TIME ON
   SET STATISTICS IO ON

   CREATE TABLE #temp(RecNo INT PRIMARY KEY CLUSTERED, Data varchar(80))

   INSERT INTO #temp SELECT -1, CAST(NewID() AS varchar(80))

   DECLARE @cnt AS INT
   SET @cnt = 0

   WHILE @cnt > -1
   BEGIN
      Print 'Loop ' + CAST(@cnt AS VARCHAR(9))
      
      INSERT INTO #temp 
      SELECT RecNo-Power(2,@cnt) , Right(Data + CAST(NewID() AS varchar(80)), 80)
      FROM #temp

      SET @cnt = @cnt+1
   END

Mit dieser Stored Procedure wird eine temporäre Tabelle in der “TempDB” erstellt und diese mit einfachen Werten befüllt, damit diese Werte nich “stupide” Hochzählen werden diese mit Rechenoperationen manipuliert. Da diese While-Schleife keinen Exist hat, läuft dieser Insert-Befehl in einer Endlos-Schleife mit dem Ziel die Grenze der TempDB zu ermitteln, da sich die Anzahl der einzufügenden Datenzeilen mit jedem Loop erhöht. Ein Kommentar in dem Forumsbeitrag deutet darauf, dass der Verprober auf seinem SQL Server 21 Loops geschafft hat, was ein erster Anhaltspunkt ist. Meine Azure VM mit SQL Server 2016 (Standard DS12 v2 (4 vCPUs, 28 GB memory)) schafft innerhalb von 2 Minuten 23 Loops…

Azure SQL Database - Lasttest

 

Lasttest-Bedingungen

Meine erste Tests zeigten, dass die Anzahl der Loops tatsächlich in einem gewissen Bereich liegen bzw eine gewisse Zeit benötigen, daraus machte ich einen einheitlichen Test von 2 Minuten… heißt das ich nach 2 Minuten Laufzeit auf den “STOP”-Knopf drücke, um somit die Ausführung der Stored Procedure zu unterbrechen bzw abzubrechen. Nachdem der SQL Server die Ausführung beendet hat, habe ich die Anzahl der durchlaufenen Loops ermittelt.

Loop 1 ergab 1 Insert
Loop 2 ergab 2 Inserts
Loop 3 ergab 3 Inserts
Loop 4 ergab 8 Inserts
[…]
Loop 10 ergab 512 Inserts
Loop 11 ergab 1024 Inserts
Loop 12 ergab 2048 Inserts
[…]
Loop 18 ergab 131072 Inserts
[…]
Loop 20 ergab 524288 Inserts
Loop 21 ergab 1048576 Inserts
Loop 22 ergab 2097152 Inserts
Loop 23 ergab 4194304 Inserts
Loop 24 ergab 8388608 Inserts

Wie man sehen kann hat die Datenbank bzw die TempDB ganz schön viel Daten zu verarbeiten, was auf deren Leistungsfähigkeit schließen lässt. Dieser Test soll erst einmal nur einen Anhaltspunkt für die Belastungsgrenzen aufzeigen… Die kleineren Leistungsklassen der Azure SQL Databases haben bei diesem Lasttest gezeigt, dass sie nach einer gewissen Anzahl Insert bzw Loops einfach am Ende sind und nicht mehr oder nur noch bedingt in der Lage sind Daten zu verarbeiten/aufzunehmen. Überrascht war ich in den höheren Leistungsklassen wie schnell die Inserts erfolgten und diese konnten sicherlich noch mehr Daten aufnehmen, hätte ich die Laufzeit des Testes erweitert (was ich sicherlich zu einem späteren Zeitpunkt nochmal machen könnte).

Lasttest-Ergebnis-Vergleich

Leistungsklasse Anzahl Loops Anzahl Inserts
Azure SQL Database S0 18 131072
Azure SQL Database S1 18 131072
Azure SQL Database S3 22 2097152
Azure SQL Database S9 25 16777216
Azure SQL Database P1 23 4194304
Azure SQL Database P6 24 8388608
Azure SQL Database P15 24 8388608
Azure SQL Database PR1 23 4194304
Azure SQL Database PR6 24 8388608
Azure SQL Server
(Standard DS12 v2 (4 vCPUs, 28 GB memory))
24 8388608
Azure SQL Server
(Standard DS15 v2 (20 vCPUs, 140 GB memory))
24 8388608

Wie man an der Ergebnis-Tabelle erkennen kann, sind die Unterschiede zwischen den höheren Leistungsklassen und den bewährten SQL Servern nicht sonderlich groß bzw gar nicht vorhanden. Was entweder heißt, man kann die Azure SQL Databases genau so stark belasten wie einen herkömmlichen SQL Server oder aber sie erreichen genauso schnell ihre Limits. Mein persönlicher Eindruck ist eher, dass die höheren Klassen bei diesem Lasttest noch mehr leisten können, wenn man ihnen mehr Zeit gibt. Anders herum würde ich sagen, dass man die Azure SQL Databases ohne zu zögern und ohne Bedenken mit einem “normalen” SQL Server mit SSDs vergleichen kann.

Azure SQL Database - Lasttest - TOP Ergebnis

Fazit des Lasttests

Aus aktueller Sicht würde ich jedem die Nutzung von Azure SQL Databases im Vergleich zu herkömmlichen SQL Servern empfehlen, sofern die Solution und das Umfeld/der Kunde dies ermöglichen.