Speaking at SQLGrillen 2018

[German version below]

Hello #SQLFamily,

as previously announced I was selected to speak in the Newcomer Track of SQL Grillen 2018.

My first ever session on a SQL Server conference was in German and called „Mission SQL Migration – Aus Blech wird VM“ and was about migrating physical SQL Server to virtual ones.
The important parts were the VMware architecture, guest configuration and how to migrate the whole SQL Server with one single command.

About 20 people were in the room and the session went smooth. Also the demo on a remote server in our company network works like a charme. Because of some deeper discussions about the need of virtualization and the pros and cons, I was not able to show some more of the fantastic dbatools commands I’ve prepared.
So only the Start-DbaMigration was shown and the „Best Practices“ commands like Test-DbaMaxMemory, Test-DbaMaxDop, Test-DbaTempDBConfiguration (…) and the important Invoke-DbaDatabaseUpgrade for upgrading the migrated Databases to the last compatibility level were not shown.

But at the end I finished just in time and I was happy how it works.
I’ve got some direct Feedback from friends and also my mentor Björn Peters (t) who had helped me a lot preparing the session. Thanks a lot!

Hopefully I’ll be able to present on other SQL conferences in the future.

Here is the complete (german) presentation: Mission SQL Migration – Aus Blech wird VM 2018-06-20

Thanks for reading,
Volker


[German]

Hallo # SQLFamily,

Wie bereits angekündigt, wurde ich ausgewählt, im Newcomer Track von SQL Grillen 2018 zu sprechen.

Meine allererste Session auf einer SQL Server-Konferenz war auf Deutsch und hieß „Mission SQL Migration – Aus Blech wird VM“. Es ging darum, physikalsche SQL Server auf virtuelle SQL Server zu migrieren.
Die wichtigsten Teile waren die VMware-Architektur, die Guest-Konfiguration und die Migration des gesamten SQL-Servers mit einem einzigen Befehl.

Ungefähr 20 Leute waren im Raum und die Session lief glatt. Auch die Demo auf einem Remote-Server in unserem Firmennetzwerk funktionierte reibungslos. Aufgrund einiger tiefer gehender Diskussionen über die Notwendigkeit von Virtualisierung und die Vor- und Nachteile, konnte ich einige der fantastischen dbatools-Befehle, die ich vorbereitet hatte, nicht mehr zeigen.
Es wurde also leider nur die eigentliche Migration mit dem Kommando Start-DbaMigration gezeigt und die „Best Practices“ -Befehle wie Test-DbaMaxMemory, Test-DbaMaxDop, Test-DbaTempDBConfiguration (…) und das wichtige Invoke-DbaDatabaseUpgrade für das Upgrade der migrierten Datenbanken auf die letzte Kompatibilitätsstufe wurden aus Zeitmangel leider nicht mehr gezeigt.

Aber am Ende war ich gerade rechtzeitig fertig und ich war glücklich, wie es geklappt hat. Ich habe ein direktes, positives Feedback von Freunden und auch von meinem Mentor Björn Peters (t) erhalten, der mir bei der Vorbereitung der Session sehr geholfen hat. Vielen Dank nochmal dafür!

Ich hoffe auch auf zukünftigen SQL Konferenzen noch als Sprecher vortragen zu können um meine Erkenntnisse und Erfahrungen mit der SQL Community zu teilen.

Hier findet sich noch die Präsentation: Mission SQL Migration – Aus Blech wird VM 2018-06-20

Vielen Dank fürs Lesen,
Volker

Projekt SQL Server auf VMware – Zusammenfassung

Zum Abschluss meiner Artikelserie zur „Migration von physikalischen SQL Servern in eine VMware Umgebung“, kommt hier nun noch die versprochene Zusammenfassung.

Das Projekt wird als abgeschlossen betrachtet, obwohl aktuell noch ein physikalischer SQL Server „übrig“ ist zu virtualisieren. Das hängt zum einen damit zusammen, dass der Server noch bis Ende 2019 im Hardware Support ist, andererseits aber auch mit der noch unklaren Backup Strategie der virtuellen Maschinen.

Dazu muss ich noch ein wenig weiter ausholen. Derzeit werden die SQL Datenbanken mit Standard Backup Methoden (nativ oder mit Redgate SQLBackup) gesichert (Voll- und Log-Sicherungen) auf einen zentralen Server von dem aus dann täglich Sicherungen in unsere Backup Lösung Quest Rapid Recovery (vormals Dell AppAssure) übertragen werden.
Zusätzlich werden die Produktiv Datenbanken per LogShipping alle 15 Minuten auf separate SQL Server gesichert als Disaster Recovery Lösung.

Ein Wiederanlauf einer Datenbank auf dem LogShipping Server dauert geschätzte 30-60 Minuten wenn die richtigen Ressourcen da sind. Dafür sind die folgenden Aktionen notwendig:

  1. Zugriff auf alte Datenbanken sperren – falls nicht durch Ausfall des alten Servers so und so geschehen.
  2. entsprechende Datenbank auf dem LogShipping Server aktivieren, d.h. aus dem Recovery Status rausholen, nachdem das letzte Log angewendet wurde.
  3. Konfigurationsdateien editieren bzw. entsprechenden CNAME im DNS Server auf den LogShipping Server ändern.
  4. Danach kann die Anwendung wieder neu gestartet werden.

Soweit so gut für die Datenbanken. 😉

Allerdings ist die VM damit noch nicht gesichert, d.h. bei einem Fehler in der VM zum Beispiel durch Updates usw. gibt es kein Backup der kompletten VM. Durch das fehlende zweite SAN (siehe dazu den ersten Artikel meiner Blog Serie) ist eine Replikation der VMs, und damit eine Sicherung derzeit auf diesem Weg nicht möglich. Ich teste aktuell zwei unterschiedliche VM Backup Programme von Veeam und Vembu um die VMs doch irgendwie sichern zu können, bisher aber funktioniert das noch nicht vollautomatisch.

Da die VMs über eine Vorlage erstellt werden können, dauert die Erstellung zwar nicht so lange wie die Neuerstellung aus einem ISO, eine Komplett-Neueinrichtung mit sämtlichen Konfigurationen (RAM, CPU, Agenten-Jobs, Linked Server, Benutzern usw.) dauert aber dann doch ein wenig länger als eine Rücksicherung einer VM.
Bei einer Migration ist der Quellserver vorhanden um schnell die Konfiguration zu übertragen (mittels dbatools), das geht bei einer defekten VM dann im Zweifelsfall nicht mehr.

Hier sehen wir noch Verbesserungs-Potenzial. Entweder eine regelmäßige Sicherung der VMs oder die Replikation auf ein zweites SAN.

Das ist im Grunde die Erklärung warum wir das Projekt als abgeschlossen betrachtet haben, obwohl noch nicht alle Server virtualisiert sind. Ein weiteres VMware Projekt ist für 2019 geplant, dort werden die Überlegungen mit einfließen.

Zu der Zusammenfassung gehört aber auch der Vergleich vorher/nachher. Dieser beinhaltet auch die Beobachtung ob die drei Hardware Server (ESX Hosts) die Last der ehemals eigenständigen physikalischen SQL Server übernehmen können.
Wir haben dabei die Anzahl der physikalischen Cores reduziert von gesamt 116 auf nun 72 in der VMware Umgebung. Der übrig gebliebene physikalische Server ist schon in der VMware Umgebung vorgesehen, aber noch nicht mit der endgültigen Core Anzahl versehen.

Wie wir feststellen konnten, ist die VMware Umgebung in der Lage alle physikalischen Server abzubilden. Aktuell sind die Ressourcen in den VMs noch nicht reserviert und damit fest zugeordnet. Das wird spätestens mit den restlichen VMs dann notwendig werden.

Hier endet nun die Artikelserie.

Vielen Danks fürs Lesen,
Volker

Das sind die Links zu den anderen Teilen der Artikelserie:

Teil 1: Einführung oder das “Warum?”
Teil 2: Konfiguration VMware Umgebung
T
eil 3: VMware Guest Konfiguration
Teil 4: Migration of SQL Server with PowerShell dbatools

Migration SSRS 2008R2 -> 2016 – Renderformat für Excel hat sich geändert

Migration SSRS 2008R2 -> 2016 – Renderformat für Excel hat sich geändert

Bei der Migration unseres SQL Server Reporting Servers von 2008 R2 auf 2016 ergab sich gerade die Schwierigkeit, dass die zu versenden Excel Dateianhänge nicht erstellt werden können.
Die Reports und die Abos bleiben grundsätzlich erhalten wenn die Datenbanken ReportServer und ReportServerTempDB einfach mit umgezogen werden. Die Jobs werden nach Aktivierung des alten Berichtsserver-Schlüssels automatisch wieder erstellt.

Hintergrund der Fehlermeldung zu Excel ist dann das Renderformat. Das stand bei 2008R2 noch auf Excel 2003. Das Format gibt es nun aber nicht mehr.
Das bedeutet es muss in allen Reportabos das Format des Dateianhangs umgestellt werden.

Entweder manuell für jeden Report einzeln oder für alle Reports gleichzeitig per Skript.
Die Basis des Skripts ist für die Änderung von Email Adressen der Empfängern innerhalb der Reports (Quelle s.u.).
Ich habe das für mich angepasst so dass nun das Renderformat geändert werden kann.
Es muss dann anstatt EXCEL einfach EXCELOPENXML heißen:

DECLARE  @OldParameter      VARCHAR(100) = '<Value>EXCEL</Value>'
DECLARE  @NewParameter    VARCHAR(100) ='<Value>EXCELOPENXML</Value>'

BEGIN TRANSACTION
      UPDATE Subscriptions
            SET ExtensionSettings = CONVERT(NTEXT,REPLACE(CONVERT(VARCHAR(MAX),ExtensionSettings),@OldParameter,@NewParameter))
        FROM ReportServer.dbo.Subscriptions
        WHERE CONVERT(VARCHAR(MAX),ExtensionSettings) LIKE '%' + CONVERT(VARCHAR(100),@OldParameter) + '%'
COMMIT TRANSACTION

So hat es bei uns geklappt.

Danke fürs Lesen,
Volker

Quelle: http://www.sqlservercentral.com/blogs/briankmcdonald/2010/07/19/updating-email-addresses-in-ssrs-subscriptions/