Osvědčené postupy pro monitorování úloh pomocí úložiště dotazů

platí pro: SQL Server 2016 (13.x) a novější verze Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (pouze vyhrazený fond SQL)databázi SQL v Microsoft Fabric

Tento článek popisuje osvědčené postupy pro používání úložiště dotazů SQL Serveru s vaší úlohou.

• Další informace o konfiguraci a správě pomocí úložiště dotazů najdete v tématu Monitorování výkonu pomocí úložiště dotazů.
• Informace o zjišťování informací umožňujících akci a ladění výkonu pomocí úložiště dotazů najdete v tématu Ladění výkonu pomocí úložiště dotazů.
• Informace o provozu úložiště dotazů ve službě Azure SQL Database najdete v tématu Provoz úložiště dotazů ve službě Azure SQL Database.
• Ve službě Azure Synapse Analytics není úložiště dotazů ve výchozím nastavení povolené pro vyhrazené fondy SQL, ale je možné ho povolit. Další možnosti konfigurace úložiště dotazů se nepodporují. Další informace najdete v tématu Historické úložiště dotazů a analýza ve službě Azure Synapse Analytics.

Použití nejnovější aplikace SQL Server Management Studio

SQL Server Management Studio má sadu uživatelských rozhraní navržených pro konfiguraci úložiště dotazů a pro využívání shromážděných dat o vaší úloze. Stáhnout nejnovější verzi aplikace SQL Server Management Studio.

Rychlý popis použití úložiště dotazů ve scénářích řešení potíží najdete v tématu Query Store Azure blogs.

Použití nástroje Query Performance Insight ve službě Azure SQL Database

Pokud spustíte úložiště dotazů ve službě Azure SQL Database, můžete k analýze spotřeby prostředků v průběhu času použít Query Performance Insight. I když můžete použít Management Studio a Azure Data Studio k získání podrobné spotřeby prostředků pro všechny dotazy, jako je procesor, paměť a vstupně-výstupní operace, poskytuje Nástroj Query Performance Insight rychlý a efektivní způsob, jak určit jejich vliv na celkovou spotřebu DTU pro vaši databázi. Další informace najdete v tématu Azure SQL Database Query Performance Insight.

Pokud chcete monitorovat výkon vdatabáze SQL Fabric, použijte řídicí panel výkonu .

Použití úložiště dotazů s databázemi elastického fondu

Úložiště dotazů můžete používat ve všech databázích bez obav, a to i v hustě zabalených elastických fondech Azure SQL Database. Všechny předchozí problémy související s nadměrným využitím prostředků, ke kterým mohlo dojít při povolení Query Store pro velký počet databází v rámci elastických fondů, byly vyřešeny.

Začínáme s řešením potíží s výkonem dotazů

Pracovní postup řešení potíží s úložištěm dotazů je jednoduchý, jak je znázorněno v následujícím diagramu:

Povolte úložiště dotazů pomocí nástroje Management Studio, jak je popsáno v předchozí části, nebo spusťte následující příkaz Transact-SQL:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Než úložiště dotazů shromáždí sadu dat, která přesně představuje vaši úlohu, nějakou dobu trvá. Obvykle stačí jeden den i pro velmi složité úlohy. Můžete ale začít zkoumat data a identifikovat dotazy, které vyžadují vaši pozornost okamžitě po povolení funkce. V Průzkumníku objektů v sadě Management Studio přejděte do podsložky Úložiště dotazů a otevřete zobrazení řešení potíží pro konkrétní scénáře.

Zobrazení úložiště dotazů Management Studio fungují se sadou metrik provádění, které jsou vyjádřeny jako některé z následujících statistických funkcí:

Verze SQL Serveru	Metrika provádění	Statistická funkce
SQL Server 2016 (13.x)	Čas procesoru, doba trvání, počet spuštění, logické čtení, logické zápisy, spotřeba paměti, fyzické čtení, čas CLR, stupeň paralelismu (DOP) a počet řádků	Průměr, maximum, minimum, směrodatná odchylka, součet
SQL Server 2017 (14.x)	Čas procesoru, doba trvání, počet spuštění, logické čtení, logické zápisy, spotřeba paměti, fyzická čtení, čas CLR, stupeň paralelismu, počet řádků, paměť protokolu, paměť tempDB a doby čekání	Průměr, Maximum, Minimum, Směrodatná odchylka, Celkový součet

Následující obrázek ukazuje, jak nalézt zobrazení Query Store:

Následující tabulka vysvětluje, kdy použít každé zobrazení úložiště dotazů:

Zobrazení aplikace SQL Server Management Studio	Scénář
regrese dotazů	Určení dotazů, u kterých se metriky spouštění nedávno zhoršily (například změnily k horšímu). Toto zobrazení slouží ke korelaci pozorovaných problémů s výkonem ve vaší aplikaci se skutečnými dotazy, které je potřeba opravit nebo vylepšit.
celkové využití prostředků	Analyzujte celkovou spotřebu prostředků databáze pro jakoukoli z metrik provádění. V tomto zobrazení můžete identifikovat vzory prostředků (denní a noční úlohy) a optimalizovat celkovou spotřebu pro vaši databázi.
dotazy s nejvyšším využitím prostředků	Zvolte metriku provádění, kterou zajímáte, a identifikujte dotazy, které měly nejextrémnější hodnoty pro zadaný časový interval. Toto zobrazení vám umožní zaměřit pozornost na nejrelevantní dotazy, které mají největší vliv na spotřebu databázových prostředků.
dotazy s vynucenými plány	Zobrazí seznam dříve vynucených plánů pomocí úložiště dotazů. Pomocí tohoto zobrazení můžete rychle získat přístup ke všem aktuálně vynuceným plánům.
dotazy s vysokou variací	Analyzujte dotazy s vysokou variantou spouštění, protože souvisí s některou z dostupných dimenzí, jako je Doba trvání, čas procesoru, vstupně-výstupní operace a využití paměti, v požadovaném časovém intervalu. Toto zobrazení slouží k identifikaci dotazů s široce variantovaným výkonem, které můžou ovlivnit uživatelské prostředí napříč vašimi aplikacemi.
Statistiky očekávání dotazu	Analyzujte kategorie čekání, které jsou v databázi nejaktivnější a které dotazy přispívají nejvíce do vybrané kategorie čekání. Pomocí tohoto zobrazení můžete analyzovat statistiky čekání a identifikovat dotazy, které můžou mít vliv na uživatelské prostředí napříč vašimi aplikacemi. Platí pro: SQL Server Management Studio verze 18.0 a SQL Server 2017 (14.x).
Sledované Dotazy	Sledujte provádění nejdůležitějších dotazů v reálném čase. Toto zobrazení obvykle používáte, pokud máte dotazy s vynucenými plány a chcete zajistit, aby byl výkon dotazů stabilní.

Spropitné

Podrobný popis použití nástroje Management Studio k identifikaci dotazů, které nejvíce využívají prostředky, a opravě těch, jejichž výkon se kvůli změně zvoleného plánu zhoršil, najdete v tématu Query Store Azure Blogs.

Když identifikujete dotaz s neoptimálním výkonem, akce závisí na povaze problému.

• Pokud byl dotaz proveden s více plány a poslední plán je výrazně horší než předchozí plán, můžete ho vynutit pomocí mechanismu vynucení plánu. SQL Server se pokusí vynutit plán v optimalizátoru. Pokud dojde k selhání vynucení plánu, aktivuje se událost XEvent a optimalizátoru je dáno pokyn, aby optimalizoval běžným způsobem.

Poznámka

Předchozí obrázek může obsahovat různé obrazce pro konkrétní plány dotazů s následujícími významy pro každý možný stav:

Tvar	Význam
Kruh	Dotaz byl dokončen, což znamená, že standardní provádění bylo úspěšně dokončeno.
Náměstí	Zrušeno, což znamená, že spuštění iniciované klientem bylo přerušeno.
Trojúhelník	Selhání, což znamená, že výjimka přerušila spuštění.

Velikost obrazce také odráží počet provádění dotazu v zadaném časovém intervalu. Velikost se zvyšuje s vyšším počtem spuštění.

• Můžete dojít k závěru, že v dotazu chybí index pro optimální spuštění. Tyto informace se zobrazí v rámci plánu provádění dotazů. Vytvořte chybějící index a pomocí úložiště dotazů zkontrolujte výkon dotazů.

Pokud spustíte úlohu ve službě SQL Database, zaregistrujte si sql Database Index Advisor, abyste automaticky dostávali doporučení k indexu.

• V některých případech můžete vynutit rekompilace statistiky, pokud zjistíte, že rozdíl mezi odhadovaný a skutečným počtem řádků v plánu provádění je významný.
• Přepište problematické dotazy, například za účelem využití parametrizace dotazů nebo implementace optimaličtější logiky.

Spropitné

Ve službě Azure SQL Database zvažte použití funkce nápovědy úložiště dotazů pro vynucení nápověd pro dotazy bez změn kódu. Další informace a příklady najdete v tématu pokyny pro úložiště dotazů.

Ověření, že úložiště dotazů shromažďuje data dotazů nepřetržitě

Úložiště dotazů může bezobslužně změnit režim operace. Pravidelně monitorujte stav úložiště dotazů, abyste měli jistotu, že je úložiště dotazů v provozu, a proveďte opatření, abyste se vyhnuli selháním kvůli zabránitelným příčinám. Spuštěním následujícího dotazu určete režim operace a zobrazte nejrelevavantnější parametry:

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;

Rozdíl mezi actual_state_desc a desired_state_desc znamená, že došlo k automatické změně režimu operace. Nejběžnější změnou je, že úložiště dotazů může bezobslužně přepnout do režimu jen pro čtení. Ve výjimečných případech může úložiště dotazů skončit ve stavu ERROR kvůli interním chybám.

Pokud je skutečný stav jen pro čtení, použijte sloupec readonly_reason k určení původní příčiny. Obvykle zjistíte, že úložiště dotazů přešlo do režimu jen pro čtení, protože došlo k překročení kvóty velikosti. V takovém případě je readonly_reason nastavená na 65536. Z jiných důvodů viz sys.database_query_store_options (Transact-SQL).

Pokud chcete přepnout úložiště dotazů do režimu čtení a zápisu a aktivovat shromažďování dat, zvažte následující kroky:

• Zvyšte maximální velikost úložiště pomocí možnosti MAX_STORAGE_SIZE_MBALTER DATABASE.

• Pomocí následujícího příkazu vyčistíte data úložiště dotazů:

  ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
  

Jeden nebo oba tyto kroky můžete použít spuštěním následujícího příkazu, který explicitně změní režim operace zpět na čtení i zápis:

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

Pokud chcete být proaktivní, postupujte následovně:

• Pomocí osvědčených postupů můžete zabránit tichým změnám režimu provozu. Ujistěte se, že velikost úložiště dotazů je vždy pod maximální povolenou hodnotou, aby se výrazně snížila pravděpodobnost přechodu do režimu jen pro čtení. Aktivujte zásady založené na velikosti, jak je popsáno v části Konfigurace úložiště dotazů, aby úložiště dotazů automaticky vyčistilo data, když se velikost blíží limitu.
• Abyste měli jistotu, že se uchovávají nejnovější data, nakonfigurujte zásady založené na čase, aby pravidelně odebíraly zastaralé informace.
• Nakonec zvažte nastavení Query Store Capture Mode na Automaticky, protože filtruje dotazy, které jsou obvykle méně relevantní pro vaše pracovní zatížení.

STAV CHYBY

Pokud chcete obnovit úložiště dotazů, zkuste explicitně nastavit režim čtení i zápisu a znovu zkontrolovat skutečný stav.

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;

Pokud problém přetrvává, znamená to, že poškození dat úložiště dotazů je na disku trvalé.

Od verze SQL Server 2017 (14.x) je možné úložiště dotazů obnovit spuštěním sys.sp_query_store_consistency_check uložené procedury v ovlivněné databázi. Úložiště dotazů musí být zakázáno předtím, než se pokusíte o operaci obnovení. Tady je ukázkový dotaz, který se má použít nebo upravit, aby bylo možné provést kontrolu konzistence a obnovení QDS:

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

Pro SQL Server 2016 (13.x) musíte vymazat data z úložiště dotazů, jak je znázorněno.

Pokud obnovení nebylo úspěšné, můžete zkusit vymazat úložiště dotazů před nastavením režimu čtení a zápisu.

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;

Vyhněte se používání neparametrizovaných dotazů

Použití neparametrizovaných dotazů, pokud to není nutné, není osvědčeným postupem. Příkladem je ad hoc analýza. Plány v mezipaměti se nedají opakovaně použít, což vynutí Optimalizátor dotazů kompilovat dotazy pro každý jedinečný text dotazu. Další informace naleznete v tématu Pokyny pro použití vynucené parametrizace.

Úložiště dotazů také může rychle překročit kvótu velikosti z důvodu potenciálně velkého počtu různých textů dotazů a v důsledku toho velkého počtu různých plánů provádění s podobným tvarem. V důsledku toho je výkon vaší úlohy neoptimální a úložiště dotazů může přepnout do režimu jen pro čtení nebo trvale odstranit data, aby se pokusil udržet krok s příchozími dotazy.

Zvažte následující možnosti:

• Parametrizovat dotazy tam, kde je to možné. Například uzavřete dotazy do uložené procedury nebo sp_executesql. Další informace naleznete v tématu Parametry a opakované použití plánu provádění.
• Použijte možnost optimalizovat pro ad hoc úlohy, pokud vaše úloha obsahuje mnoho jednorázových ad hoc dávek s různými plány dotazů.
  • Porovnejte počet jedinečných query_hash hodnot s celkovým počtem položek v sys.query_store_query. Pokud je poměr blízko 1, vaše ad hoc úloha generuje různé dotazy.
• Pokud počet různých plánů dotazů není velký, použijte vynucené parametrizace pro databázi nebo pro podmnožinu dotazů.
  • Pokud chcete vynutit parametrizaci pouze pro vybraný dotaz, použijte průvodce plánem.
  • Nakonfigurujte vynucenou parametrizaci pomocí příkazu pro možnost parametru parametrizace databáze, pokud je ve vaší úloze malý počet různých plánů dotazů. Příkladem je, když je poměr mezi počtem jedinečných query_hash a celkovým počtem položek v sys.query_store_query mnohem menší než 1.
• Nastavte QUERY_CAPTURE_MODE na AUTO, aby se automaticky odfiltrovaly ad hoc dotazy s malou spotřebou prostředků.

Spropitné

Při použití řešení mapování Object-Relational (ORM), jako je Entity Framework (EF), nemusí být dotazy aplikací, jako jsou ruční stromy dotazů LINQ nebo některé nezpracované dotazy SQL, parametrizovány, což má vliv na opětovné použití plánu a schopnost sledovat dotazy v úložišti dotazů. Další informace naleznete v části Ukládání dotazů EF do mezipaměti a parametrizace a EF dotazy v surovém SQL.

Vyhledání neparametrizovaných dotazů v úložišti dotazů

Počet plánů uložených v úložišti dotazů zjistíte následujícím dotazem pomocí DMV úložiště dotazů v SQL Serveru, Azure SQL Managed Instance nebo Azure SQL Database.

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;

Následující ukázka vytvoří relaci rozšířených událostí ke sledování události query_store_db_diagnostics, což může být užitečné pro diagnostikování spotřeby prostředků dotazů. V SQL Serveru tato rozšířená relace událostí ve výchozím nastavení vytvoří soubor události ve složce protokolů SQL Serveru. Například ve výchozí instalaci SQL Serveru 2019 (15.x) ve Windows by měl být soubor události (soubor.xel) vytvořen ve složce C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log. Pro službu Azure SQL Managed Instance místo toho zadejte umístění služby Azure Blob Storage. Další informace najdete v tématu XEvent event_file pro Azure SQL Managed Instance. Událost qds.query_store_db_diagnostics není pro Azure SQL Database dostupná.

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

Pomocí těchto dat můžete najít počet plánů v úložišti dotazů a také mnoho dalších statistik. Vyhledejte sloupce plan_count, query_count, max_stmt_hash_map_size_kba max_size_mb v datech událostí, abyste porozuměli množství využité paměti a počtu plánů, které sleduje úložiště dotazů. Pokud je počet plánů vyšší než normální, může to znamenat zvýšení neparametrizovaných dotazů. Pomocí následujícího dotazu dynamické správy úložiště dotazů zkontrolujte parametrizované dotazy a neparametrizované dotazy v úložišti dotazů.

Pro parametrizované dotazy:

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 '%@%';

Pro neparametrizované dotazy:

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;

Vyhněte se vzoru DROP a CREATE pro obsahující objekty

Úložiště dotazů přidruží položku dotazu k objektu obsahujícímu, jako je uložená procedura, funkce a trigger. Při opětovném vytvoření obsahujícího objektu se pro tentýž text dotazu vygeneruje nová položka dotazu. Zabráníte tak sledování statistik výkonu pro daný dotaz v průběhu času a použití mechanismu vynucení plánu. Pokud se chcete této situaci vyhnout, použijte proces ALTER <object> ke změně definice obsahujícího objektu, kdykoli je to možné.

Pravidelně kontrolujte stav vynucených plánů.

Vynucení plánu je pohodlný mechanismus pro zlepšení výkonu kritických dotazů a jejich větší předvídatelnost. Stejně jako u pokynů k plánu a průvodců plánem není vynucení plánu zárukou, že se použije v budoucích provedeních. Obvykle, když se změní schéma databáze způsobem, že objekty, na které odkazuje plán provádění, jsou změněny nebo odstraněny, vynucení plánu selhává. V takovém případě se SQL Server vrací k rekompilaci dotazu, zatímco skutečný důvod vynucení selhání je odhalen v sys.query_store_plan. Následující dotaz vrátí informace o vynucených plánech:

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;

Úplný seznam důvodů najdete v tématu sys.query_store_plan. Můžete také použít query_store_plan_forcing_failed XEvent ke sledování a řešení potíží se selháními vynucení plánu.

Rada

Ve službě Azure SQL Database zvažte funkci Query Store pokyny pro aplikaci pokynů na dotazy, aniž by bylo nutné měnit kód. Další informace a příklady naleznete v části rady pro úložiště dotazů.

Vyhněte se přejmenování databází u dotazů, které mají vynucené plány.

Plány provádění odkazují na objekty pomocí třídílných názvů, jako je database.schema.object.

Pokud databázi přejmenujete, plánování vynucení selže, což způsobí rekompilace ve všech následných spuštěních dotazů.

Použití úložiště dotazů na důležitých serverech

Globální příznaky trasování 7745 a 7752 lze použít ke zlepšení dostupnosti databází pomocí úložiště dotazů. Další informace naleznete v příznacích trasování .

• Příznak trasování 7745 zabraňuje výchozímu chování, kdy úložiště dotazů zapisuje data na disk před vypnutím SQL Serveru. To znamená, že data úložiště dotazů shromážděná, ale dosud neuchovaná na disku budou ztracena až do časového intervalu definovaného pomocí DATA_FLUSH_INTERVAL_SECONDS.
• Trasovací příznak 7752 umožňuje asynchronní načtení úložiště dotazů. To umožňuje, aby se databáze stala online a dotazy se spustily před úplným obnovením úložiště dotazů. Výchozím chováním je synchronní načtení úložiště dotazů. Výchozí chování zabraňuje spuštění dotazů před obnovením úložiště dotazů, ale také zajišťuje, že žádné dotazy nechybí v kolekci dat.

Poznámka

Od SQL Serveru 2019 (15.x) je toto chování řízeno jádrem, a příznak trasování 7752 nemá žádný vliv.

Důležitý

Pokud používáte úložiště dotazů pro přehledy úloh za běhu v SQL Serveru 2016 (13.x), naplánujte co nejdříve instalaci vylepšení škálovatelnosti výkonu v SQL Serveru 2016 (13.x) SP2 CU2 (KB 4340759). Bez těchto vylepšení se může stát, že když je databáze pod velkým zatížením, může dojít ke kolizím zablokování a může dojít ke zpomalení výkonu serveru. Konkrétně se může zobrazit velká kolize na QUERY_STORE_ASYNC_PERSIST spinlock nebo SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlock. Po použití tohoto vylepšení už úložiště dotazů nezpůsobí zablokování spinlocku.

Důležitý

Pokud používáte úložiště dotazů pro přehledy úloh za běhu v SQL Serveru (SQL Server 2016 (13.x) až SQL Server 2017 (14.x)), naplánujte instalaci vylepšení škálovatelnosti výkonu v SQL Serveru 2016 (13.x) SP2 CU15, SQL Server 2017 (14.x) CU23 a SQL Server 2019 (15.x) CU9 co nejdříve. Bez tohoto vylepšení může úložiště dotazů při velkém ad hoc zatížení databáze používat velké množství paměti, což může zpomalit výkon serveru. Po použití tohoto vylepšení ukládá úložiště dotazů interní limity pro množství paměti, které můžou používat různé komponenty, a může automaticky změnit režim operace na jen pro čtení, dokud se do databázového stroje nevrátí dostatek paměti. Omezení interní paměti úložiště dotazů nejsou zdokumentovaná, protože se můžou změnit.

Použití úložiště dotazů ve službě Azure SQL Database s aktivní geografickou replikací

Úložiště dotazů v sekundární aktivní geografické replice služby Azure SQL Database bude kopií aktivity na primární replice jen pro čtení.

Vyhněte se neshodovaným úrovním s geografickou replikací služby Azure SQL Database. Sekundární databáze by měla mít stejnou velikost výpočetních prostředků primární databáze nebo téměř stejnou velikost a ve stejné úrovni služby primární databáze. Vyhledejte typ čekání HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO v sys.dm_db_wait_stats, který indikuje omezování rychlosti transakčního protokolu na primární replice kvůli sekundární prodlevě.

Další informace o odhadu a konfiguraci velikosti sekundární databáze Azure SQL aktivní geografické replikace najdete v tématu Konfigurace sekundární databáze.

Udržujte úložiště dotazů přizpůsobené vaší pracovní zátěži.

Osvědčené postupy a doporučení pro konfiguraci a správu úložiště dotazů byly rozbaleny v tomto článku: osvědčené postupy pro správu úložiště dotazů.

Související obsah

• možnosti ALTER DATABASE SET (Transact-SQL)
• zobrazení katalogu úložiště dotazů (Transact-SQL)
• uložené procedury úložiště dotazů (Transact-SQL)
• použití úložiště dotazů s In-Memory OLTP
• Průvodce architekturou zpracování dotazů
• Hinty pro úložiště dotazů
• Monitorování výkonu pomocí úložiště dotazů
• ladění výkonu pomocí „úložiště dotazů“
• historické ukládání a analýza dotazů ve službě Azure Synapse Analytics