PASSCamp 2017 – spannende Agenda in allen Tracks

Seit dem Wochenende gibt es endlich einen offiziellen Zeitplan (siehe PASS Newsletter) für das diesjährige PASSCamp in Seeheim – veranstaltet von der PASS Deutschland e.V., den ich euch hier nicht vorenthalten möchte. Das diesjährige PASSCamp steht ganz unter dem Motto „Aufgeschlaut du werden wirst!“, denn auf keiner deutschen Veranstaltung ist die Dichte der Microsoft Mitarbeiter, Microsoft MVPs und Matter Experts zum Thema Dataplatform höher als auf dem PASSCamp. Diese Jahr geht es um die „Hype“-Themen wie MSSQL Operation Studio, den neuen PowerBI Report Server oder Azure Machine Learning.

Montag 04.12.2017
Start Stop Time Session DBA DEV BI InformationServices
18:00 20:00 02:00 Kick of session Microsoft Team: Microsoft Data Platform Next Version: The Strategy Session
20:00 Dinner seeheim´s eat & meet

 

Dienstag 05.12.2017
Start Stop Time Session DBA DEV BI InformationServices
08:00 Breakfast
09:00 09:45 00:45 Get-Ready & Opening Session Housekeeping & Organisation Kick Off
09:45 10:00 Splitting into groups
10:00 12:00 02:00 Session 1 WD/AK/RS: A day with Cloud DBAs on Query Store, PowerShell and more CK: Cosmos DB & Azure Functions WS: Power BI Report Server & Premium OE/TE: – Data Quality mit AZ ML Workbench und ADLA
12:00 13:30 Lunch
13:30 14:45 01:15 Session 2 WD/AK/RS: A day with Cloud DBAs on Query Store, PowerShell and more CK: Cosmos DB & Azure Functions WS: Power BI Report Server & Premium OE/TE: – Data Quality mit AZ ML Workbench und ADLA
14:45 15:00 Break
15:00 16:15 01:15 Session 3 WD/AK: PowerShell for DBAs CS: Block Chain 2.0 VH/FG: Power BI Update 2017 SD: Machine Learning mit AZ ML Workbench
16:15 16:30 Pause & Snack im Foyer
16:30 17:30  01:00 Session 4 WD/AK: PowerShell for DBAs CS: Block Chain 2.0 VH/FG: Power BI Update 2017 SD: Machine Learning mit AZ ML Workbench
18:00 18:30 Welcome reception & Late Session Rob’s Beer & Chips & PowerShell Session
20:00 Dinner seeheim´s eat & meet

 

Mittwoch 06.12.2017
Start Stop Time Session DBA DEV BI InformationServices
08:00 Breakfast
09:00 10:15 1:15 Session 5 BP: SQL Azure DB & Managed Instance BK: IoT Development Full Day TM: R for Business Intelligence Freaks OE/TE/WS: SSIS vNext (Scaleout & Everest)
10:15 10:30 Break
10:30 12:00 1:30 Session 6 BP: SQL Azure DB & Managed Instance BK: IoT Development Full Day TM: R for Business Intelligence Freaks OE/TE/WS: SSIS vNext (Scaleout & Everest)
12:00 13:30 Lunch
13:30 14:45 01:15 Session 7 UR: Multi-Server Administration Hands On BK: IoT Development Full Day IF: Power BI „M“ Deep Dive für BI Pros SK: Azure Data Factory Version 2
14:45 15:00 Break
15:00 16:15 01:15 Session 8 UR: Multi-Server Administration Hands On BK: IoT Development Full Day IF: Power BI „M“ Deep Dive für BI Pros SK: Azure Data Factory Version 2
16:15 16:30 Pause & Snack im Foyer
16:30 17:30  1:00 Session 9 WD/AK: PowerShell for DBAs BK: IoT Development Full Day IF: Power BI „M“ Deep Dive für BI Pros OE/TE: Azure Data Catalog & Common Data
Services
18:00 18:30 Late Session PH: Hybride Dataplatform: Erfahrungen, Anekdoten, Wissenswertes
20:00 Dinner seeheim´s eat & meet

 

Donnerstag 07.12.2017
Start Stop Time Session DBA DEV BI InformationServices
08:00 Breakfast
09:00 10:15 1:15 Session 10 FG: SQL Server Linux & Docker TM: Power BI Custom Visual Development MR: Power BI und IoT BW: BIML for ADF & Performance Evaluation
10:15 10:30 Break
10:30 12:00 1:30 Session 11 FG: SQL Server Linux & Docker TM: Power BI Custom Visual Development MR: Power BI und IoT BW: BIML for ADF & Performance Evaluation
12:00 13:30 Lunch
13:30 14:45 01:15 Session 12 NN: Cosmos DB for DBAs VH/FG: Power Embedding GM: Azure Analysis Services CK/MT:Die Cognitiven & Bots Datafreaks
14:45 15:00 Pause & Snack im Foyer
15:00 16:15 01:15 Session 13 NN: Cosmos DB for DBAs VH/FG: Power Embedding GM: Azure Analysis Services CK/MT:Die Cognitiven & Bots Datafreaks
16:15 16:30 Closing Session
16:30 Ende

Damon wünscht viel Spaß auf dem PASSCAMP 2017

Speaker-Zuordnung
AK: Andre Kamman (MVP) IF: Imke Feldmann (MVP) PH: Patrick Heyde (MS) WS: Wolfgang Strasser (MVP)
BK: Ben Kettner (MS pTSP) MR: Markus Raatz (MS pTSP) RK: Ralph Kemperdick (MS)
BW: Ben Weissman MT: Marcel Tilly (MS Research) RS: Rob Sewell (MVP)
BP: Björn Peters (MVP) MV: Martin Vach (MS) TE: Tillmann Eitelberg (MVP)
CK: Constantin Klein (MVP) NN: Niko Neugebauer (MVP) TM: Tom Martens
CS: Christoph Seck (MS pTSP) OE: Oliver Engels (MVP & MS pTSP) UR: Uwe Ricken (MVP)
FG: Frank Geisler (MVP & MS pTSP) SD: Sascha Dittmann (MS) VH: Volker Hinz (MS)
GM: Gabi Münster (MVP) SK: Steffan Kirner (MS pTSP) WD: William Durkin (MVP)

Das ist der aktuelle (vorläufige) Schedule des PASSCamp 2017 und kann sich wirklich sehen lassen, sagenhafte 12 MVPs sind vertreten und können euch den „heißen Scheiß“ näher bringen.

Anmelden könnt Ihr Euch wie immer: http://www.sqlpasscamp.de/anmeldung.html

PS: Ich selber habe mich immer geärgert, warum es kurz vor dem PASSCamp noch immer keine vollständiger Speaker-Liste und/oder Themenliste gab… ich habe mal nachgefragt… weil man den „real hot shit“ vom PASS Summit Anfang November abwarten möchte, damit auch alle frischen Themen, Keynotes und Announcements tatsächlich auf dem PASSCamp abgedeckt werden !!!

In einem Blogpost aus 2016 habe ich schon einmal ein Video vom PASSCamp 2015 verlinkt, damit ihr einen ersten Eindruck bekommt was euch dort erwartet.

short reminder to me or all ;-) – cannot connect to SSAS in a Cluster

Dieser Post gilt für mich als Reminder, um zukünftig diesen Fehler schneller beheben zu können, aber vielleicht hilft es ja auch anderen 😉
Ursprünglich sollte ich heute einer vorhandenen SQL Server Cluster-Instanz das Feature Analysis Services hinzufügen, was ja bekannterweise nicht geht (zumindest nicht nachträglich). Dann habe ich mit dem OS-Kollegen spontan eine neue Cluster-Ressource angelegt und dort eine eigenständige SQL Server Analysis Services Instanz installiert. Servicepack und letzte Patches drauf und noch schnell die User berechtigen… SSMS öffnen und mit der SSAS Instanz verbinden… aber was ist das? Eine Fehlermeldung…

Reminder - Short Note - How to resolve this SSAS Login Error

Nach ewig langem googlen, bin ich auf folgende Forumsseite gestossen, die mir wirklich weitergeholfen hat…
Also habe ich den SQL-Browser-Dienst umgestellt und die Port-Number des SSAS-Dienstes, den SQL Server Analysis Service neu gestartet und erneut den Verbindungsaufbau mittels SQL Server Management Studio versucht und siehe da, die Connection kam zu stande.

Achso, es handelte sich um einen Cluster mit SQL Server 2014.

 

Azure SQL Database – Lasttest der TempDB

Auf Facebook wurde ich gefragt, wie leistungsstark denn die „TempDB“ einer Azure SQL Database wäre bzw sehr man diese belasten könne… also was liegt näher als die „TempDB“ mit einem Lasttest zu verproben. Also habe ich über die Suchmaschine meines Vertrauens eine einfache und schnelle Möglichkeit gesucht, wie man explizit die „TempDB“ belasten kann. Bei SQLServerCentral bin ich dann fündig geworden => Load Generator for TempDB

CREATE PROC EXERCISE_TEMPDB_SILLY AS
   SET STATISTICS TIME ON
   SET STATISTICS IO ON

   CREATE TABLE #temp(RecNo INT PRIMARY KEY CLUSTERED, Data varchar(80))

   INSERT INTO #temp SELECT -1, CAST(NewID() AS varchar(80))

   DECLARE @cnt AS INT
   SET @cnt = 0

   WHILE @cnt > -1
   BEGIN
      Print 'Loop ' + CAST(@cnt AS VARCHAR(9))
      
      INSERT INTO #temp 
      SELECT RecNo-Power(2,@cnt) , Right(Data + CAST(NewID() AS varchar(80)), 80)
      FROM #temp

      SET @cnt = @cnt+1
   END

Mit dieser Stored Procedure wird eine temporäre Tabelle in der „TempDB“ erstellt und diese mit einfachen Werten befüllt, damit diese Werte nich „stupide“ Hochzählen werden diese mit Rechenoperationen manipuliert. Da diese While-Schleife keinen Exist hat, läuft dieser Insert-Befehl in einer Endlos-Schleife mit dem Ziel die Grenze der TempDB zu ermitteln, da sich die Anzahl der einzufügenden Datenzeilen mit jedem Loop erhöht. Ein Kommentar in dem Forumsbeitrag deutet darauf, dass der Verprober auf seinem SQL Server 21 Loops geschafft hat, was ein erster Anhaltspunkt ist. Meine Azure VM mit SQL Server 2016 (Standard DS12 v2 (4 vCPUs, 28 GB memory)) schafft innerhalb von 2 Minuten 23 Loops…

Azure SQL Database - Lasttest

 

Lasttest-Bedingungen

Meine erste Tests zeigten, dass die Anzahl der Loops tatsächlich in einem gewissen Bereich liegen bzw eine gewisse Zeit benötigen, daraus machte ich einen einheitlichen Test von 2 Minuten… heißt das ich nach 2 Minuten Laufzeit auf den „STOP“-Knopf drücke, um somit die Ausführung der Stored Procedure zu unterbrechen bzw abzubrechen. Nachdem der SQL Server die Ausführung beendet hat, habe ich die Anzahl der durchlaufenen Loops ermittelt.

Loop 1 ergab 1 Insert
Loop 2 ergab 2 Inserts
Loop 3 ergab 3 Inserts
Loop 4 ergab 8 Inserts
[…]
Loop 10 ergab 512 Inserts
Loop 11 ergab 1024 Inserts
Loop 12 ergab 2048 Inserts
[…]
Loop 18 ergab 131072 Inserts
[…]
Loop 20 ergab 524288 Inserts
Loop 21 ergab 1048576 Inserts
Loop 22 ergab 2097152 Inserts
Loop 23 ergab 4194304 Inserts
Loop 24 ergab 8388608 Inserts

Wie man sehen kann hat die Datenbank bzw die TempDB ganz schön viel Daten zu verarbeiten, was auf deren Leistungsfähigkeit schließen lässt. Dieser Test soll erst einmal nur einen Anhaltspunkt für die Belastungsgrenzen aufzeigen… Die kleineren Leistungsklassen der Azure SQL Databases haben bei diesem Lasttest gezeigt, dass sie nach einer gewissen Anzahl Insert bzw Loops einfach am Ende sind und nicht mehr oder nur noch bedingt in der Lage sind Daten zu verarbeiten/aufzunehmen. Überrascht war ich in den höheren Leistungsklassen wie schnell die Inserts erfolgten und diese konnten sicherlich noch mehr Daten aufnehmen, hätte ich die Laufzeit des Testes erweitert (was ich sicherlich zu einem späteren Zeitpunkt nochmal machen könnte).

Lasttest-Ergebnis-Vergleich

Leistungsklasse Anzahl Loops Anzahl Inserts
Azure SQL Database S0 18 131072
Azure SQL Database S1 18 131072
Azure SQL Database S3 22 2097152
Azure SQL Database S9 25 16777216
Azure SQL Database P1 23 4194304
Azure SQL Database P6 24 8388608
Azure SQL Database P15 24 8388608
Azure SQL Database PR1 23 4194304
Azure SQL Database PR6 24 8388608
Azure SQL Server
(Standard DS12 v2 (4 vCPUs, 28 GB memory))
24 8388608
Azure SQL Server
(Standard DS15 v2 (20 vCPUs, 140 GB memory))
24 8388608

Wie man an der Ergebnis-Tabelle erkennen kann, sind die Unterschiede zwischen den höheren Leistungsklassen und den bewährten SQL Servern nicht sonderlich groß bzw gar nicht vorhanden. Was entweder heißt, man kann die Azure SQL Databases genau so stark belasten wie einen herkömmlichen SQL Server oder aber sie erreichen genauso schnell ihre Limits. Mein persönlicher Eindruck ist eher, dass die höheren Klassen bei diesem Lasttest noch mehr leisten können, wenn man ihnen mehr Zeit gibt. Anders herum würde ich sagen, dass man die Azure SQL Databases ohne zu zögern und ohne Bedenken mit einem „normalen“ SQL Server mit SSDs vergleichen kann.

Azure SQL Database - Lasttest - TOP Ergebnis

Fazit des Lasttests

Aus aktueller Sicht würde ich jedem die Nutzung von Azure SQL Databases im Vergleich zu herkömmlichen SQL Servern empfehlen, sofern die Solution und das Umfeld/der Kunde dies ermöglichen.

TSQL2sday #94 – daily database copy using Powershell – dbatools

T-SQL Tuesday #82 – To the cloud… And beyond!!!

T-SQL Tuesday is a recurring blog party, that is started by Adam Machanic (b | t). Each month a blog will host the party, and everyone that want’s to can write a blog about a specific subject.

This month Rob Sewell is our TSQL2sDay host and his subject is “Let’s get all Posh!”.

As I had written in a former post I was inspired by Andre Kamann to start using Powershell to manage our SQL Server environments, since this year I’m a major contributor of dbatools – a multifunctional Powershell module for DBAs.

I use the functions from the dbatools module day by day more and more. And I try to write about some of those tasks here in my blog like this post 😉

So one of me ServiceManager asked me to write a job which should refresh the test-environment each day – only 3 databases (out of 12). So I just wrote a Powershell-script which copies those databases from production to test environment.

First, we start with the requirements:

  • Currently approx. 280 GB
  • Backup with Copy only
  • Creation of database duplication as an automatic job
  • Every morning at 4:00

My first thoughts about that were creating a SQL Server Agent Job with following steps:

  1. check the availability of Shared-Destination-Folder
  2. delete/clear Destination-Folder-Content
  3. Shrink all Transaction-Logfiles
  4. Backup all Databases from given list
  5. Restore each Backup-File from folder
  6. Check all orphaned user
  7. delete/clear Destination-Folder-Content

A year or two ago, I had built this with a lot of normal T-SQL-Agent-Jobs, now I’m doing this with dbatools which make it very easy and fast (and in one step)

dbatools.io - Logo - Thor

I’m building such scripts in a very simple way, in order to make it easy to understand what a script is doing… so I’m not using any complex one-liner 😉
This time I need a job log and dbatools, so I started with importing those functionalities

. E:\SQL_Admin_Skripte\Function-Write-Log.ps1

$Network_Transfer_Folder = '\\DestinationShare\Backup'
$Local_Transfer_Folder = 'E:\BackupPath\'


if (-not  (Get-Module -Name dbatools)) {
    Import-Module E:\SQL_Admin_Skripte\dbatools-master\dbatools.psd1
}

Claudio Silva (b | t) helped me a little with the following „SHRINK“-command which was in a first stage a normal combination of Powershell „Invoke-Sqlcmd“ and T-SQL, now it is a dbatools-function called „Invoke-DbaDatabaseShrink“ which is a little bit tricky if you only want to shrink log files… but it works.

#Shrink TLogs
Invoke-DbaDatabaseShrink -SqlInstance Src-InstanceName -Database DB1,DB2,DB3 -LogsOnly -ShrinkMethod TruncateOnly

Now I had just to make a Backup and restore those Backups on the destination instance… no real magic 😉

#Backup named databases
Backup-DbaDatabase -SqlInstance Src-InstanceName -Databases DB1,DB2,DB3 -Type Full -FileCount 32 -CopyOnly -BackupDirectory $Network_Transfer_Folder

#Restore all databases in given folder
Restore-DbaDatabase -SqlServer Dest-InstanceName -Path $Local_Transfer_Folder -WithReplace -UseDestinationDefaultDirectories 

Last but not least… I’ll have to check for orphaned user and clean up everything…

#Repair orphaned users
Repair-SqlOrphanUser -SqlServer Dest-InstanceName

#Cleanup after Restoring
Get-ChildItem -Path $Local_Transfer_Folder -Include *.bak -File -Recurse | foreach { $_.Delete() }

Now I’m triggering the script every day with a SQL Server Agent Job what makes it even easier for me as DBA. (but be careful – dbatools run only with a PowerShell version > 3 => SQL Server 2014 if you use a PowerShell step)

The job runs ~12 minutes including importing dbatools module, Backup three databases (~280GB) and restoring them on the test server which I think is a good runtime!

 

At the end, I’m having more time to read any books, tweets or other blog posts 😉

 

My former blog post about another database copy job can be found here: Copy Database with Rename using dbatools

Special Thanks to Jason Wasser @wasserja for his great logging function!
https://gallery.technet.microsoft.com/scriptcenter/Write-Log-PowerShell-999c32d0

and to Derik Hammer for his list of PowerShell version in SQL Server and how to implement PowerShell into Agent Steps…
https://www.sqlhammer.com/running-powershell-in-a-sql-agent-job/

#4 SQL Server Konfiguration – Best Practices umsetzen

Ich habe schon lange nichts mehr für meine Powershell-Serie geschrieben und möchte dies nun nachholen, obwohl sich mittlerweile sehr viel (in meinem Arbeits- & Communityleben) diesbezüglich getan hat… Ich möchte euch heute zweierlei Dinge vorstellen, einmal wie auf herkömmliche Art und Weise mit Powershell den SQL Server konfigurieren konnte (oder ich es in meinem Skript getan habe) und zum anderen die mittlerweile einfachere und schnellere Weise mit dem Powershell Modul von dbatools.io.

Best Practices mit T-SQL

Im Rahmen der SQL Server Installation sollte man gewisse Parameter optimieren, damit einem performanten und stabilen Betrieb nichts im Wege steht. Hierzu gehören eine Vielzahl Konfigurationsparametern auf Instanzebene, wie zum Beispiel „Max. Memory“ oder „Max. Degree of Parallelism“. All diese Instanz-Einstellungen können mit der selben Funktion durchgeführt werden, also habe ich für diese wiederkehrenden T-SQL-Befehle eine eigene „Funktion“ geschrieben, um für spätere Erweiterungen flexibel bleiben zu können.

function ExecuteSQLCmd ([string]$SQLQuery) {
     Invoke-Sqlcmd -ServerInstance $ServerName -Query $SQLQuery -QueryTimeout 65535
}

Mit dieser einfachen Funktion (auch schon vorher, aber so ist es „einfacher“), kann ich die nun folgenden Funktionen entsprechend aufrufen und meinen SQL Server gemäß Best Practices konfigurieren, in dem ich die jeweilige Funktion aufrufe, Werte je nach Systemausstattung berechne um sie dann an ExecuteSQLCmd zu übergeben. Die folgenden Funktionen ermöglichen mir die Anpassungen an das jeweilige Umfeld.

SetMaxMemory
Add_TempDBFiles
SetMaxDOP
SetNetworkPacketSize
SetOptimizeAdhocWorkload
SetBackupCompression
AddLocalSystemToSysadminGroup
enable_XPAgent

Beispiel – Powershell Funktion „SetMaxDOP“

Um den Wert für MaxDOP (max Degree of Parallelism) setzen zu können, muss ich wissen wieviele logische CPU ich habe. Diesen Wert hatte ich mir zur Anfang des Skriptes über Hilfsfunktionen ermittelt, erst mit diesem Wert kann ich entscheiden… Den Threshold für MaxDOP sezte ich auf unseren Systemen in der Regel auf 40, dies passt zumindest bei 90% der Systeme. Sicherlich kann man sich hier noch viel mehr an die Best-Practices halten, wie ihr auch im nächsten Abschnitt lesen könnt, aber mit diesen Werten bin ich die letzten zwei Jahre auf unseren Systemen ganz gut gefahren.

function SetMaxDOP() {
    Try { 
        Write-Host "Setting of MaxDOP / Threshold"
        $sqlquery = "
        EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE;
        EXEC sys.sp_configure N'cost threshold for parallelism', N'40';
        "
        ExecuteSQLCmd $sqlquery

        if ($global:NoLogicalCPUs -le 4) {
            $sqlquery = "
            EXEC sys.sp_configure N'max degree of parallelism', N'0'
            RECONFIGURE WITH OVERRIDE
            "
            Write-Host "[INFO] Set Threshold to 40 and Set MaxDOP to 0."  -ForegroundColor Green
        } else {
            $sqlquery = "
            EXEC sys.sp_configure N'max degree of parallelism', N'"+($global:NoLogicalCPUs/2)+"'
            RECONFIGURE WITH OVERRIDE
            "
            Write-Host "[INFO] Set Threshold to 40 and Set MaxDOP to "($global:NoLogicalCPUs/2) -ForegroundColor Green
        }
        ExecuteSQLCmd $sqlquery
    }
    Catch {
        Write-Host "[ERROR] Failed to set MaxDOP." -ForegroundColor Red
    }
}

dbatools – die Funktion Set-DbaMaxDop

Ich hatte ja schon mehrmals über das Powershell Modul dbatools berichtet – zum Beispiel beim Erstellen einer Datenbank-Kopie – hier möchte ich euch nun den Vergleich zwischen dem herkömmlichen Weg und dem einfacheren Weg mittels dbatools vorstellen. dbatools bietet eine Funktion zum einfachen Setzen des SQL Server Instanz Parameters für Max Degree of Parallelism, auch weitere Instanz-Parameter sind entsprechende Funktionen vorhanden.

Das Kommando „Set-DbaMaxDop“ bietet eine Vielzahl von Möglichkeiten, das einfache Setzen des MaxDop auf Instanzebene (SQL Server 2008 – 2016) sowie das Setzen des MaxDop auf Datenbank-Ebene ab dem SQL Server 2016. Ohne Angabe eines weiteren Parameters ermittelt die Funktion alle Rahmenbedingungen, basierend auf dem Algorythmus aus dem Microsoft KB-Artikel KB2806535, sowie dem MaxDoP-Calculator von Sakthivel Chidambaram werden daraus die notwendigen Werte zum Setzen des MaxDoPs zu errechnet. Wobei man natürlich – wie auch bei meinen Angaben/Hinweisen – auch immer darauf hinweisen muss, dass es sich hierbei um Empfehlungen handelt die nicht zu 100% auf jede Umgebung und Applikation passen, aber einen ersten Anhaltspunkt geben.

Set-DbaMaxDop -SqlServer SQL2016

dbatools - Set-DbaMaxDop - Set to Best Practices

Möchte man nun selber einen Wert vorgeben, ist dies auch möglich… oder das verwenden der internen Test-Funktion „Test-DbaMaxDop

Test-DbaMaxDop -SqlServer SQL2016

dbatools - Test-DbaMaxDop

oder eben das selber entscheiden, welcher Wert für diese Umgebung sinnvoller ist…

Set-DbaMaxDop -SqlServer SQL2016 -MaxDop 6

dbatools - Set-DbaMaxDop - Set to your own Value

Weitere Informationen findet ihr auf folgenden Hilfe-Seiten von dbatools.io : https://dbatools.io/functions/set-dbamaxdop/ und https://dbatools.io/functions/test-dbamaxdop/

dbatools – die Funktion Set-DbaSpConfigure

Nun haben wir oben aber nicht nur den Wert für MaxDop geändert, sondern ebenso auch den Wert für den Threshold für den max Degree of Parallelism. Auch diesen Wert kann man mit den dbatools sehr einfach setzen. Da beides Instanz-Parameter sind könnte man beide Einstellungen individuell mit eigenen Werten und diesem Kommando anpassen, aber die interne Berechnung macht den Einsatz zwei unterschiedlicher Befehle sinnvoll. Um nun also den Wert für den Threshold auf 40 zu setzen, verwende ich „Set-DbaSpConfigure“, was uns ansich nicht unbekannt sein sollte.

Set-DbaSpConfigure -SqlServer SQL2016 -ConfigName CostThresholdForParallelism -Value 40

dbatools - Set-DbaSpConfigure

Gerade mit dem IntelliSense-Feature macht diese Funktion Freude, da die einzeln verfügbaren Parameter schnell einsetzbar sind und man schnell zu ganzen Befehl kommt. Weitere Hilfe und Beispiele findet ihr natürlich auch auf den Hilfe-Seiten der Funktion => https://dbatools.io/functions/set-dbaspconfigure/

So kann man nun – im Gegensatz zu meinem eigenen Skript – beide Instanz-Parameter mit nur 3 Zeilen optimieren.

Import-Module .\dbatools\dbatools.psd1

Set-DbaSpConfigure -SqlServer SQL2016 -ConfigName CostThresholdForParallelism -Value 40
Set-DbaMaxDop -SqlServer SQL2016