Mit der aktuellen Version vom SQL Server bietet Microsoft eine neue Funktion an, mit der Sie die Möglichkeit haben, Veränderungen in der Performance von einzelnen Statements nachzuvollziehen. Wir werfen einen Blick auf die Details, die Granularität der Daten, Einschränkungen und Anwendungsfälle.
Wer kennt nicht folgende Situationen: Von jetzt auf gleich wird eine Anwendung oder Webseite langsamer, nach dem Upgrade auf SQL Server 2016 ist der Server langsamer geworden oder man möchte eine Anwendung tunen, weiß aber nicht wo man anfangen soll. Wie finde ich die Abfragen, die sich schlecht sind oder sich verschlechtert haben und den Grund dafür?
Vor SQL Server 2016 gab es die Möglichkeit, einen entsprechend konfigurierten Trace mit dem SQL Profiler zu starten, Extended Events zu nutzen oder DMVs z.B. sys.dm_exec_query_stats, sys.dm_exec_cached_plans, die aber meist nur Real-Time Daten oder aggregierte Daten seit dem letzten Restart liefern. Zumal dies meist nur reaktiv möglich ist, also nachdem sich eine Verschlechterung der Performance bereits bemerkbar gemacht hat.
Mit dem Query Store hat man nun aber die Möglichkeit, SQL Statements samt Ausführungsplan und Laufzeitstatistik automatisch zu sammeln und zu speichern. Die gesammelten Daten bleiben auch nach einem Neustart erhalten und können über verschiedene Zeitintervalle ausgewertet werden. Zudem kann bei einer Verschlechterung des Zugriffsplans mittels Plan Forcing der beste verwendete Plan ausgewählt werden. Der Query Store steht in allen SQL Server-Editionen zur Verfügung und wird pro Datenbank aktiviert.
Die wesentlichen Unterschiede zu den Abfrage-Statistiken bei den DMVs ist die Verfügbarkeit der Daten auf Statement-Ebene, der Statement-Text ist leicht zugänglich, die Messdaten bleiben dauerhaft erhalten und es können Zeitintervalle ausgewertet werden. Zudem werden auch In-Memory-Abfragen abgedeckt.
Die Query Store-Funktion kann einfach im SQL Server Management Studio für eine Datenbank aktiviert und konfiguriert werden. Alternativ auch mittels T-SQL. Als die wichtigsten Parameter sind der Operation Mode und der Query Capture Mode anzusehen. Mit dem Operation Mode legt man fest, ob Daten gesammelt (Read/Write) oder nur die Sammlung abgeschaltet und nur die Auswertung möglich ist (Read Only). Der Query Capture Mode legt fest, ob alle Statements (All) oder nur laufzeit-, ressourcen- intensive und häufig abgesetzte Abfrage gesammelt werden sollen. Hier entscheidet der Query Store selbst, welche Statements er speichert. Diese Einstellung ist sicher nichts für Komplettisten, die alle Statements analysieren möchten, jedoch für den Einstieg und eine gröbere Analyse bestens geeignet.
Ist der Query Store aktiviert, kann man nun die Performance-Messwerte einer Abfrage mit einem bestimmten Ausführungsplan, die Historie der Ausführungspläne mitsamt aller Änderungen analysieren oder für eine Abfrage einen bestimmten in der Vergangenheit benutzten Ausführungsplan zum Ausführen festlegen. Das SSMS bietet dazu Out-of-the-Box vier sehr nützliche Ansichten:
- Verschlechterte Ausführungspläne
- Genereller Ressourcenverbrauch innerhalb eines bestimmten Zeitintervalls
- Top-Abfragen bzgl. Laufzeit und Ressourcenverbrauch
- Performance-Verlauf einer bestimmten Abfrage
Das Schema des Query Stores ist ausführlich dokumentiert. Im Internet finden sich zahlreiche Query Store-Abfragen für die unterschiedlichsten Fragestellungen, aber auch eigene Abfragen und Auswertungen z.B. mit Power BI sind schnell erstellt.
Die Vorteile vom Query Store sind neben der einfachen Aktivierung, Konfiguration und Bedienung, die Möglichkeit, diese Funktion pro Datenbank zu aktivieren, so daß man den Workload speziell von Performance Problemen geplagten Datenbanken analysieren und gezielte Tuning-Maßnahmen ergreifen kann.
Allerdings hat der Query Store auch noch ein paar Einschränkungen. Für die Master- und TempDB ist er nicht verfügbar. Was auf den ersten Blick verschmerzbar erscheint, wird bei Abfragen, die keinen expliziten Use-Befehl haben, zum Problem, da der Query Store nur die Abfragen abfängt, deren Sessions sich explizit mit Use an diese Datenbank verbinden. Auch Abfragen aus der tempdb auf andere Datenbanken werden nicht erfasst. Auch ist die Konfiguration mit manuellem Aufwand verbunden, die Möglichkeit einer Instanz-weiten Standardkonfiguration ist nicht gegeben. Auch den Speicherplatzverbrauch des Query Stores sollte man im Auge behalten. Die Daten werden in der Primary Filegroup der jeweiligen Datenbank abgelegt, was nicht zu ändern ist. Daher sollte man ein Gleichgewicht von Speicherverbrauch und sinnvollem Umfang an historischen Daten finden. Auch werden keine Kontextinformationen zur Abfrage gespeichert, z.B. Wer führte die Query aus? Welches Programm/Server oder Stored Procedure? Durch die Fokussierung auf das SQL Statement steht das Performance Tuning klar im Vordergrund.
Trotz dieser Einschränkungen ist der Query Store ist ein schönes Tool für das Performance Tuning beim SQL Server, man kann mit seiner Hilfe schnell und einfach Verschlechterungen von Ausführungsplan erkennen und beheben und er eignet sich sehr gut zur Workload-Analyse.
