Примусові плани на читаються вторинники

Якщо план вимушений для основного в групі доступності, чи застосовується він до запитів, запущених на вторинній?

Я шукаю відповіді, які охоплюють обидві можливості примусового плану:

Я прочитав наступне, що дозволяє припустити, що примусові плани щодо управління якістю не переносяться, але не можу знайти нічого авторитетного в документації чи нічого про посібники щодо плану.

Магазин запитів та групи доступності від Ерін Стеллато
Здійснення поведінки в магазині даних запитів на AlwaysOn Readada Secondary від Vikas Rana

Переконливий доказ примусу буде наявністю Use Planабо PlanGuideNameі PlanGuideDBвластивості в плані вторинного виконання - х.

— Пол Білий 9
джерело

Форсинг плану магазинів запитів НЕ впливає на запити на вторинному рівні

Використання магазину запитів для примусового плану на первинному, безумовно, виглядає так, що воно змушує план на другорядне.

Я спробував запустити запит на сервері, який не продає, а потім промити сховище запитів sp_query_store_flush_db(для чого потрібно було синхронізувати дані до вторинного). Ось вторинна ліва (зверніть увагу на кругле попередження про те, що "лише для читання"), і основне праворуч:

Тепер я натискаю "План сили" праворуч, а потім оновлюю обидва види:

Тож "примушування" принаймні переноситься в основні таблиці магазинів запитів. Це має сенс, враховуючи, що статті, що цитуються в ОП, означають, що форсування запитів має залишатися на місці після відмови:

Запитання: Чи збереже 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">

— Джош Дарнелл
джерело