Resize einer Azure SQL Database mit Powershell – Teil 2

Nachdem ich im ersten Teil meiner Azure SQL Database Powershell Automation Reihe gezeigt habe, wie man sich die Ressource-Gruppe, den logischen SQL Server und die entsprechende Datenbank anlegt, möchte ich euch nun zeigen wie man ein Resize des Performance-Level dieser Datenbank umsetzen kann.
Warum soll man eine Datenbank resizen wollen? Nach oben – also mehr Leistung kann man vielleicht noch verstehen, aber warum auch wieder ein Downsizing machen? Also starte ich erst einmal mit den jeweiligen Gründen für eine Anpassung der gewählten Leistungsklasse.

Welche Leistung brauche ich wann?

Nehmen wir am besten ein Beispiel… eine größere Firma die Arbeitsplätze (Workspace) vermietet und nur in Deutschland aktiv ist, hat eine Applikation zur Verwaltung/Buchung ihrer Meetingräume bzw Arbeitsplätze. Diese Applikation wird von den Damen am Empfang nur während der „Öffnungszeiten“ intensiv genutzt und außerhalb dieser Zeiten gelegentlich durch Mitarbeiter. Im Grunde benötigen die Empfangsdamen ihre Applikation und somit die Datenbank nur zwischen bestimmten Zeitpunkten, beispielsweise 7 – 20 Uhr, den Rest des Tages bleibt die Datenbank nahezu ungenutzt…
Was liegt also näher diese Datenbank tagsüber „schneller“ zu machen? On-prem ist dies leider nicht möglich, da man einer einzelnen Datenbank nicht so ohne weiteres weitere Ressourcen zuweisen kann.

Ein weiteres Beispiel sind Auswertungen oder Verarbeitungen, hier können die betrieblichen Belange stark variieren, wenn am Monatsende der Abschluss ansteht wird mehr Rechenleistung in der Azure SQL Database benötigt, damit die Daten ausreichend schnell verarbeitet und bereitgestellt werden können.

  • je nach Applikation-Nutzung-Verhalten
  • je nach betrieblichen Anforderungen
    • nächtliche Verarbeitungen
    • Monatsabschluss
    • Jahres-End-Rally

Azure SQL Database

Was benötigen wir alles für einen Resize der Azure SQL Database

  • eine Resource Gruppe bzw deren Namen
  • einen Namen für den logischen SQL Server (der unique sein muss)
  • einen Datenbank Namen
  • das neue Performance-Level (DTU)

Die Anmeldung an Azure sowie die Auswahl der zu nutzenden Subscription lasse ich hier aussen vor und beginne mit dem eigentlichen Script.
Auch hier starte ich mit der Definition der notwendigen Variablen (siehe oben):

# Set the resource group name for your server
$resourcegroupname = "RG-AzureSQLDatabase-Demo"
# Set logical server name
$servername = "server-sqldbdemo"
# The sample database name
$databasename = "db-sqldbdemo"
# Set new performance-level
$newdbDTUsize = "S3"

Nun können wir die Azure SQL Database resizen

Dies ist wesentlich einfacher als die Neu-Anlage einer Datenbank, da wir weniger Variabeln (siehe oben) und nur eine Kommandozeile zur Ausführung benötigen. Aber auch frage ich vorsichtshalber das Vorhandensein der Datenbank ab, um sicherzustellen, dass das Script keinen „Blödsinn“ macht.

# Resize Azure SQL Database to new performance-level
Get-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -ev notPresent -ea 0
if ($notPresent) {
    Write-Host $databasename "doesn't exist" 
} else {
    Set-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -Edition "Standard" -RequestedServiceObjectiveName $newdbDTUsize
}

Wie der Vorher-Nachher-Vergleich zeigt, ist ein Resize ohne Probleme möglich und dauert nur wenige Augenblicke.

Vorher-Nachher-Resize 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.

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.