Feedback om kardinalitetsuppskattning (CE)

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

Från och med SQL Server 2022 (16.x) är feedbacken om kardinalitetsuppskattning (CE) en del av den intelligenta frågebearbetningsfamiljen med funktioner och åtgärdar suboptimala frågekörningsplaner för upprepade frågor när dessa problem beror på felaktiga antaganden i CE-modellen. Det här scenariot hjälper till att minska regressionsrisker relaterade till standard-CE när du uppgraderar från äldre versioner av databasmotorn.

Eftersom ingen enskild uppsättning CE-modeller och antaganden kan hantera den stora mängden kundarbetsbelastningar och datadistributioner, ger CE-feedback en anpassningsbar lösning baserat på frågekörningsegenskaper. CE-feedback identifierar och tillämpar ett modellantagande som bättre passar en given fråga och dess datadistribution för att förbättra kvaliteten på frågekörningsplanen. För närvarande kan CE-feedback identifiera planoperatorer där det uppskattade antalet rader och det faktiska antalet rader skiljer sig mycket åt. Feedback tillämpas när betydande modelluppskattningsfel inträffar och det finns en fungerande alternativ modell att prova.

För andra frågor gällande feedback-funktioner, se Minnesbidragsfeedback och Feedback om grad av parallellitet.

Förstå feedback på kardinalitetsestimering (CE)

Kardinalitetsuppskattning (CE) är hur frågeoptimeraren kan uppskatta det totala antalet rader som bearbetas på varje nivå i en frågeplan. Kardinalitetsuppskattning i SQL Server härleds främst från histogram som skapas när index eller statistik skapas, antingen manuellt eller automatiskt. Ibland använder SQL Server även villkorsinformation och logiska omskrivningar av frågor för att fastställa kardinalitet.

Olika versioner av databasmotorn använder olika CE-modellantaganden baserat på hur data distribueras och efterfrågas. För mer information, se versioner av CE.

Implementering av feedback för kardinalitetsuppskattning (CE)

Feedback om kardinalitetsuppskattning (CE) lär sig vilka CE-modellantaganden som är optimala över tid och tillämpar sedan det historiskt mest korrekta antagandet:

1. CE-feedback identifierar modellrelaterade antaganden och utvärderar om de är korrekta för upprepade frågor.

2. Om ett antagande ser felaktigt ut testas en efterföljande körning av samma fråga med en frågeplan som justerar det effektfulla CE-modellantagandet och verifierar om det hjälper. Vi identifierar felaktighet genom att jämföra faktiska och uppskattade rader från planoperatorer. Alla fel kan inte korrigeras av modellvarianter som är tillgängliga i CE-feedback.

3. Om planens kvalitet förbättras, ersätts den gamla frågeplanen med en frågeplan som använder lämplig USE HINT-frågetips för att justera uppskattningsmodellen, implementerad genom Query Store-tipsmekanismen.

Endast verifierad feedback sparas permanent. CE-feedback används inte för den frågan om det justerade modellantagandet resulterar i en prestandaregression. I det här sammanhanget uppfattas även en användares avbrutna fråga som en regression.

Feedbackscenarier för kardinalitetsuppskattning (CE)

Feedback om kardinalitetsuppskattning (CE) åtgärdar upplevda regressionsproblem som uppstår till följd av felaktiga CE-modellantaganden vid användning av standard-CE (CE120 eller högre) och kan selektivt använda olika modellantaganden. Scenarierna inkluderar Korrelation, Sammanfogningsinhägnad och Optimerarens radmål.

Feedbackkorrelation för kardinalitetsuppskattning (CE)

När Frågeoptimeraren uppskattar predikatens selektivitet i en viss tabell eller vy, eller antalet rader som uppfyller predikatet, använder den antaganden för korrelationsmodell. Dessa antaganden kan vara att predikat är:

• Helt oberoende (standard för CE70), där kardinaliteten beräknas genom att multiplicera urvalen för alla predikat.

• Delvis korrelerad (standard för CE120 och högre), där kardinaliteten beräknas med hjälp av en variant på exponentiell backoff, som beställer urvalen från de flesta till det minst selektiva predikatet.

• Fullständigt korrelerad, där kardinaliteten beräknas med hjälp av minsta möjliga urval för alla predikat.

I följande exempel används partiell korrelation när databaskompatibiliteten är inställd på 120 eller högre:

USE AdventureWorks2016_EXT;
GO
SELECT AddressID, AddressLine1, AddressLine2
FROM Person.Address
WHERE StateProvinceID = 79 AND City = N'Redmond';
GO

När databaskompatibiliteten är inställd på 160 och standardkorrelation används, försöker CE-feedback flytta korrelationen till rätt riktning ett steg i taget baserat på om den uppskattade kardinaliteten underskattades eller överskattades jämfört med det faktiska antalet rader. Använd fullständig korrelation om ett faktiskt antal rader är större än den uppskattade kardinaliteten. Använd fullständigt oberoende om ett faktiskt antal rader är mindre än den uppskattade kardinaliteten.

För mer information, se versionerna av CE.

Feedback om kardinalitetsuppskattning (CE) för sammanslagningsinneslutning

När Frågeoptimeraren uppskattar selektiviteten för kopplingspredikat och tillämpliga filterpredikat använder den inneslutningsmodellsantaganden. Dessa antaganden är:

• Enkel inneslutning (standard för CE70) förutsätter att kopplingspredikaten är helt korrelerade, där filterväljbarhet beräknas först och sedan är kopplingsväljbarheten faktorinräknad.

• Basisonhållning (standard för CE120 och högre) förutsätter ingen korrelation mellan kopplingspredikat och nedströmsfilter, där kopplingsselektivitet beräknas först och sedan faktoreras filtreringsselektiviteten in.

I följande exempel används basbegränsning när databaskompatibiliteten är inställd på 120 eller högre:

USE AdventureWorksDW2016_EXT;
GO
SELECT *
FROM dbo.FactCurrencyRate AS f
INNER JOIN dbo.DimDate AS d ON f.DateKey = d.DateKey
WHERE d.MonthNumberOfYear = 7 AND f.CurrencyKey = 3 AND f.AverageRate > 1;
GO

För mer information, se versioner av CE.

Feedback om kardinalitetsuppskattning (CE) och frågeoptimerarens radmål

När Frågeoptimeraren uppskattar kardinaliteten för en exekveringsplan förutsätter den vanligtvis att alla kvalificerande rader från alla tabeller måste bearbetas. Vissa frågemönster gör dock att frågeoptimeraren söker efter en plan som returnerar ett mindre antal rader för att minska I/O. Om frågan anger ett målantal rader (radmål) som kan förväntas vid körning med hjälp av ett TOP, IN eller EXISTS nyckelord, frågetipset FAST eller en SET ROWCOUNT instruktion, används radmålet som en del av frågeoptimeringsprocessen, till exempel i följande exempel:

USE AdventureWorks2016_EXT;
GO
SELECT TOP 1 soh.*
FROM Sales.SalesOrderHeader AS soh
INNER JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID;
GO

När radmålsplanen tillämpas minskas det uppskattade antalet rader i frågeplanen eftersom frågeoptimeraren förutsätter att ett mindre antal rader måste bearbetas för att nå radmålet.

Radmålet är en fördelaktig optimeringsstrategi för vissa frågemönster, men om data inte är jämnt fördelade kan fler sidor genomsökas än beräknat, vilket innebär att radmålet blir ineffektivt. CE-feedback kan inaktivera radmålsökningen och aktivera en sökning när den här ineffektiviteten identifieras.

I körningsplanen finns inget attribut specifikt för CE-feedback, men det finns ett attribut angivet för Query Store-hint. Kontrollera om QueryStoreStatementHintSource är CE feedback.

Överväganden för återkoppling om kardinalitetsuppskattning (CE)

• Aktivera feedback om kardinalitetsuppskattning (CE) genom att aktivera databaskompatibilitetsnivå 160 för databasen som du är ansluten till när du kör frågan. Query Store måste vara aktiverat och i READ_WRITE läge för varje databas där CE-feedback används.

• Om du vill inaktivera CE-feedback på databasnivå använder du konfigurationen CE_FEEDBACK med databasomfattning. Till exempel i användardatabasen:

  ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;
  

• Om du vill inaktivera CE-feedback på frågenivå använder du frågetipset DISABLE_CE_FEEDBACK .

CE-feedbackaktiviteten visas via query_feedback_analysis och query_feedback_validation XEvents.

Tips som anges av CE-feedback kan spåras med sys.query_store_query_hints katalogvyn.

Feedbackinformation kan spåras med hjälp av sys.query_store_plan_feedback katalogvy.

Om en fråga har en frågeplan som har tvingats genom Query Store används inte CE-feedback för den frågan.

Om en fråga använder hårdkodade frågetips eller använder Frågearkivtips som angetts av användaren används inte CE-feedback för den frågan. Mer information finns i Frågetips och Query Store-tips.

Från och med SQL Server 2022 (16.x), när Query Store för sekundära repliker är aktiverat, är CE-feedback inte replikmedveten för sekundära repliker i tillgänglighetsgrupper. CE-feedback gynnar för närvarande endast primära repliker. Vid failover går feedback som tillämpas på primära eller sekundära repliker förlorad. Query Store är tillgängligt på sekundära tillgänglighetsgrupprepliker från och med SQL Server 2025 (17.x). För mer information, se Query Store för sekundära repliker.

Beständighet för feedback om kardinalitetsuppskattning (CE)

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

Feedback om kardinalitetsuppskattning (CE) kan identifiera scenarier när radmålsoptimeringen ska bevaras och behålla den här ändringen genom att spara den i Frågearkivet i form av ett Frågearkiv-tips. Den nya optimeringen används för framtida exekveringar av frågan. CE-feedback bevarar andra scenarier utanför frågemönster för radmålsoptimering, enligt beskrivningen i feedbackscenarier. CE-feedback hanterar för närvarande predikatscenarier för selektivitet som används av CE:s korrelationsmodell och ansluter predikatscenarier som hanteras av CE:s inneslutningsmodell.

Den här funktionen introducerades i SQL Server 2022 (16.x), men den här prestandaförbättringen är tillgänglig för frågor som körs på databaskompatibilitetsnivå 160 eller senare, eller tipset QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n om 160 och senare, och när Query Store är aktiverat för databasen och är i ett "lässkrivningstillstånd".

Kända problem med kardinalitetsuppskattningens (CE) feedback

Problematik	Identifierat datum	Läge	Datum åtgärdat
Långsamma SQL Server-prestanda när du har tillämpat kumulativ uppdatering 8 för SQL Server 2022 (16.x) under vissa förhållanden. Du kan stöta på dramatisk minnesutnyttjande för Plan Cache tillsammans med oväntade ökningar av CPU-utnyttjandet när CE-feedback aktiveras.	December 2023	Löst	22 april 2024 (CU 12)

Information om kända problem

Långsamma SQL Server-prestanda när du har tillämpat kumulativ uppdatering 8 för SQL Server 2022 under vissa förhållanden

Från och med SQL Server 2022 (16.x) Kumulativ uppdatering 8 kan SQL Server uppvisa oväntade ökningar av processor- och minnesanvändningen. Dessutom kan en ökning av RESOURCE_SEMAPHORE_QUERY_COMPILE väntetider observeras. Du kan också märka stadiga ökningar av antalet plancacheobjekt som används, som närmar sig plancachens gränser, och att manuell rensning av plancache med tekniker som ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE, DBCC FREESYSTEMCACHE eller DBCC FREEPROCCACHE inte ger någon hjälp. Det här beteendet har bara observerats av några få kunder.

Detta problem påverkar inte alla arbetslaster och beror på antalet olika genererade planer samt antalet planer som var kvalificerade för CE feedback-funktionen. Ce-feedback analyserar planoperatorer för betydande modellfelberäkning, men det finns ett scenario där en refererad plan kan derefereras under den här analysfasen. Den här situationen förhindrar att planen tas bort från minnet med hjälp av den vanliga LRU-algoritmen (Least Recently Used). LRU-mekanismen är ett sätt som SQL Server upprätthåller utkastningspolicyer för planer. SQL Server tar också bort planer från minnet om systemet är under minnesbelastning. När SQL Server försöker ta bort de planer som har avrefererat felaktigt kan den inte ta bort dessa planer från plancachen, vilket gör att cacheminnet fortsätter att växa. Den växande cachen kan börja orsaka ytterligare kompileringar som i slutändan använder mer CPU och minne. Mer information finns i Planera interna cacheminnen.

Symptom: Antalet poster i plancache som används och markeras som smutsiga från antingen SQL-planer eller objektplaner ökar med tiden till 50 000 eller mer. Om du ser poster i plancachen som börjar närma sig den här nivån tillsammans med oväntade ökningar av CPU-användningen kan det uppstå ett problem i systemet. En korrigering tillhandahålls med SQL Server 2022 (16.x) kumulativ uppdatering 12. Se KB5033663.

Om du vill övervaka antalet plancacheposter som systemet använder kan följande exempel användas som en tidpunktsvy över antalet poster i plancachen som finns. Till exempel är ett sätt att regelbundet över tid övervaka det här fenomenet att titta på antalet poster i plancachen som har markerats som smutsiga.

SELECT
  CASE
    WHEN mce.[name] LIKE 'SQL Plan%' THEN 'SQL Plans'
    WHEN mce.[name] LIKE 'Object Plan%' THEN 'Object Plans'
    ELSE '[All other cache stores]'
  END AS PlanType,
  COUNT(*) AS [Number of plans marked to be removed]
FROM sys.dm_os_memory_cache_entries AS mce
LEFT OUTER JOIN sys.dm_exec_cached_plans AS ecp
  ON mce.memory_object_address = ecp.memory_object_address
WHERE mce.is_dirty = 1
AND ecp.bucketid is NULL
GROUP BY
  CASE
    WHEN mce.[name] LIKE 'SQL Plan%' THEN 'SQL Plans'
    WHEN mce.[name] LIKE 'Object Plan%' THEN 'Object Plans'
    ELSE '[All other cache stores]'
  END;

En annan uppsättning frågor som också ger samma information som föregående exempel samtidigt som du kan observera ytterligare prestandamått. Plan Cache-hitförhållanden minskar, liksom antalet kompileringar i förhållande till antalet batchförfrågningar/sekund. Följande frågor kan användas för att övervaka ditt system över tid. Hålla ett öga på cacheträffförhållandet (oväntade dalar), cacheobjekten som används (ökar antalet till nivåer som närmar sig 50 000 utan att minska) och ett lägre batchbegäranden/sek-förhållande än förväntat jämfört med en ökning av kompileringar/sek.

--SQL Plan (Adhoc and Prepared plans)
SELECT
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN 'Cache Hit Ratio'
        WHEN [counter_name] = 'Cache Object Counts' THEN 'Cache Object Counts'
        WHEN [counter_name] = 'Cache Objects in use' THEN 'Cache Objects in use'
        WHEN [counter_name] = 'Cache Pages' THEN 'Cache Pages'
    END AS [SQLServer:Plan Cache (SQL Plans)],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN NULL
        ELSE FORMAT(cntr_value, '#,###')
    END AS [Counter Value],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN
            FORMAT(TRY_CONVERT(DECIMAL(5, 2), (cntr_value * 1.0 / NULLIF((SELECT cntr_value
        FROM sys.dm_os_performance_counters WHERE
        [object_name] LIKE '%:Plan Cache%' AND [counter_name] = 'Cache Hit Ratio Base'
        AND instance_name LIKE 'SQL Plan%'), 0))), '0.00%')
    END AS [SQL Plan Cache Hit Ratio]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%:Plan Cache%'
    AND [counter_name] IN ('Cache Hit Ratio', 'Cache Object Counts', 'Cache Objects in use', 'Cache Pages')
    AND instance_name LIKE 'SQL Plan%'
ORDER BY [counter_name];

--Module/Stored procedure based plans
SELECT
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN 'Cache Hit Ratio'
        WHEN [counter_name] = 'Cache Object Counts' THEN 'Cache Object Counts'
        WHEN [counter_name] = 'Cache Objects in use' THEN 'Cache Objects in use'
        WHEN [counter_name] = 'Cache Pages' THEN 'Cache Pages'
    END AS [SQLServer:Plan Cache (Object Plans)],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN NULL
        ELSE FORMAT(cntr_value, '#,###')
    END AS [Counter Value],
    CASE
        WHEN [counter_name] = 'Cache Hit Ratio' THEN
            FORMAT(TRY_CONVERT(DECIMAL(5, 2), (cntr_value * 1.0 / NULLIF((SELECT cntr_value
        FROM sys.dm_os_performance_counters WHERE
        [object_name] LIKE '%:Plan Cache%' AND [counter_name] = 'Cache Hit Ratio Base'
        AND instance_name LIKE 'Object Plan%'), 0))), '0.00%')
    END AS [SQL Plan Cache Hit Ratio]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%:Plan Cache%'
    AND [counter_name] IN ('Cache Hit Ratio', 'Cache Object Counts', 'Cache Objects in use', 'Cache Pages')
    AND instance_name LIKE 'Object Plan%'
ORDER BY [counter_name];

SELECT
    CASE
        WHEN [counter_name] = 'Batch Requests/sec' THEN 'Batch Requests/sec'
        WHEN [counter_name] = 'SQL Compilations/sec' THEN 'SQL Compilations/sec'
    END AS [SQLServer:SQL Statistics],
    FORMAT(cntr_value, '#,###') AS [Counter Value]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%:SQL Statistics%'
AND counter_name IN ('Batch Requests/sec', 'SQL Compilations/sec'
);

Övergångslösning

Om systemet fortsätter att uppleva de symtom som beskrevs tidigare, efter att den kumulativa uppdateringen 12 KB5033663 har tillämpats, kan CE-feedbackfunktionen inaktiveras på databasnivå.

Om du vill frigöra planens cacheminne som tas upp av det här problemet krävs en omstart av SQL Server-instansen. Den här omstartsåtgärden kan vidtas när CE-feedbackfunktionen har inaktiverats. Om du vill inaktivera CE-feedback på databasnivå använder du konfigurationen CE_FEEDBACK med databasomfattning. Till exempel i användardatabasen:

ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;

Problem med feedback och rapportering

För feedback eller frågor, e-post CEFfeedback@microsoft.com

Relaterat innehåll

• Feedback om kardinalitetsuppskattning i SQL Server 2022
• Intelligent frågebearbetning i SQL-databaser
• Intelligenta frågebearbetningsfunktioner i detalj
• Kardinalitetsuppskattning (SQL Server)
• KONFIGURERA OM (Transact-SQL)
• Övervaka och finjustera prestanda
• ÄNDRA DATABASOMFATTNINGSKONFIGURATION (Transact-SQL)