Unterwegs zum SQL Saturday Rheinland #605 – mein erstes Mal

Mittlerweile ist der SQL Saturday Rheinland schon einige Zeit her und ich komme erst jetzt zum Schreiben meines Blogbeitrages… es war einfach zu viel in den letzten Tagen bzw Wochen, beruflich war viel los, mehrere Termine zu Azure und andere Artikel waren in der Pipeline (die thematisch besser in meinen Alltag und aktuellen Lernplan passten). Aber aufgeschoben ist nicht aufgehoben, jetzt also mein Beitrag zum SQL Saturday Rheinland, der mittlerweile zum 5 Mal erfolgte, was auch in Zusammenarbeit mit der Hochschule Rhein-Sieg großartig zelebriert wurde. Im letzten Jahr war ich “nur” als Teilnehmer und Voluntär dabei, dieses Jahr ging ich noch einen Schritt weiter und hatte mehrere Sessions eingereicht und wurde als Sprecher (“Azure SQL Server und Azure SQL Database Automation”) ausgewählt. Bei einem Treffen mit Kostja Klein und Tillmann Eitelberg bei Microsoft wurde ich auch noch gefragt, ob ich mir vorstellen könne im 101-Track einen Vortrag zur SQL Server Installation zu halten… also durfte ich auf meinem ersten SQL Saturday als Sprecher gleich zweimal ran! (Vielen Dank dafür!)

SQL Saturday Rheinland - Fachschaft grillt für die Teilnehmer - Foto von Dirk Hondong - Flickr

Wie bereits im Vorjahr begann mein SQL Saturday Rheinland bereits am Freitag sehr früh, denn ich wollte am Azure Precon Vortrag von Scott Klein teilnehmen… und natürlich am Speakers-Dinner. Also klingelte der Wecker bereits um 3:30, damit ich rechtzeitig um 4:00 auf der Autobahn sein konnte, nun hieß es etwa 4 Stunden bis nach St. Augustin ohne große Staus zu bewältigen.

Der Precon-Day mit Azure Guru – Scott Klein

Dank guter Planung war ich pünktlich und konnte vor Beginn noch die ersten Gespräche mit anderen bekannten Anwesenden führen, unter dem wachsamen Auge der Kamera von DatamonsterTV fing Scott dann an uns die Neuerungen bzw zahlreicher Highlights der Azure Dataplatform näherzubringen. Vielen Dank für die großartigen Einblicke und Demos, ich habe viel neues mitgenommen und einige Details zu bereits bekannten Themen erfahren. Der Tag ging schneller voran als befürchtet, die Pizza zum Mittag schmeckte lecker, die geek-typischen Snacks in den Pausen ebenfalls. Zahlreiche interessante Gespräche in den Pausen und “lustige” ungeplante Kennenlernen (“du machst auch ein Azure Meetup” – es waren 4 Azure Meetups anwesend) taten ihr übriges zu einem kurzweiligen Tag.

Nach dem Vortrag war vor dem Vorbereiten, wie auch bereits in meinem ersten Jahr beim SQL Saturday Rheinland hatte ich mich auch dieses Jahr wieder für die Vorbereitungen und das Aufbauen gemeldet… ich kann das nur jedem empfehlen, man lernt alle frühzeitig kennen und es macht riesigen Spaß…

SQL Saturday Rheinland - Taschenpacken - Foto von Dirk Hondong - FlickrSQL Saturday Rheinland - Taschenpacken - Foto von Dirk Hondong - Flickr

Das Speakers-Dinner – ein Ausflug mit der SQLFamily

Am Freitag Abend findet in der Regel immer ein Treffen aller Speaker statt, so dass man mal alle anderen Sprecher kennenlernen kann und meist ist es dann auch wie bei einem Familientreffen. Die meisten kennen sich sehr gut, was daran liegt, dass es einen “harten” Kern an Sprechern gibt, die sich immer wieder auf Veranstaltungen wie SQLSaturday oder anderen Usergruppen-Treffen sehen, die SQLFamily ist schließlich nicht so groß 😉 Vielen Dank an dieser Stelle an den You-Rock-Sponsor Solisyon, der unter anderem auch zu diesem entspannten und leckeren Abend beigetragen hat.
Ich möchte euch auch nicht vorenthalten wo wir diesen netten Abend verbracht haben und zwar waren wir im Weingut Sülz in Königswinter, sehr idyllisch an einem Weinhang gelegen und sehr gut zu Fuß von der Straßenbahn zu erreichen. Die verschiedenen Flammkuchen und anderen Speisen sowie natürlich der Wein waren super lecker, auf jeden Fall ist diese Lokalität sehr zu empfehlen… auch für Spaziergänger sehr gut zu erreichen, laut Auskunft von Tillmann führt ein schöner Wanderweg direkt durch den Weinanbau.

SQL Saturday Rheinland - Speakerdinner auf dem Weingut Sülz - Foto von Dirk Hondong - Flickr

Der eigentlich SQL Saturday Rheinland

Ich kann nur jedem “Erstling” empfehlen, besucht die Veranstaltung erst einmal vorher als Teilnehmer => macht euch vertraut mit der Umgebung und den Abläufen, lernt vielleicht sogar schon mal die Organisatoren kennen, mir hat dies entscheident geholfen die Nervosität abzubauen. Also wie bereits geschrieben, war dies mein erster SQL Saturday als Sprecher und dann auch gleich zwei Sessions (Danke nochmals an Tillmann, Oliver und Kostja für das Vertrauen!). Es ging also los mit meinem Vortrag über “Wie installiert man einen SQL Server” im 101-Track, also eigentlich gedacht für SQL Server Einsteiger und/oder die Studenten, aber auch erfahrenere Teilnehmer konnten noch was mitnehmen – wie mir einige hinterher erzählten. Die Session wird im Laufe des Jahres dann auch im DatamonsterTV zu sehen sein. Meine Slides findet ihr hier im Blog => http://www.sql-aus-hamburg.de/speaker-sessions/.

Meine zweite Session durfte ich dann im großen Audimax zum Thema “Azure SQL Server und Azure SQL Database und deren Automation mit Powershell” halten, auch diese Runde mit all ihren Demos lief recht reibungslos und hat mir viel Spaß gemacht, ein wenig mehr Zeit wäre schön gewesen (aber warum rede ich auch soviel…) Nach meinen beiden Sessions konnte ich mir dann in aller Ruhe die anderen Vorträge aussuchen und entspannt geniessen, so war ich zum Beispiel bei Gabi Münster zum Thema “Women in Technology” oder Andre Kamann zu “SQL Server and Docker. What, How and Why”. Es gab für jeden garantiert ein Thema von dem er etwas mit nach Hause nehmen konnte und wem das nicht reichte konnte sich an den zahlreichen Informationsständen der Sponsoren über deren Produkte oder Dienstleistungen erkundigen.

Nachdem alle Vorträge gehalten waren, ging es zu einem weiteren Highlight des SQL Saturday Rheinland, dem Raffle… jeder Teilnehmer erhielt im Laufe des Tages durch Gespräche mit den Sponsoren die Möglichkeit einen von mehreren Preisen zu gewinnen, so verloste die PASS Deutschland e.V. zum Beispiel eine X-Box oder Solisyon ein Carrerabahn-Set.

SQL Saturday Rheinland #605

Das Abschluss-Grillen mit guten Freunden

Am Abend konnten alle Teilnehmer bleiben und sich durch die Fachschaft der Hochschule Rhein-Sieg begrillen lassen, dazu gab es diverse Getränke zu wirklich moderaten Preisen zu Gunsten der Fachschaft. Es war lecker, unterhaltsam, kurzweilig und sehr lustig mit den zahlreichen Anwesenden, das kann gerne wiederholt werden! Der Abend fand einen gemütlichen und geselligen Ausklang mit einigen Sprechern in der Hotelbar, auch dieses Zusammensitzen trägt sehr zum “Wir”-Gefühl bei, was ich während dieses SQL Saturday Rheinland empfunden habe. Ich hatte eigentlich nie das Gefühl, dass ich der “Neue” bin sondern schon lange dazu gehöre und kein “Fremdkörper” bin, die SQLFamily ist sehr offen für neue Gesichter und freut sich immer über engagierte Sprecher.

Vielen Dank auch an Dirk Hondong, der wieder sehr viele großartige Bilder des SQL Saturdays geschossen hat und derer ich mich hier fleißig bedient habe!

Bilder von Dirk findet ihr auf Flickr, in seinen Blog schreibt er über den SQL Server und auf seinem Twitter Account teilt er gerne vorab schon mal ein paar Bilder von Veranstaltungen der SQLFamily.

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!