Planos forçados em secundários legíveis

Se um plano for forçado no primário em um Grupo de Disponibilidade, ele será aplicado a consultas executadas em um secundário?

Estou procurando respostas que cubram as duas possibilidades de forçar plano:

Li o seguinte que sugere que os planos forçados do QS não são transferidos, mas não conseguem encontrar nada autoritativo na documentação ou nada sobre os guias de plano.

Grupos de armazenamento e disponibilidade de consulta de Erin Stellato
Comportamento do plano forçado do repositório de dados de consulta no secundário legível AlwaysOn de Vikas Rana

Uma evidência conclusiva de forçar seria a presença de Use Planou PlanGuideNamee PlanGuideDBpropriedades no plano de execução do secundário.

— Paul White 9
fonte

Forçar o plano do Query Store NÃO afeta as consultas no secundário

Usar o Query Store para forçar um plano no primário certamente parece que força o plano no secundário.

Tentei executar uma consulta em um servidor que não é de produção e, em seguida, liberar o armazenamento de consultas sp_query_store_flush_db(que era necessário para sincronizar os dados com o secundário). Aqui está o secundário à esquerda (observe o aviso circulado sobre ser "somente leitura") e o primário à direita:

Agora vou clicar em "Forçar plano" à direita e atualizar as duas visualizações:

Portanto, o "forçar" pelo menos é transportado nas tabelas subjacentes do Query Store. Isso faz sentido, uma vez que os artigos citados no OP enfatizam que o forçamento da consulta deve permanecer no local após um failover:

Pergunta: O QDS reterá as informações do FORCED Plan quando o failover do banco de dados da réplica primária para a réplica secundária?

Resposta: Sim, o QDS armazena as informações do Plano Forçado na tabela sys.query_store_plan, portanto, em caso de failover, você continuará vendo o mesmo comportamento na nova Primária.

Mas o comportamento forçado realmente ocorre? Agora vou executar a mesma consulta nos dois servidores. No primário, como esperado, o atributo "UsePlan" existe no XML do plano:

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

E na interface do usuário:

No secundário (observe o nome do servidor diferente), o plano não foi forçado . Aqui está o mesmo fragmento XML do plano:

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

Os Guias de Plano NÃO afetam as consultas no secundário

Criei um guia de plano no primário usando esse código (os nomes das tabelas foram alterados para proteger os inocentes):

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

O guia do plano foi, é claro, eficaz no primário, como evidenciado pelo plano de execução:

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

Confirmei neste momento que o guia do plano foi replicado para o secundário.

Executando a mesma consulta no secundário, o plano de execução está ausente de todos os sinais de ser forçado por um guia de plano:

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

— Josh Darnell
fonte