Piani forzati su secondari leggibili

Se un piano viene forzato sul primario in un gruppo di disponibilità, viene applicato alle query eseguite su un secondario?

Sto cercando risposte che coprano entrambe le possibilità per forzare il piano:

Ho letto quanto segue che suggerisce che i piani forzati QS non vengono riportati, ma non riesco a trovare nulla di autorevole nella documentazione o qualcosa sulle guide dei piani.

Negozio di query e gruppi di disponibilità di Erin Stellato
Query Data Store: comportamento del piano forzato su Secondario sempre leggibile di Vikas Rana

Prova conclusiva di forzare sarebbe la presenza di Use Plano PlanGuideNamee PlanGuideDBimmobili a piano di esecuzione del secondario.

— Paul White 9
fonte

La forzatura del piano dell'archivio query NON influisce sulle query sul secondario

L'uso di Query Store per forzare un piano sul primario sembra certamente forzare il piano sul secondario.

Ho provato a eseguire una query su un server non prod e quindi a svuotare l'archivio query con sp_query_store_flush_db(che era necessario per ottenere la sincronizzazione dei dati con il secondario). Ecco il secondario a sinistra (nota l'avvertimento cerchiato di essere "sola lettura") e il primario a destra:

Ora farò clic su "Force Plan" sulla destra, quindi aggiornerò entrambe le visualizzazioni:

Quindi il "forzamento" almeno riportato nelle tabelle del Query Store sottostante. Ciò ha senso, dato che gli articoli citati nel PO sottolineano che il forzare le query dovrebbe rimanere sul posto dopo un failover:

Domanda: QDS manterrà le informazioni del piano FORZED durante il failover del database dalla replica primaria alla replica secondaria?

Risposta: Sì, QDS memorizza le informazioni sul piano forzato nella tabella sys.query_store_plan, quindi in caso di failover continuerai a vedere lo stesso comportamento sul nuovo primario.

Ma il comportamento forzante ha effettivamente luogo? Ora eseguirò la stessa query su entrambi i server. Sul primario, come previsto, l'attributo "UsePlan" è presente nell'XML del piano:

<QueryPlan DegreeOfParallelism="1" MemoryGrant="11096" CachedPlanSize="288" CompileTime="82"
           CompileCPU="78" CompileMemory="2104" UsePlan="true">

E nell'interfaccia utente:

Sul secondario (notare il diverso nome del server), il piano non è stato forzato . Ecco lo stesso snippet XML del piano:

<QueryPlan DegreeOfParallelism="1" MemoryGrant="11096" CachedPlanSize="288" CompileTime="32" 
           CompileCPU="28" CompileMemory="1656">

Le guide di piano NON influiscono sulle query sul secondario

Ho creato una guida di piano sul primario usando questo codice (i nomi delle tabelle sono stati modificati per proteggere gli innocenti):

EXEC sp_create_plan_guide 
    @name = 'plan-guide-test',
    @stmt = N'SELECT TOP (1000) * 
FROM dbo.TableName t 
WHERE 
    NOT EXISTS 
    (
        SELECT NULL 
        FROM dbo.OtherTable o 
        WHERE t.Id = o.TableName
    );',
    @type = N'SQL',
    @module_or_batch = NULL,
    @hints = N'OPTION (MAXDOP 1)';

La guida del piano era, ovviamente, efficace sul primario, come evidenziato dal piano di esecuzione:

<StmtSimple StatementCompId="1" StatementEstRows="1000" ... StatementType="SELECT" 
            PlanGuideDB="..._UAT" PlanGuideName="plan-guide-test" ...>

Ho confermato a questo punto che la guida del piano è stata replicata al secondario.

Eseguendo la stessa query sul secondario, nel piano di esecuzione mancano tutti i segni di essere forzati da una guida di piano:

<StmtSimple StatementCompId="1" StatementEstRows="1000" ... StatementType="SELECT" 
            QueryHash="0xECF8A24F126EE77A" QueryPlanHash="0x0E93CF7FEAC1B6EA" 
            RetrievedFromCache="true" SecurityPolicyApplied="false">

— Josh Darnell
fonte