Azure und insbesondere Azure SQL ist klasse – es nimmt einem viele Dinge der täglichen Verwaltung ab, einiges davon sogar automatisch. Klar, das hat seinen Preis, immerhin ist Azure SQL nicht ganz billig, aber wenn man es schon bezahlt, dann kann man auch seine Fähigkeiten nutzen. Eine davon ist, automatisch anhand der Nutzung einer Datenbank Empfehlungen für die Leistungsoptimierung zu geben. Diese kann man sich im UI bzw. dem Azure Portal anschauen. Dazu öffnet man entweder links im Blade den Punkt „Recommondations“ unterhalb von „Intelligent Performance“ oder den Punkt „Performance“ auf der Main-Page bei den Notifications:
Dort sieht man dann einige Empfehlungen aufgeführt (vorausgesetzt, Azure hat etwas gefunden, was wiederum eine regelmäßige Nutzung der Datenbank voraussetzt):
Diese Daten kann man sich auch automatisch abrufen und auf Wunsch dann z.B. an die Entwickler verteilen. Dazu bediene ich mich einfach der PowerShell:
Dieses Script wiederum kann man dann z.B. per Jenkins regelmäßig auslösen. Oder alternativ ein Azure Automation Runbook dafür anlegen… Viel Spaß beim Ausprobieren!
Bei der Version 2012 R2 des System Center Data Protection Managers gibt es ein Problem mit der Sicherung von SQL Servern der Version 2012. Es wird nach Erstellen der Schutzgruppe bzw. beim Versuch der Erstellung eines Replikates die Meldung “Der Schutz kann nicht konfiguriert werden” ausgegeben (Im Englischen: “Unable to configure protection”).
(Leider hab ich vom Fehler selbst in der Produktiv-Umgebung keinen Screenshot gemacht und ich wollte ihn nicht nochmal nachträglich provozieren – daher ein Shot aus einer englischen Umgebung)
Dieses Problem ist scheinbar bei Microsoft bekannt und auch im TechNet dokumentiert:
Die Lösung ist auch recht einfach, da der Grund ebenso einfach ist: Der Schutz-Agent hat keine SA-Rechte auf der Datenbank, also müssen diese noch vergeben werden!
Dazu startet man auf dem zu sichernden Zielserver einfach das “SQL Server Management Studio”:
Dort kann man dann in dem Bereich “Sicherheit”, unter “Anmeldungen” das Konto von “NT-AUTORITÄT\SYSTEM” mit einem Rechtklick und der Auswahl von “Eigenschaften” öffnen. Hier muss dann die Rolle “sysadmin” zusätzlich mit ausgewählt werden.
Danach sollte sich die Sicherung via DPM auch problemlos einrichten und durchführen lassen:
Auf einem Test-Server für eine System Center Configuration Manager 2012 Umgebung lief auch der dazu notwendige SQL-Server. Da die Hardware einen Defekt aufwies, musste ich das System auf eine neue Hardware umziehen. Problematisch: Alte und neue Hardware waren derart verschieden, dass hier Probleme zu erwarten gewesen wären, wenn ich die Platten einfach nur umgesteckt hätte. Also habe ich vorher einen Sysprep inkl. /generalize laufen lassen. Nach dem Umbau der Festplatten in den neuen Server startete dieser Anstandslos. Das Problem: Die SQL-Server-Dienste starteten nicht!
Problem:
Durch den SYSPREP sind die privaten Schlüssel für die SSL-Kommunikation verloren gegangen, da der alte User-Account ja danach nicht mehr vorhanden war. Dies war u.a. im Logfile „C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG“ nachzulesen:
"The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d [...]"
Lösung:
Im „SQL Server Configuration Manager“ die Zuordnung zum alten Zertifikat löschen:
Nach einem Reboot des Servers generiert dieser ein neues Zertifikat und trägt dieses hier entsprechend ein (Es existieren dann 2 Zertifikate mit gleichem Namen, man kann sie aber u.a. am Ausstellungsdatum unterscheiden).
Dieses neue Zertifikat muss nun noch zu den „Vertrauenswürdigen Stammzertifizierungsstellen“ hinzugefügt werden bzw. evtl. den Clients als vertrauenswürdig bekanntgegeben werden. Danach sollte alles wieder funktionieren, im Logfile steht dann:
"A self-generaterd certificate was successfully loaded for encryption. [...]"