Принудительные планы на читаемые вторичные

Если план принудительно применяется к первичному в группе доступности, применяется ли он к запросам, выполняемым на вторичном?

Я ищу ответы, которые охватывают обе возможности для составления плана:

• План руководства
• Принудительный план магазина запросов

Я прочитал следующее, в котором говорится, что принудительные планы QS не переносятся, но я не могу найти ничего авторитетного в документации или в руководствах по планам.

• Магазин запросов и группы доступности от Erin Stellato
• Поведение принудительного плана хранилища данных запросов на всегда читаемом вторичном объекте от Vikas Rana

Неопровержимым доказательством принуждения будет наличие Use Planили PlanGuideNameи PlanGuideDBсвойства в плане выполнения вторичного агента.

Форсирование плана хранилища запросов НЕ влияет на запросы на вторичном сервере.

Использование Query Store для принудительного создания плана на первичном сервере, безусловно, выглядит так, будто оно навязывает план вторичному.

Я попытался выполнить запрос на сервере, не sp_query_store_flush_dbявляющемся продуктом, а затем очистить хранилище запросов (что было необходимо для синхронизации данных с дополнительным устройством). Вот вторичный слева (обратите внимание на обведенное кружком предупреждение о том, что он «только для чтения»), и первичный справа:

Теперь я нажму «Force Plan» справа, а затем обновлю оба представления:

Таким образом, «форсирование» по крайней мере переносится в базовые таблицы Query Store. Это имеет смысл, учитывая, что статьи, цитируемые в OP, указывают на то, что форсирование запросов должно оставаться на месте после аварийного переключения:

Вопрос: Будет ли QDS сохранять информацию плана FORCED при переключении базы данных с первичной реплики на вторичную реплику?

Ответ: Да, QDS хранит информацию о принудительном плане в таблице sys.query_store_plan, поэтому в случае сбоя вы продолжите видеть то же поведение на новом первичном сервере.

Но имеет ли место принудительное поведение ? Теперь я выполню один и тот же запрос на обоих серверах. На первичном, как и ожидалось, атрибуте «UsePlan» присутствует в плане XML:

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

И в пользовательском интерфейсе:

На дополнительном сервере (обратите внимание на другое имя сервера) план не был принудительным . Вот тот же план XML-фрагмент:

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

Руководства по планированию НЕ влияют на запросы на вторичном

Я создал руководство плана на основном с использованием этого кода (имена таблиц изменены, чтобы защитить невинных):

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

Руководство плана было, конечно, эффективным на первичном, что подтверждается планом выполнения:

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

В этот момент я подтвердил, что руководство плана было скопировано на вторичное.

При выполнении того же запроса на вторичном сервере план выполнения пропускает все признаки принудительного использования руководством плана:

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