Ajánlott eljárások a számítási feladatok lekérdezéstárral való monitorozásához

A következőkre vonatkozik: Sql Server 2016 (13.x) és újabb verziók Azure SQL DatabaseFelügyelt Azure SQL-példányAzure Synapse Analytics (csak dedikált SQL-készlet)SQL-adatbázis a Microsoft Fabricben

Ez a cikk az SQL Server Query Store számítási feladattal való használatának ajánlott eljárásait ismerteti.

• A lekérdezéstárral való konfigurálással és felügyelettel kapcsolatos további információkért lásd: Teljesítmény figyelése a Lekérdezéstár használatával.
• A végrehajtható információk felderítéséről és a lekérdezéstár teljesítményének finomhangolásáról további információt a Teljesítmény finomhangolása a Lekérdezéstárcímű témakörben talál.
• A lekérdezéstár Azure SQL Database-ben való működtetéséről további információt A lekérdezéstár üzemeltetése az Azure SQL Database-bencímű témakörben talál.
• Az Azure Synapse Analyticsben a Lekérdezéstár alapértelmezés szerint nincs engedélyezve dedikált SQL-készletek esetében, de engedélyezhető. A Lekérdezéstár további konfigurációs beállításai nem támogatottak. További információ: Korábbi lekérdezések tárolása és elemzése az Azure Synapse Analytics.

A legújabb SQL Server Management Studio használata

Az SQL Server Management Studio számos felhasználói felülettel rendelkezik, amelyek a Lekérdezéstár konfigurálására és a számítási feladatra vonatkozó összegyűjtött adatok felhasználására lettek kialakítva. Telepítse az SQL Server Management Studio (SSMS) legújabb verzióját.

A Lekérdezéstár hibaelhárítási forgatókönyvekben való használatáról a Query Store Azure blogscímű cikkben talál rövid leírást.

Lekérdezési teljesítményelemzés használata az Azure SQL Database-ben

Ha a Lekérdezéstárat az Azure SQL Database-ben futtatja, Lekérdezési teljesítményelemzési használatával elemezheti az erőforrás-felhasználást az idő függvényében. Bár a Management Studio és Azure Data Studio használatával részletes erőforrás-felhasználást érhet el az összes lekérdezéshez, például a CPU-hoz, a memóriához és az I/O-hoz, a Lekérdezési teljesítményelemzés gyors és hatékony módot kínál az adatbázis teljes DTU-használatára gyakorolt hatásuk meghatározására. További információ: Azure SQL Database Query Performance Insight.

A Fabric SQL Database teljesítményénekfigyeléséhez használja a Teljesítmény irányítópultot.

Lekérdezéstár használata rugalmas készlet-adatbázisokkal

A Query Store-t minden adatbázisban gond nélkül használhatja, még sűrűn csomagolt Rugalmas Azure SQL Database-készletekben is. A rugalmas készletekben lévő nagy számú adatbázis esetében a Lekérdezéstár engedélyezésekor a túlzott erőforrás-használattal kapcsolatos összes korábbi probléma megoldódott.

Kezdje a lekérdezési teljesítmény hibaelhárításával

A Lekérdezéstár hibaelhárítási munkafolyamata egyszerű, ahogyan az alábbi ábrán látható:

Engedélyezze a Lekérdezéstárat a Management Studióval az előző szakaszban leírtak szerint, vagy hajtsa végre a következő Transact-SQL utasítást:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Ez egy ideig tart, amíg a Lekérdezéstár összegyűjti a számítási feladatot pontosan képviselő adatkészletet. Általában egy nap még nagyon összetett számítási feladatokhoz is elegendő. A funkció engedélyezése után azonban azonnal megkezdheti az adatok feltárását és a figyelmet igénylő lekérdezések azonosítását. Nyissa meg a Lekérdezéstár almappát az adatbáziscsomópont alatt a Management Studio Objektumkezelőjében, és nyissa meg az adott forgatókönyvek hibaelhárítási nézeteit.

A Management Studio Lekérdezéstár nézetei a végrehajtási metrikák készletével működnek, amelyek mindegyike az alábbi statisztikai függvények bármelyikeként van kifejezve:

SQL Server-verzió	Végrehajtási metrikák	Statisztikai függvény
SQL Server 2016 (13.x)	CPU-idő, Időtartam, Végrehajtás száma, Logikai olvasások, Logikai írások, Memóriahasználat, Fizikai olvasások, CLR-idő, párhuzamossági fok (DOP) és sorok száma	Átlag, Maximum, Minimum, Szórás, Összeg
SQL Server 2017 (14.x)	CPU-idő, Időtartam, Végrehajtás száma, Logikai olvasások, Logikai írások, Memóriahasználat, Fizikai olvasások, CLR-idő, Párhuzamosság foka, Sorok száma, Naplómemória, tempdb Memória és Várakozási idő	Átlag, Maximum, Minimum, Szórás, Összeg

Az alábbi ábra bemutatja, hogyan keresheti meg a Lekérdezéstár nézeteket:

Az alábbi táblázat bemutatja, hogy mikor érdemes használni az egyes lekérdezéstár-nézeteket:

SQL Server Management Studio nézet	Scenario
Regressziós lekérdezések	Pinpoint-lekérdezések, amelyek végrehajtási metrikái a közelmúltban visszafejlődtek (például rosszabbra módosultak). Ezzel a nézettel korrelálhatja az alkalmazásban megfigyelt teljesítményproblémát azokkal a tényleges lekérdezésekkel, amelyeket javítani vagy javítani kell.
teljes erőforrás-felhasználás	Elemezze az adatbázis teljes erőforrás-felhasználását a végrehajtási metrikák bármelyikéhez. Ezzel a nézetben azonosíthatja az erőforrásmintákat (napi és éjszakai számítási feladatok), és optimalizálhatja az adatbázis teljes felhasználását.
leggyakoribb erőforrás-fogyasztó lekérdezések	Válasszon ki egy fontos végrehajtási metrikát, és azonosítsa azokat a lekérdezéseket, amelyek a legszélsőségesebb értékekkel rendelkeztek egy megadott időintervallumhoz. Ezzel a nézetgel a leginkább releváns lekérdezésekre összpontosíthatja a figyelmét, amelyek a legnagyobb hatással vannak az adatbázis-erőforrás-felhasználásra.
kényszerített tervekkel rendelkező lekérdezések	Felsorolja a Query Store használatával korábban kényszerített terveket. Ebben a nézetet gyorsan elérheti az összes jelenleg kényszerített tervet.
nagy variációjú lekérdezések	Elemezze a lekérdezéseket nagy végrehajtási variációval, mivel az a rendelkezésre álló dimenziók bármelyikére vonatkozik, például az időtartamra, a processzoridőre, az I/O-ra és a memóriahasználatra a kívánt időintervallumban. Ezzel a nézettel azonosíthatja a széles körben változó teljesítménnyel rendelkező lekérdezéseket, amelyek hatással lehetnek az alkalmazások felhasználói élményére.
Lekérdezés várakozási statisztika	Elemezze az adatbázis legaktívabb várakozási kategóriáit, és hogy mely lekérdezések járulnak hozzá a leginkább a kiválasztott várakozási kategóriához. Ezzel a nézettel elemezheti a várakozási statisztikákat, és azonosíthatja azokat a lekérdezéseket, amelyek hatással lehetnek az alkalmazások felhasználói élményére. A következőkre vonatkozik: Az SQL Server Management Studio 18.0-s verziójától és az SQL Server 2017-től kezdve (14.x).
Nyomon követett lekérdezések	Valós időben követheti nyomon a legfontosabb lekérdezések végrehajtását. Ezt a nézetet általában akkor használja, ha kényszerített tervekkel rendelkező lekérdezéseket használ, és meg szeretné győződni arról, hogy a lekérdezési teljesítmény stabil.

Tip

A Management Studio használatával a legfontosabb erőforrás-fogyasztó lekérdezések azonosításához és a tervválasztás módosítása miatt visszafejtött lekérdezések javításához a Query Store Azure Blogscímű témakörben talál részletes leírást.

Ha egy optimálisnál rosszabb teljesítményű lekérdezést azonosít, a művelet a probléma jellegétől függ.

• Ha a lekérdezés több tervvel lett végrehajtva, és az utolsó terv lényegesen rosszabb az előző tervnél, a terv kényszerítési mechanizmusával kényszerítheti azt. Az SQL Server megpróbálja kikényszeríteni a tervet az optimalizálóban. Ha a terv kényszerítése sikertelen, egy XEvent aktiválódik, és az optimalizálónak a szokásos módon kell optimalizálnia.

Note

Az előző ábrán különböző alakzatok lehetnek az egyes lekérdezési tervekhez, és az egyes lehetséges állapotok jelentése a következő:

Shape	Meaning
Circle	A lekérdezés befejeződött, ami azt jelenti, hogy a rendszeres végrehajtás sikeresen befejeződött.
Square	Megszakítva, ami azt jelenti, hogy az ügyfél megszakította a végrehajtást.
Triangle	Sikertelen volt, ami azt jelenti, hogy egy kivétel megszakította a végrehajtást.

Az alakzat mérete emellett a lekérdezés végrehajtásának számát is tükrözi a megadott időintervallumon belül. A méret nagyobb számú végrehajtással nő.

• Arra következtethet, hogy a lekérdezésből hiányzik egy index az optimális végrehajtáshoz. Ez az információ a lekérdezés végrehajtási tervében jelenik meg. Hozza létre a hiányzó indexet, és ellenőrizze a lekérdezés teljesítményét a Lekérdezéstár használatával.

Ha számítási feladatot futtat az SQL Database-en, regisztráljon az SQL Database Index Advisor szolgáltatásra, hogy automatikusan megkapja az indexjavaslatokat.

• Bizonyos esetekben kényszerítheti a statisztikai újrafordítást, ha azt látja, hogy a végrehajtási tervben szereplő sorok becsült és tényleges száma között jelentős a különbség.
• Írja át a problémás lekérdezéseket, például a lekérdezésparaméterezés előnyeinek kihasználásához vagy az optimálisabb logika implementálásához.

Tip

Az Azure SQL Database-ben fontolja meg a Lekérdezéstár tippjeinek funkciót, amely kódmódosítások nélküli lekérdezésekre kényszeríti a lekérdezési tippeket. További információkért és példákért lásd Lekérdezéstár tippeket.

Ellenőrizze, hogy a Lekérdezéstár folyamatosan gyűjti-e a lekérdezési adatokat

A Lekérdezéstár csendesen módosíthatja a műveleti módot. A Lekérdezéstár állapotának rendszeres monitorozása a Lekérdezéstár működésének biztosítása érdekében, valamint a megelőzhető okokból eredő hibák elkerülése érdekében. Hajtsa végre a következő lekérdezést a műveleti mód meghatározásához és a legrelevánsabb paraméterek megtekintéséhez:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

A actual_state_desc és a desired_state_desc közötti különbség azt jelzi, hogy a műveleti mód automatikusan megváltozott. A leggyakoribb változás az, hogy a Lekérdezéstár észrevétlenül írásvédett üzemmódra vált. Rendkívül ritka körülmények között a Lekérdezéstár belső hibák miatt HIBA állapotba kerülhet.

Amikor az aktuális állapot írásvédett, a kiváltó okának meghatározásához használja a readonly_reason oszlopot. Általában azt tapasztalja, hogy a Lekérdezéstár írásvédett üzemmódra váltott, mert túllépte a méretkvótát. Ebben az esetben a readonly_reason értéke 65536. Egyéb okokból lásd: sys.database_query_store_options.

Fontolja meg az alábbi lépéseket a Lekérdezéstár olvasási-írási módra való váltásához és az adatgyűjtés aktiválásához:

• Növelje a maximális tárterületméretet a MAX_STORAGE_SIZE_MBALTER DATABASE lehetőségével.

• A lekérdezéstár adatainak törlése az alábbi utasítással:

  ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
  

Ezen lépések egyikét vagy mindkettőt alkalmazhatja az alábbi utasítás végrehajtásával, amely explicit módon módosítja a műveleti módot olvasási-írási módra:

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

Proaktív módon hajtsa végre az alábbi lépéseket:

• Ajánlott eljárások alkalmazásával megakadályozhatja a üzemmód csendes módosítását. Győződjön meg arról, hogy a Lekérdezéstár mérete mindig a maximálisan megengedett érték alatt van, így jelentősen csökkentheti az írásvédett üzemmódra való áttérés esélyét. A Lekérdezéstár konfigurálása szakaszban leírtak szerint aktiválja a méretalapú szabályzatot, hogy a Lekérdezéstár automatikusan megtisztítsa az adatokat, amikor a méret eléri a korlátot.
• A legutóbbi adatok megőrzésének biztosításához konfiguráljon időalapú szabályzatot az elavult információk rendszeres eltávolításához.
• Végül fontolja meg, hogy a lekérdezéstár rögzítési módját Auto értékre állítsa, mert ez kiszűri azokat a lekérdezéseket, amelyek általában kevésbé relevánsak a számítási feladat szempontjából.

HIBAállapot

A Lekérdezéstár helyreállításához próbálja meg explicit módon beállítani az írási-olvasási módot, és ellenőrizni a tényleges állapotot.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Ha a probléma továbbra is fennáll, az azt jelzi, hogy a lekérdezéstár adatainak sérülése megmarad a lemezen.

Az SQL Server 2017 -től kezdve (14.x) a lekérdezéstár az érintett adatbázisban tárolt sys.sp_query_store_consistency_check művelet végrehajtásával állítható helyre. A lekérdezéstárat le kell tiltani a helyreállítási művelet megkísérlése előtt. Az alábbiakban egy minta lekérdezést használunk vagy módosítunk a QDS konzisztencia-ellenőrzésének és helyreállításának elvégzéséhez:

IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3)
BEGIN
  BEGIN TRY
    ALTER DATABASE [QDS] SET QUERY_STORE = OFF
    Exec [QDS].dbo.sp_query_store_consistency_check
    ALTER DATABASE [QDS] SET QUERY_STORE = ON
    ALTER DATABASE [QDS] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)
  END TRY

  BEGIN CATCH
    SELECT
      ERROR_NUMBER() AS ErrorNumber
      ,ERROR_SEVERITY() AS ErrorSeverity
      ,ERROR_STATE() AS ErrorState
      ,ERROR_PROCEDURE() AS ErrorProcedure
      ,ERROR_LINE() AS ErrorLine
      ,ERROR_MESSAGE() AS ErrorMessage;
  END CATCH;
END

Az SQL Server 2016 (13.x) esetében törölnie kell az adatokat a Lekérdezéstárból az ábrán látható módon.

Ha a helyreállítás sikertelen volt, az olvasási-írási mód beállítása előtt próbálja meg törölni a Lekérdezéstárat.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE CLEAR;
GO

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Ne használjon nem paraméteres lekérdezéseket

Nem paraméteres lekérdezések használata, ha ez nem szükséges, nem ajánlott eljárás. Példa az alkalmi elemzésre. A gyorsítótárazott tervek nem használhatók fel újra, ami arra kényszeríti a Lekérdezésoptimalizálót, hogy lekérdezéseket állítson össze minden egyedi lekérdezési szöveghez. További információért lásd a kényszerített paraméterezés használatának irányelveit: .

A Lekérdezéstár emellett gyorsan meghaladhatja a méretkvótát, mivel valószínűleg sok különböző lekérdezési szöveg és következésképpen sok hasonló alakú végrehajtási terv van. Ennek eredményeképpen a számítási feladat teljesítménye nem optimális, és a Lekérdezéstár írásvédett módra válthat, vagy folyamatosan törölheti az adatokat, hogy lépést tartson a bejövő lekérdezésekkel.

Vegye figyelembe a következő lehetőségeket:

• Adott esetben paraméterezi a lekérdezéseket. Például csomagolja a lekérdezéseket egy tárolt eljárásba vagy használjon sp_executesql-t. További információ: Paraméterek és végrehajtási terv újrafelhasználása.
• Használja az az alkalmi számítási feladatokra való optimalizálás lehetőséget, ha a számítási feladat számos, különböző lekérdezési csomagokkal rendelkező, egyszer használatos alkalmi köteget tartalmaz.
  • Hasonlítsa össze a különböző query_hash értékek számát a sys.query_store_querybejegyzéseinek teljes számával. Ha az arány megközelíti az 1-et, az alkalmi számítási feladat különböző lekérdezéseket hoz létre.
• Alkalmazza kényszerített paraméterezést az adatbázisra vagy a lekérdezések egy részhalmazára, ha a különböző lekérdezési tervek száma nem nagy.
  • A terv útmutatóját használja, hogy csak a kiválasztott lekérdezés paraméterezését kényszerítse.
  • Konfigurálja a kényszerített paraméterezést a paraméterezési adatbázis beállításával paranccsal, ha a számítási feladatban kevés különböző lekérdezési csomag található. Ilyen például, ha a különböző query_hash száma és az sys.query_store_query bejegyzéseinek teljes száma közötti arány sokkal kisebb, mint 1.
• Állítsa QUERY_CAPTURE_MODEAUTO a kis erőforrás-felhasználású alkalmi lekérdezések automatikus kiszűréséhez.

Tip

Az Object-Relational-leképezési (ORM-) megoldás, például az Entity Framework (EF) használatakor előfordulhat, hogy az alkalmazáslekérdezések, például a manuális LINQ-lekérdezési fák vagy bizonyos nyers SQL-lekérdezések nem paraméterezhetők, ami hatással van a terv újrahasználatára és a lekérdezések nyomon követésére a Lekérdezéstárban. További információ: EF-lekérdezések gyorsítótárazása és paraméterezése és EF Raw SQL-lekérdezések.

Nem paraméteres lekérdezések keresése a Lekérdezéstárban

A Lekérdezéstárban tárolt csomagok számát az alábbi lekérdezéssel, a Lekérdezéstár DMV-kkel, az SQL Serverben, az Azure SQL Managed Instanceben vagy az Azure SQL Database-ben találja:

SELECT count(Pl.plan_id) AS plan_count, Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry
    ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id
GROUP BY Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
ORDER BY plan_count desc;

Az alábbi minta egy bővített események áttekintését hozza létre az esemény query_store_db_diagnosticsrögzítéséhez, amely hasznos lehet a lekérdezési erőforrás-felhasználás diagnosztizálásához. Az SQL Serverben ez a kiterjesztett esemény-munkamenet alapértelmezés szerint létrehoz egy eseményfájlt az SQL Server Napló mappájában. Windowson például az SQL Server 2019 (15.x) alapértelmezett telepítésekor létre kell hozni az eseményfájlt (.xel fájl) a C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Logmappában. Az Azure SQL Kezelt Példány esetén adjon meg egy Azure Blob Storage-helyet. További információkért, lásd az Azure SQL Managed Instance XEvent event_filefájlt. Az "qds.query_store_db_diagnostics" esemény nem érhető el az Azure SQL Database-hez.

CREATE EVENT SESSION [QueryStore_Troubleshoot] ON SERVER
ADD EVENT qds.query_store_db_diagnostics(
      ACTION(sqlos.system_thread_id,sqlos.task_address,sqlos.task_time,sqlserver.database_id,sqlserver.database_name))
ADD TARGET package0.event_file(SET filename=N'QueryStore',max_file_size=(100))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF);

Ezekkel az adatokkal megtalálhatja a tervszámokat a Lekérdezéstárban, valamint számos más statisztikát is. Keresse meg a plan_count, query_count, max_stmt_hash_map_size_kbés max_size_mb oszlopokat az eseményadatokban, hogy megértse a felhasznált memória mennyiségét és a Lekérdezéstár által nyomon követett tervek számát. Ha a terv száma magasabb a normálnál, az a nem paraméteres lekérdezések számának növekedését jelezheti. Az alábbi Lekérdezéstár DMVs lekérdezésével áttekintheti a paraméteres lekérdezéseket és a nem paraméterezett lekérdezéseket a Lekérdezéstárban.

Paraméteres lekérdezések esetén:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id
WHERE qsq.query_parameterization_type<>0 or qsqt.query_sql_text like '%@%';

Nem paraméteres lekérdezések esetén:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id
WHERE query_parameterization_type=0;

Objekttumokat tartalmazó DROP és CREATE minta használatának elkerülése

A Lekérdezéstár a lekérdezési bejegyzést egy olyan objektumhoz társítja, mint a tárolt eljárás, a függvény és az eseményindító. Ha újra létrehoz egy objektumot, a rendszer új lekérdezési bejegyzést hoz létre ugyanahhoz a lekérdezésszöveghez. Ez megakadályozza, hogy az adott lekérdezés teljesítménystatisztikáit időben nyomon kövesse, és terv-kényszerítési mechanizmust használjon. A helyzet elkerülése érdekében a ALTER <object> folyamat segítségével bármikor módosíthatja az objektumdefiníciót.

A kényszerített tervek állapotának rendszeres ellenőrzése

A terv kényszerítése kényelmes mechanizmus a kritikus lekérdezések teljesítményének javítására és azok kiszámíthatóbbá tételére. A tervmutatókhoz és a terv útmutatóihoz hasonlóan a tervek kényszerítése nem garantálja, hogy a jövőbeli végrehajtásokban is használni fogják. Jellemzően, amikor az adatbázisséma úgy változik, hogy a végrehajtási terv által hivatkozott objektumok módosulnak vagy eldobják őket, a terv kényszerítése meghiúsul. Ebben az esetben az SQL Server visszatér a lekérdések újrafordításához, miközben a kényszerítési hiba tényleges oka a sys.query_store_planjelenik meg. Az alábbi lekérdezés a kényszerített tervekkel kapcsolatos információkat adja vissza:

USE [QueryStoreDB];
GO

SELECT p.plan_id, p.query_id, q.object_id as containing_object_id,
    force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan AS p
JOIN sys.query_store_query AS q on p.query_id = q.query_id
WHERE is_forced_plan = 1;

Az okok teljes listáját lásd a sys.query_store_plan. A query_store_plan_forcing_failed XEvent használatával is nyomon követheti és elháríthatja a terv kényszerítési hibáit.

Tip

Az Azure SQL Database-ben fontolja meg a Lekérdezéstár tippjeinek funkciót, amely kódmódosítások nélküli lekérdezésekre kényszeríti a lekérdezési tippeket. További információkért és példákért lásd Lekérdezéstár tippeket.

Az adatbázisok átnevezésének elkerülése kényszerített tervekkel rendelkező lekérdezésekhez

A végrehajtási tervek három részből álló nevek, például database.schema.objecthasználatával hivatkoznak az objektumokra.

Ha átnevez egy adatbázist, a végrehajtási terv kényszerítése meghiúsul, ami az összes későbbi lekérdezés-végrehajtás során újragenerálást okoz.

A Lekérdezéstár használata kritikus fontosságú kiszolgálókon

A 7745 és 7752 globális nyomkövetési jelzők az adatbázisok rendelkezésre állásának javítására használhatók a Lekérdezéstár használatával. További információ: Nyomkövetési jelzők beállítása a DBCC TRACEON használatával.

• A 7745-ös nyomkövetési jelző megakadályozza azt az alapértelmezett viselkedést, amikor a Lekérdezéstár adatokat ír lemezre, mielőtt az SQL Server leállítható lenne. Ez azt jelenti, hogy a lemezen még nem írt, de már összegyűjtött lekérdezéstár-adatok elvesznek, a DATA_FLUSH_INTERVAL_SECONDS-val meghatározott időablakig.
• A 7752 nyomkövetési jelző lehetővé teszi a lekérdezéstár aszinkron betöltését. Ez lehetővé teszi, hogy egy adatbázis online állapotba váljon, és a lekérdezések végrehajtása a Lekérdezéstár teljes helyreállítása előtt történik. Az alapértelmezett viselkedés a Lekérdezéstár szinkron terhelésének beállítása. Az alapértelmezett viselkedés megakadályozza a lekérdezések végrehajtását a Lekérdezéstár helyreállítása előtt, de megakadályozza, hogy a lekérdezések ne maradjanak le az adatgyűjtésben.

Note

Az SQL Server 2019-től (15.x) kezdve ezt a viselkedést a motor szabályozza, és a 7752 nyomkövetési jelzőnek nincs hatása.

Important

Ha a Query Store-t használja az SQL Server 2016-ban (13.x) az igény szerinti számítási feladatok elemzéséhez, a lehető leghamarabb telepítse az SQL Server 2016 (13.x) SP2 CU2 (KB 4340759) teljesítményskálázhatósági fejlesztéseit. E fejlesztések nélkül, ha az adatbázis nagy számítási feladatok alatt áll, spinlock-versengés következhet be, és a kiszolgáló teljesítménye lassúvá válhat. Különösen jelentős versengés jelenhet meg a QUERY_STORE_ASYNC_PERSIST spinlockon vagy a SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlockon. A javítás alkalmazása után a Lekérdezéstár többé nem okoz spinlock-versengést.

Important

Ha a Query Store-t használja az SQL Server (SQL Server 2016 (13.x) és az SQL Server 2017 (14.x) közötti igény szerinti számítási feladatok elemzéséhez, tervezze meg a teljesítmény skálázhatóságának javítását az SQL Server 2016 (13.x) SP2 CU15-ben, AZ SQL Server 2017 (14.x) CU23 és az SQL Server 2019 (15.x) CU9 a lehető leghamarabb. A fejlesztés nélkül, ha az adatbázis nagy alkalmi számítási feladatok alatt áll, előfordulhat, hogy a lekérdezéstár nagy mennyiségű memóriát használ, és a kiszolgáló teljesítménye lassúvá válhat. A fejlesztés alkalmazása után a Lekérdezéstár belső korlátokat szab a különböző összetevők által használható memória mennyiségére, és automatikusan írásvédettre módosíthatja a műveleti módot, amíg elegendő memóriát nem ad vissza az adatbázismotornak. A lekérdezéstár belső memóriakorlátjai nincsenek dokumentálva, mert változhatnak.

A Lekérdezéstár használata az Azure SQL Database aktív georeplikálásában

Az Azure SQL Database másodlagos aktív georeplikáján a Lekérdezési Tár az elsődleges replikán zajló tevékenység írásvédett másolata lesz.

Kerülje a nem egyező szinteket az Azure SQL Database georeplikálásával. A másodlagos adatbázisoknak az elsődleges adatbázis számítási méretével megegyező vagy közeli méretűnek kell lenniük, és az elsődleges adatbázis szolgáltatási szintjén kell lenniük. Keresse meg a HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO várakozási típust a sys.dm_db_wait_stats-ben. Ez azt jelzi, hogy a tranzakciónapló sebességének szabályozására az elsődleges replikán kerül sor, a másodlagos késlekedés miatt.

Az aktív georeplikációs másodlagos Azure SQL-adatbázis méretének becsléséről és konfigurálásáról további információt a Másodlagos adatbázis konfigurálásacímű témakörben talál.

Tartsa a Lekérdezéstárat az ön munkaterheléséhez igazítva.

A lekérdezéstár konfigurálására és kezelésére vonatkozó ajánlott eljárásokat és javaslatokat ebben a cikkben bővítettük: A lekérdezéstárkezelésének ajánlott eljárásai.

Kapcsolódó tartalom

• ALTER DATABASE SET opciók (Transact-SQL)
• Lekérdezéstár katalógusnézetei (Transact-SQL)
• Lekérdezéstár tárolt eljárásai (Transact-SQL)
• A lekérdezéstár használata In-Memory OLTP-vel
• lekérdezésfeldolgozási architektúra útmutatója
• Lekérdezéstár útmutatások
• A teljesítmény figyelése a Lekérdezéstár segítségével
• Teljesítmény finomhangolása a Lekérdezéstár
• Korábbi lekérdezések tárolása és elemzése az Azure Synapse Analytics