Kardinalitásbecslés (CE) visszajelzés

A következőkre vonatkozik:A következőkre vonatkozik: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, Azure SQL kezeltt példány.

Az SQL Server 2022 -től (16.x) kezdődően a számosságbecslés (CE) visszajelzése része az intelligens lekérdezésfeldolgozó szolgáltatáscsaládnak , és a lekérdezések ismétlődő végrehajtásának optimálisnál rosszabb terveit kezeli, ha ezek a problémák helytelen CE-modellel kapcsolatos feltételezésekből erednek. Ez a forgatókönyv segít csökkenteni az alapértelmezett CE-vel kapcsolatos regressziós kockázatokat az adatbázismotor régebbi verzióiról való frissítéskor.

Mivel a CE-modellek és feltételezések egyetlen készlete sem képes elférni az ügyfelek számítási feladatainak és adateloszlásainak széles skáláján, a CE-visszajelzések a lekérdezési futtatókörnyezet jellemzői alapján adaptálható megoldást biztosítanak. A CE-visszajelzések azonosítják és használják a modell feltételezését, amely jobban megfelel egy adott lekérdezésnek és adatterjesztésnek a lekérdezés-végrehajtási terv minőségének javítása érdekében. A CE-visszajelzések jelenleg olyan tervoperátorok azonosítására képesek, amelyekben a sorok becsült száma és a sorok tényleges száma nagyon eltérő. A rendszer visszajelzést alkalmaz, ha jelentős modellbecslési hibák lépnek fel, és van egy működőképes alternatív modell, amelyet ki kell próbálni.

További lekérdezési visszajelzési funkciókért lásd: Memóriahasználati visszajelzés és a párhuzamosság foka (DOP) visszajelzése.

A számosságbecslés (CE) visszajelzésének ismertetése

A számosság becslése (CE) segítségével a Lekérdezésoptimalizáló meg tudja becsülni a lekérdezésterv minden szintjén feldolgozott sorok teljes számát. Az SQL Server számosságbecslése elsősorban az indexek vagy statisztikák létrehozásakor létrehozott hisztogramokból származik, manuálisan vagy automatikusan. Az SQL Server néha kényszerinformációkat és a lekérdezések logikai átírását is használja a számosság meghatározásához.

Az adatbázismotor különböző verziói különböző CE-modellel kapcsolatos feltételezéseket használnak az adatok elosztásának és lekérdezésének módjától függően. További információkért lásd a CE verzióit.

Számosságbecslés (CE) visszajelzések implementálása

A számosságbecslés (CE) visszajelzéseiből megtudhatja, hogy mely CE-modell feltételezései optimálisak az idő függvényében, majd alkalmazza a történetileg legkorrektebb feltételezést:

A CE-visszajelzések azonosítják a modellel kapcsolatos feltételezéseket, és kiértékelik, hogy pontosak-e az ismétlődő lekérdezésekhez.
Ha egy feltételezés helytelennek tűnik, ugyanazon lekérdezés későbbi végrehajtását egy olyan lekérdezési tervvel teszteli, amely módosítja az érintett CE-modell feltételezését, és ellenőrzi , hogy segít-e. A helytelenséget a terv operátoraiból származó tényleges és becsült sorok alapján azonosítjuk. A CE-visszajelzésben elérhető modellvariánsok nem minden hibát javíthatnak ki.
Ha javítja a terv minőségét, a régi lekérdezési tervet egy olyan lekérdezési terv váltja fel , amely a megfelelő USE HINT lekérdezési tippet használja, amely módosítja a becslési modellt a Lekérdezéstár tipp mechanizmusán keresztül.

Csak az ellenőrzött visszajelzések maradnak meg. A CE-visszajelzések nem használhatók a lekérdezéshez, ha a módosított modell feltételezése teljesítményregressziót eredményez. Ebben az összefüggésben a felhasználó által megszakított lekérdezések regressziónak is tekinthetők.

Számosságbecslési (CE) visszajelzési forgatókönyvek

A számosságbecslés (CE) visszajelzései olyan észlelt regressziós problémákat kezelnek, amelyek helytelen CE-modellel kapcsolatos feltételezésekből erednek az alapértelmezett CE (CE120 vagy újabb) használatakor, és szelektíven használhatnak különböző modellfeltehetéseket. A forgatókönyvek közé tartozik a Korreláció, a Join Containment és az Optimizer sor célja.

Számosságbecslés (CE) visszajelzési korrelációja

Amikor a Lekérdezésoptimalizáló megbecsüli a predikátumok választóképességét egy adott táblán vagy nézeten, vagy az említett predikátumnak megfelelő sorok számát, korrelációs modellel kapcsolatos feltételezéseket használ. Ezek a feltételezések lehetnek a predikátumokra vonatkozóak.

Teljesen független (a CE70 alapértelmezett értéke), ahol a számosság kiszámítása az összes predikátum kiválasztásának szorzatával történik.
Részben korrelált (a CE120 és újabb verziók alapértelmezett értéke), ahol a számosság kiszámítása exponenciális visszalépési variációval történik, és a kiválasztást a legtöbbtől a legkevésbé szelektív predikátumig rendezi.
Teljes mértékben korrelált, ahol a számosság kiszámítása az összes predikátum minimális szelekcióinak használatával történik.

Az alábbi példa részleges korrelációt használ, ha az adatbázis kompatibilitása 120-ra vagy magasabbra van állítva:

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

Ha az adatbázis kompatibilitása 160-ra van állítva, és az alapértelmezett korrelációt használják, a CE visszajelzései egy lépésben megpróbálják a korrelációt a megfelelő irányba helyezni annak alapján, hogy a becsült számosság alábecsülve vagy túlbecsülve lett-e a sorok tényleges számához képest. Használjon teljes korrelációt, ha a sorok tényleges száma nagyobb a becsült számosságnál. Használjon teljes függetlenségi feltételezést, ha a sorok tényleges száma kisebb, mint a becsült számosság.

További információkért lásd a CE verzióit.

Számosságbecslés (CE) – visszajelzések összekapcsolása

Amikor a Lekérdezésoptimalizáló megbecsüli az illesztési predikátumok és az alkalmazható szűrő predikátumok szelektivitását, az elszigetelési modell feltételezéseit használja. Ezek a feltételezések a következők:

Az egyszerű elszigetelés (a CE70 alapértelmezett beállítása) feltételezi, hogy az illesztési predikátumok teljes mértékben korrelálnak, ahol először a szűrőszekrézivitást számítják ki, majd az illesztési szelektivitást számítják ki.
Az alapelszigetelés (a CE120-as és újabb verziók esetében alapértelmezés szerint) nem feltételezi az illesztési predikátumok és az alsóbb rétegbeli szűrők közötti korrelációt, ahol először az illesztési szelektivitást számítja ki, majd a szűrő szelektivitását számítja ki.

Az alábbi példa alapszintű elszigetelést használ, ha az adatbázis kompatibilitása 120-ra vagy magasabbra van állítva:

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

További információkért lásd a CE verzióit.

Számosságbecslési (CE) visszajelzés és a lekérdezésoptimalizáló sor célja

Amikor a Lekérdezésoptimalizáló megbecsüli egy végrehajtási terv számosságát, általában azt feltételezi, hogy az összes táblázat minden sorát, amely megfelel a feltételeknek, fel kell dolgozni. Egyes lekérdezési minták azonban azt okozzák, hogy a Lekérdezésoptimalizáló olyan tervet keres, amely kisebb számú sort ad vissza az I/O csökkentése érdekében. Ha a lekérdezés olyan célsorszámot (sorcélt) határoz meg, amely a futásidő alatt várható egy TOP, IN vagy EXISTS kulcsszavak, a FAST lekérdezési tipp vagy egy SET ROWCOUNT utasítás használatával, akkor a sorcél a lekérdezésoptimalizálási folyamat részeként lesz felhasználva, például az alábbi példában:

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

A sor céltervének alkalmazásakor a lekérdezési tervben lévő sorok becsült száma csökken, mert a Lekérdezésoptimalizáló feltételezi, hogy kevesebb sort kell feldolgozni a sor céljának eléréséhez.

Bár a sorcél egy előnyös optimalizálási stratégia bizonyos lekérdezési mintákhoz, ha az adatok nem egyenletesen vannak elosztva, több oldalt lehet beolvasni a becsültnél, ami azt jelenti, hogy a sorcél nem lesz hatékony. A CE-visszajelzések letilthatják a sor célvizsgálatát, és engedélyezhetik a kereséseket, ha ez az eredménytelenség észlelhető.

A végrehajtási tervben nincs a CE-visszajelzésre jellemző attribútum, de a Lekérdezéstár tippje tartalmaz egy attribútumot. Keresse meg a QueryStoreStatementHintSource, hogy CE feedback legyen.

A számosságbecslés (CE) visszajelzésének szempontjai

A számosságbecslés (CE) visszajelzésének engedélyezéséhez engedélyezze a 160-es adatbázis-kompatibilitási szintet ahhoz az adatbázishoz, amelyhez a lekérdezés végrehajtásakor csatlakozik. A lekérdezéstárat engedélyezni kell, és READ_WRITE módban kell lennie minden olyan adatbázis esetében, ahol CE-visszajelzést használnak.
Ha az adatbázis szintjén szeretné letiltani a CE-visszajelzést, használja az CE_FEEDBACKadatbázis hatókörébe tartozó konfigurációt. Például a felhasználói adatbázisban:
```
ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;
```
Ha le szeretné tiltani a CE-visszajelzést a lekérdezés szintjén, használja a lekérdezési DISABLE_CE_FEEDBACK tippet.

A CE visszajelzési tevékenysége az query_feedback_analysis és query_feedback_validation XEvents segítségével látható.

A CE-visszajelzések által beállított tippek a sys.query_store_query_hints katalógusnézettel követhetők nyomon.

A visszajelzési információk a sys.query_store_plan_feedback katalógusnézet használatával követhetők nyomon.

Ha egy lekérdezéshez lekérdezési terv van kényszerítve a Lekérdezéstáron keresztül, a rendszer nem használ CE-visszajelzést a lekérdezéshez.

Ha egy lekérdezés kemény kódú lekérdezési tippeket használ, vagy a felhasználó által beállított Lekérdezéstár-tippeket használ, a CE-visszajelzések nem lesznek használva ehhez a lekérdezéshez. További információ: Lekérdezési tippek és Lekérdezéstár tipp.

Az SQL Server 2022-től (16.x) kezdődően, amikor a másodlagos replikák lekérdezéstára engedélyezve van, a CE visszajelzései nem replikaérzékenyek a rendelkezésre állási csoportok másodlagos replikáihoz. A CE-visszajelzések jelenleg csak az elsődleges replikák előnyeit élvezik. Átálláskor az elsődleges vagy másodlagos replikákra alkalmazott visszajelzések elvesznek. A Lekérdezéstár az SQL Server 2025 -től (17.x) kezdődő másodlagos rendelkezésre állási csoport replikáin érhető el. További információkért lásd: Másodlagos replikák lekérdezési tárolója.

A számosságbecslés (CE) visszajelzésének megőrzése

A következőkre vonatkozik:A következőkre vonatkozik: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database, Azure SQL kezeltt példány.

A kardinalitás becslési (CE) visszajelzés képes észlelni azokat a helyzeteket, amikor a sorcél optimalizálását meg kell tartani, és ezt a változást a Lekérdezéstárban Lekérdezéstár-útmutató formájában megőrizheti. Az új optimalizálás a lekérdezés későbbi végrehajtásához használatos. A CE-visszajelzések a sorcél-optimalizálási lekérdezési mintákon kívül más forgatókönyveket is megőriznek, a visszajelzési forgatókönyvekben leírtak szerint. A CE-visszajelzés jelenleg a CE korrelációs modellje által használt predikátumválasztási forgatókönyveket kezeli, és összekapcsolja a ce-beli elszigetelési modell által kezelt predikátumforgatókönyveket.

Ez a funkció az SQL Server 2022-ben (16.x) lett bevezetve, de ez a teljesítménybeli fejlesztés elérhető a 160-as vagy annál magasabb adatbázis-kompatibilitási szinten működő lekérdezések, vagy 160-as vagy magasabb verziójú QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n jelzéssel ellátott lekérdezések esetében, valamint ha a Lekérdezéstár engedélyezve van az adatbázishoz, és "írás-olvasási" állapotban van.

A számosságbecslés (CE) visszajelzésével kapcsolatos ismert problémák

Probléma	Felderített dátum	Státusz	A megoldás dátuma
Az SQL Server 2022 (16.x) 8. kumulatív frissítésének bizonyos feltételek mellett történő alkalmazása után lassú az SQL Server teljesítménye. Amikor a feltételes becslés (CE) visszajelzések engedélyezve vannak, előfordulhat, hogy a Plan Cache memóriahasználata drámaian megnő, és ezzel egy időben váratlanul növekszik a processzorhasználat is.	2023. december	Resolved	2024. április 22. (CU 12)

Ismert problémák részletei

Lassú SQL Server-teljesítmény az SQL Server 2022 8. kumulatív frissítésének bizonyos feltételek mellett történő alkalmazása után

Az SQL Server 2022 (16.x) 8. kumulatív frissítésétől kezdve az SQL Server váratlan processzor- és memóriakihasználtságot mutathat. Emellett a RESOURCE_SEMAPHORE_QUERY_COMPILE várakozások növekedése is megfigyelhető. Azt is tapasztalhatja, hogy folyamatosan nő a Plan Cache használatban lévő objektumainak száma, amelyek megközelítik a Plan Cache korlátait, és a tervgyorsítótár manuális törlése olyan technikákkal, mint ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE, DBCC FREESYSTEMCACHE vagy DBCC FREEPROCCACHE, nem nyújt segítséget. Ezt a viselkedést csak néhány ügyfél észlelte.

Ez a probléma nem érinti az összes számítási feladatot, és a létrehozott különböző tervek számától, valamint a tervek számától függ, amelyek megfelelnek a CE visszajelzési funkció használatához. Bár a CE-visszajelzések a terv operátorainak jelentős modellbeli becslési hibáit elemzik, van egy olyan forgatókönyv, amelyben a hivatkozott tervet el lehet hivatkozásveszteni ebben az elemzési fázisban. Ez a helyzet megakadályozza a terv eltávolítását a memóriából a szokásos legkevésbé használt (LRU) algoritmus használatával. Az LRU mechanizmus az egyik módja annak, hogy az SQL Server végrehajtási terv kilakoltatási politikáját érvényesítse. Az SQL Server akkor is eltávolítja a terveket a memóriából, ha a rendszer memóriaterhelés alatt áll. Amikor az SQL Server megkísérli eltávolítani a hibásan hivatkozott terveket, nem tudja eltávolítani ezeket a tervgyorsítótárból, ami miatt a gyorsítótár tovább nő. A növekvő gyorsítótár további fordításokat okozhat, amelyek végül több processzort és memóriát használnak. További információ: Plan Cache Internals.

Hibajelenség: A használatban lévő terv gyorsítótár-bejegyzések száma, melyek mind az SQL-tervek, mind az objektumtervek alapján piszkosként meg vannak jelölve, folyamatosan növekszik, elérve az 50 000-et vagy annál többet. Ha olyan tervgyorsítótár-bejegyzéseket észlel, amelyek elkezdik megközelíteni ezt a szintet, és nem várt módon növelik a processzorhasználatot, előfordulhat, hogy a rendszer ezt a problémát tapasztalja. Az SQL Server 2022 (16.x) 12- es kumulatív frissítése javítást tartalmaz. Lásd : KB5033663.

A rendszer által használt tervgyorsítótár-bejegyzések számának figyeléséhez az alábbi példák használhatók a meglévő tervgyorsítótár-bejegyzések számának időnézetében. Ennek a jelenségnek az egyik módja például a tervgyorsítótár-bejegyzések számának időszakos figyelése, amelyeket piszkosként jelöltek meg.

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;

Egy másik lekérdezéskészlet, amely ugyanazokat az információkat tartalmazza, mint az előző példában, és lehetővé teszi további teljesítménymetrikák megfigyelését is. A terv gyorsítótár találati aránya csökken, valamint a fordítások száma a kötegkérések/másodperc számához képest. Az alábbi lekérdezések a rendszer hosszú távú monitorozására használhatók. Figyelje a gyorsítótár-találatok arányát (nem várt visszaeséseket), a használatban lévő gyorsítótár-objektumokat (a szám növekedése akár 50 000-et elérő szintekre, anélkül, hogy csökkenne) és a vártnál alacsonyabb Batch kérések/másodperc arányt, összehasonlítva a fordítások/másodperc növekedésével.

--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'
);

Megoldás

Ha a rendszer továbbra is tapasztalja a korábban leírt tüneteket, a 12-es kumulatív frissítés alkalmazása után KB5033663, a CE visszajelzési funkció az adatbázis szintjén letiltható.

A probléma által elfoglalt tervgyorsítótár-memória visszaszerzése érdekében újra kell indítani az SQL Server példányt. Ezt az újraindítási műveletet a CE visszajelzési funkció letiltása után lehet elvégezni. Ha az adatbázis szintjén szeretné letiltani a CE-visszajelzést, használja az CE_FEEDBACKadatbázis hatókörébe tartozó konfigurációt. Például a felhasználói adatbázisban:

ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK = OFF;

Visszajelzési és jelentéskészítési problémák

Visszajelzés vagy kérdés esetén e-mailben CEFfeedback@microsoft.com

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-19