Lezen in het Engels

Share via

Aanbevolen procedures voor het bewaken van workloads met Query Store

  • Artikel

van toepassing op: SQL Server 2016 (13.x) en latere versies Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (alleen toegewezen SQL-pool)SQL-database in Microsoft Fabric

In dit artikel vindt u een overzicht van de aanbevolen procedures voor het gebruik van SQL Server Query Store met uw workload.

De nieuwste SQL Server Management Studio gebruiken

SQL Server Management Studio heeft een set gebruikersinterfaces die zijn ontworpen voor het configureren van Query Store en voor het verbruik van verzamelde gegevens over uw workload. Download de nieuwste versie van SQL Server Management Studio.

Zie Query Store Azure blogsvoor een korte beschrijving van het gebruik van Query Store in scenario's voor probleemoplossing.

Query Performance Insight gebruiken in Azure SQL Database

Als u Query Store uitvoert in Azure SQL Database, kunt u Query Performance Insight gebruiken om het resourceverbruik in de loop van de tijd te analyseren. Hoewel u Management Studio en Azure Data Studio kunt gebruiken om gedetailleerd resourceverbruik te krijgen voor al uw query's, zoals CPU, geheugen en I/O, biedt Query Performance Insight een snelle en efficiënte manier om het effect ervan op het totale DTU-verbruik voor uw database te bepalen. Zie Azure SQL Database Query Performance Insightvoor meer informatie.

Gebruik het Prestatiedashboardom de prestaties te bewaken in fabric SQL Database.

Query Store gebruiken met databases voor elastische pools

U kunt Query Store gebruiken in alle databases zonder zorgen, in zelfs dicht verpakte elastische Pools van Azure SQL Database. Alle eerdere problemen met betrekking tot overmatig resourcegebruik dat zich mogelijk heeft voorgedaan toen Query Store was ingeschakeld voor het grote aantal databases in de elastische pools, zijn opgelost.

Beginnen met het oplossen van problemen met queryprestaties

De werkstroom voor probleemoplossing met Query Store is eenvoudig, zoals wordt weergegeven in het volgende diagram:

diagram van het oplossen van problemen met Query Store: Query Store inschakelen, Query Store de gegevens laten verzamelen, problematische query's opsporen en oplossen.

Schakel Query Store in met behulp van Management Studio, zoals beschreven in de vorige sectie, of voer de volgende Transact-SQL-instructie uit:

SQL 
ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Het duurt enige tijd voordat Query Store de gegevensset verzamelt die uw workload nauwkeurig vertegenwoordigt. Normaal gesproken is één dag voldoende, zelfs voor zeer complexe workloads. U kunt echter beginnen met het verkennen van de gegevens en query's identificeren die direct na het inschakelen van de functie uw aandacht nodig hebben. Ga naar de submap Query Store onder het databasisknooppunt in de Object Explorer van Management Studio om probleemoplossingsweergaven te openen voor specifieke scenario's.

Management Studio Query Store-weergaven werken met de set metrische uitvoeringsgegevens, die elk worden uitgedrukt als een van de volgende statistische functies:

SQL Server-versie Metrische uitvoeringsgegevens Statistische functie
SQL Server 2016 (13.x) CPU-tijd, duur, aantal uitvoeringen, logische leesbewerkingen, logische schrijfbewerkingen, geheugenverbruik, fysieke leesbewerkingen, CLR-tijd, mate van parallelle uitvoering (DOP) en aantal rijen Gemiddelde, Maximum, Minimum, Standaarddeviatie, Totaal
SQL Server 2017 (14.x) CPU-tijd, duur, aantal uitvoeringen, logische leesbewerkingen, logische schrijfbewerkingen, geheugenverbruik, fysieke leesbewerkingen, CLR-tijd, mate van parallelle uitvoering, aantal rijen, logboekgeheugen, TempDB-geheugen en wachttijden Gemiddelde, Maximum, Minimum, Standaarddeviatie, Totaal

In de volgende afbeelding ziet u hoe u Query Store-weergaven kunt vinden:

Schermopname van SSMS met de locatie van de Query Store-weergaven.

In de volgende tabel wordt uitgelegd wanneer u elk van de Query Store-weergaven gebruikt:

SQL Server Management Studio-weergave Scenario
Teruggegaan queries Identificeer queries waarvoor uitvoeringsstatistieken onlangs zijn verslechterd (bijvoorbeeld gewijzigd naar slechter).
Gebruik deze weergave om waargenomen prestatieproblemen in uw toepassing te correleren met de werkelijke query's die moeten worden opgelost of verbeterd.
algemeen resourceverbruik Analyseer het totale resourceverbruik voor de database voor een van de metrische uitvoeringsgegevens.
Gebruik deze weergave om resourcepatronen (dagelijks versus nachtworkloads) te identificeren en het algehele verbruik voor uw database te optimaliseren.
Hoogst gebruikende resource-vragenuitslagen Kies een interessante uitvoeringswaarde en identificeer query's met de meest extreme waarden voor een opgegeven tijdsinterval.
Gebruik deze weergave om uw aandacht te richten op de meest relevante query's die het grootste effect hebben op het verbruik van databaseresources.
Queries met afgedwongen plannen Hiermee geeft u vroege geforceerde plannen weer met behulp van Query Store.
Gebruik deze weergave om snel toegang te krijgen tot alle momenteel geforceerde abonnementen.
Zoekopdrachten met een hoge variatie Analyseer queries met grote uitvoeringsvariatie voor zover het betrekking heeft op een van de beschikbare dimensies, zoals duur, CPU-tijd, IO en geheugengebruik, in het gewenste tijdsinterval.
Gebruik deze weergave om query's te identificeren met veel variantprestaties die van invloed kunnen zijn op de gebruikerservaring in uw toepassingen.
querywachtstatistieken Analyseer wachtcategorieën die het actiefst zijn in een database en welke query's het meeste bijdragen aan de geselecteerde wachtcategorie.
Gebruik deze weergave om wachtstatistieken te analyseren en query's te identificeren die van invloed kunnen zijn op de gebruikerservaring in uw toepassingen.

Van toepassing op: te beginnen met SQL Server Management Studio v18.0 en SQL Server 2017 (14.x).
Geregistreerde zoekopdrachten Houd de uitvoering van de belangrijkste query's in realtime bij. Normaal gesproken gebruikt u deze weergave wanneer u query's met geforceerde plannen hebt en u ervoor wilt zorgen dat de queryprestaties stabiel zijn.

Tip

Zie Query Store Azure Blogsvoor een gedetailleerde beschrijving van het gebruik van Management Studio om de meest resources verbruikende query's te identificeren en om de query's te corrigeren die zijn gewijzigd als gevolg van een verandering in plankeuze.

Wanneer u een query met suboptimale prestaties identificeert, is uw actie afhankelijk van de aard van het probleem.

  • Als de query is uitgevoerd met meerdere plannen en het laatste plan aanzienlijk slechter is dan het vorige plan, kunt u het planforceringsmechanisme gebruiken om het af te dwingen. SQL Server probeert het plan af te dwingen in de optimizer. Als het afdwingen van plannen mislukt, wordt een XEvent geactiveerd en wordt de optimizer geïnstrueerd om op de normale manier te optimaliseren.

Schermopname van SSMS van de knop

Notitie

De vorige afbeelding kan verschillende vormen bevatten voor specifieke queryplannen, met de volgende betekenissen voor elke mogelijke status:

Vorm Betekenis
Cirkel De query is voltooid, wat betekent dat een reguliere uitvoering succesvol is afgerond.
Vierkant Geannuleerd, wat betekent dat een door de client geïnitieerde afgebroken uitvoering.
Driehoek Mislukt, wat betekent dat de uitvoering is afgebroken door een uitzondering.

De grootte van de shape weerspiegelt ook het aantal queryuitvoeringen binnen het opgegeven tijdsinterval. De grootte neemt toe naarmate het aantal uitvoeringen toeneemt.

  • U kunt concluderen dat er een index ontbreekt voor een optimale uitvoering van uw query. Deze informatie wordt weergegeven in het queryuitvoeringsplan. Maak de ontbrekende index en controleer de queryprestaties met behulp van Query Store.

Schermopname van SSMS van een Query Store-plan, met de ontbrekende indexmelding gemarkeerd.

Als u uw workload uitvoert op SQL Database, meldt u zich aan voor SQL Database Index Advisor om automatisch indexaan aanbevelingen te ontvangen.

  • In sommige gevallen kunt u statistiekhercompilatie afdwingen als u ziet dat het verschil tussen het geschatte en het werkelijke aantal rijen in het uitvoeringsplan aanzienlijk is.
  • Herschrijf problematische query's bijvoorbeeld om te profiteren van queryparameterisatie of om optimalere logica te implementeren.

Tip

Houd in Azure SQL Database rekening met de Query Store-hints functie voor het afdwingen van queryhints voor query's zonder codewijzigingen. Zie Query Store-hintsvoor meer informatie en voorbeelden.

Controleer of Query Store continu querygegevens verzamelt

Query Store kan de bewerkingsmodus op de achtergrond wijzigen. Controleer regelmatig de status van Query Store om ervoor te zorgen dat Query Store actief is en om actie te ondernemen om fouten te voorkomen vanwege te voorkomen oorzaken. Voer de volgende query uit om de bewerkingsmodus te bepalen en de meest relevante parameters weer te geven:

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

Het verschil tussen de actual_state_desc en desired_state_desc geeft aan dat er automatisch een wijziging van de bewerkingsmodus is opgetreden. De meest voorkomende wijziging is dat Query Store op de achtergrond overschakelt naar de modus Alleen-lezen. In zeer zeldzame gevallen kan Query Store vanwege interne fouten in de status ERROR terechtkomen.

Wanneer de werkelijke status het kenmerk Alleen-lezen heeft, gebruikt u de kolom readonly_reason om de hoofdoorzaak te bepalen. Normaal gesproken vindt u dat Query Store is overgezet naar de modus Alleen-lezen omdat het quotum voor de grootte is overschreden. In dat geval is de readonly_reason ingesteld op 65536. Zie om andere redenen sys.database_query_store_options (Transact-SQL).

Overweeg de volgende stappen om van Query Store over te schakelen naar de lees-/schrijfmodus en het activeren van gegevensverzameling:

  • Verhoog de maximale opslaggrootte met behulp van de optie MAX_STORAGE_SIZE_MB van ALTER DATABASE.

  • Query Store-gegevens opschonen met behulp van de volgende instructie:

    SQL 
    ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;

U kunt een of beide stappen toepassen door de volgende instructie uit te voeren waarmee de bewerkingsmodus expliciet wordt gewijzigd in lezen/schrijven:

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

Voer de volgende stappen uit om proactief te zijn:

  • U kunt stille wijzigingen in de bewerkingsmodus voorkomen door aanbevolen procedures toe te passen. Zorg ervoor dat de grootte van Query Store altijd lager is dan de maximaal toegestane waarde om de kans op een overgang naar de modus Alleen-lezen aanzienlijk te verminderen. Activeer op grootte gebaseerd beleid zoals beschreven in de sectie Query Store configureren, zodat Query Store automatisch gegevens opschoont wanneer de grootte de limiet nadert.
  • Als u ervoor wilt zorgen dat de meest recente gegevens worden bewaard, configureert u op tijd gebaseerd beleid om verouderde informatie regelmatig te verwijderen.
  • Ten slotte kunt u Query Store Capture Mode instellen om automatisch te, omdat hiermee query's worden gefilterd die meestal minder relevant zijn voor uw workload.

FOUTstatus

Als u Query Store wilt herstellen, stelt u de lees-/schrijfmodus expliciet in en controleert u de werkelijke status opnieuw.

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

Als het probleem zich blijft voordoen, geeft dit aan dat beschadiging van Query Store-gegevens op de schijf blijft bestaan.

Vanaf SQL Server 2017 (14.x) kan Query Store worden hersteld door de sys.sp_query_store_consistency_check opgeslagen procedure in de betrokken database uit te voeren. Query Store moet worden uitgeschakeld voordat u de herstelbewerking probeert uit te voeren. Hier volgt een voorbeeldquery die u kunt gebruiken of wijzigen om de consistentiecontrole en het herstel van QDS uit te voeren:

SQL 
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

Voor SQL Server 2016 (13.x) moet u de gegevens uit Query Store wissen zoals wordt weergegeven.

Als het herstel is mislukt, kunt u proberen Query Store op te ruimen voordat u de lees-/schrijfmodus instelt.

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

Vermijd het gebruik van niet-geparameteriseerde query's

Het gebruik van niet-geparameteriseerde query's wanneer dat niet nodig is, is geen best practice. Een voorbeeld hiervan is in het geval van ad-hocanalyse. Plannen in cache kunnen niet opnieuw worden gebruikt, waardoor Query Optimizer wordt gedwongen om query's te compileren voor elke unieke querytekst. Zie Richtlijnen voor het gebruik van geforceerde parametersvoor meer informatie.

Query Store kan ook snel het quotum voor de grootte overschrijden vanwege een potentieel groot aantal verschillende queryteksten en dus een groot aantal verschillende uitvoeringsplannen met een vergelijkbare vorm. Als gevolg hiervan zijn de prestaties van uw workload suboptimaal en kan Query Store overschakelen naar de modus Alleen-lezen of voortdurend gegevens verwijderen om de binnenkomende query's bij te houden.

Houd rekening met de volgende opties:

  • Parameteriseer query's indien van toepassing. U kunt bijvoorbeeld query's verpakken in een opgeslagen procedure of sp_executesql. Zie Parameters en hergebruik van het uitvoeringsplanvoor meer informatie.
  • Gebruik de optie optimaliseren voor ad-hoc workloads als uw workload veel ad-hocbatches die slechts één keer worden gebruikt met verschillende queryplannen bevat.
    • Vergelijk het aantal afzonderlijke query_hash waarden met het totale aantal vermeldingen in sys.query_store_query. Als de verhouding dicht bij 1 ligt, genereert uw ad-hocworkload verschillende query's.
  • Pas geforceerde parameters toe voor de database of voor een subset van query's als het aantal verschillende queryplannen niet groot is.
    • Gebruik een plangids om alleen de parameterisatie af te dwingen voor de geselecteerde query.
    • Configureer geforceerde parameterisatie met behulp van de parameterisatiedatabaseoptie opdracht, als er een klein aantal verschillende queryplannen in uw workload zijn. Een voorbeeld is wanneer de verhouding tussen het aantal afzonderlijke query_hash en het totale aantal vermeldingen in sys.query_store_query veel kleiner is dan 1.
  • Stel QUERY_CAPTURE_MODE in op AUTO om ad-hocquery's automatisch te filteren met een klein resourceverbruik.

Tip

Wanneer u een Object-Relational Toewijzingsoplossing (ORM) gebruikt, zoals Entity Framework (EF), worden toepassingsquery's zoals handmatige LINQ-querystructuren of bepaalde onbewerkte SQL-query's mogelijk niet geparameteriseerd, wat van invloed is op het opnieuw gebruiken van plannen en de mogelijkheid om query's in de Query Store bij te houden. Zie voor meer informatie EF Query-caching en parameterisatie en EF Raw SQL-query's.

Niet-geparameteriseerde query's zoeken in Query Store

U vindt het aantal plannen dat is opgeslagen in Query Store met behulp van de onderstaande query, met behulp van DMV's van Query Store, in SQL Server, Azure SQL Managed Instance of Azure SQL Database:

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

In het volgende voorbeeld wordt er een sessie met Uitgebreide Gebeurtenissen gemaakt om de gebeurtenis query_store_db_diagnosticsvast te leggen, wat handig kan zijn bij het diagnosticeren van het gebruik van queryresources. In SQL Server maakt deze uitgebreide gebeurtenissessie standaard een gebeurtenisbestand in de map SQL Server-logboek. In een standaardinstallatie van SQL Server 2019 (15.x) in Windows moet het gebeurtenisbestand (.xel-bestand) bijvoorbeeld worden gemaakt in de map C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log. Geef voor Azure SQL Managed Instance in plaats daarvan een Azure Blob Storage-locatie op. Zie XEvent-event_file voor Azure SQL Managed Instancevoor meer informatie. De gebeurtenis 'qds.query_store_db_diagnostics' is niet beschikbaar voor Azure SQL Database.

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

Met deze gegevens kunt u het planaantal in de Query Store vinden, evenals vele andere statistieken. Zoek naar de kolommen plan_count, query_count, max_stmt_hash_map_size_kben max_size_mb in de gebeurtenisgegevens om inzicht te krijgen in de hoeveelheid geheugen die wordt gebruikt en het aantal plannen dat door Query Store wordt bijgehouden. Als het aantal plannen hoger is dan normaal, kan dit duiden op een toename van niet-geparameteriseerde query's. Gebruik de onderstaande Query Store DMVs-query om de geparameteriseerde en niet-geparameteriseerde query's in de Query Store te bekijken.

Voor geparameteriseerde query's:

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

Voor niet-geparameteriseerde query's:

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

Vermijd een DROP- en CREATE-patroon voor het bevatten van objecten

Query Store koppelt een queryvermelding aan een bevat object, zoals een opgeslagen procedure, functie en trigger. Wanneer u een bevatd object opnieuw maakt, wordt er een nieuwe queryvermelding gegenereerd voor dezelfde querytekst. Hiermee voorkomt u dat u prestatiestatistieken voor die query in de loop van de tijd kunt bijhouden en een mechanisme voor het afdwingen van een plan gebruikt. Als u deze situatie wilt voorkomen, gebruikt u het ALTER <object> proces om een objectdefinitie te wijzigen wanneer dit mogelijk is.

Controleer regelmatig de status van gedwongen plannen

Het afdwingen van plannen is een handig mechanisme om de prestatie van kritieke query's te verbeteren en voorspelbaarder te maken. Net als bij planhints en planhandleidingen is het afdwingen van een plan geen garantie dat het in toekomstige uitvoeringen wordt gebruikt. Wanneer het databaseschema op een manier verandert dat de objecten waarnaar het uitvoeringsplan verwijst, worden gewijzigd of verwijderd, begint het afdwingen van het plan te falen. In dat geval valt SQL Server terug op queryhercompilatie, terwijl de werkelijke reden voor het mislukken van de afdwingpoging wordt uitgewerkt in sys.query_store_plan. De volgende query retourneert informatie over geforceerde plannen:

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

Zie sys.query_store_planvoor een volledige lijst met redenen. U kunt ook de query_store_plan_forcing_failed XEvent gebruiken om het mislukken van plan forcing bij te houden en op te lossen.

Tip

Houd in Azure SQL Database rekening met de Query Store-hints functie voor het afdwingen van queryhints voor query's zonder codewijzigingen. Zie Query Store-hintsvoor meer informatie en voorbeelden.

Vermijd hernoemen van databases voor query's met geforceerde plannen

Uitvoeringsplannen verwijzen naar objecten met behulp van driedelige namen, zoals database.schema.object.

Als u de naam van een database wijzigt, mislukt het afdwingen van plannen, waardoor de hercompilatie in alle volgende queryuitvoeringen wordt veroorzaakt.

Query Store gebruiken op bedrijfskritieke servers

De globale traceringsvlagken 7745 en 7752 kunnen worden gebruikt om de beschikbaarheid van databases te verbeteren met behulp van Query Store. Voor meer informatie, zie Traceervlaggen.

  • Traceringsvlag 7745 voorkomt het standaardgedrag waarbij Query Store gegevens naar schijf schrijft voordat SQL Server kan worden afgesloten. Dit betekent dat Query Store-gegevens die zijn verzameld maar nog niet op de schijf zijn opgeslagen, verloren gaan tot het tijdvenster dat is gedefinieerd met DATA_FLUSH_INTERVAL_SECONDS.
  • Traceringsvlag 7752 maakt asynchroon laden van Query Store mogelijk. Hierdoor kan een database online worden en query's worden uitgevoerd voordat Query Store volledig is hersteld. Het standaardgedrag is om Query Store synchroon te laden. Het standaardgedrag voorkomt dat query's worden uitgevoerd voordat Query Store is hersteld, maar voorkomt ook dat query's worden gemist in de gegevensverzameling.

Notitie

Vanaf SQL Server 2019 (15.x) wordt dit gedrag beheerd door de engine en heeft traceringsvlag 7752 geen effect.

Belangrijk

Als u Query Store gebruikt voor Just-In-Time-workloadinzichten in SQL Server 2016 (13.x), wilt u de verbeteringen voor schaalbaarheid van prestaties in SQL Server 2016 (13.x) SP2 CU2 (KB 4340759) zo snel mogelijk installeren. Zonder deze verbeteringen kan er sprake zijn van spinlockconflicten wanneer de database zwaar wordt belast en kunnen de serverprestaties traag worden. Met name zou u mogelijk sterke conflicten op de QUERY_STORE_ASYNC_PERSIST spinlock of SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlock kunnen zien. Nadat deze verbetering is toegepast, zal Query Store geen spinlockconflicten meer veroorzaken.

Belangrijk

Als u Query Store gebruikt voor just-in-time-werkbelastinginzichten in SQL Server (SQL Server 2016 (13.x) tot en met SQL Server 2017 (14.x)), plan om de verbeterde prestatieschaalbaarheid in SQL Server 2016 (13.x) SP2 CU15, SQL Server 2017 (14.x) CU23 en SQL Server 2019 (15.x) CU9 zo snel mogelijk te installeren. Zonder deze verbetering kan de Query Store, wanneer de database onder zware ad-hocworkloads valt, een grote hoeveelheid geheugen gebruiken en de serverprestaties langzaam worden. Nadat deze verbetering is toegepast, legt Query Store interne limieten op voor de hoeveelheid geheugen die de verschillende onderdelen ervan kunnen gebruiken en kan de bewerkingsmodus automatisch worden gewijzigd in alleen-lezen totdat er voldoende geheugen is teruggezet naar de database-engine. Interne geheugenlimieten van Query Store worden niet gedocumenteerd omdat ze onderhevig zijn aan wijzigingen.

Query Store gebruiken in actieve geo-replicatie in Azure SQL Database

Query Store op een secundaire actieve geo-replica van Azure SQL Database is een alleen-lezen kopie van de activiteit op de primaire replica.

Vermijd niet-overeenkomende lagen met geo-replicatie van Azure SQL Database. Een secundaire database moet zich op dezelfde rekenkracht van de primaire database bevinden en zich in dezelfde servicelaag van de primaire database bevinden. Zoek naar het HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO-wachttype in sys.dm_db_wait_stats, wat wijst op beperking van transactielogboek snelheid bij de primaire replica door secundaire vertraging.

Zie Secundaire database configurerenvoor meer informatie over het schatten en configureren van de grootte van de secundaire Azure SQL-database van actieve geo-replicatie.

Houd Query Store aangepast aan uw belastingsprofiel

Aanbevolen procedures en aanbevelingen voor het configureren en beheren van Query Store zijn in dit artikel uitgebreid: Aanbevolen procedures voor het beheren van de Query Store-.

Verwante inhoud