Optimering av parameterkänslig plan

Gäller för: SQL Server 2022 (16.x) och senare versioner Azure SQL DatabaseAzure SQL Managed InstanceSQL Database i Förhandsversion av Microsoft Fabric

Psp-optimering (Parameter Sensitive Plan) är en del av den intelligenta frågebearbetningsfamiljen med funktioner. Den hanterar scenariot där en enda cachelagrad plan för en parameteriserad fråga inte är optimal för alla möjliga inkommande parametervärden. Detta gäller för icke-enhetliga datadistributioner. För mer information, se Parameterkänslighet och Parametrar och Återanvändning av exekveringsplan.

Mer information om befintliga lösningar för det här problemscenariot finns i:

• Undersöka och lösa parameterkänsliga problem
• Parametrar och återanvändning av körningsplan
• Frågor som har problem med parameterkänslig plan (PSP)

PSP-optimering möjliggör automatiskt flera aktiva cachelagrade planer för en enda parameteriserad instruktion. Cachelagrade körningsplaner rymmer olika datastorlekar baserat på de kundspecifika körningsparametervärdena.

Förstå parameterisering

I SQL Server Database Engine ökar användningen av parametrar eller parametermarkörer i Transact-SQL -instruktioner (T-SQL) relationsmotorns möjlighet att matcha nya T-SQL-instruktioner med befintliga, tidigare kompilerade körningsplaner och främja planomutnytting. Mer information finns i Enkel parameterisering.

Du kan också åsidosätta standardbeteendet för enkel parameterisering för SQL Server genom att ange att alla SELECT, INSERT, UPDATEoch DELETE -instruktioner i en databas är parametriserade, med vissa begränsningar. Mer information finns i Tvingad parameterisering.

Implementering av PSP-optimering

Under den första kompileringen identifierar histogram för kolumnstatistik icke-enhetliga fördelningar och utvärderar de mest riskbelagda parametriserade predikaten, upp till tre av alla tillgängliga predikat. Med andra ord, om flera predikat i samma fråga uppfyller kriterierna väljer PSP-optimering de tre främsta. PSP-funktionen begränsar antalet predikat som utvärderas för att undvika att överbelasta plancachen och Query Store (om Query Store är aktiverat) med för många planer.

För berättigade planer skapar den första kompileringen en dispatcher-plan som innehåller PSP-optimeringslogik som kallas ett dispatcher-uttryck. En dispatcherplan kartlägger till frågevarianter baserat på predikaten för kardinalitetsområdets gränsvärden.

Terminology

Dispatcher-uttryck

Utvärderar kardinaliteten för predikat baserat på körningsparametervärden och dirigera körning till olika frågevarianter.

Dispatcherplan

En plan som innehåller dispatcher-uttrycket cachelagras för den ursprungliga frågan. Dispatcher-planen är i princip en samling predikat som har valts av funktionen, med några extra detaljer. För varje predikat som väljs ingår viss information i dispatcherplanen, nämligen de höga och låga gränsvärdena. Dessa värden används för att dela in parametervärden i olika bucketar eller intervall. Dispatcher-planen innehåller också den statistik som användes för att beräkna gränsvärdena.

Frågevariant

När en dispatcher-plan utvärderar kardinaliteten för predikat baserat på värden från körningsparametrar, indelar den dessa värden i kategorier och genererar separata underordnade frågor för kompilering och körning. Dessa barnfrågor kallas frågevarianter. Frågevarianter har sina egna planer i plancachen och i Query Store.

Predikat kardinalitetsområde

Vid körning utvärderas kardinaliteten för varje predikat baserat på körningsparametervärden. Dispatcher delar in kardinalitetsvärdena i tre predikatkardinalitetsintervall vid kompileringstiden. Psp-optimeringsfunktionen kan till exempel skapa tre intervall som representerar låga, medelstora och höga kardinalitetsintervall, enligt följande diagram.

Med andra ord, när en parametriserad fråga först kompileras genererar PSP-optimeringsfunktionen en skalplan som kallas för en dispatcher-plan. Dispatcher-uttrycket har logiken som bucketiserar frågor till frågevarianter baserat på körningsvärdena för parametrar. När den faktiska körningen börjar utför dispatchern två steg:

• dispatchern utvärderar sitt dispatcher-uttryck för den angivna uppsättningen parametrar för att beräkna kardinalitetsintervallet.

• dispatcher mappar dessa intervall till specifika frågevarianter och kompilerar och kör varianterna. Med hjälp av flera frågevarianter uppnår PSP-optimeringsfunktionen flera planer för en enda fråga.

Gränserna för kardinalitetsintervallet kan ses i ShowPlan XML för en leveransplan:

<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>

Ett PSP-optimeringsgenererat tips läggs till i SQL-instruktionen i ShowPlan XML för en frågevariant. Tipset kan inte användas direkt och parsas inte om det läggs till manuellt. Tipset innehåller följande element:

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

• ObjectID kommer från modulen (dvs. lagrad procedur, funktion, utlösare) som den aktuella instruktionen är en del av; med antagandet att -instruktionen har genererats från en modul. Om -instruktionen är resultatet av dynamisk eller ad hoc SQL (dvs sp_executesql. ) är ObjectID-elementet lika med 0.
• QueryVariantID motsvarar ungefär kombinationen av intervall för alla predikat som PSP-optimering har valt. Om en fråga till exempel har två predikat som är berättigade till PSP och varje predikat har tre intervall, kommer det att finnas nio frågevariantintervall numrerade 1–9.
• predikatintervallet är den predikaterade kardinalitetsintervallinformationen som genereras från dispatcher-uttrycket.

Och inom ShowPlan XML för en frågevariant (inom Dispatcher-elementet):

<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

• Från och med SQL Server 2025 (17.x) Förhandsversion och databaskompatibilitet 170 innehåller PSP-optimering följande fyra förbättringar:

  • Stöd för DML-instruktioner (Data Manipulation Language) för datamanipulering, till exempel DELETE, INSERT, MERGE och UPDATE.
  • Utökat stöd för tempdb.
  • Ytterligare övervägande ges i scenarier där flera berättigade predikat finns i samma tabell.
  • Ändringar i den query_with_parameter_sensitivity utökade händelsen som inkluderade fälten interesting_predicate_count, max_skewness, psp_optimization_supported och query_type före ändringarna i SQL Server 2025 (17.x) Förhandsversion och databaskompatibilitet 170. Men ta nu med fälten interesting_predicate_count, interesting_predicate_details, psp_optimization_supported och query_type. Mer information finns i avsnittet Utökade händelser .

• PSP-optimeringsfunktionen fungerar för närvarande endast med likhetspredikat.

• Dispatcherplaner återskapas automatiskt om det sker betydande ändringar i datadistributionen. Frågevariantplaner rekompileras oberoende vid behov, precis som andra frågeplanstyper, beroende på standardhändelser för omkompilering. Mer information om rekompilering finns i Rekompilera exekveringsplaner.

• Systemkatalogvyn sys.query_store_plan för Query Store har ändrats för att skilja mellan en normalt kompilerad plan, en dispenserplan och en frågevariantplan. Den nya systemkatalogvyn för Query Store, sys.query_store_query_variant, innehåller information om förhållandet mellan de ursprungliga parametriserade frågorna (även kända som föräldrafrågor), distributionsplaner och deras underordnade frågevarianter.

• När det finns flera predikat som ingår i samma tabell väljer PSP-optimering det predikat som har mest datasnedvridning baserat på det underliggande statistik histogrammet. Till exempel med SELECT * FROM table WHERE column1 = @predicate1 AND column2 = @predicate2, eftersom både column1 = @predicate1 och column2 = @predicate2 kommer från samma tabell, table1utvärderas endast det mest skeva predikatet av funktionen. Men om exempelfrågan involverar en operator, till exempel en UNION, utvärderar PSP mer än ett predikat. Om en fråga till exempel har egenskaper som liknar SELECT * FROM table WHERE column1 = @predicate UNION SELECT * FROM table WHERE column1 = @predicateväljer PSP högst två predikater i det här fallet, eftersom systemet behandlar det här scenariot som om de vore två olika tabeller. Samma beteende kan ses i förfrågningar som självansluter via tabellalias.

• ShowPlan XML för en frågevariant skulle se ut ungefär som i följande exempel, där båda predikaten som valts har sin respektive information tillagd till den PLAN PER VALUE PSP-relaterade ledtråden.

  <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">
  

• Du kan påverka de aktuella tröskelvärdena för skevhet som används av PSP-optimeringsfunktionen med en eller flera av följande metoder:

  • Spårningsflaggor för kardinalitetsestimator (CE), till exempel spårningsflagga 9481 (global, session eller frågenivå)

  • Databasomfattande konfigurationsalternativ som försöker sänka CE-modellen som används eller påverka de antaganden som CE-modellen gör när det gäller oberoendet för flera predikater. Detta är särskilt användbart i fall där statistik med flera kolumner inte finns, vilket påverkar PSP-optimeringens förmåga att utvärdera kandidaturen för dessa predikater.

  • Mer information finns i avsnittet Increased Correlation Assumption for Multiple Predicates (Ökat korrelationsantagande för flera predikater) i vitboken Optimera dina frågeplaner med SQL Server 2014 Cardinality Estimator . Den nyare CE-modellen försöker anta en viss korrelation och mindre oberoende för konjunktion och disjunktion av predikat. Användning av den äldre CE-modellen kan påverka hur selektiviteten för predikaten i ett scenario med flera kolumner kan beräknas. Den här åtgärden bör endast övervägas för specifika scenarier och vi rekommenderar inte att du använder den äldre CE-modellen för de flesta arbetsbelastningar.

• PSP-optimering kompilerar och kör för närvarande varje frågevariant som en ny förberedd instruktion, vilket är en av anledningarna till att frågevarianterna förlorar sin koppling till överordnade moduler om object_id dispatcher-planen baserades på en modul (det vill: lagrad procedur, utlösare, funktion, vy och så vidare). Som en förberedd instruktion är object_id inte något som kan mappas direkt till ett objekt i sys.objects, utan är i huvudsak ett beräknat värde baserat på en intern hash för batchtexten. Mer information finns i avsnittet Returnerad tabell i sys.dm_exec_plan_attributes DMV-dokumentationen.

  Frågevariantplaner placeras i objektarkivet för plancache (CACHESTORE_OBJCP) medan avsändarplaner placeras i SQL Plans cachelager (CACHESTORE_SQLCP). PSP-funktionen kommer dock att lagra object_id av en frågevariants förälder inom ObjectID-attributet som ingår i hintet PLAN PER VALUE, som PSP lägger till i ShowPlan XML, om den överordnade frågan är en del av en modul och inte en dynamisk eller uppsatt T-SQL-förfrågan. Sammanställd prestandastatistik för cachelagrade procedurer, funktioner och utlösare kan fortsätta att användas för respektive ändamål. Mer körningsrelaterad statistik på detaljnivå, som den som finns i vyer som liknar sys.dm_exec_query_stats DMV, innehåller fortfarande data för frågevarianter; dock är associationen object_id för frågevarianter och objekt i sys.objects-tabellen är för närvarande inte i linje, utan ytterligare bearbetning av ShowPlan XML för var och en av de frågevarianter där mer detaljerad statistik krävs. Information om körnings- och väntestatistik för frågevarianter kan hämtas från Query Store utan ytterligare ShowPlan XML-parsningstekniker om Query Store är aktiverat.

• Eftersom PSP-frågevarianter körs som en ny förberedd instruktion object_id exponeras inte automatiskt i de olika plancacherelaterade sys.dm_exec_* DMV:erna utan att strimla ShowPlan XML och tillämpa matchningstekniker för textmönster (det vill:s ytterligare XQuery-bearbetning). Endast PSP-optimeringsdistributionsplaner genererar för närvarande lämpligt föräldraobjekt-ID. object_id Exponeras i Query Store, eftersom Query Store tillåter en mer relationsmodell än vad som anges i hierarkin för plancache. Mer information finns i frågearkivets katalogvy sys.query_store_query_variant.

Considerations

• Aktivera PSP-optimering genom att aktivera databaskompatibilitetsnivå 160 för databasen som du är ansluten till när du kör frågan.

• För ytterligare insikter om PSP-optimeringsfunktionen rekommenderar vi att Query Store-integrering aktiveras genom att aktivera Query Store. I följande exempel aktiveras Query Store för en befintlig databas med namnet MyNewDatabase:

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

• Om du vill inaktivera PSP-optimering på databasnivå använder du konfigurationen ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF med databasomfattning.

• Om du vill inaktivera PSP-optimering på frågenivå använder du frågetipset DISABLE_PARAMETER_SENSITIVE_PLAN .

• Om parametersniffning inaktiveras av spårningsflagga 4136, PARAMETER_SNIFFING databasomfattande konfiguration eller USE HINT('DISABLE_PARAMETER_SNIFFING') frågetipset inaktiveras PSP-optimering för associerade arbetsbelastningar och körningskontexter. Mer information finns i Frågetips och ÄNDRA DATABASOMFATTNINGSKONFIGURATION.

• Antalet unika planvarianter per dispatcher som lagras i plancachen är begränsat för att undvika överbelastning av cachen. Det interna tröskelvärdet är inte dokumenterat. Eftersom varje SQL-batch har potential att skapa flera planer, och varje frågevariantplan har en oberoende post i plancachen, är det möjligt att nå det maximala standardantalet tillåtna planposter. Om borttagningshastigheten för plancache är märkbart hög eller om storlekarna på CACHESTORE_OBJCPCACHESTORE_SQLCP är för stora, bör du överväga att använda spårningsflagga 174.

• Antalet unika planvarianter som lagras för en fråga i Query Store-arkivet begränsas av konfigurationsalternativet max_plans_per_query . Eftersom frågevarianter kan ha fler än en plan kan totalt 200 planer finnas per fråga i Query Store. Det här talet innehåller alla frågevariantplaner för alla dispatchers som tillhör en överordnad fråga. Överväg att öka konfigurationsalternativet max_plans_per_query för Query Store.

  • Ett exempel på hur antalet unika planer kan överskrida standardgränsen för Query Store max_plans_per_query är ett scenario där du har följande beteende. Anta att du har en fråga med fråge-ID:t 10, som har två dispatcher-planer och varje dispatcher-plan har 20 frågevarianter vardera (totalt 40 frågevarianter). Det totala antalet planer för fråge-ID 10 är 40 planer för frågevarianterna och de två dispatcher-planerna. Det är också möjligt att den överordnade frågan (fråge-ID 10) kan ha 5 vanliga (icke-dispatcher)-planer. Detta gör 47 planer (40 från frågevarianter, 2 dispatcher och 5 icke-PSP-relaterade planer). Om varje frågevariant också har ett genomsnitt på fem planer är det dessutom möjligt i det här scenariot att ha fler än 200 planer i Query Store för en överordnad fråga. Detta beror också på stora datasnedvridningar i datauppsättningarna som den överordnade exempelfrågan kan referera till.

• För varje frågevariantmappning till en viss dispatcher:

  • Den query_plan_hash är unik. Den här kolumnen är tillgänglig i sys.dm_exec_query_stats, och andra dynamiska hanteringsvyer och katalogtabeller.
  • Den plan_handle är unik. Den här kolumnen är tillgänglig i sys.dm_exec_query_stats, sys.dm_exec_sql_text, sys.dm_exec_cached_plansoch i andra dynamiska hanteringsvyer och funktioner samt katalogtabeller.
  • query_hash Är vanligt för andra varianter som mappas till samma dispatcher, så det är möjligt att fastställa aggregerad resursanvändning för frågor som endast skiljer sig åt med indataparametervärden. Den här kolumnen är tillgänglig i sys.dm_exec_query_stats, sys.query_store_queryoch andra dynamiska hanteringsvyer och katalogtabeller.
  • sql_handle Är unikt på grund av att särskilda PSP-optimeringsidentifierare läggs till i frågetexten under kompilering. Den här kolumnen är tillgänglig i sys.dm_exec_query_stats, sys.dm_exec_sql_text, sys.dm_exec_cached_plansoch i andra dynamiska hanteringsvyer och funktioner samt katalogtabeller. Samma referensinformation är tillgänglig i Query Store som kolumnen last_compile_batch_sql_handle i katalogtabellen sys.query_store_query.
  • query_id är unikt i Query Store. Den här kolumnen är tillgänglig i sys.query_store_query, och andra Query Store-katalogtabeller.

Planera framtvingande i Query Store

Använder samma sp_query_store_force_plan och sp_query_store_unforce_plan lagrade procedurer för att hantera dispatcher- och variantplaner.

Om en variant tvingas tvingas inte den överordnade dispatchern. Om en dispatcher tvingas, kommer endast varianter från den dispatchern att anses godkända för användning.

• Tidigare framtvingade varianter från andra distributörer blir inaktiva men behåller den framtvingade statusen tills deras distributör tvingas igen
• De varianter som tidigare hade tvingats fram i samma dispatcher och blivit inaktiva tvingas fram igen.

Frågebutikens frågetipsbeteende

• När ett Query Store-tips läggs till i en frågevariant (underordnad fråga) tillämpas tipset på samma sätt som en icke-PSP-fråga. Frågevarianttips har högre prioritet om ett tips också har tillämpats på den överordnade frågan i Query Store.

• När ett Query Store-tips läggs till i den överordnade frågan och den underordnade frågan (frågevarianten) inte har ett befintligt Query Store-tips ärver den underordnade frågan (frågevarianten) tipset från den överordnade frågan.

• Om ett frågetips för Query Store tas bort från den överordnade frågan tas även de underordnade frågorna (frågevarianterna) bort.

• Om en RECOMPILE ledtråd läggs till i huvudfrågan genererar systemet icke-PSP-planer efter att befintliga frågevariantplaner har tagits bort från plancachen, eftersom PSP-funktionen inte fungerar på frågor som har en RECOMPILE ledtråd.

• Frågearkivets tipsresultat kan observeras med hjälp av utökade händelser query_store_hints_application_success och query_store_hints_application_failed händelser. För tabellen sys.query_store_query_hints innehåller den information om frågetipset som har tillämpats. Om tipset bara har tillämpats på en överordnad fråga innehåller systemkatalogen tipsinformationen för den överordnade frågan, men inte för dess underordnade frågor, även om de underordnade frågorna ärver den överordnade frågans tips.

PSP med frågehintar och planforceringsbeteende kan sammanfattas i följande tabell:

¹ Automatisk plankorrigeringskomponent för funktionen för automatisk justering

Utökade händelser

• parameter_sensitive_plan_optimization_skipped_reason: Inträffar när funktionen för parameterkänslig plan hoppas över. Använd den här händelsen för att övervaka orsaken till att PSP-optimering hoppar över.

  Följande fråga visar alla möjliga orsaker till varför PSP hoppades över:

  SELECT map_value
  FROM sys.dm_xe_map_values
  WHERE [name] = 'psp_skipped_reason_enum'
  ORDER BY map_key;
  

• parameter_sensitive_plan_optimization: Inträffar när en fråga använder PSP-optimeringsfunktionen. Endast felsökningskanal. Vissa intressanta områden kan vara:

  • is_query_variant: beskriver om det här är en dispatcher-plan (överordnad) eller en frågevariantplan (underordnad)
  • predicate_count: antal predikater som valts av PSP
  • query_variant_id: visar frågevariant-ID:t. Värdet 0 innebär att objektet är en dispatcher-plan (överordnad).

• query_with_parameter_sensitivity: Den här händelsen när den utlöses visar antalet predikat som funktionen fann intressant, mer information i json-format om de intressanta predikaten, samt om PSPO stöds för predikatet eller predikaten.

• Exempel på utdata från den query_with_parameter_sensitivity utökade händelsen

SQL Server-granskningsbeteende

PSP-optimering tillhandahåller granskningsdata för dispatcher-planinstruktionen och de eventuella frågevarianter som är associerade med dispatchern. Kolumnen additional_information i SQL Server Audit innehåller också lämplig T-SQL-stackinformation för frågevarianter. Om databasen MyNewDatabase till exempel har en tabell med namnet T2 och en lagrad procedur med namnet , efter körningen av usp_testden usp_test lagrade proceduren, kan granskningsloggen innehålla följande poster:

Kända problemområden

Har lösning

Undantag för åtkomstöverträdelse kan inträffa på läsbara sekundära repliker under vissa villkor

Frågor som uppfyller följande villkor kan uppleva en åtkomstöverträdelse när en PSP-frågevariant inte kan fastställa det bevarade tillståndet för dess överordnade dispatcher-instruktion:

• Körs på en sekundär replik
• Känslig för parametersniffning
• Berättigad till optimering av parameterkänslig plan (PSP)

Lösning: Inaktivera PSP på sekundärfiler för varje databas som registrerades för att använda Query Store för läsbara sekundärfiler. I kontexten för en specifik databas utfärdar du följande Transact-SQL-instruktion:

ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY
    SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF;

Resolved

Undantag för åtkomstöverträdelse inträffar i Query Store i SQL Server 2022 under vissa villkor

Det här problemet inträffade på grund av ett konkurrenstillstånd som kan orsakas när körningsstatistiken för en körd fråga i Query Store sparas från minnesrepresentationen av Query Store (finns i minnesarkivet MEMORYCLERK_QUERYDISKSTORE_HASHMAP) till diskversionen av Query Store. Körningsstatistiken, som visas som Körningsstatistik, sparas i minnet under en tidsperiod, definierad av DATA_FLUSH_INTERVAL_SECONDS alternativet för -instruktionen SET QUERY_STORE (standardvärdet är 15 minuter). Du kan använda dialogrutan Management Studio Query Store för att ange ett värde för dataspolningsintervall (minuter), som konverteras internt till sekunder. Om systemet är under minnesbelastning kan körningsstatistik rensas till disken tidigare än vad som definierats med DATA_FLUSH_INTERVAL_SECONDS alternativet. När ytterligare Query Store-bakgrundstrådar relaterade till borttagning av frågeplaner i Query Store (d.v.s STALE_QUERY_THRESHOLD_DAYS och/eller MAX_STORAGE_SIZE_MB Query Store-alternativ) utför frågor från Query Store, finns det ett scenario där en frågevariant och/eller dess associerade dispatcher-instruktion kan avrefereras för tidigt. Detta kan leda till en åtkomstöverträdelse vid infogning eller borttagning av frågevarianter i Query Store.

Mer information om Query Store-åtgärder finns i avsnittet Anmärkningar i artikeln Hur Query Store samlar in data.

Relaterat innehåll

• Återkompilera körningsplaner
• Parametrar och återanvändning av körningsplan
• Enkel parameterisering
• Tvingad parameterisering
• Frågetips (Transact-SQL)
• Intelligent frågebearbetning i SQL-databaser
• Parameterkänslighet
• ÄNDRA DATABASOMFATTNINGSKONFIGURATION (Transact-SQL)