Planes forzados en secundarias legibles

Si un plan se fuerza en el primario en un Grupo de disponibilidad, ¿se aplica a las consultas que se ejecutan en un secundario?

Estoy buscando respuestas que cubran ambas posibilidades para forzar el plan:

He leído lo siguiente que sugiere que los planes forzados de QS no se transfieren, pero no pueden encontrar nada autorizado en la documentación, ni nada sobre guías de planes.

Consulta de tiendas y grupos de disponibilidad por Erin Stellato
Consultar el comportamiento del plan forzado del almacén de datos en AlwaysOn Readable Secondary por Vikas Rana

La evidencia concluyente de forzar sería la presencia de Use Plano PlanGuideNamey PlanGuideDBpropiedades en el plan de ejecución del secundario.

— Paul White 9
fuente

El forzado del plan del almacén de consultas NO afecta las consultas en el secundario

Usar Query Store para forzar un plan en el primario ciertamente parece forzar el plan en el secundario.

Intenté ejecutar una consulta en un servidor no prod y luego enjuagar el almacén de consultas con sp_query_store_flush_db(que era necesario para sincronizar los datos con el secundario). Aquí está el secundario a la izquierda (tenga en cuenta la advertencia en un círculo sobre ser "de solo lectura"), y el primario a la derecha:

Ahora haré clic en "Forzar plan" a la derecha y luego actualizaré ambas vistas:

Por lo tanto, el "forzado" se trasladó al menos en las tablas subyacentes del Almacén de consultas. Esto tiene sentido, dado que los artículos citados en el OP señalan que el forzado de consultas debe permanecer en su lugar después de una conmutación por error:

Pregunta: ¿QDS retendrá la información del Plan FORZADO cuando la conmutación por error de la base de datos de la réplica principal a la réplica secundaria?

Respuesta: Sí, QDS almacena la información del plan forzado en la tabla sys.query_store_plan, por lo que en caso de conmutación por error continuará viendo el mismo comportamiento en el nuevo primario.

Pero, ¿tiene lugar el comportamiento forzado ? Ahora ejecutaré la misma consulta en ambos servidores. En el primario, como se esperaba, el atributo "UsePlan" está en el plan XML:

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

Y en la interfaz de usuario:

En el secundario (tenga en cuenta el nombre del servidor diferente), el plan no fue forzado . Aquí está el mismo fragmento de XML del plan:

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

Las guías de plan NO afectan las consultas en la secundaria

Creé una guía de plan en la primaria usando este código (se cambiaron los nombres de las tablas para proteger a los 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)';

La guía del plan fue, por supuesto, efectiva en la primaria, como lo demuestra el plan de ejecución:

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

Confirmé en este punto que la guía del plan fue replicada a la secundaria.

Al ejecutar la misma consulta en el secundario, al plan de ejecución le faltan todas las señales de ser forzado por una guía de plan:

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

— Josh Darnell
fuente