Query Store för läsbara sekundärfiler

Gäller för: SQL Server 2025 (17.x) Förhandsversion av Azure SQL DatabaseAzure SQL Managed Instance

Query Store för läsbara sekundärfiler aktiverar Query Store-insikter för arbetsbelastningar som körs på sekundära repliker. När den här funktionen är aktiverad strömmar sekundära repliker utförandeinformation för frågor (till exempel körnings- och väntestatistik) till den primära repliken, där data lagras i Query Store och görs tillgänglig över alla repliker.

Funktionen introducerades ursprungligen i SQL Server 2022 (16.x), men den var inaktiverad som standard och krävde en spårningsflagga för att aktivera. Detta berodde delvis på att funktionen var och förblir i ett förhandsversionstillstånd för SQL Server 2022 (16.x).

Från och med SQL Server 2025 (17.x) Förhandsversion och Azure SQL Database är Query Store för läsbara sekundärfiler aktiverat som standard.

Aktivera Query Store för läsbara sekundärfiler

Innan du använder Query Store för läsbara sekundärfiler på en SQL Server 2025-instans (17.x) måste en AlwaysOn-tillgänglighetsgrupp konfigureras.

För Azure SQL Database stöder Query Store för läsbara sekundärfiler följande tjänstnivåer:

• Generell användning med aktiv geo-replikering (inga inbyggda repliker med hög tillgänglighet, kräver geo-replikeringskonfiguration för sekundärt stöd)
• Premium (innehåller inbyggda repliker med hög tillgänglighet, aktiv geo-replikering stöds också)
• Affärskritisk (innehåller inbyggda repliker med hög tillgänglighet, aktiv geo-replikering stöds också)
• Azure SQL Managed Instance med principen Always-up-to-date
  • Generell användning med en redundansgrupp
  • Affärskritisk (innehåller inbyggda repliker med hög tillgänglighet)

gäller för: SQL Server 2022 (16.x) och senare versioner.

Om Query Store inte redan är aktiverat och i READ_WRITE läge på den primära repliken måste du aktivera det innan du fortsätter. Kör följande skript för varje önskad databas på den primära repliken:

ALTER DATABASE [Database_Name]
    SET QUERY_STORE = ON(OPERATION_MODE = READ_WRITE);

Om du vill aktivera Query Store på alla läsbara sekundärfiler ansluter du till den primära repliken och kör följande skript för varje databas som ska registreras för att använda funktionen.

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_WRITE);

Aktivera automatisk plankorrigering för sekundära repliker

Gäller för: SQL Server 2022 (16.x) och senare versioner, Azure SQL Database.

När du har aktiverat Query Store för sekundära repliker kan du aktivera automatisk optimering så att funktionen för automatisk plankorrigering kan tvinga fram planer på sekundära repliker. Detta gör det möjligt för frågeoptimeraren att automatiskt identifiera och åtgärda problem med frågeprestanda som orsakas av regressioner av körningsplan på sekundära repliker.

Om du vill aktivera automatisk plankorrigering för sekundära repliker ansluter du till den primära repliken och kör följande skript för varje önskad databas:

ALTER DATABASE [Database_Name]
FOR SECONDARY
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);

Inaktivera Query Store för sekundära repliker

Om du vill inaktivera funktionen Query Store för sekundära repliker på alla sekundära repliker ansluter du till master databasen på primary repliken och kör följande skript för varje önskad databas:

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_ONLY);

Verifiera att Query Store är aktiverat på sekundära repliker

Du kan kontrollera att Query Store är aktiverat på en secondary replik genom att ansluta till databasen på den sekundära repliken och köra följande t-sql-instruktion:

SELECT desired_state_desc,
       actual_state_desc,
       readonly_reason
FROM sys.database_query_store_options;

Resultatet av frågan i sys.database_query_store_options-katalogvyn bör ange att Query Stores faktiska tillstånd är READ_CAPTURE_SECONDARY med ett readonly_reason av 8.

Anmärkningar

Terminologi

En replikuppsättning definieras som en databas skriv/läs-replica (primär) och en eller flera skrivskyddade repliker (sekundära) som behandlas som en logisk enhet. En roll i den här kontexten refererar till rollen för en specifik replik. När en replik används i den primära rollen är det läs-/skrivrepliken som kan utföra både dataändringar och läsaktivitet. När en replik är konfigurerad för att endast utföra läsaktivitet fungerar den i en sekundär roll (sekundär, geo-sekundär, geo-ha sekundär). Roller kan ändras vid planerade eller oplanerade felövergångar; när detta händer kan en primär roll bli en sekundär roll eller tvärtom.

De roller som stöds för närvarande är:

• Primary
• Secondary
• Geo-sekundär
• Geo HA sekundär
• Namngiven replika

Så här fungerar det

Data som lagras om frågor kan analyseras som arbetsbelastningar på rollbasis. Med Query Store för läsbara sekundärfiler kan du övervaka prestanda för alla unika, skrivskyddade arbetsbelastningar som kan köras mot sekundära repliker. Data aggregeras på rollnivå. En konfiguration av distribuerade tillgänglighetsgrupper i SQL Server kan till exempel bestå av:

• En primär replik, en del av tillgänglighetsgrupp 1 (AG1)

• Två lokala sekundära repliker, även del AG1

• En fjärrprimärreplik på en annan plats som ingår i en separat tillgänglighetsgrupp (AG2). I SQL Server-termer kallas det också ofta för en global vidarebefordrare, men funktionen Query Store för läsbara sekundärfiler identifierar och refererar till den som en Geo secondary replik, förutsatt att den är en geografiskt distribuerad sekundär replik.

Om AG1 och AG2 har konfigurerats för att tillåta skrivskyddade anslutningar när en skrivskyddad arbetsbelastning körs mot någon av AG1:s sekundära repliker, skickas körningsstatistiken för Query Store till AG1:s primära replik och aggregeras och sparas som data som genererades från secondary rollen innan dessa data skickas tillbaka till alla sekundära repliker, inklusive den globala vidarebefordraren i AG2. När en separat arbetsbelastning körs mot AG2:s primära globala vidarekopplare, skickas dess data tillbaka till den primära replika av AG1 och lagras som data som genererades från Geo secondary rollen.

Ur ett observerbarhetsperspektiv har systemkatalogvyn sys.query_store_runtime_stats utökats för att hjälpa till att identifiera den roll från vilken körningsstatistiken härstammar. Det finns en relation mellan den här vyn och sys.query_store_replicas systemkatalogvyn, som kan ge rollen ett mer användarvänligt namn. I SQL Server, Azure SQL Database och Azure SQL Managed Instance är NULLkolumnen replica_name . Kolumnen replica_name fylls dock i för tjänstnivån Hyperskala om det finns en namngiven replik och används för skrivskyddade arbetsbelastningar.

Ett exempel på en t-sql-fråga som kan användas för att tillhandahålla en övergripande analys av de 50 viktigaste frågorna under de senaste 8 timmarna, som förbrukade CPU-resurser från alla repliker skulle vara:

-- Top 50 queries by CPU across all replicas in the last 8 hours
DECLARE @hours AS INT = 8;

SELECT TOP 50 qsq.query_id,
              qsp.plan_id,
              CASE qrs.replica_group_id WHEN 1 THEN 'PRIMARY' WHEN 2 THEN 'SECONDARY' WHEN 3 THEN 'GEO SECONDARY' WHEN 4 THEN 'GEO HA SECONDARY' ELSE CONCAT('NAMED REPLICA_', qrs.replica_group_id) END AS replica_type,
              qsq.query_hash,
              qsp.query_plan_hash,
              SUM(qrs.count_executions) AS sum_executions,
              SUM(qrs.count_executions * qrs.avg_logical_io_reads) AS total_logical_reads,
              SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) AS total_cpu_ms,
              AVG(qrs.avg_logical_io_reads) AS avg_logical_io_reads,
              AVG(qrs.avg_cpu_time / 1000.0) AS avg_cpu_ms,
              ROUND(TRY_CAST (SUM(qrs.avg_duration * qrs.count_executions) AS FLOAT) / NULLIF (SUM(qrs.count_executions), 0) * 0.001, 2) AS avg_duration_ms,
              COUNT(DISTINCT qsp.plan_id) AS number_of_distinct_plans,
              qsqt.query_sql_text
FROM sys.query_store_runtime_stats_interval AS qsrsi
     INNER JOIN sys.query_store_runtime_stats AS qrs
         ON qrs.runtime_stats_interval_id = qsrsi.runtime_stats_interval_id
     INNER JOIN sys.query_store_plan AS qsp
         ON qsp.plan_id = qrs.plan_id
     INNER JOIN sys.query_store_query AS qsq
         ON qsq.query_id = qsp.query_id
     INNER JOIN sys.query_store_query_text AS qsqt
         ON qsq.query_text_id = qsqt.query_text_id
WHERE qsrsi.start_time >= DATEADD(HOUR, -@hours, GETUTCDATE())
GROUP BY qsq.query_id, qsq.query_hash, qsp.query_plan_hash, qsp.plan_id, qrs.replica_group_id, qsqt.query_sql_text
ORDER BY SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) DESC, AVG(qrs.avg_cpu_time / 1000.0) DESC;

Query Store-rapporterna i SQL Server Management Studio (SSMS) 21 och senare versioner innehåller en listruta för repliker , som ger ett sätt att visa Query Store-data över olika replikuppsättningar/roller. I objektutforskarens vy visar noden Query Store även det aktuella tillståndet för Query Store (det vill säga READ_CAPTURE) om den är ansluten till en läsbar sekundär replik.

Query Store för läsbar sekundär övervakningsdata i Azure-diagnostikinställningar

gäller för: Azure SQL Database

När du streamar Query Store körningsstatistik via Azure diagnostikinställningar ingår två kolumner för att identifiera replikkällan för telemetridata.

• is_primary_b: Ett booleskt värde som anger om data kommer från den primära repliken (sant) eller en sekundär replik (false)
• replica_group_id: Ett heltal som motsvarar replikeringsrollen

Dessa kolumner är väsentliga för att klargöra metrik och prestandadata när man analyserar arbetsbelastningar över replikuppsättningar. När du konfigurerar diagnostikinställningar för att strömma Query Store-körningsstatistik till Log Analytics, Event Hubs eller Azure Storage kontrollerar du att dina frågor och instrumentpaneler tar hänsyn till dessa kolumner så att data segmenteras korrekt efter replikroll. Mer information om hur du konfigurerar diagnostikinställningar och tillgängliga mått finns i Diagnostikinställningar i Azure Monitor.

Prestandaöverväganden för Query Store för läsbara sekundärfiler

Kanalen som används av sekundära repliker för att skicka frågeinformation tillbaka till den primära repliken är samma kanal som används för att hålla sekundära repliker uppdaterade. Vad betyder channel det här?

I en konfiguration för tillgänglighetsgrupp (HADR) synkroniseras repliker med varandra med hjälp av ett dedikerat transportlager som innehåller loggblock, bekräftelser och statusmeddelanden mellan de primära och sekundära replikerna. Detta säkerställer datakonsekvens och redundansberedskap.

När Query Store för läsbara sekundärfiler är aktiverat skapar det inte en separat nätverksslutpunkt. I stället upprättas en ny logisk kommunikationsväg över det befintliga transportskiktet:

• För Azure SQL Database (icke-Hyperskala), Azure SQL Managed Instance och SQL Server används Always On-transportlagret för hög tillgänglighet och haveriberedskap (HADR).

• För Azure SQL Database Hyperscale används transportskiktet RbIo (Remote Blob I/O), som är kommunikationskanalen mellan beräkningsnoderna och loggtjänsten/sidservrarna. RbIo tillhandahåller en tillförlitlig, krypterad kanal för att flytta loggposter och datasidor.

Den här vägen multiplexar Query Store-körningsdata (frågetext, planer, körnings-/väntestatistik) tillsammans med den normala loggposttrafiken, genom att använda samma krypterade session. Funktionen har egna avbildnings- och mottagningsköer, som kan visas genom att sys.database_query_store_internal_state fråga vyn från vilken replik som helst:

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

Data från sekundärfiler sparas i samma Query Store-tabeller på den primära, vilket kan öka lagringskraven. Under hög belastning kan du observera svarstid eller ryggtryck på transportkanalen. Samma ad hoc-frågeinsamlingsbegränsningar som gäller för Query Store på den primära gäller även för sekundärfiler. För mer information och vägledning om hantering av storlek och insamlingsprinciper för Query Store kan du läsa Behåll de mest relevanta data i Query Store.

Negativ fråge-ID/plan-ID-synlighet

Negativa ID-n indikerar tillfälliga minnesbaserade platshållare för sökningar/planer på sekundära system före persistens till primärsystemet.

Innan Query Store-data sparas till den primära från läsbara sekundära repliker kan frågor och planer tilldelas tillfälliga identifierare i den lokala minnesintern representationen av Query Store – MEMORYCLERK_QUERYDISKSTORE_HASHMAP. Fråge- och plan-ID:t kan visas som negativa tal och är platshållare tills den primära repliken tilldelar en auktoritativ identifierare, vilket inträffar efter att Query Store har fastställt att en fråga uppfyller kraven för det konfigurerade insamlingsläget. Om en anpassad inspelningspolicy finns kan du granska de krav som måste uppfyllas genom att göra en förfrågan till sys.database_query_store_options systemkatalogvyn.

SELECT query_capture_mode_desc,
       capture_policy_execution_count,
       capture_policy_total_compile_cpu_time_ms,
       capture_policy_total_execution_cpu_time_ms
FROM sys.database_query_store_options;

När en fråga anges som infångad kan dess körnings-/väntestatistik och plan bevaras och de lokala tillfälliga ID:erna ersätts med positiva ID:er. På så sätt kan du också använda funktioner för att tvinga eller tipsa om planen.

Relaterat innehåll

• ALTER DATABASE SET-alternativ (Transact-SQL)
• sys.query_store_replicas
• sys.query_store_plan_forcing_locations (Transact-SQL) - en funktion för lagring och styrning av frågeplaner
• sys.sp_query_store_force_plan (Transact-SQL)
• Query Store-hints
• Användningsscenarier för Query Store
• sys.database_query_store_options (Transact-SQL)
• Metodtips för övervakning av arbetsbelastningar med Query Store
• metodtips för att hantera Query Store-
• Finjustera prestanda med Query Store-