Query Store

Query Store är en funktion i en flexibel Azure Database for PostgreSQL-serverinstans som ger ett sätt att spåra frågeprestanda över tid. Query Store förenklar felsökningen av prestandaproblem genom att hjälpa dig att snabbt hitta de längsta och mest resursintensiva frågorna. Frågearkivet samlar automatiskt in en historik över frågor och körningsstatistik och behåller dem för din granskning. Den delar upp data efter tid så att du kan se tidsmässiga användningsmönster. Data för alla användare, databaser och sökningar lagras i en databas med namnet azure_sys i Azure Database for PostgreSQL flexibil serverinstans.

Aktivera frågearkiv

Query Store är tillgängligt att använda utan extra avgifter. Det är en opt-in-funktion, så den är inte aktiverad som standard på en server. Frågearkiv kan aktiveras eller inaktiveras globalt för alla databaser på en viss server och kan inte aktiveras eller inaktiveras per databas.

Aktivera frågearkiv i Azure Portal

1. Logga in på Azure Portal och välj din flexibla Serverinstans för Azure Database for PostgreSQL.
2. Välj Serverparametrar i avsnittet Inställningar på menyn.
3. Sök efter parametern pg_qs.query_capture_mode .
4. Ange värdet till top eller all, beroende på om du vill spåra frågor på den översta nivån eller även kapslade frågor (de som körs i en funktion eller procedur) och välj Spara. Tillåt upp till 20 minuter för den första databatchen att sparas i azure_sys databasen.

Aktivera väntesampling för frågelagring

1. Sök efter parametern pgms_wait_sampling.query_capture_mode .
2. Ange värdet till all och Spara.

Information i frågearkivet

Frågelager består av två lager:

• Ett statistiklager för körningstid för att bevara information om utföranden av frågestatistik.
• Ett väntestatistikarkiv för att spara information om väntestatistik.

Vanliga scenarier för att använda frågearkivet är:

• Fastställa hur många gånger en fråga kördes under en viss tidsperiod.
• Jämföra den genomsnittliga exekveringstiden för en fråga över olika tidsintervall för att observera stora variationer.
• Identifiera de frågor som har körts längst under de senaste timmarna.
• Identifiera de främsta N-frågorna som väntar på resurser.
• Förstå typen av väntetider för en viss fråga.

För att minimera utrymmesanvändningen aggregeras körstatistiken i körstatistikarkivet över ett fast, konfigurerbart tidsfönster. Informationen i dessa butiker kan efterfrågas med hjälp av vyer.

Åtkomst till information om frågearkiv

Frågelagringsdata lagras i azure_sys databasen på din flexibla Azure Database for PostgreSQL-serverinstans. Följande fråga returnerar information om frågor som har registrerats i frågearkivet:

SELECT * FROM  query_store.qs_view;

Och den här frågan returnerar information om väntande statistik:

SELECT * FROM  query_store.pgms_wait_sampling_view;

Hitta väntefrågor

Väntehändelsetyper kombinerar olika väntehändelser i bucketar efter likhet. Frågearkivet innehåller typen av väntehändelse, ett specifikt namn på väntehändelsen och frågan i fråga. Om du kan korrelera den här vänteinformationen med frågekörningsstatistiken kan du få en djupare förståelse för vad som bidrar till frågeprestandaegenskaper.

Här följer några exempel på hur du kan få mer insikter om din arbetsbelastning med hjälp av väntestatistiken i frågearkivet:

Konfigurationsalternativ

När frågearkivet är aktiverat sparar det data i aggregeringsfönster med längd som bestäms av serverparametern pg_qs.interval_length_minutes (standardvärdet är 15 minuter). För varje fönster lagras upp till 500 distinkta frågor per fönster. Attribut som särskiljer unikheten för varje fråga är user_id (identifierare för användaren som kör frågan), db_id (identifierare för databasen i vars kontext frågan körs) och query_id (ett heltalsvärde som unikt identifierar frågan som körs). Om antalet distinkta frågor når 500 under det konfigurerade intervallet frigörs 5 % av de som registreras för att göra plats för fler. De som avallokeras först är de som kördes minst antal gånger.

Följande alternativ är tillgängliga för att konfigurera Query Store-parametrar:

Följande alternativ gäller specifikt för väntestatistik:

Använd Azure Portal för att hämta eller ange ett annat värde för en parameter.

Vyer och funktioner

Du kan köra frågor mot den information som registreras av frågearkivet och/eller ta bort den med hjälp av vissa vyer och funktioner som är tillgängliga i query_store-schemat för azure_sys-databasen. Vem som helst i den offentliga PostgreSQL-rollen kan använda dessa vyer för att se data i frågearkivet. Dessa vyer är endast tillgängliga i azure_sys-databasen.

Frågor normaliseras genom att titta på deras struktur och ignorera allt som inte är semantiskt betydelsefullt, till exempel literaler, konstanter, alias eller skillnader i hölje.

Om två frågor är semantiskt identiska, även om de använder olika alias för samma refererade kolumner och tabeller, identifieras de med samma query_id. Om två frågor bara skiljer sig åt i de literalvärden som används i dem identifieras de också med samma query_id. För frågor som identifieras med samma query_id är deras sql_query_text den fråga som kördes först sedan frågearkivet startade inspelningsaktiviteten, eller sedan den senaste gången de sparade data togs bort eftersom funktionen query_store.qs_reset kördes.

Så här fungerar frågenormalisering

Här följer några exempel för att försöka illustrera hur den här normaliseringen fungerar:

Anta att du skapar en tabell med följande instruktion:

create table tableOne (columnOne int, columnTwo int);

Du aktiverar Query Store-datainsamling och en eller flera användare kör följande frågor i exakt den här ordningen:

select * from tableOne;
select columnOne, columnTwo from tableOne;
select columnOne as c1, columnTwo as c2 from tableOne as t1;
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one";

Alla tidigare frågor delar samma query_id. Och texten som Query Store behåller är den för den första frågan som körs efter aktivering av datainsamling. Därför skulle det vara select * from tableOne;.

Följande uppsättning frågor, när de har normaliserats, matchar inte den tidigare uppsättningen frågor eftersom WHERE-satsen gör dem semantiskt olika:

select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
select * from tableOne where columnOne = -3 and columnTwo = -3;
select columnOne, columnTwo from tableOne where columnOne = '5' and columnTwo = '5';
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = 7 and columnTwo = 7;

Alla frågor i den senaste uppsättningen delar dock samma query_id och den text som används för att identifiera dem alla är den första frågan i batchen select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.

Slutligen hittar du nedan några frågor som inte matchar query_id av dem i föregående batch och orsaken till att de inte gör det:

Fråga:

select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;

Orsak till att den inte matchar: Listan över kolumner refererar till samma två kolumner (columnOne och ColumnTwo), men ordningen som de hänvisas till är omvänd, från columnOne, ColumnTwo i föregående batch till ColumnTwo, columnOne i den här frågan.

Fråga:

select * from tableOne where columnTwo = 25 and columnOne = 25;

Orsak till att inte matcha: Ordningen där de uttryck som utvärderas i WHERE-satsen refereras återförs från columnOne = ? and ColumnTwo = ? i föregående batch till ColumnTwo = ? and columnOne = ? i den här frågan.

Fråga:

select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;

Orsak till att inte matcha: Det första uttrycket i kolumnlistan är inte columnOne längre, utan funktionen abs utvärderas över columnOne (abs(columnOne)), vilket inte är semantiskt likvärdigt.

Fråga:

select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;

Orsak till att inte matcha: Det första uttrycket i WHERE-satsen utvärderar inte likheten columnOne med en literal längre, utan med resultatet av funktionen ceiling utvärderad över en literal, vilket inte är semantiskt likvärdigt.

Views

query_store.qs_view

Den här vyn returnerar alla data som sparas i stödtabellerna i frågearkivet. Data som fortfarande registrerar minnesinternt för det aktuella aktiva tidsfönstret visas inte förrän tidsfönstret har upphört och dess minnesinterna data samlas in och sparas i tabeller som lagras på disken. Den här vyn returnerar en annan rad för varje distinkt databas (db_id), användare (user_id) och fråga (query_id).

frågebutik.förfrågnings_text_vy

Den här vyn returnerar frågetextdata i Query Store. Det finns en rad för varje unik query_sql_text.

query_store.pgms_wait_sampling_view

Den här vyn returnerar väntehändelser i Query Store. Den här vyn returnerar en annan rad för varje distinkt databas (db_id), användare (user_id), fråga (query_id) och händelse (händelse).

query_store.query_plans_view

Den här vyn returnerar frågeplanen som användes för att exekvera en fråga. Det finns en rad per varje distinkt databas-ID och fråge-ID. Frågearkivet registrerar endast frågeplaner för frågor som inte används.

Functions

query_store.qs_reset

Den här funktionen tar bort all statistik som hittills samlats in av Query Store. Den tar bort statistiken för redan stängda tidsfönster, som redan finns kvar i disktabeller. Den tar också bort statistiken för det aktuella tidsfönstret, som bara finns i minnet. Endast medlemmar i serveradministratörsrollen (azure_pg_admin) kan köra den här funktionen.

query_store.staging_data_reset

Den här funktionen raderar all statistik som samlats in i minnet av frågelagring (det vill säga, data i minnet som ännu inte har skrivits till disktabellerna som stöder beständighet av insamlade data för frågelagring). Endast medlemmar i serveradministratörsrollen (azure_pg_admin) kan köra den här funktionen.

Skrivskyddat läge

När en flexibel Azure Database for PostgreSQL-serverinstans är i skrivskyddat läge, till exempel när parametern default_transaction_read_only är inställd på on, eller om skrivskyddat läge aktiveras automatiskt på grund av att lagringskapaciteten har nåtts, samlar frågearkivet inte in några data.

Om du aktiverar frågearkivet på en server som har läsrepliker aktiveras inte automatiskt frågearkiv på någon av de lästa replikerna. Även om du aktiverar det på någon av läsreplikerna, registrerar inte frågearkivet de frågor som körs på läsrepliker, eftersom de fungerar i läsläge tills du uppgraderar dem till primära.

Relaterat innehåll

• Användningsscenarier för frågearkiv
• Metodtips för frågearkiv
• Query Performance Insight