Lekérdezéstár olvasható másodtárakhoz

A következőkre vonatkozik: SQL Server 2025 (17.x) Azure SQL Database

Az olvasható másodpéldányok lekérdezéstára lehetővé teszi a Lekérdezéstár elemzéseit a másodlagos replikákon futó számítási feladatokhoz. Ha engedélyezve van, a másodlagos replikák a lekérdezések végrehajtási adatait (például futásidejű és várakozási statisztikákat) továbbítják az elsődleges replikára, ahol az adatok megmaradnak a Lekérdezéstárban, és az összes replikán láthatóvá válik.

Platformtámogatás

Jelenleg az olvasható másodlagos fájlok lekérdezéstára funkció érhető el és támogatott éles környezetben az SQL Server 2025-ben (17.x), valamint az Azure SQL Database-ben. Az SQL Server 2025 -től (17.x) kezdve az Azure SQL Database-ben alapértelmezés szerint engedélyezve van az olvasható másodlagos fájlok lekérdezéstára.

Az SQL Server 2022 -ben (16.x) az olvasható másodtárak lekérdezéstára előzetes verzióban marad, ezért éles környezetben nem támogatott, és alapértelmezés szerint le van tiltva. Ahhoz, hogy a Lekérdezéstár csak az SQL Server 2022 (16.x) olvasható másodpéldányai számára legyen engedélyezve, engedélyezni kell az 12606-os nyomkövetési jelzőt az elsődleges és az összes olvasható másodlagos replikán. A 12606-os nyomjelző zászló nem ajánlott az SQL Server 2022 (16.x) alapú éles telepítésekhez. További információ: SQL Server 2022 kibocsátási megjegyzések. Az SQL Server 2025 (17.x) esetében alapértelmezés szerint be van kapcsolva az olvasható másodlagos fájlok lekérdezéstára funkció.

Az Azure SQL Database automatikusan regisztrálja és engedélyezi az összes adatbázist, hogy támogassa a Lekérdezéstár olvasható másodosztályok funkcióját a támogatott szolgáltatási szinteken és a magas rendelkezésre állási forgatókönyvekben. Ez a funkció jelenleg nem támogatott az Azure SQL Database rugalmas skálázásában.

Ez a funkció jelenleg nem támogatott a Felügyelt Azure SQL-példányban vagy a Microsoft Fabric SQL-adatbázisban.

Támogatott magas rendelkezésre állási forgatókönyvek

Mielőtt egy SQL Server 2025(17.x) példány olvasható másodpéldányaihoz használja a Lekérdezéstárat, konfigurálnia kell egy Always On rendelkezésre állási csoportot .
Az Azure SQL Database esetében az olvasható másodfokú lekérdezéstár a következő szolgáltatási szinteket támogatja:
- Általános célú aktív georeplikációs szolgáltatás (nincsenek beépített magas rendelkezésre állású replikák; a másodlagos támogatáshoz georeplikációs konfiguráció szükséges)
- Prémium (beépített magas rendelkezésre állású replikákat is tartalmaz; aktív georeplikálás is támogatott)
- Üzleti szempontból kritikus (beépített magas rendelkezésre állású replikákat is tartalmaz; az aktív georeplika is támogatott)

A Lekérdezéstár engedélyezése olvasható másodtárakhoz

Ha a Lekérdezéstár még nincs engedélyezve és nincs READ_WRITE módban az elsődleges replikán, a folytatás előtt engedélyeznie kell. Hajtsa végre a következő szkriptet az elsődleges replikán található összes kívánt adatbázishoz:

ALTER DATABASE [Database_Name]
    SET QUERY_STORE = ON(OPERATION_MODE = READ_WRITE);

Ha engedélyezni szeretné a lekérdezéstárat az összes olvasható másodsorban, csatlakozzon az elsődleges replikához, és hajtsa végre a következő szkriptet minden olyan adatbázishoz, amely a funkció használatához fel lesz sorolva.

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_WRITE);

Automatikus tervkorrekció engedélyezése másodlagos replikákhoz

A következőkre vonatkozik: SQL Server 2022 (16.x) és újabb verziók, Azure SQL Database.

Miután engedélyezte a Query Store funkciót a másodlagos replikák esetében, opcionálisan engedélyezheti az automatikus hangolást, hogy lehetővé tegye az automatikus tervkorrekciós funkcióval a tervek kényszerítését a másodlagos replikákon. Így a lekérdezésoptimalizáló automatikusan azonosíthatja és kijavíthatja a végrehajtási terv regressziói által okozott lekérdezési teljesítményproblémákat a másodlagos replikákon.

A másodlagos replikák automatikus tervkorrekciójának engedélyezéséhez csatlakozzon az elsődleges replikához, és hajtsa végre a következő szkriptet minden egyes kívánt adatbázishoz:

ALTER DATABASE [Database_Name]
FOR SECONDARY
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);

Lekérdezéstár letiltása másodlagos replikákhoz

Ha le szeretné tiltani a másodlagos replikák lekérdezéstárát az összes másodlagos replikán, csatlakozzon a master replika primary adatbázisához, és hajtsa végre a következő szkriptet minden egyes kívánt adatbázishoz:

ALTER DATABASE [Database_Name]
    FOR SECONDARY
    SET QUERY_STORE = ON
    (OPERATION_MODE = READ_ONLY);

Ellenőrizze, hogy a lekérdezéstár engedélyezve van-e a másodlagos replikákon.

Ellenőrizze, hogy a Lekérdezéstár engedélyezve van-e egy secondary replikán, ha csatlakozik a másodlagos replika adatbázisához, és végrehajtja a következő T-SQL-utasítást:

SELECT desired_state_desc,
       actual_state_desc,
       readonly_reason
FROM sys.database_query_store_options;

A sys.database_query_store_options katalógusnézet lekérdezésének eredményei jelzik, hogy a lekérdezéstár tényleges állapota READ_CAPTURE_SECONDARY, és readonly_reason értéke 8.

`desired_state_desc`	`actual_state_desc`	`readonly_reason`
`READ_CAPTURE_SECONDARY`	`READ_CAPTURE_SECONDARY`	`8`

Megjegyzések

Terminológia

A replikakészlet egy adatbázis olvasási/írási replikájából (elsődleges) és egy vagy több írásvédett replikából (másodlagos) áll, logikai egységként kezelve őket. Ebben a kontextusban egy szerepkör egy adott replika szerepkörére utal. Amikor egy replika az elsődleges szerepkörben szolgál, az olvasási/írási replika képes adatmódosításokat és olvasási tevékenységeket végezni. Ha egy replika úgy van konfigurálva, hogy csak olvasási tevékenységet végezzen, másodlagos szerepkörben (másodlagos, geo másodlagos, geo ha másodlagos) működik. A szerepkörök tervezett vagy nem tervezett feladatátvételi eseményeken keresztül változhatnak, ha ez történik, az elsődleges szerepkör másodlagossá vagy fordítva válhat.

A jelenleg támogatott szerepkörök a következők:

Primary
Secondary
Geo másodlagos egység
Geo HA másodlagos
Elnevezett replika

Hogyan működik?

A lekérdezésekről tárolt adatok szerepköralapú számítási feladatként elemezhetők. Az olvasható másodpéldányok lekérdezéstárában figyelheti a másodlagos replikákon végrehajtható egyedi, írásvédett számítási feladatok teljesítményét. Az adatok a szerepkör szintjén összesítve lesznek. Az SQL Server elosztott rendelkezésre állási csoportok konfigurációja például a következőkből állhat:

Egy elsődleges replika, az 1. rendelkezésre állási csoport része (AG1)
Két helyi másodlagos replika, szintén az AG1 része
Egy távoli elsődleges replika egy másik helyen, amely egy külön rendelkezésre állási csoport (AG2) része. Az SQL Server terminológiája szerint ezt gyakran globális továbbítóként is emlegetik, azonban az olvasható másodpéldányok lekérdezéstára funkció ezt Geo secondary replikaként fogja felismerni és hivatkozni rá, feltéve, hogy földrajzilag elosztott másodlagos replikáról van szó.

Ha az AG1 és az AG2 úgy van konfigurálva, hogy írásvédett kapcsolatokat engedélyezzen, amikor egy írásvédett számítási feladat az AG1 másodlagos replikáin fut, a lekérdezéstár végrehajtási statisztikáit a rendszer elküldi az AG1 elsődleges replikájára, és összesíti és megőrzi a szerepkörből secondary létrehozott adatokat, mielőtt az adatok vissza lesznek küldve az összes másodlagos replikára, beleértve az AG2 globális továbbítóját is. Ha egy külön számítási feladatot hajt végre az AG2 elsődleges replikáján, a globális átirányító az adatokat visszaküldi az AG1 elsődleges replikájába, és azokat úgy tárolja, mint amelyeket a Geo secondary szerepkörből generáltak.

Megfigyelhetőség szempontjából a sys.query_store_runtime_stats rendszerkatalógus nézete ki van terjesztve annak a szerepkörnek a azonosításához, ahonnan a végrehajtási statisztikák származnak. Kapcsolat van a nézet és a sys.query_store_replicas rendszerkatalógus nézet között, amely a szerepkör barátságosabb nevét is megadhatja. Az SQL Serverben a replica_name oszlop NULL. Az replica_name oszlop azonban akkor lesz feltöltve a Hyperscale szolgáltatási szinthez, ha van egy nevesített replika, és írásvédett számítási feladatokhoz használják.

Példa egy T-SQL-lekérdezésre, amely az elmúlt 8 óra 50 lekérdezésének átfogó elemzésére használható, amely az összes replikából felhasznált CPU-erőforrásokat:

-- Top 50 queries by CPU across all replicas in the last 8 hours
DECLARE @hours AS INT = 8;

SELECT TOP 50 qsq.query_id,
              qsp.plan_id,
              CASE qrs.replica_group_id WHEN 1 THEN 'PRIMARY' WHEN 2 THEN 'SECONDARY' WHEN 3 THEN 'GEO SECONDARY' WHEN 4 THEN 'GEO HA SECONDARY' ELSE CONCAT('NAMED REPLICA_', qrs.replica_group_id) END AS replica_type,
              qsq.query_hash,
              qsp.query_plan_hash,
              SUM(qrs.count_executions) AS sum_executions,
              SUM(qrs.count_executions * qrs.avg_logical_io_reads) AS total_logical_reads,
              SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) AS total_cpu_ms,
              AVG(qrs.avg_logical_io_reads) AS avg_logical_io_reads,
              AVG(qrs.avg_cpu_time / 1000.0) AS avg_cpu_ms,
              ROUND(TRY_CAST (SUM(qrs.avg_duration * qrs.count_executions) AS FLOAT) / NULLIF (SUM(qrs.count_executions), 0) * 0.001, 2) AS avg_duration_ms,
              COUNT(DISTINCT qsp.plan_id) AS number_of_distinct_plans,
              qsqt.query_sql_text
FROM sys.query_store_runtime_stats_interval AS qsrsi
     INNER JOIN sys.query_store_runtime_stats AS qrs
         ON qrs.runtime_stats_interval_id = qsrsi.runtime_stats_interval_id
     INNER JOIN sys.query_store_plan AS qsp
         ON qsp.plan_id = qrs.plan_id
     INNER JOIN sys.query_store_query AS qsq
         ON qsq.query_id = qsp.query_id
     INNER JOIN sys.query_store_query_text AS qsqt
         ON qsq.query_text_id = qsqt.query_text_id
WHERE qsrsi.start_time >= DATEADD(HOUR, -@hours, GETUTCDATE())
GROUP BY qsq.query_id, qsq.query_hash, qsp.query_plan_hash, qsp.plan_id, qrs.replica_group_id, qsqt.query_sql_text
ORDER BY SUM(qrs.count_executions * qrs.avg_cpu_time / 1000.0) DESC, AVG(qrs.avg_cpu_time / 1000.0) DESC;

Az SQL Server Management Studio (SSMS) 21-es és újabb verzióiban található Lekérdezéstár-jelentések egy replika legördülő listát biztosítanak, amely lehetővé teszi a lekérdezéstár adatainak megtekintését különböző replikakészletek/szerepkörök között. Az Objektumkezelő nézeten belül a Lekérdezéstár csomópont a Lekérdezéstár aktuális állapotát (azaz READ_CAPTURE_SECONDARY) tükrözi, ha olvasható másodlagos replikához csatlakozik.

Lekérdezéstár olvasható másodfokú telemetriához az Azure SQL Database-ben

A következővonatkozik: Azure SQL Database

Amikor a Lekérdezéstár futtatókörnyezeti statisztikáit az Azure diagnosztikai beállításain keresztül streameli, a rendszer két oszlopot tartalmaz a telemetriai adatok replikaforrásának azonosításához:

is_primary_b: Logikai érték, amely azt jelzi, hogy az adatok az elsődleges replikából (igaz) vagy másodlagos replikából származnak-e (hamis)
replica_group_id: A replikaszerepkörnek megfelelő egész szám

Ezek az oszlopok nélkülözhetetlenek a metrikák és a teljesítményadatok egyértelműsítéséhez a replikakészletek számítási feladatainak elemzésekor. Amikor diagnosztikai beállításokat konfigurál a Lekérdezéstár futásidejű statisztikáinak streameléséhez a Log Analyticsbe, az Event Hubsba vagy az Azure Storage-ba, győződjön meg arról, hogy a lekérdezések és irányítópultok figyelembe veszik ezeket az oszlopokat az adatok replikaszerepkör szerinti megfelelő szegmentálásához. A diagnosztikai beállítások és az elérhető metrikák konfigurálásáról további információt az Azure Monitor diagnosztikai beállításai című témakörben talál.

Fontos

Az Azure SQL Database lekérdezési teljesítményelemzése (QPI)does not jelenleg támogatja a koncepciót replica_group_id . Az irányítópulton megjelenő adatok összesítik az összes futtatókörnyezeti és várakozási statisztikai adatot az összes replikából.

A Lekérdezéstár teljesítménnyel kapcsolatos szempontjai olvasható másodtárak esetén

A másodlagos replikák által a lekérdezési adatok elsődleges replikába való visszaküldésére használt csatorna ugyanaz a csatorna, amellyel a másodlagos replikák naprakészen tarthatók. Mit jelent channel itt?

Egy rendelkezésre állási csoport (HADR) konfigurációjában a replikák egy dedikált átviteli réteg használatával szinkronizálódnak egymással, amely naplóblokkokat, nyugtázásokat és állapotüzeneteket hordoz az elsődleges és a másodlagos replikák között. Ez biztosítja az adatok konzisztenciáját és a feladatátvétel készültségét.

Ha az olvasható másodtárak lekérdezéstára engedélyezve van, nem hoz létre külön hálózati végpontot. Ehelyett egy új logikai kommunikációs útvonalat hoz létre a meglévő átviteli rétegen:

Az Azure SQL Database (nem Hyperscale), a felügyelt Azure SQL-példány és az SQL Server esetében ez a magas rendelkezésre állást és vészhelyreállítást biztosító (HADR) Always On átviteli réteget használja.
Az Azure SQL Database rugalmas skálázása esetén a rendszer egy másik, távoli blob I/O átviteli rétegnek nevezett átviteli réteget használ. A távoli Blob I/O átviteli réteg a számítási csomópontok és a naplószolgáltatás/lapkiszolgálók közötti kommunikációs csatorna. A Távoli Blob I/O átviteli réteg megbízható, titkosított csatornát biztosít a naplórekordok és adatlapok áthelyezéséhez.

Ez az adatfolyam vegyesen kezeli a lekérdezéstár végrehajtási adatait (lekérdezésszöveg, tervek, futtatási/várakozási statisztikák) a normál naplórekord-forgalom mellett, ugyanazon titkosított munkamenet használatával. A funkció saját rögzítési és fogadási üzenetsorokkal rendelkezik, amelyek bármely replika szemszögéből megtekinthetők a nézet lekérdezésével sys.database_query_store_internal_state:

SELECT pending_message_count,
       messaging_memory_used_mb
FROM sys.database_query_store_internal_state;

A másodlagos fájlokból származó adatok megmaradnak az elsődleges lekérdezéstár ugyanazon tábláiban, ami növelheti a tárolási követelményeket. Nagy terhelés esetén előfordulhat, hogy késést vagy visszanyomást észlel a szállítási csatornán. Ugyanazok az alkalmi lekérdezésrögzítési korlátozások, amelyek az elsődleges lekérdezéstárra vonatkoznak, a másodfokokra is érvényesek. A Lekérdezéstár méretének és rögzítési szabályzatainak kezelésével kapcsolatos további információkért és útmutatásért tekintse meg a lekérdezéstár legfontosabb adatainak megőrzése című témakört.

Negatív lekérdezésazonosító/tervazonosító láthatósága

A negatív azonosítók ideiglenes memóriabeli helyőrzőket jeleznek a lekérdezésekhez és tervekhez a másodlagos példányokon, mielőtt az elsődleges példányra kerülnek tárolásra.

Mielőtt a Lekérdezéstár adatai áthelyezésre kerülnek az elsődlegesre a másodlagos replikákból, a lekérdezések és tervek ideiglenes azonosítókat kaphatnak a Lekérdezéstár helyi memóriabeli ábrázolásában – a MEMORYCLERK_QUERYDISKSTORE_HASHMAP. A lekérdezési és tervazonosítók negatív számként és helyőrzőként is megjelenhetnek, amíg az elsődleges replika nem rendel hozzá mérvadó azonosítót, amely azután következik be, hogy a Lekérdezéstár megállapítja, hogy a lekérdezés megfelel a konfigurált rögzítési mód követelményeinek. Ha egyéni rögzítési szabályzat van érvényben, a rendszerkatalógus nézet lekérdezésével áttekintheti azokat a sys.database_query_store_options követelményeket, amelyeknek teljesülniük kell.

SELECT query_capture_mode_desc,
       capture_policy_execution_count,
       capture_policy_total_compile_cpu_time_ms,
       capture_policy_total_execution_cpu_time_ms
FROM sys.database_query_store_options;

Miután egy lekérdezést rögzítettként kijelöltek, a futásidejű/várakozási statisztikák és a terv megőrzésre kerülhetnek, és a helyi ideiglenes azonosítókat pozitív azonosítók váltják fel. Ez lehetővé teszi a terv-kényszerítési vagy -javaslatkészítési képességek használatát is.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-20