Erkunden der SQL Server 2016-Abfragespeicher-GUI

Einführung

Der Abfragespeicher ist ein neues Feature, das in SQL Server 2016 eingeführt wurde und es Datenbankadministratoren ermöglicht, Abfragen und die zugehörigen Pläne mithilfe der in SQL Server Management Studio verfügbaren GUI historisch zu überprüfen und die Abfrageleistung mithilfe bestimmter dynamischer Verwaltungsansichten zu analysieren. Der Abfragespeicher ist eine datenbankweite Konfigurationsoption und kann verwendet werden, wenn der Kompatibilitätsgrad der betreffenden Datenbank 130 beträgt.

Query Store ähnelt solchen Technologien in der Oracle-Datenbankplattform wie Automatic Workload Repository (AWR). Der AWR erfasst Leistungsstatistiken in noch größerem Umfang als der Abfragespeicher und ermöglicht es einem Datenbankadministrator, die Leistung historisch zu analysieren. Konzepte wie eine Aufbewahrungsfrist und Speichergrenzen für gesammelte Daten sind in der AWR-Architektur ebenso verfügbar wie im Abfragespeicher. Die folgenden Schlüsselkonfigurationsoptionen sind verfügbar, wenn der Abfragespeicher aktiviert wird:

• Betriebsmodus: Legt fest, ob der Abfragespeicher neu erfasste Daten akzeptiert (ReadWrite-Modus) oder nur alte Daten speichert, die für Berichte verfügbar sind (Read-Only-Modus)
• Datenlöschintervall: Legt fest, wie oft die Speicherpuffer des Abfragespeichers auf eine Festplatte geleert werden. Denken Sie daran, dass die Daten des Abfragespeichers in der Datenbank gespeichert werden, in der der Abfragespeicher aktiviert ist. Der Standardwert ist 15 Minuten.
• Statistikerfassungsintervall: Legt fest, wie oft Statistiken zur Laufzeit des Abfragespeichers erfasst werden.
• Maximale Größe: Legt fest, wie stark das Repository für Abfragespeicherstatistiken wachsen kann. Standardmäßig sind es 100 MB.
• Abfragespeicher-Erfassungsmodus: Bestimmt die Granularität von Abfrageerfassungen. ALL, AUTO und NONE sind die verfügbaren Optionen. Der Standardwert ist AUTO.
• Größenbasierter Bereinigungsmodus: Legt fest, ob der Abfragespeicher alte Daten löscht, wenn die maximale Größe erreicht ist.
• Schwellenwert für veraltete Abfragen: Legt die Anzahl der Tage fest, für die der Abfragespeicher Daten aufbewahrt. Der Standardwert ist auf dreißig Tage eingestellt.

Abb. 2 Abfragespeicheroptionen

Der Abfragespeicher ist ein datenbankbezogenes Feature, das entweder über die GUI (SQL Server Management Studio) oder durch Ausführen des folgenden Befehls aktiviert werden kann:

ALTER DATABASE [WideWorldImporters] SET QUERY_STORE =ON;

Die vom Abfragespeicher gesammelte Abfragetelemetrie wird in Systemtabellen innerhalb der Datenbank gespeichert, in der der Abfragespeicher aktiviert wurde.

Beispielabfragen und Standardberichte

Bisher ist alles, was ich geschrieben habe, aus vielen anderen Quellen erhältlich; Einige davon finden Sie im Abschnitt Referenzen.

In diesem Abschnitt werden wir anhand einfacher Beispiele einen etwas tieferen Blick darauf werfen, was wir mit Query Store tatsächlich tun können, nachdem wir es aktiviert haben. Betrachten wir die folgenden zwei Abfragen:

Listing 1:Abrufen von Datensätzen mit einem bestimmten Filter

use WideWorldImportersgoselecta.ContactPersonID,a.OrderDate,a.DeliveryMethodID,a.Comments,b.OrderedOutersfromPurchasing.PurchaseOrders ainner join Purchasing.PurchaseOrderLines bon a.PurchaseOrderID=b.PurchaseOrderIDwhere a.SupplierReference='ML0300202';go 1000 

 Listing 2:Abrufen von Datensätzen mithilfe eines Bereichs 
 
use WideWorldImportersgoselecta.ContactPersonID,a.OrderDate,a.DeliveryMethodID,a.Comments,b.OrderedOutersfromPurchasing.PurchaseOrders ainner join Purchasing.PurchaseOrderLines bon a.PurchaseOrderID=b.PurchaseOrderIDwhere a.SupplierReference like 'ML%';go 1500
 

 Achten Sie auf die alternative Version dieser in Großbuchstaben geschriebenen Abfragen:
 

 Listing 1:Abrufen von Datensätzen mit einem bestimmten Filter (Großbuchstaben) 
 
USE WIDEWORLDIMPORTERSGOSELECTA.CONTACTPERSONID,A.ORDERDATE,A.DELIVERYMETHODID,A.COMMENTS,B.ORDEREDOUTERSFROMPURCHASING.PURCHASEORDERS AINNER JOIN PURCHASING.PURCHASEORDERLINES BON A.PURCHASEORDERID=B.PURCHASEORDERIDWHERE A.SUPPLIERREFERENCE='ML0300202';GO 500 

 Listing 2:Abrufen von Datensätzen mit einem Bereich (Großbuchstaben) 
 
VERWENDEN SIE WIDEWORLDIMPORTERSGOSELECTA.KONTAKTPERSONEN-ID,A.BESTELLDATUM,A.LIEFERMETHODEN-ID,A.KOMMENTARE,B.BESTELLTEOUTERSFROMPURCHASING.PURCHASEORDERS AINNER JOIN PURCHASING.PURCHASEORDERLINES BON A.PURCHASEORDERID=B.PURCHASEORDERIDWHERE A.SUPPLIERREFERENCE WIE 'ML%';GO 250
 

 Wie Sie sehen können, haben wir diese Abfragen mehrmals mit dem Schlüsselwort GO ausgeführt. Daher haben wir eine angemessene Datenmenge, mit der wir arbeiten können. Das erste, was wir bei der Verwendung des Abfragespeichers zur Analyse der Leistung beachten sollten, ist, dass sechs Standardberichte in den Abfragespeicher von SQL Server 2016 integriert sind, wie in Abb. 3 gezeigt.
  

 Abb. 3 Abfragespeicherberichte
 

 Die Namen der Berichte sind in den vorherigen Artikeln sowie in der Microsoft-Dokumentation ausführlich beschrieben. Die von diesen Berichten bereitgestellten Daten werden aus den unten aufgeführten wichtigen dynamischen Verwaltungsansichten abgerufen:
 

 Planstatistiken DMVs 
 
 
sys.query_store_query_text – enthält eindeutige Abfragetexte, die gegen die Datenbank ausgeführt werden
 
sys.query_store_plan – enthält einen ungefähren Plan für die Abfrage mit der Kompilierzeitstatistik
 
sys.query_context_settings – enthält einige einzigartige Kombinationen des Plans, die sich auf die Einstellungen auswirken, unter denen Abfragen ausgeführt werden
 
sys.query_store_query – Abfrageeinträge, die im Abfragespeicher separat verfolgt und erzwungen werden
 
 

 Laufzeitstatistiken DMVs 
 
 
sys.query_store_runtime_stats_interval – Query Store unterteilt die Zeit in automatisch generierte Zeitfenster (Intervalle) und speichert aggregierte Statistiken zu diesem Intervall für jeden ausgeführten Plan
 
sys.query_store_runtime_stats – enthält aggregierte Laufzeitstatistiken für ausgeführte Pläne
 
 

 Weitere Details zur Verwendung dieser DMVs finden Sie in der referenzierten Microsoft-Dokumentation. In diesem Artikel werden wir hauptsächlich die GUI verwenden.
 

 Wie Sie in Abb. 4 sehen können, sehen wir uns den Bericht zum Gesamtressourcenverbrauch an, während wir uns im nächsten Abschnitt auf die zuvor aufgelisteten Abfragen und die Daten beschränken, die wir aus diesen einfachen Abfragen abrufen können.
  

 Abb. 4 Bericht zum Gesamtressourcenverbrauch
 
Anfragen mit der GUI analysieren
 

 Einige wichtige Dinge sollten bei der Verwendung der Abfragespeicherberichte als hilfreich betrachtet werden:
 
 
Sie können die Umgebung konfigurieren, indem Sie auf die in Abb. 4 hervorgehobene Schaltfläche klicken. Abb. 5 zeigt uns die Details, die wir an unseren Anwendungsfall anpassen können:Kriterien der zurückzugebenden Daten, Datumsbereich und zurückzugebender Datensatz. Wenn ich beispielsweise die mit den von mir überprüften Abfragen verknüpfte Abfrage-ID deutlich sehen möchte, möchte ich beispielsweise meinen Datensatz von den standardmäßigen Top 25 auf Top 10 reduzieren.  

 Abb. 5 Konfigurationsoptionen für Berichte
  

 Abb. 6 Die 25 häufigsten Suchanfragen, die am 1. Mai 2018 ausgeführt wurden
  

 Abb. 7 Die 10 häufigsten Suchanfragen, die am 1. Mai 2018 ausgeführt wurden
 

 
 
Die Balkendiagramme zeigen Daten hauptsächlich mit der Zeit auf der x-Achse an, aber Sie können einen Drilldown zu einem bestimmten Datenpunkt durchführen, um Daten basierend auf Abfrage-IDs anzuzeigen. Jede Abfrage-ID bestimmt eine bestimmte Abfrage. Es ist wichtig zu beachten, dass eine Abfrage eindeutig identifiziert wird, indem der Text gehasht wird. Somit unterscheidet sich eine Abfrage in Kleinbuchstaben von der gleichen Abfrage in Großbuchstaben. Dies sollte allgemein bekannt sein:Ad-hoc-Abfragen sind ein Problem für den Plan-Cache und sie sind auch schlecht für den Abfragespeicher, sowohl in Bezug auf die Speicherplatznutzung als auch auf die ordnungsgemäße Analyse.  

 Abb. 8 Abfrage in Listing 1 (Kleinschreibung, Abfrage 42480)
 

  

 Abb. 9 Abfrage in Listing 3 (Großbuchstaben, Abfrage 42490)
 
 
Die dritte wichtige Beobachtung ist die Tatsache, dass, wenn ein Datenpunkt grün markiert ist, der detaillierte Ausführungsplan, der im unteren Bereich angezeigt wird, sich auf diesen Datenpunkt bezieht. In Abb. 7 bezieht sich dieser Datenpunkt auf die Abfrage-ID 42481, die wir zuvor ausgeführt haben (vollständige Abfrage in Listing 2). Wenn Sie mit der Maus über diesen Datenpunkt fahren, werden die Abfrage, ihre ID und die Anzahl der mit dieser Abfrage verknüpften Pläne angezeigt (siehe Abb. 8).  

 Abb. 10 Abfrage 42481 Details
 

 Unsere Abfrage wurde 1391 Mal ausgeführt, da sie vom Abfragespeicher genau erfasst und auf der Y-Achse (Ausführungsanzahl) des Balkendiagramms in Abb. 10 angezeigt wird. Der Bericht wurde abgerufen, während der Stapel noch ausgeführt wurde. Daher haben wir nicht die vollständige Zählung (1500), die uns darüber informiert, dass bei jeder Ausführung einer Abfrage Daten in Echtzeit erfasst werden. Auf der rechten Seite sehen wir auch den Plan, der für diese mehrfachen Hinrichtungen verwendet wurde (Plan 675). Wir können dies mit der Abfrage in Listing 5 überprüfen.
 
 

 Auflistung 5 
 
WideWorldImportersVERWENDENGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FROM sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_idJOIN sys.query_store_query_text AS Txt ON Qry.query_text_id =Txt .query_text_idwhere Qry.query_id=42481;
  

 Abb. 11 Abfrage-ID und Plan-ID von DMVs
 
Ein bisschen Tuning
 

 Sehen wir uns eine andere Abfrage an.
 

 Wenn wir die Abfrage in Listing 6 ausführen und die Details aus dem Abfragespeicher untersuchen, zeigen die Details des Ausführungsplans, dass wir einen Index benötigen, um eine Verbesserung von 51 % zu erreichen.
 

 Listing 6:Suboptimale Abfrage 
 
SELECT TOP (1000) [OrderLineID] ,[OrderID] ,[StockItemID] ,[Description] ,[PackageTypeID] ,[Quantity] ,[UnitPrice] ,[TaxRate] ,[PickedQuantity] ,[PickingCompletedWhen] ,[LastEditedBy ] ,[LastEditedWhen] FROM [WideWorldImporters].[Sales].[OrderLines] where unitPrice> 1000 GO 2000
  

 Abb. 12 Suboptimale Abfragedetails
  

 Abb. 13 Suboptimaler Abfrageausführungsplan
 

 Sobald wir den empfohlenen Index mit der Anweisung in Listing 7 erstellt haben, veranlassen wir den Abfrageoptimierer, einen neuen Ausführungsplan zu generieren. In diesem Fall wird erwartet, dass der neue Ausführungsplan die Leistung verbessert. Es gibt jedoch Fälle, in denen bestimmte Änderungen zu Leistungseinbußen führen können, z. B. erhebliche Änderungen des Datenvolumens, die Statistiken effektiv ungültig machen oder die Anzahl der Indizes verringern usw. Solche Abfragen sollen in der Leistung zurückgegangen sein und können mit dem Bericht Regressed Queries im Query Store untersucht werden.
 

 Listing 7:Indexerstellung 
 
USE [WideWorldImporters]GOCREATE NONCLUSTERED INDEX [Custom_IX_UnitPrice]ON [Sales].[OrderLines] ([UnitPrice])INCLUDE([OrderLineID],[OrderID],[StockItemID],[Description],[PackageTypeID],[Menge ],[TaxRate],[PickedQuantity],[PickingCompletedWhen],[LastEditedBy],[LastEditedWhen])GO
  

 Abb. 14 Optimierte Abfrage (Änderung des Ausführungsplans)
  

 Abb. 15 Optimierte Abfrage (zwei Pläne)
  

 Abb. 16 Optimierte Abfrage (Force Plan)
 

 Wenn mehrere Pläne für eine Abfrage vorhanden sind, wie in Abb. 14 und Abb. 16 gezeigt, können wir den Optimierer anweisen, immer einen von uns ausgewählten Plan zu verwenden, indem wir auf die Schaltfläche Plan erzwingen klicken. Dies war in den vorherigen Versionen von SQL Server eine etwas mühsame Aufgabe.
 

 Wie Sie in Abb. 17 sehen können, ermöglicht uns der Abfragespeicher, die verschiedenen Pläne, die mit einer Abfrage verbunden sind, anhand einer Reihe von Metriken zu vergleichen.
  

 Abb. 17 Vergleich von Ausführungsplänen
 

 Auch hier können wir die Abfrage in Listing 8 verwenden, um die mit dieser Abfrage-ID verknüpften Pläne mithilfe von DMVs zu überprüfen. (Siehe Abb. 11)
 

 Listing 8:Pläne im Zusammenhang mit Abfrage 42497 
 
WideWorldImportersVERWENDENGOSELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*FROM sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_idJOIN sys.query_store_query_text AS Txt ON Qry.query_text_id =Txt .query_text_idwhere Qry.query_id=42497;
 
Erkunden von Variationen
 

 Ein weiterer nützlicher Bericht, den uns der Abfragespeicher bietet, sind die Abfragen mit hoher Variation. Dieser Bericht zeigt uns, wie weit die gewünschten Metriken für eine bestimmte Suchanfrage über einen bestimmten Zeitraum auseinander liegen. Dies ist sehr nützlich für die historische Analyse der Performance. Mit den Aussagen in Listing 9 generieren wir Daten, die ein Bild davon geben können, wie Variationen aussehen würden. Die Schritte in diesem Verfahren erstellen einfach eine kleine Tabelle und fügen dann Datensätze mit unterschiedlichen Stapelgrößen ein.
 

 Listing 9:Pläne im Zusammenhang mit Abfrage 42497 
 
WideWorldImportersgo verwenden-- Tabelle erstellenTabelle erstellen tableone(ID int identity(1000,1),FirstName varchar(30),LastName varchar(30),CountryCode char(2),HireDate datetime2 default getdate());-- Einfügen von Datensätzen in Stapeln unterschiedlicher GrößeEinfügen in Tableone-Werte ('Kenneth','Igiri','NG',getdate());GO 10000Einfügen in Tableone-Werte ('Kwame','Boateng','GH', getdate());GO 10in Tabellenwerte einfügen ('Philip','Onu','NG',getdate());GO 100000in Tabellenwerte einfügen ('Kwesi','Armah','GH', getdate());GO 100
 

 Der Abfragespeicher zeigt uns Details wie die Mindest- und Höchstwerte dieser Metriken für bestimmte Ausführungsintervalle der Abfrage, an der wir interessiert sind. In diesem Beispiel stellen wir fest, dass dies einfach ein Ergebnis der Anzahl der Batches pro Ausführung ist (beachten Sie, dass die Parameter tatsächlich verwendet werden, um die INSERT-Anweisung auszuführen). In der Produktion können andere Faktoren für solche Schwankungen verantwortlich sein.
  

 Abb. 18 Variationen in der Dauer
  

 Abb. 19 Variation bei logischen Schreibvorgängen
  

 Abb. 20 Variation der physischen Lesevorgänge
 
Schlussfolgerung
 

 In diesem Artikel haben wir die SQL Server 2016-Abfragespeicher-GUI-Umgebung und einige Dinge überprüft, die wir in Bezug auf die Leistung unserer Instanz (in Bezug auf SQL) mithilfe des Abfragespeichers ableiten können. Es gibt mehrere Artikel im Internet, die noch fortgeschrittenere Anwendungsfälle und eine viel tiefere Erklärung der Interna zeigen. Dieser Artikel sollte für DBAs auf mittlerer Ebene von Nutzen sein, die sich einen Vorsprung bei der Verwendung des Abfragespeichers zur Leistungsbewertung/-optimierung verschaffen möchten.
 
Referenzen
 
 
Best Practice mit dem Abfragespeicher
 
Cristiman, L. (2016) Query Store – Settings and Limits
 
Leistungsüberwachung mithilfe des Abfragespeichers
 
Speicherkatalogansichten abfragen
 
Speicherprozeduren abfragen
 
Abfragespeicher – Funktionsweise und Verwendung
 
Nutzungsszenarien für den Abfragespeicher
 
Van de Lar, E. (2016) SQL Server 2016-Abfragespeicher:Erzwingen von Ausführungsplänen mithilfe des Abfragespeichers
 
 

 
 
Nützliches Tool:
 

 dbForge Query Builder for SQL Server – ermöglicht Benutzern das schnelle und einfache Erstellen komplexer SQL-Abfragen über eine intuitive visuelle Oberfläche ohne manuelles Schreiben von Code.