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

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

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

dbatools – Migration der SQL Agent Backup Jobs

Man kann denken was man will, aber manchmal muss man über seinen Schatten springen… in der Regel bin ich ein Verfechter des SQL Server eigenen Backups, egal ob Backup to Disc, Backup to URL oder Backup to NetworkShare, aber hier musste ich (leider) nachgeben und die Sicherung mittels 3rd-Party-Tools einrichten. Gesagt… getan…

Bei dem Kunden hatten wir sowieso schon alles auf 3rd-Party-Backup umgestellt, aber nicht auf Backup-Server initiertes Sicherungen, sondern SQL Server initiert. Der SQL Server Agent startet also das jeweilige Backup als Kommandozeilen-Aufruf. Hierzu musste ich also die Sicherungsjobs von einem existierenden Server kopieren und anpassen, sowie alle dazugehörigen SQL Server Objekte. Gestartet habe ich mittels “Create Objects to NewQuery”, erhielt aber die Fehlermeldung, dass die Mail-Komponente bzw Empfänger noch existiert bzw konfiguriert ist. Also musste ich erst die SQL-Mail-Konfiguration übernehmen, hierzu auch noch die Operator übernehmen und wenn wir schon beim Mailing sind, dann kann ich die von Brent Ozar empfohlenen SQL Agent Alerts auch gleich mit migrieren…

dbatools - die Powershell Modulsammlung für den DBA

verwendete Powershell Module – dbatools

Macht euch mal kurz Gedanken dazu, wie man die Konfiguration von SQL-Mail, Operatoren und Custom-Alerts ohne großen Aufwand von einem SQL Server auf den anderen migrieren kann, also ich meine mit Bordmitteln… das ist zwar nicht wirklich viel Aufwand, aber doch etwas mehr als 5 Minuten. Also was liegt näher als sich intensiver mit den dbatools zu beschäftigen…
Mittels “Copy-SqlDatabaseMail” kann man die SQLMail-Konfiguration übernehmen, mit “Copy-SqlOperator” die eingerichteten Operatoren migrieren, weiter geht es mit “Copy-SqlAlert” und zum Schluss noch die Jobs kopieren. Ist doch gar nicht so viel 😉

Copy-SqlDatabaseMail -Source SQLServer01 -Destination SQLServer02
Copy-SqlOperator -Source SQLServer01 -Destination SQLServer02
Copy-SqlAlert -Source SQLServer01 -Destination SQLServer02
Copy-SqlJob -Source SQLServer01 -Destination SQLServer02 -Jobs  Full-Backup, TLog-Backup

Also ganze 4 Zeilen Powershell Code um mir die Arbeit zu erleichtern, auch dank der Vereinheitlichung der Parameter innerhalb von dbatools ist auch die Parametrisierung der einzelnen Befehle eine sehr einfache Sache und schnell und unkompliziert zu erledigen. Man kann die Nutzung von dbatools nur jedem empfehlen!

dbatools – Copy-SqlLogin – Wie man Kunden beeindrucken kann

Für einen Kunden habe ich diese Woche einen neuen SQL Server 2016 SP1 + Management Studio installiert und konfiguriert, alle notwendigen Housekeeping-Jobs eingerichtet und mich um meine dokumentarischen Pflichten gekümmert. Über meine Rückmeldung, dass ich den Server bereits fertig hatte, freute sich mein Kunde und bat mich dann per Mail um folgendes:

[…]
Sent: Wednesday, June 21, 2017 3:43 PM

Außerdem sollten die SQL-User vom SQL01 übernommen werden (wenn möglich).
Geht das?
[…]

Vor zwei Jahren hätte ich wahrscheinlich geantwortet: “Ich versuche es, kann aber für nichts garantieren. Ich melde mich dann in 2 Tagen wenn ich fertig bin…”
Dann hätte ich mich daran gemacht und alle vorhanden Logins und deren Rechte auf Instanz- und Datenbankebene heraus geskriptet, auf dem neuen SQL Server eingespielt und den Kunden gebeten zu testen… (natürlich in der Hoffnung, dass alle Passwörter und Rechte passen) Mein Gott war das immer ein Aufwand, bei zwei oder drei Accounts war das ja gar nicht so das Problem, aber was wenn es plötzlich 100 Accounts sind 😮

Aber da gab es ja die Powershell-Modul-Sammlung von dbatools noch nicht, mit der ich ja bereits großartige Erfahrungen gemacht, schon in einigen Talks darauf hingewiesen und in meinem Blog darauf hingewiesen habe.

In dbatools gibt es eine Funktion “Copy-SqlLogin”, welcher laut Beschreibung alle meine gewünschten Aufgaben in einer Powershell Zeile vereint!

This command migrates logins from source to destination SQL Servers. Supports SQL Server versions 2000 and above. Migrates logins with SIDs, passwords, defaultdb, server roles & securables, database permissions & securables, login attributes (enforce password policy, expiration, etc).
By default, all logins with the exception of system (####Example Login## and local (SERVERNAME\administrators) logins are copied. The -Logins parameter is autopopulated for command-line completion and can be used to copy only specific logins.
If the login already exists on the destination, it will be skipped unless -Force is specified. Force drops and recreates the login.

Da die Anforderung des Kunden lautete “die SQL-User vom SQL01 übernommen werden”, brauchte ich nicht vorher zu analysieren, sondern einfach alle vorhandenen User des alten Servers auf den neuen Server migrieren. Dazu einfach die aktuelle Modul-Sammlung herunterladen, sicherstellen dass auf dem neuen Server auch mindestens Powershell 3 installiert ist. Wenn alles vorhanden ist, müssen die Module nur import werden und schon kann man mit den dbatools loslegen und alle Kommandos auf der Commandline ausführen oder in Scripten verwenden.

Um die Kundenanforderung zu erfüllen, nutze ich also die ganz einfache Kommandozeile:

Import-Module .\dbatools-master\dbatools.psd1
Copy-SqlLogin -Source SQL01 -Destination SQL02

Die Ausführung des Scriptes hat kaum 2 Minuten gedauert und alle User waren migriert!

Durch diese sehr starke Vereinfachung der Account Migration von einem SQL Server zum anderen, konnte ich dem Kunden sehr schnell eine Abschluss-Meldung schicken.

Gesendet: Mittwoch, 21. Juni 2017 15:56
Bitte sehen Sie diesen Task als erledigt an.

Die Antwort meines Kunden kam umgehend 😉

Sent: Wednesday, June 21, 2017 3:59 PM
Danke. Respekt!

(Man muss dazu wissen, dass diese Worte von diesem Kunden(-Mitarbeiter) schon “Gewicht” haben, da dieser sonst nicht so leicht zu beeindrucken ist, daher freuen mich diese Worte sehr!)

Vielen Dank an Chrissy LeMaire und die dbatools-Community für diese hervoragende Arbeit!