Alle Tools aus der Community

Ich habe in den letzten Tagen für einen Kunden ein wenig programmiert, damit dieser einen reproduzierbaren Lasttest bzw Funktionstest auf unterschiedlichen Umgebungen durchführen kann. Gleich im Gespräch hatte ich die ersten Community-Tools im Kopf, welche ich dafür benutzen wollen würde, ich fange aber einfach mal vorne an zu erzählen… der Kunde möchte eine neue SQL Server Umgebung etablieren und möchte nun erst einmal die alte Umgebung als „Baseline“ nutzen und mehrere Konfigurationen (Ausstattung, Version, Edition) dagegen testen und hat bei mir nach Unterstützung gefragt. Ich hatte hierzu gleich mehrere Gedanken wie zum Beispiel die WorkloadTools von Gianluca Sartori (b|t).

Performance Vergleiche mit WorkloadTools

Gianluca hat mit diesem Tool ein sehr großartiges Tool geschaffen, mit dem man relativ einfach und schnell die aktuelle SQL Server Workload aufzeichnen, analysieren und wieder abspielen kann. Bisher musste das mehr oder weniger umständlich über mehrere Tools gemacht werden, ein richtiger Replay ging nur mit dem Distributed Replay Feature und war nicht immer so einfach zu erstellen. WorkloadTools bietet die Möglichkeit zum Beispiel über Extended-Events alle ausgeführten SQL Statements live mitzuschneiden und speichert diese in einer eigenen Datenbank, man kann hier erst einmal die Workload aufzeichnen und später gegen die Datenbank analysieren oder direkt parallel die Analyse (Analyse = relevante Performance Daten ermitteln), dann diese Statements zum Beispiel gegen ein Test-System abspielen und dort ebenfalls analysieren. Man erhält also über die beiden Analysen mit der selben Workload auf unterschiedlichen Systemen eben unterschiedliche Performance-Werte, die man gegeneinander vergleichen kann. Auch hier hat Gianluca einen Viewer geschrieben, der diese Daten grafisch aufbereitet und man sich durch die Unterschiede wühlen kann und so die Abweichungen feststellen kann.

Im ersten Schritt benötigen wir also eine Konfiguration um das Aufzeichnen („Capturing“) der SQL Server Workload zu ermöglichen, dies erfolgt über ein JSON-File welches man dann beim Starten der SQLWorkload.exe mit angeben muss.

{
    "Controller": { 
        "Listener":
        {
            "__type": "ExtendedEventsWorkloadListener",
            "ConnectionInfo":
            {
                "ServerName": "SQL2017"
            },
            "DatabaseFilter": "AdventureWorks2014"
        },
        "Consumers":
        [
            {
                "__type": "WorkloadFileWriterConsumer",
                "OutputFile": "C:\\temp\\SqlWorkload.sqlite"
            },
            {
                "__type": "AnalysisConsumer",
                "ConnectionInfo":
                {
                    "ServerName": "AdminServer",
                    "DatabaseName": "AnalysisDatabase",
                    "SchemaName": "baseline"
                },
                "UploadIntervalSeconds": 60
            }
        ]
    }
}

Die Workload wurde in diesem Beispiel in einer lokalen SQLite Datenbank unter C:\temp gespeichert, aus dieser Datenbank kann die einzelnen Statements wieder in derselben zeitlichen Reihenfolge abrufen und gegen eine zu testende Datenbank ausführen, hierfür wird ebenfalls eine JSON-Konfigurationsdatei benötigt.

{
    "Controller": {
         "Listener":
        {
            "__type": "FileWorkloadListener",
            "Source": "C:\\temp\\SqlWorkload.sqlite",
            "SynchronizationMode": "true"
        },
         "Consumers":
        [{
            "__type": "ReplayConsumer",
            "ConnectionInfo": 
                {
                    "ServerName": "SQL2019",
                    "DatabaseName": "AdventureWorks2014"
                }
            },
            {
                "__type": "AnalysisConsumer",
                "ConnectionInfo": 
                {
                    "ServerName": "AdminServer",
                    "DatabaseName": "AnalysisDatabase",
                    "SchemaName": "benchmark2019"
                },
                "UploadIntervalSeconds": 60
            }
       ]}
}

Die aus diesen Analysen ermittelten Daten werden über die WorkloadViewer.exe dargestellt und lassen sich entsprechend runterbrechen, dass man daraus entsprechende Erkenntnisse auf Engpässe oder andere Probleme ziehen kann.

Aber für meine eigenen Tests benötigte ich auch erst einmal eine Workload-Generator und hier hatte ich bereits in der Vergangenheit für meine Demos für die Vorträge rund um die Azure SQL Database etwas zur Hand… diese konnte ich ein wenig abgewandelt und meine Zwecke hier angepasst – gemäß einem Blogbeitrag von Rob Sewell (b|t) mit weiteren Tools aus der Community – in diesem Fall hat Rob selber eine Funktion „Invoke-RandomWorkload“ für dbatools entwickelt, welche er mit dem Powershell Modul von Boe Prox (b|t) „PoshRSJob“ gegen die Sammlung von SQL-Statements für die AdventureWorks2014-Datenbank parallel laufen lässt. Also eine großartige Mischung aus vielen unterschiedlichen Komponenten und Mitspielern aus der Community, die mir hier eine Hilfe waren.

parallele Ausführung von SQL Statements mit Powershell

tbd

#Community oder #CommunityRocks – gemeinsam stark sein

tbd

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland 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.