Erzwungene Pläne für lesbare Secondaries

Wenn ein Plan in einer Verfügbarkeitsgruppe für den primären Plan erzwungen wird, wird er auf Abfragen angewendet, die auf einem sekundären Plan ausgeführt werden?

Ich bin auf der Suche nach Antworten, die beide Möglichkeiten für das Forcen von Plänen abdecken:

Ich habe die folgenden Informationen gelesen, die darauf hindeuten, dass erzwungene QS-Pläne nicht übertragen werden, jedoch keine maßgeblichen Informationen in der Dokumentation oder Informationen zu Planungsleitfäden enthalten.

Abfragegeschäft und Verfügbarkeitsgruppen von Erin Stellato
Erzwungenes Planverhalten für Abfragedatenspeicher auf AlwaysOn Readable Secondary von Vikas Rana

Ein schlüssiger Beweis für das Erzwingen wäre das Vorhandensein von Use Planoder PlanGuideNameund PlanGuideDBEigenschaften im Ausführungsplan des Sekundärs.

— Paul White Monica wieder einsetzen
quelle

Das Forcen von Abfragespeicherplänen wirkt sich NICHT auf Abfragen auf der Sekundärseite aus

Die Verwendung von Query Store zum Erzwingen eines Plans auf der Primärseite sieht mit Sicherheit so aus, als würde der Plan auf der Sekundärseite erzwungen.

Ich habe versucht, eine Abfrage auf einem Nicht-Prod-Server auszuführen und anschließend den Abfragespeicher mit zu leeren sp_query_store_flush_db(was erforderlich war, damit die Daten mit dem sekundären Server synchronisiert werden konnten). Hier ist die sekundäre auf der linken Seite (beachten Sie die eingekreiste Warnung, dass sie "nur lesbar" ist) und die primäre auf der rechten Seite:

Jetzt klicke ich rechts auf "Force Plan" und aktualisiere dann beide Ansichten:

Das "Forcen" wird also zumindest in die zugrunde liegenden Abfragespeichertabellen übertragen. Dies ist sinnvoll, da in den Artikeln, die im OP zitiert werden, darauf hingewiesen wird, dass das Forcen von Abfragen nach einem Failover bestehen bleiben soll:

Frage: Behält QDS die FORCED-Plan-Informationen bei, wenn ein Datenbank-Failover vom primären zum sekundären Replikat durchgeführt wird?

Antwort: Ja, QDS speichert Forced Plan-Informationen in der Tabelle sys.query_store_plan. Im Falle eines Failovers wird das gleiche Verhalten weiterhin auf der neuen Primärdatenbank angezeigt.

Aber ist das Zwingen Verhalten nimmt tatsächlich statt? Ich werde jetzt dieselbe Abfrage auf beiden Servern ausführen. Auf der primären Seite befindet sich, wie erwartet, das Attribut "UsePlan" im Plan-XML:

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

Und in der Benutzeroberfläche:

Auf der Sekundärseite (beachten Sie den anderen Servernamen) wurde der Plan nicht erzwungen . Hier ist das gleiche Plan-XML-Snippet:

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

Planungshandbücher wirken sich NICHT auf Abfragen auf der Sekundärseite aus

Ich habe auf der Primärseite einen Plan-Leitfaden mit diesem Code erstellt (die Tabellennamen wurden geändert, um die Unschuldigen zu schützen):

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

Der Planleitfaden war natürlich in erster Linie wirksam, wie aus dem Ausführungsplan hervorgeht:

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

Ich habe zu diesem Zeitpunkt bestätigt, dass der Planungsleitfaden auf den sekundären repliziert wurde.

Bei der Ausführung derselben Abfrage auf der Sekundärseite fehlen dem Ausführungsplan alle Anzeichen dafür, dass er von einem Planungsleitfaden erzwungen wird:

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

— Josh Darnell
quelle