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.

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.

Pause / Resume / Backup einer Azure SQL Database mit Powershell – Teil 3

Viele Services in Azure erlauben durch Automatisierung eine gewisse Kostenersparnis, wie man das mit dem Platform-as-a-Service „Azure SQL Database“ erreichen kann, darum geht es in diesem Blogbeitrag. Ganz so einfach wie z.B. beim Azure Analysis Service ist es hier leider nicht, denn es gibt eigentlich keine Pause-Resume Funktionalität – wie hier das Backup mitspielt, dazu kommen wir als erstes.

Azure SQL Database und das Thema Backup

Bevor wir einsteigen in das Thema Azure SQL Database und dessen Pause-Resume-Funktionalität müssen wir vorher kurz einen Blick auf das Thema Backup werfen, welches in diesem Zusammenhang nicht ganz unwichtig ist. Einen großen Vorteil gegenüber einem SQL Server (onpremise oder IaaS) hat die Azure SQL Database auf jeden Fall… man muss sich nicht explizit um das Backup kümmern, da dieses automatisch erstellt wird. Soll heißen, je nach Datenbank-Größe und dem Aufkommen von Datenveränderungen sichert Microsoft automatisch die Datenbanken in regelmäßigen Abständen! Was heißen soll, die Kosten für eine extra Backup-Software oder gar die Entwicklung eigener Services fallen schon einmal weg. Je nach PerformanceLevel gibt es unterschiedliche Backup Retention Zeiten:

  • beim Basis Level beträgt die Aufbewahrungszeit 7 Tage.
  • beim Standard Level beträgt die Aufbewahrungszeit 35 Tage.
  • beim Premium Level beträgt die Aufbewahrungszeit 35 Tage.

Wann wird meine Datenbank denn aber nun gesichert? Auch darauf gibt es eine Anwort…
Das Full-Backup erfolgt jede Woche (leider) zu nicht fest definierten Zeiten, differentielle Backups werden generell alle paar Stunden erstellt und eben je nach Datenaufkommen erfolgt die Sicherung der TransaktionsProtokolle alle 5-10 Minuten. Ein erste Voll-Sicherung wird innerhalb der ersten 30 Minuten nach Erstellung der Datenbank erstellt. Diese Sicherungen werden entsprechend des Service-Tiers (siehe oben) aufbewahrt (Kostenersparnis : man braucht keinen extra Storage-Account, da das Backup bereits im Preis inkludiert ist). Möchte man sein Backup aber länger als 35 Tage aufbewahren, so hat man die Möglichkeit ein „Long-Time-Retention-Backup“ zu aktivieren, hierzu ist ein weitere Storage-Account notwendig auf dem dann die Backups parallel abgelegt werden und eben dauerhaft abgelegt werden können.

Backup Azure SQL Database

Pause und Resume zwecks Kostenersparnis

Diese Funktionalität gibt es leider bei Azure SQL Database nicht… Wie kann ich trotzdem eine Kostenersparnis erwirken, wenn ich diesen Platform-as-a-Service verwenden möchte… natürlich kann man – wie bereits in einem anderen Blogpost erläutert – die Datenbank Performance verändern, um die auftretenden Lastspitzen abzufangen. Aber wir möchten doch eigentlich mit der Migration in die Cloud auch eine gewisse Kostenersparnis erreichen… wenn die Fachabteilung nur tagsüber arbeitet (8-20 Uhr), dann brauche ich diese Datenbank(n) doch während der Nacht nicht… kann man die dann nicht einfach stoppen, da man doch nur zahlt, wenn die Datenbank online ist?

Für genau dieses Szenario – die Fachabteilung braucht die Datenbank nur tagsüber – gibt es eigentlich keine Lösung, aber einen Workaround, denn hier hilft abends nur ein „Drop Database“ und am nächsten Morgen  ein „Create Database from Backup“. Aber dieses Vorgehen hat Microsoft ausgesprochen angenehm gelöst und bedeutet keinen großen Aufwand.

# Dropping DB to stop costs
Get-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -ev notPresent -ea 0
if ($notPresent) {
    Write-Host $databasename "already deleted" 
} else {
    Remove-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename
}

Hierzu sollte man beachten, dass man nur die Datenbank löscht/entfernt und nicht den logischen Server, denn die Backup-Historie hängt am Server. Man benötigt also das Datum des letzten Backups um diese Datenbank wieder herzustellen. Beim Neu-Erstellen der Datenbank am folgenden Morgen nutzt man dann diesen Backup-Zeitpunkt, um damit direkt einen Restore durchzuführen. In Powershell kann man diese Tätigkeiten sehr einfach kombinieren.

$deleteddatabase = Get-AzureRmSqlDeletedDatabaseBackup -ResourceGroupName $resourcegroupname -ServerName $servername #-DatabaseName $databasename
$deleteddatabase
# Do not continue until the cmdlet returns information about the deleted database.

Restore-AzureRmSqlDatabase -FromDeletedDatabaseBackup `
    -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -TargetDatabaseName $databasename `
    -ResourceId $deleteddatabase.ResourceID `
    -DeletionDate $deleteddatabase.DeletionDate `
    -Edition "Standard" `
    -ServiceObjectiveName "S0"

Weitere Beispiele-Skripte zum Thema Backup/Restore findet ihr hier => https://docs.microsoft.com/de-de/azure/sql-database/scripts/sql-database-restore-database-powershell

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.

Einstieg in Azure SQL Database mit Powershell – Teil 1

Neben der Möglichkeit in Azure sich einen virtuellen Server zu deployen auf dem ein SQL Server läuft, gibt es auch die „einfachere“ Methode nur eine Datenbank on Demand zu deployen => die Azure SQL Database. Diese Database-as-a-Service kann man auch sehr gut und einfach für eine Vielzahl von Applikationen nutzen, wobei es auch eine Vielzahl an Optionen gibt über die man sich vorher Gedanken machen sollte.

  • reicht eine einfache Datenbank
  • lieber doch einen Elastic Pool
  • welche Region
  • oder doch lieber Geo-Redundant auslegen
  • reicht das „mitgelieferte“ Backup
  • oder muss das Backup eine „Long Time Retention“ erhalten
  • Wer greift von wo aus auf die Datenbank zu?
  • Welche Leistungsstufe brauche ich für die Datenbank bzw den Elastic Pool?

Eine Übersicht über die einzelnen Möglichkeiten und deren Verwendung für die jeweilige Solution, sowie eine großere Anzahl an Antworten auf viele Fragen findet man in der Dokumentation von Microsoft => https://docs.microsoft.com/en-us/azure/sql-database/

Beginn mit einer einfachen Azure SQL Database

Ein wichtiger Punkt in der Bereitstellung einer Azure SQL Database ist, dass man nicht nur eine Datenbank braucht sondern auch einen logischen SQL Server (=> Listener Endpunkt), ohne diese „Hülle“ kann man keine Datenbanken hosten.

In meinem folgenden Beispiel legen wir mit Powershell eine Standard-Datenbank an, natürlich als Script, damit wir den Server und seine Datenbank oder nur die Datenbank immer wieder gleich (als Standard) anlegen können.

Was benötigen wir alles um eine Azure SQL Database anzulegen

  • eine Resource Gruppe bzw deren Namen
  • eine Location für die Resource Gruppe
  • Admin-Usernamen und Passwort
  • einen Namen für den logischen SQL Server (der unique sein muss)
  • einen Datenbank Namen
  • idealerweise auch die IP-Adressen/Ranges, die darauf zugreifen dürfen (die eigene IP reicht für den ersten Zugriff)

Die Anmeldung an Azure sowie die Auswahl der zu nutzenden Subscription lasse ich hier aussen vor und beginne mit dem eigentlichen Script.
Mein erstes Script startet also mit der Definition diverser Variablen (siehe oben):

# Set the resource group name and location for your server
$resourcegroupname = "RG-AzureSQLDatabase-Demo"
$location = "west europe"
# Set an admin login and password for your server
$adminlogin = "dbadmin"
$password = "DemoPwd@2017"
# Set server name - the logical server name has to be unique in the system
$servername = "server-sqldbdemo"
# The sample database name
$databasename = "db-sqldbdemo"
# The ip address range that you want to allow to access your server
$clientIP = (Invoke-WebRequest ifconfig.me/ip).Content
$startip = $clientIP
$endip = $clientIP

Nun das Erstellen des logischen Servers und der Azure SQL Database mit Beispiel-Daten

Nun kommt – wie in fast allen meinen Scripten – erst einmal die Abfrage ob die Resourcegruppe bereits exisitiert, wenn nicht wird sie angelegt. Nach der Resourcegruppe kommt als nächstes der logische Server in den wir zum Schluss unsere Azure SQL Database einbinden können. Dem logischen Server weisen wir noch die Credentials aus adminlogin und password zu, damit der Server als auch die Datenbanken geschützt sind. Apropos geschützt, auch die Firewall des Servers müssen wir natürlich für einen externen Zugriff öffnen, hierzu ermittel ich über eine zusätzliche Funktion und einen externen Dienst meine eigene Public-IP-Adresse. Mit dieser IP-Adresse konfigurieren wir nun den logischen SQL Server und zu guter Letzt prüfen wir ob die gewünschte Datenbank vielleicht schon existiert, wenn nicht wird diese mit den gewünschten Parametern erstellt.

# Create a resource group
Get-AzureRmResourceGroup -Name $resourcegroupname -ev notPresent -ea 0
if ($notPresent) {
    $resourcegroup = New-AzureRmResourceGroup -Name $resourcegroupname -Location $location
} else {
    Write-Host $resourcegroupname "already exists"
}

# Create a server with a system wide unique server name
Get-AzureRmSqlServer -ResourceGroupName $resourcegroupname -ServerName $servername -ev notPresent -ea 0
if ($notPresent) {
    $server = New-AzureRmSqlServer -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -Location $location `
    -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $adminlogin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
} else {
    Write-Host $servername "already exists"
}

# Create a server firewall rule that allows access from the specified IP range
Get-AzureRmSqlServerFirewallRule -ResourceGroupName $resourcegroupname -ServerName $servername -FirewallRuleName "AllowedIPs" -ev notPresent -ea 0
if ($notPresent) {
    $serverfirewallrule = New-AzureRmSqlServerFirewallRule -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -FirewallRuleName "AllowedIPs" -StartIpAddress $startip -EndIpAddress $endip
} else {
    Write-Host "FirewallRule already exists"
}

# Create a blank database with an S0 performance level
Get-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -ev notPresent -ea 0
if ($notPresent) {
    $database = New-AzureRmSqlDatabase  -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -DatabaseName $databasename `
    -RequestedServiceObjectiveName "S0"
} else {
    Write-Host "Database" $databasename "already exists"
}

Nun können wir von unserer Workstation mittels SQL Server Tools – z.b. dem Management Studio – auf diese Datenbank zugreifen und die nutzende Applikation anbinden sowie testen.

Beispielzugriff - SSMS auf Azure SQL Database

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.