Paraméterérzékeny csomag optimalizálása

A következőkre vonatkozik: Az SQL Server 2022 (16.x) és újabb verziói az Azure SQL DatabaseAzure SQL Managed InstanceSQL-adatbázist a Microsoft Fabricben

A paraméterérzékeny terv (PSP) optimalizálása az intelligens lekérdezésfeldolgozó szolgáltatáscsalád része. Azt a forgatókönyvet kezeli, amikor egy paraméteres lekérdezés egyetlen gyorsítótárazott terve nem optimális az összes lehetséges bejövő paraméterértékhez. Ez a nem egységes adateloszlások esetében fordul elő. További információ: Paraméterérzékenység , paraméterek és végrehajtási terv újrafelhasználása.

A problémaforgatókönyv meglévő kerülő megoldásaiért lásd a következő forrást:

A PSP-optimalizálás automatikusan engedélyezi, hogy egyetlen paraméterezett utasításhoz több aktív, gyorsítótárazott terv legyen. A gyorsítótárazott végrehajtási tervek az ügyfél által megadott futtatókörnyezeti paraméterérték(ek) alapján különböző adatméreteket fogadnak el.

A paraméterezés ismertetése

Az SQL Server adatbázismotorban a Transact-SQL (T-SQL) utasítások paramétereinek vagy paraméterjelölőinek használata növeli a relációs motor azon képességét, hogy az új T-SQL-utasítások egyezzenek a meglévő, korábban lefordított végrehajtási tervekkel, és előléptesse a terv újrahasználatát. További információ: Egyszerű paraméterezés.

Az SQL Server alapértelmezett egyszerű paraméterezési viselkedését úgy is felülbírálhatja, hogy megadja, hogy az adatbázis összes SELECT, INSERT, UPDATE és DELETE utasítása paraméterezett legyen, bizonyos korlátozások figyelembevételével. További információ: Kényszerített paraméterezés.

PSP-optimalizálás implementálása

A kezdeti összeállítás során az oszlopstatisztikai hisztogramok azonosítják a nem egységes eloszlásokat, és kiértékelik a legkockázatosabb paraméteres predikátumokat, az összes rendelkezésre álló predikátumból legfeljebb három. Más szóval, ha ugyanazon lekérdezésen belül több predikátum is megfelel a feltételeknek, a PSP optimalizálása az első háromat választja. A PSP szolgáltatás korlátozza a kiértékelt predikátumok számát, hogy elkerülje a tervgyorsítótár és a lekérdezéstár túlterhelését túl sok tervvel (ha a lekérdezéstár engedélyezve van).

A jogosult csomagok esetében a kezdeti fordítás egy diszpécsercsomagot hoz létre, amely tartalmazza a PSP optimalizálási logikáját, az úgynevezett diszpécserkifejezést. A diszpécserterv a számosságtartomány határértékeinek predikátumai alapján lekérdezi a variánsokat .

Terminology

Diszpécser kifejezés

Kiértékeli a predikátumok számosságát a futásidejű paraméterértékek alapján, és a végrehajtást különböző lekérdezési változatokhoz irányítja.

Diszpécser terv

Az eredeti lekérdezéshez az a terv van gyorsítótárazva, amely tartalmazza a diszpécserkifejezést. A diszpécsercsomag lényegében a funkció által kiválasztott predikátumok gyűjteménye, néhány további részlettel. Minden egyes kiválasztott predikátum esetében a diszpécsertervben szereplő részletek között szerepel néhány, mint például a magas és az alacsony határértékek. Ezeket az értékeket használják a paraméterértékek különböző kategóriákra vagy tartományokra osztására. A diszpécserterv tartalmazza a határértékek kiszámításához használt statisztikákat is.

Lekérdezésvariáns

A diszpécserterv a futtatási környezet paraméterértékei alapján értékeli ki a predikátumok számosságát, csoportosítja ezeket az értékeket, és különálló lekérdezéseket generál a fordításhoz és a végrehajtáshoz. Ezeket a gyermek lekérdezéseket lekérdezésvariánsoknak nevezzük. A lekérdezés variánsoknak saját terveik vannak a terv gyorsítótárban és a Lekérdezéstárban.

Predikátum számosságtartománya

Futásidőben a rendszer az egyes predikátumok számosságát a futtatókörnyezet paraméterértékei alapján értékeli ki. A kézbesítő a számosságértékeket három predikátum számosságtartományba gyűjti össze fordításkor. A PSP optimalizálási funkció például három olyan tartományt hozhat létre, amelyek alacsony, közepes és magas számosságtartományokat jelölnek, ahogyan az alábbi ábrán látható.

Más szóval, amikor egy paraméteres lekérdezést először lefordítanak, a PSP optimalizálási funkciója létrehoz egy rendszerhéjtervet, amelyet diszpécsertervnek neveznek. A diszpécserkifejezés logikája a paraméterek futásidejű értékei alapján lekérdezésvariánsokba gyűjti a lekérdezéseket. A tényleges végrehajtás kezdetekor a diszpécser két lépést hajt végre:

a diszpécser kiértékeli a diszpécserkifejezést az adott paraméterkészlethez a számosságtartomány kiszámításához.
a diszpécser társítja ezeket a tartományokat adott lekérdezési változatokhoz, összeállítja, majd végrehajtja a változatokat. A PSP optimalizálási funkciója több lekérdezésvariánssal rendelkezik, így több terv is elérhető egyetlen lekérdezéshez.

A számosságtartomány határai a küldési terv ShowPlan XML-fájljain belül láthatók:

<Dispatcher>
  <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1000000">
    <StatisticsInfo Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Statistics="[NCI_Property_AgentId]" ModificationCount="0" SamplingPercent="100" LastUpdate="2019-09-07T15:32:16.89" />
    <Predicate>
      <ScalarOperator ScalarString="[PropertyMLS].[dbo].[Property].[AgentId]=[@AgentId]">
        <Compare CompareOp="EQ">
          <ScalarOperator>
            <Identifier>
              <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Column="AgentId" />
            </Identifier>
          </ScalarOperator>
          <ScalarOperator>
            <Identifier>
              <ColumnReference Column="@AgentId" />
            </Identifier>
          </ScalarOperator>
        </Compare>
      </ScalarOperator>
    </Predicate>
  </ParameterSensitivePredicate>
</Dispatcher>

A rendszer hozzáfűz egy PSP-optimalizálási tippet egy lekérdezésvariáns ShowPlan XML-jében található SQL-utasításhoz. A tipp nem használható közvetlenül, és nem elemezhető, ha manuálisan adja hozzá. A tipp a következő elemeket tartalmazza:

option ( PLAN PER VALUE ( ObjectID = (int), QueryVariantID = (int), predicate_range ( [databaseName].[ schemaName]. [tableName]. [columnName] = @paramName, lowBoundaryValue, highBoundaryValue ) ) )

Az ObjectID a modulból (azaz tárolt eljárásból, függvényből, triggerből) származik, amelynek az aktuális utasítás része; azzal a feltételezéssel, hogy az utasítás egy modulból lett létrehozva. Ha az utasítás dinamikus vagy alkalmi SQL (azaz) eredménye, sp_executesqlakkor az ObjectID elem egyenlő 0.
A QueryVariantID nagyjából egyenértékű a PSP-optimalizálás által kiválasztott összes predikátum tartományainak kombinációjával. Ha például egy lekérdezés két PSP-re jogosult predikátummal rendelkezik, és mindegyik predikátum három tartományból áll, kilenc lekérdezésvariáns tartomány lesz 1–9-es számmal.
predikátumtartomány a diszpécserkifejezésből generált predikált számosságtartomány-információ.

Egy lekérdezésvariáns ShowPlan XML-jában (a Dispatcher elemen belül):

<Batch>
  <Statements>
    <StmtSimple StatementText="SELECT PropertyId,&#xD;&#xA;       AgentId,&#xD;&#xA;       MLSLinkId,&#xD;&#xA;       ListingPrice,&#xD;&#xA;       ZipCode,&#xD;&#xA;       Bedrooms,&#xD;&#xA;       Bathrooms&#xD;&#xA;FROM dbo.Property&#xD;&#xA;WHERE AgentId = @AgentId&#xD;&#xA;ORDER BY ListingPrice DESC option (PLAN PER VALUE(ObjectID = 613577224, QueryVariantID = 1, predicate_range([PropertyMLS].[dbo].[Property].[AgentId] = @AgentId, 100.0, 1000000.0)))" StatementId="1" StatementCompId="2" StatementType="SELECT" StatementSqlHandle="0x090085E4372DFC69BB9E7EBA421561DE8E1E0000000000000000000000000000000000000000000000000000" DatabaseContextSettingsId="1" ParentObjectId="0" StatementParameterizationType="1" RetrievedFromCache="false" StatementSubTreeCost="0.021738" StatementEstRows="3" SecurityPolicyApplied="false" StatementOptmLevel="FULL" QueryHash="0x476167A000F589CD" QueryPlanHash="0xDE982107B7C28AAE" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" CardinalityEstimationModelVersion="160">
      <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />

      <Dispatcher>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2019-09-07T15:32:16.89" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_Property_AgentId]" Table="[Property]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[Property].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
      </Dispatcher>

    </StmtSimple>
  </Statements>
</Batch>

Remarks

Az SQL Server 2025 -től (17.x) és az adatbázis-kompatibilitás 170-től kezdve a PSP optimalizálása a következő négy fejlesztést tartalmazza:
- Az adatmanipulációs nyelv (DML) olyan utasításainak támogatása, mint a DELETE, az INSERT, a MERGE és az UPDATE.
- Bővített támogatás tempdb esetében.
- További megfontolandó szempontok olyan helyzetekben, ahol több jogosult predikátum is létezik ugyanazon a táblán.
- A query_with_parameter_sensitivity kiterjesztett esemény módosításai, amelyek az érdekes_predikátum_számot, a max_frontosságot, a psp_optimalizálás_támogatást és a lekérdezéstípust tartalmazzák, az SQL Server 2025 (17.x) és az adatbázis-kompatibilitás 170 módosításai előtt történtek. Most azonban vegye fel a interesting_predicate_count, interesting_predicate_details, psp_optimization_supported és query_type mezőket. További információkért lásd a Bővített események szakaszt .
A PSP optimalizálási funkciója jelenleg csak egyenlőségi predikátumokkal működik.
A diszpécsertervek automatikusan újra összeállításra kerülnek, ha jelentős adatelosztási változások történnek. A lekérdezésvariáns tervek igény szerint egymástól függetlenül újrafordodnak, mint bármely más lekérdezésterv-típus esetén, az alapértelmezett újrafordítási események függvényében. Az újrafordításról további információt a Végrehajtási tervek újrafordítása című témakörben talál.
A sys.query_store_plan Lekérdezéstár rendszerkatalógus nézete megváltozott, hogy különbséget tegyen egy normál lefordított terv, egy diszpécsercsomag és egy lekérdezésvariáns csomag között. Az új Lekérdezéstár rendszerkatalógus nézete sys.query_store_query_variant az eredeti paraméteres lekérdezések (más néven szülő-lekérdezések), a diszpécsercsomagok és a gyermek lekérdezésvariánsok közötti szülő-gyermek kapcsolatokról tartalmaz információkat.
Ha több predikátum is szerepel ugyanahhoz a táblához, a PSP-optimalizálás kiválasztja azt a predikátumot, amely az alapul szolgáló statisztikai hisztogram alapján a legtöbb adateltérésnek felel meg. Ha például SELECT * FROM table WHERE column1 = @predicate1 AND column2 = @predicate2mind a kettő column1 = @predicate1column2 = @predicate2 azonos táblából származik, table1a funkció csak a leginkább ferde predikátumot értékeli ki. Ha azonban a példa lekérdezés egy olyan operátort tartalmaz, mint például egy UNION, a PSP több predikátumot is kiértékel. Ha például egy lekérdezés jellemzői hasonlóak SELECT * FROM table WHERE column1 = @predicate UNION SELECT * FROM table WHERE column1 = @predicate, a PSP ebben az esetben legfeljebb két predikátumot választ ki, mivel a rendszer úgy kezeli ezt a forgatókönyvet, mintha két különböző tábla volna. Ugyanez a viselkedés figyelhető meg az olyan lekérdezések esetében is, amelyek önkiszolgálóan csatlakoznak a tábla aliasaihoz.

Egy lekérdezésvariáns ShowPlan XML-fájlja az alábbi példához hasonlóan nézne ki, ahol mindkét kiválasztott predikátumhoz tartozó információ hozzá van adva a PLAN PER VALUE PSP-hez kapcsolódó jelzőhöz.

<Batch>
  <Statements>
    <StmtSimple StatementText="SELECT  b.PropertyId, &#xD;&#xA;       AgentId, &#xD;&#xA;       MLSLinkId, &#xD;&#xA;       ListingPrice, &#xD;&#xA;       ZipCode, &#xD;&#xA;       Bedrooms, &#xD;&#xA;       Bathrooms &#xD;&#xA;FROM dbo.AgentProperty a join  PropertyDetails b on a.PropertyId = b.PropertyId&#xD;&#xA;WHERE AgentId = @AgentId and  Property_id=@Property_id&#xD;&#xA;UNION&#xD;&#xA;          SELECT  c.PropertyId, &#xD;&#xA;       AgentId, &#xD;&#xA;       MLSLinkId, &#xD;&#xA;       ListingPrice, &#xD;&#xA;       ZipCode, &#xD;&#xA;       Bedrooms, &#xD;&#xA;       Bathrooms &#xD;&#xA;FROM dbo.AgentProperty c join  PropertyDetails d on c.PropertyId = d.PropertyId&#xD;&#xA;WHERE AgentId = @AgentId and  Property_id=@Property_id option (PLAN PER VALUE(ObjectID = 981578535, QueryVariantID = 9, predicate_range([PropertyMLS].[dbo].[AgentProperty].[AgentId] = @AgentId, 100.0, 1000000.0),predicate_range([PropertyMLS].[dbo].[AgentProperty].[AgentId] = @AgentId, 100.0, 1000000.0)))" StatementId="1" StatementCompId="2" StatementType="SELECT" StatementSqlHandle="0x090051FBCD918F8DFD60D324887356B422D90000000000000000000000000000000000000000000000000000" DatabaseContextSettingsId="2" ParentObjectId="0" StatementParameterizationType="1" RetrievedFromCache="false" StatementSubTreeCost="29.2419" StatementEstRows="211837" SecurityPolicyApplied="false" StatementOptmLevel="FULL" QueryHash="0x6D2A4E407085C01E" QueryPlanHash="0x72101C0A0DD861AB" CardinalityEstimationModelVersion="160" BatchModeOnRowStoreUsed="true">
      <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />
      <Dispatcher>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2022-08-11T20:42:35.02" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_AgentProperty_AgentId]" Table="[AgentProperty]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[AgentProperty].[AgentId] as [a].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[AgentProperty]" Alias="[a]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2022-08-11T20:42:35.02" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_AgentProperty_AgentId]" Table="[AgentProperty]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[AgentProperty].[AgentId] as [c].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[AgentProperty]" Alias="[c]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
      </Dispatcher>
      <QueryPlan CachedPlanSize="160" CompileTime="17" CompileCPU="17" CompileMemory="1856" QueryVariantID="9">

A PSP optimalizálási funkció által használt jelenlegi ferdeségi küszöbértékeket az alábbi módszerek közül egy vagy több használatával befolyásolhatja:
- Számosságbecslő (CE) nyomkövetési jelzői, például a 9481-es nyomkövetési jelző (globális, munkamenet vagy lekérdezési szint)
- Adatbázis-hatókörű konfigurációs lehetőségek, amelyek megpróbálják csökkenteni a használt CE-modellt, vagy befolyásolják a CE-modell által a több predikátum függetlenségére vonatkozó feltételezéseket. Ez különösen akkor hasznos, ha a többoszlopos statisztikák nem léteznek, ami befolyásolja a PSP-optimalizálás azon képességét, hogy értékelje ezen predikátumok megfelelőségét.
- További információért lásd a SQL Server 2014 Számosságbecslő használatával történő lekérdezéstervek optimalizálása című dokumentáció több predikátumra vonatkozó megnövekedett korrelációra vonatkozó feltételezés szakaszát. Az újabb CE-modell megpróbál némi korrelációt és kisebb függetlenséget feltételezni a predikátumok konjunkciójához és diszjunkciójához. Az örökölt CE-modell használata hatással lehet a predikátumok többoszlopos illesztés forgatókönyvben való kiválasztására. Ezt a műveletet csak bizonyos forgatókönyvek esetén érdemes megfontolni, és a legtöbb számítási feladathoz nem ajánlott az örökölt CE-modellt használni.
A PSP-optimalizálás jelenleg minden lekérdezésvariánst új előkészített utasításként fordít le és hajt végre, ami az egyik oka annak, hogy a lekérdezésvariánsok elveszítik a társításukat a szülőmodulokkal, object_id ha a diszpécsercsomag egy modulon alapult (azaz tárolt eljárás, eseményindító, függvény, nézet stb.). Előkészített utasításként a object_id nem olyan, amely sys.objects közvetlenül egy objektumra leképezhető, hanem lényegében a kötegszöveg belső kivonatán alapuló számított érték. További információkért tekintse meg a DMV-dokumentáció Visszaadott táblázat szakaszát sys.dm_exec_plan_attributes.

A lekérdezésvariáns tervek a csomaggyorsítótár objektumtárolójában (CACHESTORE_OBJCP), a diszpécsercsomagok pedig az SQL Plans gyorsítótártárolójában (CACHESTORE_SQLCP) vannak elhelyezve. A PSP szolgáltatás azonban a object_id lekérdezésvariáns szülőjét az ObjectID attribútumban tárolja, amely része a PSP által a ShowPlan XML-hez hozzáadott PLAN PER VALUE tippnek, ha a szülő lekérdezés egy modul része, és nem dinamikus vagy alkalmi T-SQL. A gyorsítótárazott eljárások, függvények és triggerek összesített teljesítménystatisztikái továbbra is felhasználhatók a megfelelő célokra. A DMV-hez sys.dm_exec_query_stats hasonló nézetekben található részletesebb végrehajtással kapcsolatos statisztikák továbbra is tartalmazzák a lekérdezésvariánsok adatait, a tábla lekérdezésvariánsai és objektumai object_id közötti sys.objects társítás azonban jelenleg nem igazodik egymáshoz, anélkül, hogy a ShowPlan XML további feldolgozást kapna minden olyan lekérdezésvariánshoz, amelyben részletesebb futtatókörnyezeti statisztikákra van szükség. A lekérdezésvariánsok futásidejű és várakozási statisztikai adatai további ShowPlan XML-elemzési technikák nélkül kérhetők le a lekérdezéstárból, ha a Lekérdezéstár engedélyezve van.
Mivel a PSP-lekérdezésvariánsok új előkészített utasításként vannak végrehajtva, a object_id nem jelenik meg automatikusan a terv gyorsítótárához kapcsolódó sys.dm_exec_* DMV-kben a ShowPlan XML feldarabolása és szövegminta-összehasonlító technikák alkalmazása nélkül (vagyis további XQuery feldolgozás). Jelenleg csak a PSP-optimalizálási diszpécsercsomagok bocsátják ki a megfelelő szülőobjektum-azonosítót. A object_id a Lekérdezéstáron belül van elérhető, mivel a Lekérdezéstár egy relációsabb modellt tesz lehetővé, mint amit a tervgyorsítótár hierarchiája biztosít. További információkért tekintse meg a Lekérdezéstár rendszerkatalógus nézetét sys.query_store_query_variant.

Considerations

A PSP-optimalizálás 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 PSP optimalizálási funkciójával kapcsolatos további információkért javasoljuk, hogy a Lekérdezéstár bekapcsolásával engedélyezve legyen a Lekérdezéstár integrációja. Az alábbi példa bekapcsolja a Lekérdezéstárat egy már létező MyNewDatabase nevű adatbázisban.

ALTER DATABASE [MyNewDatabase]
SET QUERY_STORE = ON (
    OPERATION_MODE = READ_WRITE,
    QUERY_CAPTURE_MODE = AUTO
);

Note

Az SQL Server 2022 -től (16.x) kezdődően a Lekérdezéstár alapértelmezés szerint engedélyezve van az összes újonnan létrehozott adatbázishoz.

A PSP-optimalizálás adatbázisszinten való letiltásához használja az ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF adatbázis-hatókörű konfigurációt.
Ha le szeretné tiltani a PSP optimalizálását a lekérdezés szintjén, használja a lekérdezési DISABLE_PARAMETER_SENSITIVE_PLAN tippet.
Ha a 4136-os nyomkövetési zászló, az adatbázis hatókörébe tartozó konfiguráció PARAMETER_SNIFFING, vagy a lekérdezési tippet USE HINT('DISABLE_PARAMETER_SNIFFING') letiltja a paraméter figyelését, a PSP optimalizálása le van tiltva a kapcsolódó számítási feladatok és végrehajtási környezetek esetében. További információ: Lekérdezési tippek és ALTER DATABASE SCOPED CONFIGURATION.
A csomaggyorsítótárban tárolt kézbesítőnkénti egyedi csomagvariánsok száma a gyorsítótár-blobolás elkerülése érdekében korlátozott. A belső küszöbérték nincs dokumentálva. Mivel minden SQL-köteg több csomag létrehozására is képes, és minden lekérdezésvariáns-terv rendelkezik egy független bejegyzéssel a tervgyorsítótárban, az engedélyezett tervbejegyzések alapértelmezett maximális számát is elérheti. Ha a lekérdezésterv gyorsítótár kiürítési sebessége szembetűnően magas, vagy a CACHESTORE_OBJCPCACHESTORE_SQLCP mérete túl nagy, érdemes lehet alkalmazni a 174-es nyomkövetési jelzőt.
A lekérdezéstárban lévő lekérdezésekhez tárolt egyedi tervvariánsok számát a max_plans_per_query konfigurációs beállítás korlátozza. Mivel a lekérdezésvariánsok több csomaggal is rendelkezhetnek, lekérdezésenként összesen 200 csomag jelenhet meg a Lekérdezéstárban. Ez a szám tartalmazza a szülő lekérdezéshez tartozó összes kézbesítő lekérdezésvariáns-csomagjait. Fontolja meg a max_plans_per_query Lekérdezéstár konfigurációs beállítás növelését.
- Egy példa arra, hogy az egyedi tervek száma hogyan lépheti túl az alapértelmezett lekérdezéstár-korlátot max_plans_per_query, egy olyan forgatókönyv, amelyben a következő viselkedést tapasztaljuk. Tegyük fel, hogy 10-es lekérdezésazonosítóval rendelkezik, amely két diszpécsercsomaggal rendelkezik, és mindegyik diszpécsercsomag 20 lekérdezésvariánssal rendelkezik (összesen 40 lekérdezésvariánssal). A 10-es lekérdezésazonosítóhoz tartozó tervek teljes száma 40 terv, amelyek a lekérdezési változatokhoz és a két diszpécser tervhez kapcsolódnak. Az is lehetséges, hogy a szülő lekérdezés (lekérdezés azonosítója: 10) 5 normál (nem diszpécser) tervvel rendelkezhet. Ez 47 tervet készít (40 lekérdezési variánsból, 2 diszpécsertervből és 5, nem PSP-hez kapcsolódó tervből). Továbbá, ha minden lekérdezésvariáns átlagosan öt tervvel rendelkezik, ebben a forgatókönyvben több mint 200 terv lehet a Lekérdezés Tárban egy szülő lekérdezéshez. Ez attól is függ, hogy az adathalmazokban milyen mértékű adatskew fordul elő, amelyekre ez a példa szülőlekérdezés hivatkozhat.
Minden lekérdezésvariáns adott diszpécserre való leképezése esetén:
- A query_plan_hash egyedi. Ez az oszlop elérhető más dinamikus felügyeleti nézetekben és katalógustáblákban sys.dm_exec_query_statsis.
- A plan_handle egyedi. Ez az oszlop elérhető más dinamikus felügyeleti nézetekben sys.dm_exec_query_statssys.dm_exec_sql_textsys.dm_exec_cached_plansés függvényekben, valamint katalógustáblákban.
- Ez query_hash más változatokban, amelyek ugyanarra a diszpécserre mutatnak, gyakori, így meg lehet határozni az összesített erőforrás-használatot azoknál a lekérdezéseknél, amelyek csak a bemeneti paraméterértékekben különböznek. Ez az oszlop a , sys.dm_exec_query_statsés más dinamikus felügyeleti nézetekben és katalógustáblákban sys.query_store_queryérhető el.
- Ez sql_handle azért egyedi, mert a fordítás során speciális PSP-optimalizálási azonosítókat ad hozzá a lekérdezés szövegéhez. Ez az oszlop elérhető más dinamikus felügyeleti nézetekben sys.dm_exec_query_statssys.dm_exec_sql_textsys.dm_exec_cached_plansés függvényekben, valamint katalógustáblákban. A lekérdezéstárban ugyanazok a handle információk érhetők el, mint a last_compile_batch_sql_handle oszlop a sys.query_store_query katalógustáblázatban.
- query_id egyedi a lekérdezéstárban. Ez az oszlop elérhető a lekérdezéstár katalógustábláiban sys.query_store_queryés más lekérdezéstár-táblákban.

Terv kényszerítése a Lekérdezéstárban

Ugyanazokat a sp_query_store_force_plan és sp_query_store_unforce_plan tárolt eljárásokat használja a diszpécser vagy a változó tervek üzemeltetésére.

Ha egy változat kényszerítve van, a szülő diszpécser nem lesz kényszerítve. Ha egy diszpécser kényszerítve van, csak az adott diszpécsertől származó változatok tekinthetők használatra jogosultnak:

A más diszpécserektől korábban kényszerített változatok inaktívvá válnak, de megtartják a kényszerített állapotot, amíg a diszpécser újra nem kényszeríti őket
A korábban ugyanazon diszpécserben inaktívvá vált kényszerített változatokat ismét kényszerítik.

Lekérdezéstár lekérdezési javaslat viselkedése

Ha lekérdezéstár-tippet ad hozzá egy lekérdezésvariánshoz (gyermek lekérdezéshez), a rendszer ugyanúgy alkalmazza a tippet, mint egy nem PSP-lekérdezést. A lekérdezésvariáns-tippek nagyobb elsőbbséget élveznek, ha a lekérdezéstár szülő lekérdezésére is alkalmaztak egy tippet.
Ha egy lekérdezéstár-tippet ad hozzá a szülő lekérdezéshez, és a gyermek lekérdezés (lekérdezésvariáns) nem rendelkezik meglévő lekérdezéstár-tippel, a gyermek lekérdezés (lekérdezésvariáns) örökli a szülő lekérdezéstől származó tippet.
Ha a lekérdezéstár lekérdezési tippje el van távolítva a szülő lekérdezésből, a gyermek lekérdezések (lekérdezésvariánsok) is eltávolítják a tippet.
Ha egy RECOMPILE utasítás hozzá van adva a szülő lekérdezéshez, a rendszer olyan terveket generál, amelyek nem PSP-tartalmúak, miután a meglévő lekérdezésvariáns tervek el lettek távolítva a terv gyorsítótárából, mivel a PSP funkció nem működik azokat a lekérdezéseket, amelyek RECOMPILE utasítást tartalmaznak.
A Lekérdezéstár tipperedményei a kiterjesztett események query_store_hints_application_success és query_store_hints_application_failed események használatával figyelhetők meg. A sys.query_store_query_hints tábla az alkalmazott lekérdezési tippre vonatkozó információkat tartalmazza. Ha a tippet csak szülő lekérdezésre alkalmazták, a rendszerkatalógus a szülő lekérdezés tippinformációit tartalmazza, a gyermek lekérdezésekre azonban nem, bár a gyermek lekérdezések öröklik a szülő lekérdezés tippjét.

A lekérdezési tippeket és a terv kényszerítési viselkedését tartalmazó PSP az alábbi táblázatban foglalható össze:

Lekérdezésvariáns-tipp vagy terv	A szülőnek egy felhasználó által alkalmazott tippje van	A szülő visszajelzési javaslatot kapott	A szülő manuálisan kényszerített tervet használ	A szülő APC ¹ kényszerített csomaggal rendelkezik
Tipp a felhasználón keresztül	Lekérdezési variáns javaslat	Lekérdezési variáns javaslat	Lekérdezési variáns javaslat	N/A
Tipp visszajelzésen keresztül	Lekérdezési variáns javaslat	Lekérdezési variáns javaslat	Lekérdezési variáns javaslat	N/A
Felhasználó által kényszerített terv	Lekérdezésvariáns kényszerített terv	Lekérdezésvariáns kényszerített terv	Lekérdezésvariáns kényszerített terv	Lekérdezésvariáns kényszerített terv
Az APC által kényszerített terv	Lekérdezésvariáns kényszerített terv	Lekérdezésvariáns kényszerített terv	Lekérdezésvariáns kényszerített terv	Lekérdezésvariáns kényszerített terv
Nincs tipp vagy kényszerített terv	A szülő felhasználó tippje	Nincs tipp	Nincs művelet	Nincs művelet

¹ Az automatikus finomhangolási funkció automatikus tervkorrekciós összetevője

Bővített események

parameter_sensitive_plan_optimization_skipped_reason: A paraméterérzékeny terv funkció kihagyásakor fordul elő. Az esemény segítségével figyelheti a PSP-optimalizálás kihagyásának okát.

Az alábbi lekérdezés a PSP kihagyásának lehetséges okait mutatja be:
```
SELECT map_value
FROM sys.dm_xe_map_values
WHERE [name] = 'psp_skipped_reason_enum'
ORDER BY map_key;
```
parameter_sensitive_plan_optimization: Akkor fordul elő, ha egy lekérdezés PSP-optimalizálási funkciót használ. Csak hibakeresési csatorna. Egyes érdeklődési területek a következőek lehetnek:
- is_query_variant: azt írja le, hogy ez egy diszpécsercsomag (szülő) vagy lekérdezésvariáns csomag (gyermek)
- predicate_count: A PSP által kiválasztott predikátumok száma
- query_variant_id: megjeleníti a lekérdezésvariáns azonosítóját. A 0 érték azt jelenti, hogy az objektum egy diszpécserterv (szülő).
query_with_parameter_sensitivity: Az aktivált esemény megjeleníti azoknak a predikátumoknak a számát, amelyeket a funkció érdekesnek talált, további részletek json formátumban az érdekes predikátumokról, valamint arról, hogy a PSPO támogatott-e a predikátumhoz vagy predikátumokhoz.
Példakimenet a query_with_parameter_sensitivity kiterjesztett eseményből

Field	Value
interesting_predicate_count	3
interesting_predicate_details	{"Predicates":[{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75},{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75},{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75}]}
psp_optimization_supported	True
query_type	195

SQL Server auditálási viselkedése

A PSP-optimalizálás audit adatokat biztosít a diszpécser tervutasításhoz, valamint a diszpécserhez társított lekérdezésvariánsokhoz. Az additional_information SQL Server Audit oszlopa a lekérdezési változatok megfelelő T-SQL-veremadatait is szolgáltatja. Ha az MyNewDatabase adatbázist példaként használjuk, és ennek az adatbázisnak van egy T2 nevű táblája, valamint egy usp_test nevű tárolt eljárása, a usp_test tárolt eljárás végrehajtása után a napló a következő bejegyzéseket tartalmazhatja:

action_id	object_name	kimutatás	additional_information
AUSC			`<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data"><session><![CDATA[Audit_Testing_Psp$A]]></session><action>event enabled</action><startup_type>manual</startup_type><object><![CDATA[audit_event]]></object></action_info>`
EX	usp_test	exec usp_test 300
SL	T2	válassza ki * a dbo.t2-ből ahol ID=@id	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
SL	T2	select * from dbo.t2 where ID=@id option (PLAN PER VALUE(ObjectID = 933578364, QueryVariantID = 1, predicate_range([MyNewDatabase].[dbo].[T2].[ID] = @id, 100,0, 100000,0)))	`tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
EX	usp_test	exec usp_test 60000
SL	T2	válassza ki * a dbo.t2-ből ahol ID=@id	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
SL	T2	select * from dbo.t2 where ID=@id option (PLAN PER VALUE(ObjectID = 933578364, QueryVariantID = 3, predicate_range([TestDB_FOR_PSP].[ dbo]. [T2]. [ID] = @id, 100,0, 100000,0)))	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`

Ismert problémák

Issue	Felderített dátum	Status	A megoldás dátuma
A hozzáférés-megsértési kivétel az SQL Server 2022 lekérdezéstárában (16.x) fordul elő bizonyos feltételek mellett. A PSP-optimalizálás lekérdezéstár-integrációjának engedélyezése esetén hozzáférés-megsértési kivételek léphetnek fel. További információkért tekintse meg a paraméterérzékeny terv optimalizálása, miért?	2023 márciusa	Resolved	2023. augusztus (CU 7)
Az SQL Server 2025 -ben (17.x) bizonyos feltételek mellett hozzáférés-megsértési kivétel léphet fel olvasható másodlagos replikákon. Hozzáférés-megsértési kivételek léphetnek fel, ha a PSP optimalizálása engedélyezve van egy olvasható másodlagos adatbázisban, amely úgy van konfigurálva, hogy a Lekérdezéstárat használja az olvasható másodfokú szolgáltatásokhoz .	2025. szeptember	Van áthidaló megoldás

Van áthidaló megoldás

Hozzáférés-megsértési kivétel bizonyos feltételek mellett olvasható másodlagos replikákon is előfordulhat

Az alábbi feltételeknek megfelelő lekérdezéseknél hozzáférés-megsértés fordulhat elő, ha egy PSP-lekérdezésvariáns nem képes meghatározni a szülő diszpécser utasításának tartós állapotát:

A másodlagos replikán hajtották végre
Érzékeny a paraméterszniffingre
Paraméterérzékeny csomag (PSP) optimalizálására jogosult

Megkerülő megoldás: Tiltsa le a PSP-t minden olyan adatbázis másodlagos példányán, amelyet a Lekérdezéstár olvasható másodlagos példányok funkciójának használatára készítettek elő. Egy adott adatbázis kontextusából adja ki a következő Transact-SQL utasítást:

ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY
    SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF;

Resolved

Hozzáférés-megsértési kivétel az SQL Server 2022 lekérdezéstárában fordul elő bizonyos feltételek mellett

Note

Az SQL Server 2022 (16.x) 7. kumulatív frissítése több javítást is kiadott egy versenyfeltételhez, amely hozzáférés-megsértéshez vezethet.

Ez a probléma annak köszönhető, hogy egy versenyállapot lép fel, amikor a végrehajtott lekérdezés futásidejű statisztikáit átviszik a lekérdezéstár (amely a MEMORYCLERK_QUERYDISKSTORE_HASHMAP memóriajegyzőben található) memóriaképéből a lekérdezéstár lemezverziójába. A futásidejű statisztikák a memóriában maradnak egy ideig, amelyet az DATA_FLUSH_INTERVAL_SECONDSSET QUERY_STORE utasítás opciója határoz meg (az alapértelmezett érték 15 perc). A Management Studio Lekérdezéstár párbeszédpanelen megadhatja az adatöblítési időköz (perc) értékét, amelyet a rendszer belsőleg másodpercre konvertál. Ha a rendszer memóriaterhelés alatt áll, a futásidejű statisztikák a beállítással DATA_FLUSH_INTERVAL_SECONDS definiáltnál korábbi lemezre üríthetők. Ha a Lekérdezéstárból történő lekérdezési terv tisztításhoz kapcsolódó háttérszálak (nevezetesen STALE_QUERY_THRESHOLD_DAYS és/vagy MAX_STORAGE_SIZE_MB Lekérdezéstár beállítások) futnak, előfordulhat olyan forgatókönyv, amelyben a lekérdezés variáns és/vagy a hozzá kapcsolódó diszpécser utasítás idő előtt elveszítheti a hivatkozását. Ez hozzáférés-megsértést okozhat a lekérdezési változatok lekérdezéstárba való beszúrása vagy törlése során.

A Lekérdezéstár műveleteivel kapcsolatos további információkért tekintse meg a Lekérdezéstár adatgyűjtése című cikk Megjegyzések szakaszát.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-18

Megosztás a következőn keresztül:

Paraméterérzékeny csomag optimalizálása

A paraméterezés ismertetése

PSP-optimalizálás implementálása

Terminology

Diszpécser kifejezés

Diszpécser terv

Lekérdezésvariáns

Predikátum számosságtartománya

Remarks

Considerations

Terv kényszerítése a Lekérdezéstárban

Lekérdezéstár lekérdezési javaslat viselkedése

Bővített események

SQL Server auditálási viselkedése

Ismert problémák

Van áthidaló megoldás

Hozzáférés-megsértési kivétel bizonyos feltételek mellett olvasható másodlagos replikákon is előfordulhat

Resolved

Hozzáférés-megsértési kivétel az SQL Server 2022 lekérdezéstárában fordul elő bizonyos feltételek mellett

Kapcsolódó tartalom

Visszajelzés

További források