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

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