SQL Server Performance Baseline Reports – für lau

Hallo zusammen,

falls Ihr noch nicht darüber gestolpert seid, das MSSQL Tiger Team hat auf GitHub unter der TigerToolBox ein Projekt namens SQL-Performance-Baseline liegen, auf dass man ohne Probleme zugreifen kann.

Das Projekt besteht aus einigen wenigen Skriptdateien für die zu überwachenden SQL Server und einem SSRS Projekt und hilft Euch Eure SQL Server zu überwachen.

Warum Performance Baselining wichtig ist und wie die Lösung funktioniert wird in folgendem Artikel beschrieben:

https://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining-reports-unleashed-for-enterprise-monitoring/

Die Schritte zur Implementierung sind aber wirklich einfach:

1. Bei GitHub die TigerToolBox herunterladen,

Zip File entpacken und dann nach dem Ordner SQL-Performance-Baseline Ausschau halten.

2. Die Scripte CREATEDATABASE.sql, CREATEOBJECTS.sql und CREATECollectionJob.sql auf den zu überwachenden SQL Servern ausführen.

Die Dateinamen sind selbstsprechend. Wir legen eine Datenbank namens dba_local in der zu überwachenden Instanz an, erstellen in dieser DB die notwendigen Tabellen und Prozeduren um danach 3 SQL Server Agent Jobs zu haben, welche für uns die Performancedaten sammeln.

Ich habe heute Abend dies mal eben auf die Schnelle eingerichtet. Hat keine 2 Minuten gedauert. Natürlich sollte man vor dem Einsatz in Produktivumgebungen ruhig noch mal einen Blick riskieren.

Am Ende schaut das Ergebnis jedenfalls so oder so ähnlich aus:

Damit der Job Load SystemHealthSession einwandfrei funktioniert muss noch das Skript CreateSystemhealthDBAndSchema.sql ausgeführt werden. Dies hat das Tiger Team sowohl auf der GitHub Seite als auch im Blogartikel vergessen oder ich hab es überlesen.

Weiterer Wermutstropfen: der Job DBA – PerfMon Counter Collection verwendet die cmdshell. Da im Normalfall diese immer abgedreht sein sollte, wird Euch der Job natürlich auf die Nase fallen. Ich habe mir einfach damit geholfen, dass die xp_cmdshell nur zur Laufzeit aktiviert und danach wieder deaktiviert wird. Wahrscheinlich gibt es auch noch eine elegantere und sichere Lösung, aber da muss ich noch ein wenig recherchieren und ausprobieren.

3. Die Report.zip entpacken und die Solution Datei des SSRS Projektes öffnen (SQL Server Data Tools sollten verständlicherweise installiert sein).

Dann schnell die Projekteigenschaften installieren und Eure Reporting Services Instanz Eurer Wahl auswählen und das Projekt bereitstellen.

 

Auch dies ist eine Sache von wenigen Minuten und schon habt Ihr Zugriff auf die Reports:

Eine Sache ist jedoch wichtig: Die Reports sind alle so gestrickt, dass diese mit integrierter Authentifizierung arbeiten.  Wenn Ihr also von Eurem Client PC aus auf die Reporting Services zugreift und dann auf die dba_local eines SQL Servers, dann ergibt sich daraus ein Double-Hop. Ergo müssen Eure involvierten Systeme alle sauber für Kerberos konfiguriert sein. Die Themen mit gescheiten SPNs, trust for delegation usw. würde hier jedoch jetzt den Rahmen sprengen.

Alternativ müsst Ihr die Reports entsprechend anpacken, dass Ihr entweder nach Euren Credentials gefragt werdet oder Ihr hinterlegt einen Servicebenutzer, den ich für das Reporting verwenden wollt.

Und zum Schluss noch folgender Tipp: euer Browser sollte die US englische Lokalisierung haben.  Andernfalls bekommt man mitunter solche Fehlermeldungen:

Da ich jetzt nicht der SSRS Spezi bin, habe ich hier noch keine Lösung gefunden, sondern nur den gerade erwähnten Workaround.