Rencana paksa pada sekunder yang dapat dibaca

Jika suatu rencana dipaksakan pada yang utama dalam Grup yang Tersedia, apakah itu diterapkan pada kueri yang dijalankan pada yang sekunder?

Saya mencari jawaban yang mencakup kedua kemungkinan rencana pemaksaan:

Saya telah membaca yang berikut ini yang menyarankan rencana paksa QS tidak terbawa, tetapi tidak dapat menemukan sesuatu yang otoritatif dalam dokumentasi, atau apa pun tentang panduan rencana.

Toko Kueri dan Grup Ketersediaan oleh Erin Stellato
Query Data Store perilaku Rencana Paksa pada AlwaysOn Readable Secondary oleh Vikas Rana

Bukti pemaksaan yang meyakinkan adalah adanya Use Planatau PlanGuideNamedan PlanGuideDBproperti dalam rencana eksekusi sekunder.

sql-server availability-groups execution-plan query-store plan-guides Paul White 9
sumber

Pemaksaan rencana kueri Toko TIDAK memengaruhi kueri di sekunder

Menggunakan Query Store untuk memaksa suatu rencana pada yang utama jelas terlihat seperti memaksa rencana pada yang kedua.

Saya mencoba menjalankan kueri pada server non-prod, dan kemudian membilas toko kueri dengan sp_query_store_flush_db(yang diperlukan untuk mendapatkan data untuk disinkronkan ke sekunder). Berikut yang kedua di sebelah kiri (perhatikan peringatan yang dilingkari tentang menjadi "hanya baca"), dan yang utama di sebelah kanan:

Sekarang saya akan klik "Force Plan" di sebelah kanan, dan kemudian segarkan kedua tampilan:

Jadi "pemaksaan" setidaknya terbawa dalam tabel Toko Kueri yang mendasarinya. Ini masuk akal, mengingat bahwa artikel yang dikutip dalam OP menyatakan bahwa pemaksaan kueri harus tetap di tempatnya setelah terjadi kegagalan:

Pertanyaan: Apakah QDS akan menyimpan informasi FORCED Plan ketika Database gagal dari replika Primer ke Replika sekunder?

Jawaban: Ya, QDS menyimpan informasi Rencana Paksa di tabel sys.query_store_plan, jadi jika terjadi kegagalan, Anda akan terus melihat perilaku yang sama pada Pratama baru.

Tetapi apakah perilaku pemaksaan benar-benar terjadi? Sekarang saya akan menjalankan permintaan yang sama di kedua server. Pada atribut utama, seperti yang diharapkan, atribut "UsePlan" ada dalam XML rencana:

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

Dan di UI:

Pada yang kedua (perhatikan nama server yang berbeda), rencana itu tidak dipaksakan . Berikut cuplikan XML rencana yang sama:

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

Panduan Paket TIDAK mempengaruhi permintaan pada informasi sekunder

Saya membuat panduan paket menggunakan kode ini (nama tabel diubah untuk melindungi yang tidak bersalah):

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

Panduan rencana, tentu saja, efektif pada yang utama, sebagaimana dibuktikan oleh rencana eksekusi:

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

Saya memang mengkonfirmasi pada titik ini bahwa panduan rencana direplikasi ke sekunder.

Menjalankan kueri yang sama pada sekunder, rencana eksekusi kehilangan semua tanda-tanda dipaksa oleh panduan rencana:

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

Josh Darnell
sumber