Aha-Effekt beim Setzen von SQL Instanz Parametern mit dbatools

In der letzten Woche habe ich bei einem Kunden mehrere SQL Server installiert und musste diese alle identisch installieren und konfigurieren. Was liegt hier näher als dies mit einem Powershell Skript zu machen, daher habe ich mir die „Mühe“ gemacht und die einzelnen Schritte der SQL Server Konfiguration mit dbatools zu realisieren. Ich möchte in diesem Beitrag nicht auf alle Schritte der Konfiguration eingehen, sondern nur einen Teil davon zeigen, der mir einen gewissen „Aha-Effekt“ brachte.

Im Rahmen der SQL Server Konfiguration sollten die Default-Werte von „MaxDop“ und „Cost Threshold for Parallelism“ angepasst werden. Das Setzen von MaxDoP mittels Powershell bzw dbatools ist relativ einfach da es hierfür einen eigenen Befehl gibt, aber auf für den „Cost Threshold for Parallelism“ hat dbatools einen „Workaround“, hier gibt es leider (noch) keinen direkten Befehl für.

Set-DbaMaxDop -SqlInstance sql2008, sql2012

Diese Befehlszeile legt den Wert von „Max DOP“ (Maximal Degree of Parallelism) auf den empfohlenen Wert für die SQL Server Instanzen „SQL2008“ und „SQL2012“ fest. Immer in Verbindung mit diesem Konfigurations-Parameter steht immer der „Cost Threshold“, welcher per Default immer noch auf 5 steht.

Alle SQL Server Instanzen auf einmal…

Um alle SQL Server Instanzen relativ schnell und einfach zu konfigurieren, habe ich mir das Kommando „Get-DbaRegisteredServer“ (als Alias von Get-DbaRegServer) vorgenommen. Als Vorbereitung hierfür habe ich auf allen Servern im SQL Server Management Studio die notwendigen Server (hier 2 Server mit je 3 Instanzen) als „Registered Server“ angelegt und konnte dann mit Powershell aka dbatools darauf zugreifen.

Laut dbatools-Dokumentation, ruft dieser Befehl eine Liste der SQL Server-Objekte ab, die in lokal registrierten Gruppen sowohl im Azure Data Studio als auch auf dem zentralen Verwaltungsserver gespeichert sind.

Mit diesem Befehl und der Möglichkeit die Objekte aus dem Ergebnis-Objekt als Pipeline weiterzugeben, kann man schöne Dinge machen, wie eben den Wert für „MaxDoP“ auf allen Server bzw Instanzen in einer Kommandozeile zu konfigurieren…

Get-DbaRegisteredServer | Set-DbaMaxDop

Nun aber zu meinem Aha-Effekt mit einer weiteren Kommandozeile 😉

Cost Threshold For Parallelism

Wie oben schon angedeutet, geht die Anpassung nur über eine Work-around mit dbatools und nicht mit einem dbatools-Kommando, hierzu verwende ich jetzt „Set-DbaSpConfigure“. Natürlich könnte ich auch den „MaxDoP“ mit diesem Kommando konfigurieren, dann muss ich aber selber für die vorherige Ermittlung und Berechnung des jeweiligen Wertes für MaxDoP sorgen, also die vorhandenen Kerne ermitteln, diese dann gegen die Best-Practise matchen und den Wert über eine Variable an den Set-Befehl weitergeben. Ich setze diesen Werte in 98% aller Instanzen auf 40 (ausser der Kunde oder die Applikation möchten etwas anderes), daher benötige ich hier keine Logik.

Meiner obigen Logik bzw der Dokumentation folgend habe ich es mit folgender Kommandozeile versucht:

Get-DbaRegisteredServer | Set-DbaSpConfigure -Name 'CostThresholdForParallelism' -Value 40

Dies brachte mich aber zu einem (auf den ersten Blick) nicht nachvollziehbaren Fehler (auch mein Versuch den Wert als String zu übergeben war nicht erfolgreich):

WARNING: [13:02:23][Set-DbaSpConfigure] Value out of range for Server1\Instanz1 ( <-> )
WARNING: [13:02:23][Set-DbaSpConfigure] Value out of range for Server2\Instanz1 ( <-> )
WARNING: [13:02:23][Set-DbaSpConfigure] Value out of range for Server1\Instanz2 ( <-> )
WARNING: [13:02:23][Set-DbaSpConfigure] Value out of range for Server2\Instanz2 ( <-> )
WARNING: [13:02:23][Set-DbaSpConfigure] Value out of range for Server1\Instanz3 ( <-> )
WARNING: [13:02:23][Set-DbaSpConfigure] Value out of range for Server2\Instanz3 ( <-> )

Ich habe den Grund hierfür leider noch nicht wirklich gefunden, vielleicht kann mir jemand das Phänomen näher bringen… vielleicht ist dies ja aber auch so gewollt oder ggfs sogar ein „Bug“…

Aber ich war vorher schon so erfolgreich mit dem Pipelining, dass ich das auch hier angewendet habe… also Ermitteln wir erst alle SQL-Instanzen, ermitteln dann auf diesen Instanzen den aktuellen Parameter für den „Cost Threshold For Parallelism“ und setzen ihn dann auf den neuen Wert 40.

Get-DbaRegisteredServer | Get-DbaSpConfigure -Name 'CostThresholdForParallelism' | Set-DbaSpConfigure -Value 40

ComputerName  : Server1
InstanceName  : Instanz1
SqlInstance   : Server1\Instanz1
ConfigName    : CostThresholdForParallelism
PreviousValue : 5
NewValue      : 40

ComputerName  : Server2
InstanceName  : Instanz1
SqlInstance   : Server2\Instanz1
ConfigName    : CostThresholdForParallelism
PreviousValue : 5
NewValue      : 40

ComputerName  : Server1
InstanceName  : Instanz2
SqlInstance   : Server1\Instanz2
ConfigName    : CostThresholdForParallelism
PreviousValue : 5
NewValue      : 40

ComputerName  : Server2
InstanceName  : Instanz2
SqlInstance   : Server2\Instanz2
ConfigName    : CostThresholdForParallelism
PreviousValue : 5
NewValue      : 40

ComputerName  : Server1
InstanceName  : Instanz3
SqlInstance   : Server1\Instanz3
ConfigName    : CostThresholdForParallelism
PreviousValue : 5
NewValue      : 40

ComputerName  : Server2
InstanceName  : Instanz3
SqlInstance   : Server2\Instanz3
ConfigName    : CostThresholdForParallelism
PreviousValue : 5
NewValue      : 40

Und schon habe ich wieder etwas großartiges für mich selber herausgefunden und bin um eine Erfahrung im Umgang mit dbatools reicher!

Ich liebe dieses Powershell-Modul, mit dem ich zahlreiche (nahezu alles!) Dinge am und um den SQL Server herum anpassen, optimieren und automatisieren kann. Ich verwende es sehr gerne (wie man auch meinen anderen Blog-Posts sehen kann) und mittlerweile bei allen meinen Kunden. VIELEN DANK an @Chrissy und die vielen anderen Contributors, die sich die Mühe rund um dieses Community-Tool zu machen!

Beitragsbild – von Ben White auf Unsplash

Björn Peters

Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.