Query Store för läsbara sekundära repliker (förhandsversion)

Applies to: SQL Server 2022 (16.x) och senare versioner Azure SQL DatabaseAzure SQL Managed Instance

Query Store för läsbara sekundära repliker möjliggör Query Store insikter för arbetsbelastningar som körs på sekundära repliker. När den är aktiverad strömmar sekundära repliker frågekörningsinformation (till exempel körnings- och väntestatistik) till den primära repliken, där data sparas i Query Store och görs synliga i alla repliker.

Availability

Query Store för läsbara sekundära repliker är tillgänglig från och med SQL Server 2025 (17.x), samt Azure SQL Database och Azure SQL Managed Instance med Alltid uppdaterad uppdateringspolicy. För SQL Server 2022 (16.x) måste Query Store för läsbara sekundära repliker aktivera spårningsflagga 12606 för att använda funktionen. För tidigare versioner av SQL Server och Azure SQL Managed Instance med andra uppdateringsprinciper är Query Store för läsbara sekundära repliker inte tillgängliga.

I följande tabell sammanfattas tillgängligheten och det aktiverade tillståndet för Query Store för läsbara sekundärfiler.

¹ Query Store för läsbara sekundärfiler är för närvarande inte tillgängligt på tjänstnivån Hyperskala på Azure SQL Database.
² Query Store för läsbara sekundärfiler är fortfarande i förhandsversion för SQL Server 2022 (16.x) och stöds inte i produktion och är inaktiverad som standard. För att aktivera Query Store för läsbara sekundärfiler i SQL Server 2022 (endast 16.x) krävs en spårningsflagga 12606 för att aktiveras till de primära och alla läsbara sekundära replikerna. Spårningsflagga 12606 är inte avsedd för produktionsdistributioner som baseras på SQL Server 2022 (16.x). Mer information finns i SQL Server 2022.

Scenarier med hög tillgänglighet som stöds

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

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

  • Generell användning med aktiv geo-replikering eller en failover-gruppkonfiguration (inga inbyggda repliker med hög tillgänglighet; kräver geo-replikering eller failover-gruppkonfiguration för sekundärt stöd)
  • Premium (innehåller inbyggda repliker med hög tillgänglighet, aktiv geo-replikering eller redundansgrupper som också stöds)
  • Affärskritisk (innehåller inbyggda repliker med hög tillgänglighet, aktiv geo-replikering eller redundansgrupper som också stöds)

• För Azure SQL Managed Instance med principen Always-up-to-date stöder Query Store för läsbara sekundära repliker följande tjänstnivåer:

  • Generell användning med en redundansgrupp (inga inbyggda repliker med hög tillgänglighet, kräver en konfiguration av redundanskluster för sekundär support)
  • Affärskritisk (innehåller inbyggda repliker med hög tillgänglighet)

Aktivera Query Store för läsbara sekundära repliker

Om Query Store inte redan är aktiverat och i läget READ_WRITE på den primära repliken måste du aktivera den 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ära repliker 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 justering så att funktionen för automatisk plankorrigering kan tvinga 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 databasen master på repliken primary 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);

Bekräfta att Query Store är aktiverad 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 att hämta från katalogvyn sys.database_query_store_options bör indikera att Query Store's aktuella tillstånd är READ_CAPTURE_SECONDARY, med en readonly_reason på 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. Query Store för läsbara sekundära repliker ger dig möjlighet att övervaka prestanda för alla unika, skrivskyddade arbetsbelastningar som kan köras mot sekundära repliker. Data aggregeras på rollnivå. Till exempel kan en SQL Server distribuerade tillgänglighetsgrupper konfiguration 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 även för en global vidarebefordrare, men funktionen Query Store för läsbara sekundära repliker identifierar och refererar till den som en Geo secondary replik, förutsatt att det ä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 Query Store körningsstatistik till AG1:s primära replik och aggregeras och sparas som data som genererades från secondary roll 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 är kolumnen replica_nameNULL. Kolumnen fylls dock i för Hyperscale-tjänstnivån om det finns en namngiven replica_name replik som används för arbetsbelastningar utan skrivåtkomst.

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;

De Query Store-rapporterna i SQL Server Management Studio (SSMS) 21 och senare versioner erbjuder en Replica listruta som ger ett sätt att visa Query Store-data över olika replikuppsättningar och roller. I vyn Object explorer 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 telemetri för sekundära repliker i Azure SQL Database

Tillämpas på: Azure SQL Database

När du strömmar Query Store runtime-statistik via Azure diagnostikinställningar inkluderas 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 ska du se till att dina frågor och instrumentpaneler tar hänsyn till dessa kolumner så att de segmenterar data efter replikroll korrekt. Mer information om hur du konfigurerar diagnostikinställningar och tillgängliga mått finns i Diagnostic settings in Azure Monitor.

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

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ära repliker är aktiverat skapar den 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änder det Always On-transportlagret för hög tillgänglighet och katastrofåterställning (HADR).

• För Azure SQL Database Hyperskala används ett annat transportlager som kallas fjärrblob-I/O-transportskiktet. Fjärrblob-I/O-transportskiktet är kommunikationskanalen mellan beräkningsnoderna och loggtjänsten/sidservrarna. Fjärrblob-I/O-transportlagret ger en tillförlitlig, krypterad kanal för att flytta loggposter och datasidor.

Den här vägen multiplexar Query Stores exekveringsdata (sökfrågetext, planer, körnings- och väntestatistik) tillsammans med normal loggtrafik med 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ära repliker 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ära repliker. Mer information och vägledning om hur du hanterar Query Store storleks- och insamlingsprinciper finns i Håll de mest relevanta data i Query Store.

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

Negativa ID:er indikerar tillfälliga minnesinterna platshållare för frågor/planer på sekundära repliker innan beständighet till den primära.

Innan Query Store-data sparas från läsbara sekundära repliker till den primära kan frågor och planer tilldelas tillfälliga identifierare i den minnesbaserade representationen av Query Store – MEMORYCLERK_QUERYDISKSTORE_HASHMAP. Fråge- och plan-ID:erna kan visas som negativa tal och är platshållare tills den primära repliken tilldelar en auktoritativ identifierare, vilket sker efter att Query Store fastställer att en fråga uppfyller de konfigurerade kraven för inspelningsläge. 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)
• sys.sp_query_store_force_plan (Transact-SQL)
• Query Store-anvisningar
• Query Store användningsscenarier
• sys.database_query_store_options (Transact-SQL)
• Bästa praxis för övervakning av arbetsflöden med Query Store
• Bäste metoder för att hantera Query Store
• Optimera prestanda med Query Store