Dela via

Övervaka prestanda med hjälp av Query Store

  • Artikel

gäller för: SQL Server 2016 (13.x) och senare versioner Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (endast dedikerad SQL-pool)SQL-databas i Microsoft Fabric

Funktionen Query Store ger dig insikter om val av frågeplan och prestanda för SQL Server, Azure SQL Database, Fabric SQL Database, Azure SQL Managed Instance och Azure Synapse Analytics. Query Store förenklar prestandafelsökningen genom att hjälpa dig att snabbt hitta prestandaskillnader som orsakas av ändringar i frågeplanen. Query Store samlar automatiskt in en historik över frågor, planer och körningsstatistik och behåller dessa för din granskning. Den separerar data efter tidsfönster så att du kan se databasanvändningsmönster och förstå när ändringar i frågeplanen har gjorts på servern.

Du kan konfigurera Query Store med alternativet ALTER DATABASE SET.

Viktig

Om du använder Query Store för just-in-time-arbetsbelastningsinsikter i SQL Server 2016 (13.x) planerar du att installera prestandaskalbarhetskorrigeringarna i KB-4340759 så snart som möjligt.

Aktivera Query Store

  • Query Store är aktiverat som standard för nya Azure SQL Database- och Azure SQL Managed Instance-databaser.
  • Query Store är inte aktiverat som standard för SQL Server 2016 (13.x), SQL Server 2017 (14.x), SQL Server 2019 (15.x). Det är aktiverat som standard i READ_WRITE läge för nya databaser som börjar med SQL Server 2022 (16.x). Om du vill aktivera funktioner för bättre spårning av prestandahistorik, felsöka problem med frågeplan och aktivera nya funktioner i SQL Server 2022 (16.x) rekommenderar vi att du aktiverar Query Store på alla databaser.
  • Query Store är inte aktiverat som standard för nya Azure Synapse Analytics-databaser.

Använd sidan Query Store i SQL Server Management Studio

  1. Högerklicka på en databas i Object Explorer och välj sedan Egenskaper.

    Not

    Kräver minst version 16 av Management Studio.

  2. I dialogrutan Databasegenskaper väljer du sidan Query Store.

  3. I rutan åtgärdsläge (begärt) väljer du Läs och skriv.

Använd Transact-SQL-instruktioner

Använd ALTER DATABASE-instruktionen för att aktivera Query Store för en viss databas. Till exempel:

ALTER DATABASE <database_name>
SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);

Alternativen för att konfigurera Query Store i Fabric SQL-databasen med ALTER DATABASE är för närvarande begränsade.

I Azure Synapse Analytics aktiverar du Query Store utan ytterligare alternativ, till exempel:

ALTER DATABASE <database_name>
SET QUERY_STORE = ON;

Fler syntaxalternativ som är relaterade till Query Store finns i ALTER DATABASE SET Options (Transact-SQL).

Not

Det går inte att aktivera Query Store för master eller tempdb databaser.

Viktig

Information om hur du aktiverar Query Store och håller det justerat efter din arbetsbelastning finns i Bästa praxis med Query Store-.

Information i Query Store

Körningsplaner för en specifik fråga i SQL Server utvecklas vanligtvis över tid på grund av ett antal olika orsaker, till exempel statistikändringar, schemaändringar, skapande/borttagning av index osv. Procedurens cache (där cachelagrade frågeplaner lagras) lagrar bara den senaste körningsplanen. Planer tas också bort från plan-cachen på grund av minnesbelastning. Därför kan frågeprestandaregressioner som uppstår på grund av ändringar i exekveringsplanen vara icke-triviala och tidskrävande att lösa.

Eftersom Query Store behåller flera körningsplaner per fråga kan det framtvinga principer för att dirigera frågeprocessorn att använda en specifik körningsplan för en fråga. Detta kallas för planpåverkan. Tvingande av plan i Query Store tillhandahålls genom en mekanism som liknar USE PLAN frågehint, men det kräver inga ändringar i användarprogram. Plan framtvingning kan lösa en regression av frågeprestanda som orsakas av en planändring på mycket kort tid.

Not

Query Store samlar in planer för DML-uttalanden som SELECT, INSERT, UPDATE, DELETE, MERGEoch BULK INSERT.

Med avsikt samlar Query Store inte in planer för DDL-uttryck som CREATE INDEXosv. Query Store samlar in ackumulerad resursanvändning genom att registrera planer för de underliggande DML-operationerna. Query Store kan till exempel visa de SELECT- och INSERT-instruktioner som körs internt för att fylla i ett nytt index.

Query Store samlar inte in data för internt kompilerade lagrade procedurer som standard. Använd sys.sp_xtp_control_query_exec_stats för att aktivera datainsamling för internt kompilerade lagrade procedurer.

Väntestatistik är en annan informationskälla som hjälper till att felsöka prestanda i databasmotorn. Under lång tid var väntestatistik endast tillgänglig på instansnivå, vilket gjorde det svårt att backa väntetider till en specifik fråga. Från och med SQL Server 2017 (14.x) och Azure SQL Database innehåller Query Store en dimension som spårar väntestatistik. I följande exempel kan Query Store samla in väntestatistik.

ALTER DATABASE <database_name>
SET QUERY_STORE = ON ( WAIT_STATS_CAPTURE_MODE = ON );

Vanliga scenarier för att använda funktionen Query Store är:

  • Hitta och åtgärda snabbt en planprestandaregression genom att tvinga fram den tidigare frågeplanen. Åtgärda frågefrågor som nyligen har försämrats i fråga om prestanda på grund av ändringar i exekveringsplaner.
  • Fastställa hur många gånger en fråga kördes under en viss tidsperiod, vilket hjälper en DBA att felsöka problem med prestandaresurser.
  • Identifiera de främsta n frågesökningarna med avseende på körningstid, minnesförbrukning etc. över de senaste x timmarna.
  • Granska historiken för frågeplaner för en viss fråga.
  • Analysera resursanvändningsmönstren (CPU, I/O och Minne) för en viss databas.
  • Identifiera de främsta n frågorna som väntar på resurser.
  • Förstå väntanens natur för en viss fråga eller plan.

Query Store innehåller tre butiker:

  • ett planarkiv för att bevara körningsplanens information.
  • ett körningsstatistiklager för att bevara exekveringsstatistik.
  • ett väntestatistikarkiv för att spara information om väntestatistik.

Antalet unika planer som kan lagras för en fråga i planarkivet begränsas av konfigurationsalternativet max_plans_per_query. För att förbättra prestanda skrivs informationen till butikerna asynkront. För att minimera utrymmesanvändningen aggregeras körningsstatistiken i lagringsplatsen för körningsstatistik över en fast tidsperiod. Informationen i dessa butiker kan ses genom att göra förfrågningar i Query Store-katalogvyerna.

Följande fråga returnerar information om frågor, deras planer, kompileringstid och körtidsstatistik från Query Store.

SELECT Txt.query_text_id, Txt.query_sql_text, Pln.plan_id, Qry.*, RtSt.*
FROM sys.query_store_plan AS Pln
INNER JOIN sys.query_store_query AS Qry
    ON Pln.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id
INNER JOIN sys.query_store_runtime_stats RtSt
ON Pln.plan_id = RtSt.plan_id;

Query Store för sekundära repliker

gäller för: SQL Server (från och med SQL Server 2022 (16.x))

Funktionen Query Store för sekundära repliker möjliggör samma Query Store-funktioner på sekundära replikarbetsbelastningar som är tillgängliga för primära repliker. När Query Store för sekundära repliker är aktiverat skickar repliker körningsinformation för frågorna som normalt skulle lagras i Query Store tillbaka till den primära repliken. Den primära repliken sparar sedan data på disken i sitt eget Frågearkiv. I grund och botten finns det ett Query Store som delas mellan de primära och alla sekundära repliker. Query Store finns på den primära repliken och lagrar data för alla repliker tillsammans.

Fullständig information om Query Store för sekundära repliker finns i Query Store for AlwaysOn availability group secondary replicas.

Använd funktionen för regresserade förfrågningar

När du har aktiverat Query Store uppdaterar du databasdelen i fönstret Object Explorer för att lägga till avsnittet Query Store.

Skärmbild av frågearkivets rapportträd i SSMS Object Explorer.

Not

För Azure Synapse Analytics är Query Store-vyer tillgängliga under systemvyer i databasdelen av fönstret Object Explorer.

Välj regresserade frågor för att öppna fönstret regresserade frågor i SQL Server Management Studio. Fönstret Regresserade frågor visar frågor och planer i Query Store. Använd listrutorna längst upp för att filtrera frågor baserat på olika kriterier: Varaktighet (ms) (standard), CPU-tid (ms), logiska läsningar (KB), logiska skrivningar (KB), fysiska läsningar (KB), CLR-tid (ms), DOP, minnesförbrukning (KB), radantal, loggminne som används (KB), Temp DB-minne som används (KB) och väntetid (ms).

Välj en plan för att se den grafiska frågeplanen. Knappar är tillgängliga för att visa källfrågan, framtvinga och ta bort en frågeplan, växla mellan rutnäts- och diagramformat, jämföra valda planer (om fler än en har valts) och uppdatera visningen.

Skärmbild av SQL Server Regressed Queries-rapporten i SSMS Object Explorer.

Om du vill tvinga fram en plan väljer du en fråga och en plan och väljer sedan Force Plan. Endast de planer som sparats av frågeplansfunktionen och fortfarande finns kvar i cacheminnet för frågeplaner kan tvingas fram.

Hitta väntande frågor

Från och med SQL Server 2017 (14.x) och Azure SQL Database är väntestatistik per fråga över tid tillgänglig i Query Store.

I Query Store kombineras väntetyper till väntekategorier i . Mappningen av väntekategorier till väntetyper finns i sys.query_store_wait_stats (Transact-SQL).

Välj Frågeväntestatistik för att öppna fönstret Query Wait Statistics i SQL Server Management Studio 18.0 eller senare versioner. Fönstret Frågeväntestatistik visar ett stapeldiagram som innehåller de översta väntekategorierna i Query Store. Använd listrutan längst upp för att välja ett aggregerat villkor för väntetiden: genomsnitt, max, min, std dev och totalt (standard).

Skärmbild av SQL Server Query Wait Statistics-rapporten i SSMS Object Explorer.

Välj en väntekategori genom att välja i fältet och en detaljvy på den valda väntekategorin visas. Det nya stapeldiagrammet innehåller de frågor som bidrog till den väntekategorin.

Skärmbild av SQL Server-frågeväntestatistikens detaljvy i SSMS Object Explorer.

Använd listrutan längst upp för att filtrera frågor baserat på olika väntetidsvillkor för den valda väntekategorin: genomsnitt, max, min, std dev och totalt (standard). Välj en plan för att se den grafiska frågeplanen. Knappar finns tillgängliga för att visa källfrågan, framtvinga och återställa en frågeplan samt förnya skärmen.

Väntekategorier kombinerar olika väntetyper i grupper som liknar varandra till sin natur. Olika väntekategorier kräver en annan uppföljningsanalys för att lösa problemet, men väntetyper från samma kategori leder till mycket liknande felsökningsupplevelser, och att tillhandahålla den berörda frågan ovanpå väntetider skulle vara den saknade biten för att slutföra de flesta sådana undersökningar.

Här följer några exempel på hur du kan få mer insikter om din arbetsbelastning före och efter introduktionen av väntekategorier i Query Store:

Tidigare erfarenhet Ny upplevelse Åtgärd
Höga RESOURCE_SEMAPHORE väntetider per databas Höga väntetider för minne i Query Store för specifika frågeförfrågningar Hitta de vanligaste minneskrävande frågorna i Query Store. Dessa frågor fördröjer förmodligen ytterligare förlopp för de berörda frågorna. Överväg att använda MAX_GRANT_PERCENT frågetips för dessa frågor eller för de berörda frågorna.
Höga LCK_M_X väntetider per databas Höglås väntar i Query Store för specifika frågor Kontrollera frågetexterna för de berörda frågorna och identifiera målentiteterna. Leta i Query Store efter andra frågor som ändrar samma entitet, som körs ofta och/eller har hög varaktighet. När du har identifierat dessa frågor kan du överväga att ändra programlogik för att förbättra samtidigheten eller använda en mindre restriktiv isoleringsnivå.
Höga PAGEIOLATCH_SH väntetider per databas Hög buffer-I/O-väntan i Query Store för specifika frågor Hitta frågorna med ett stort antal fysiska läsningar i Query Store. Om de matchar frågorna med höga I/O-väntetider bör du överväga att införa ett index på den underliggande entiteten för att söka i stället för genomsökningar och därmed minimera I/O-omkostnaderna för frågorna.
Höga SOS_SCHEDULER_YIELD väntetider per databas Höga CPU-väntetider i Query Store för specifika frågor Hitta de vanligaste CPU-användningsfrågorna i Query Store. Bland dem kan du identifiera de frågor för vilka hög CPU-trend korrelerar med höga CPU-väntetider för de berörda frågorna. Fokusera på att optimera dessa frågor – det kan finnas en planregression eller kanske ett index som saknas.

Konfigurationsalternativ

De tillgängliga alternativen för att konfigurera Query Store-parametrar finns i ALTER DATABASE SET-alternativ (Transact-SQL).

Utför en fråga mot vyn sys.database_query_store_options för att fastställa de aktuella alternativen för Query Store. Mer information om värdena finns i sys.database_query_store_options.

Exempel på hur du ställer in konfigurationsalternativ med hjälp av Transact-SQL-instruktioner finns i Alternativhantering.

Notera

För Azure Synapse Analytics kan Query Store aktiveras som på andra plattformar, men ytterligare konfigurationsalternativ stöds inte.

Visa och hantera Query Store via Management Studio eller med hjälp av följande vyer och procedurer.

Funktioner i Query Store

Funktioner hjälper till med åtgärder med Query Store.

sys.fn_stmt_sql_handle_from_sql_stmt (Transact-SQL)

Katalogvyer för Query Store

Katalogvyer visar information om Query Store.

sys.database_query_store_options (Transact-SQL)

sys.query_context_settings (Transact-SQL)

sys.query_store_plan (Transact-SQL)

sys.query_store_query (Transact-SQL)

sys.query_store_query_text (Transact-SQL)

sys.query_store_runtime_stats (Transact-SQL)

sys.query_store_wait_stats (Transact-SQL)

sys.query_store_runtime_stats_interval (Transact-SQL)

sys.database_query_store_internal_state (Transact-SQL)

Lagrade procedurer för Query Store

Lagrade procedurer konfigurerar Query Store.

sp_query_store_flush_db (Transact-SQL)

sp_query_store_reset_exec_stats (Transact-SQL)

sp_query_store_force_plan (Transact-SQL)

sp_query_store_unforce_plan (Transact-SQL)

sp_query_store_remove_plan (Transact-SQL)

sp_query_store_remove_query (Transact-SQL)

sp_query_store_clear_message_queues (Transact-SQL)

sp_query_store_consistency_check (Transact-SQL)1

1 I extrema scenarier kan Query Store ange ett feltillstånd på grund av interna fel. Från och med SQL Server 2017 (14.x) kan du återställa Query Store genom att köra den sp_query_store_consistency_check lagrade proceduren i den berörda databasen. Se sys.database_query_store_options för mer information som beskrivs i actual_state_desc kolumnbeskrivning.

Underhåll av Query Store

Metodtips och rekommendationer för underhåll och hantering av Query Store har utökats i den här artikeln: Metodtips för att hantera Query Store-.

Prestandagranskning och felsökning

Mer information om hur du dyker in i prestandajustering med Query Store finns i Finjustera prestanda med Query Store-.

Andra prestandaämnen:

Relaterat innehåll