Udostępnij za pośrednictwem

Magazyn zapytań SQL

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Magazyn zapytań to funkcja na serwerze elastycznym usługi Azure Database for PostgreSQL, która umożliwia śledzenie wydajności zapytań w czasie. Magazyn zapytań upraszcza rozwiązywanie problemów z wydajnością, ułatwiając szybkie znajdowanie najdłużej działających i najbardziej intensywnie korzystających z zasobów zapytań. Magazyn zapytań automatycznie przechwytuje historię zapytań i statystyk środowiska uruchomieniowego i zachowuje je do przeglądu. Przycina dane według czasu, żeby można było zobaczyć czasowe wzorce użycia. Dane dla wszystkich użytkowników, baz danych i zapytań są przechowywane w bazie danych o nazwie azure_sys w wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL.

Włączanie magazynu zapytań

Magazyn zapytań jest dostępny do użycia bez dodatkowych opłat. Jest to funkcja zgody, więc nie jest domyślnie włączona na serwerze. Magazyn zapytań można włączyć lub wyłączyć globalnie dla wszystkich baz danych na danym serwerze i nie można włączyć ani wyłączyć dla każdej bazy danych.

Ważne

Nie włączaj magazynu zapytań w elastycznej warstwie cenowej, ponieważ może to spowodować pogorszenie wydajności.

Włącz magazyn zapytań w Portalu Azure

  1. Zaloguj się do portalu Azure i wybierz wystąpienie elastycznego serwera Azure Database for PostgreSQL.
  2. Wybierz pozycję Parametry serwera w sekcji Ustawienia menu.
  3. Wyszukaj parametr pg_qs.query_capture_mode.
  4. Ustaw wartość na top lub all, w zależności od tego, czy chcesz śledzić zapytania najwyższego poziomu, czy też zagnieżdżone zapytania (te, które są wykonywane wewnątrz funkcji lub procedury), a następnie wybierz pozycję Zapisz. Poczekaj do 20 minut, aż pierwsza partia danych będzie utrwalana w azure_sys bazie danych.

Włącz próbkowanie oczekiwania przechowywania zapytań

  1. Wyszukaj parametr pgms_wait_sampling.query_capture_mode.
  2. Ustaw wartość na all i Zapisz.

Informacje w sklepie zapytań

Magazyn zapytań składa się z dwóch magazynów:

  • Magazyn statystyk środowiska uruchomieniowego do utrwalania informacji dotyczących statystyk wykonywania zapytań.
  • Magazyn statystyk oczekiwań do przechowywania informacji o statystykach oczekiwań.

Typowe scenariusze korzystania z magazynu zapytań obejmują:

  • Określenie, ile razy zapytanie zostało wykonane w danym przedziale czasu.
  • Porównanie średniego czasu wykonywania zapytania w oknach czasowych, aby zobaczyć duże różnice.
  • Znajdowanie zapytań działających najdłużej w ciągu ostatnich kilku godzin.
  • Identyfikowanie najważniejszych N zapytań oczekujących na zasoby.
  • Zrozumienie charakteru oczekiwania dla określonego zapytania.

Aby zminimalizować użycie miejsca, statystyki wykonywania środowiska uruchomieniowego w magazynie statystyk środowiska uruchomieniowego są agregowane w stałym, konfigurowalnym przedziale czasu. Informacje w tych magazynach można uzyskiwać za pomocą widoków.

Uzyskiwanie dostępu do informacji o repozytorium zapytań

Dane repozytorium zapytań są przechowywane w bazie danych azure_sys na wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL. Następujące zapytanie zwraca informacje o zapytaniach zarejestrowanych w magazynie zapytań:

SELECT * FROM  query_store.qs_view;

To zapytanie zwraca informacje o statystykach oczekiwania:

SELECT * FROM  query_store.pgms_wait_sampling_view;

Znajdź zapytania oczekujące

Typy zdarzeń oczekiwania łączą różne zdarzenia oczekiwania w grupy według ich podobieństwa. Magazyn zapytań udostępnia typ zdarzenia oczekiwania, konkretną nazwę zdarzenia oczekiwania i pytanie. Możliwość skorelowania tych informacji oczekiwania ze statystykami środowiska uruchomieniowego zapytania oznacza, że możesz lepiej zrozumieć, co przyczynia się do charakterystyki wydajności zapytań.

Poniżej przedstawiono kilka przykładów sposobu uzyskania większego wglądu w obciążenie przy użyciu statystyk oczekiwania w magazynie zapytań:

Obserwacja Akcja
Długie czasy oczekiwania na blokady Sprawdź teksty zapytań pod kątem zapytań, których dotyczy problem, i zidentyfikuj jednostki docelowe. Poszukaj w magazynie zapytań innych zapytań, które są wykonywane często i modyfikują ten sam obiekt i/lub mają wysoki czas trwania. Po zidentyfikowaniu tych zapytań rozważ zmianę logiki aplikacji w celu poprawy współbieżności lub użyj mniej restrykcyjnego poziomu izolacji.
Wysoki czas oczekiwania I/O buforu Znajdź zapytania z dużą liczbą odczytów fizycznych w repozytorium zapytań. Jeśli odpowiadają zapytaniom z dużymi opóźnieniami we/wy, rozważ włączenie funkcji automatycznego dostrajania indeksów, aby sprawdzić, czy może zalecić utworzenie niektórych indeksów, które mogą zmniejszyć liczbę fizycznych odczytów dla tych zapytań.
Opóźnienia spowodowane dużym zużyciem pamięci Znajdź zapytania zużywające najwięcej pamięci w magazynie zapytań. Te zapytania prawdopodobnie opóźniają dalszy postęp zapytań, których dotyczy problem.

Opcje konfiguracji

Gdy magazyn zapytań jest włączony, zapisuje dane w oknach agregacji długości określonej przez parametr serwera pg_qs.interval_length_minutes (domyślnie to 15 minut). Dla każdego okna przechowuje maksymalnie 500 odrębnych zapytań na okno. Atrybuty, które odróżniają unikatowość każdego zapytania, są user_id (identyfikator użytkownika wykonującego zapytanie), db_id (identyfikator bazy danych, w którym kontekst wykonuje zapytanie) i query_id (unikatowa wartość całkowita identyfikującą wykonane zapytanie). Jeśli liczba unikatowych zapytań osiągnie 500 w skonfigurowanym interwale, 5% zarejestrowanych zostanie cofnięty przydział, aby zapewnić więcej miejsca. Te, które zostają najpierw zwolnione z przydziałów, to te, które były wykonane najrzadziej.

Dostępne są następujące opcje konfigurowania parametrów magazynu zapytań:

Parametr Opis Wartość domyślna Zakres
pg_qs.interval_length_minutes (*) Interwał przechwytywania w minutach dla magazynu zapytań. Definiuje częstotliwość trwałości danych. 15 1 - 30
pg_qs.is_enabled_fs Tylko użycie wewnętrzne: ten parametr jest używany jako przełącznik zastąpienia funkcji. Jeśli jest wyświetlany jako wyłączony, magazyn zapytań jest wyłączony, pomimo wartości ustawionej dla elementu pg_qs.query_capture_mode. on on, off
pg_qs.max_plan_size Maksymalna liczba bajtów zapisanych z tekstu planu zapytania według magazynu zapytań; dłuższe plany są obcinane. 7500 100 - 10000
pg_qs.max_query_text_length Maksymalna długość zapytania, którą można zapisać; dłuższe zapytania są obcinane. 6000 100 - 10000
pg_qs.parameters_capture_mode Określa, czy i kiedy należy przechwytywać parametry pozycyjne zapytania. capture_parameterless_only capture_parameterless_only, capture_first_sample
pg_qs.query_capture_mode Oświadczenia do śledzenia. none none, top, all
pg_qs.retention_period_in_days Okno okresu przechowywania w dniach dla magazynu zapytań. Starsze dane są usuwane automatycznie. 7 1 - 30
pg_qs.store_query_plans To, czy plany zapytań powinny być zapisywane w repozytorium zapytań. off on, off
pg_qs.track_utility Czy magazyn zapytań musi śledzić komendy użytkowe. on on, off

(*) Parametr serwera statycznego, który wymaga ponownego uruchomienia serwera, aby zmiany jego wartości zaczęły obowiązywać.

Uwaga / Notatka

Jeśli zmienisz wartość pg_qs.max_query_text_length parametru, tekst wszystkich zapytań przechwyconych przed wprowadzeniem zmiany będzie nadal używać tych samych query_id i sql_query_text. Może to sprawić wrażenie, że nowa wartość nie zacznie obowiązywać, ale w przypadku zapytań, które nie zostały wcześniej zarejestrowane w magazynie zapytań, zobaczysz, że tekst zapytania używa nowo skonfigurowanej maksymalnej długości. Tak jest zaplanowane i wyjaśnione w Widoki i funkcje. Jeśli wykonasz query_store.qs_reset, usunie wszystkie informacje zarejestrowane przez magazyn zapytań do tej pory, w tym tekst przechwycony dla każdego identyfikatora zapytania, a jeśli którykolwiek z tych zapytań zostanie wykonany ponownie, nowo skonfigurowana maksymalna długość zostanie zastosowana do przechwyconego tekstu.

Następujące opcje mają zastosowanie specjalnie do statystyk oczekiwania:

Parametr Opis Wartość domyślna Zakres
pgms_wait_sampling.history_period Częstotliwość próbkowania zdarzeń oczekiwania, wyrażona w milisekundach. 100 1 - 600000
pgms_wait_sampling.is_enabled_fs Tylko użycie wewnętrzne: ten parametr jest używany jako przełącznik zastąpienia funkcji. Jeśli jest on wyświetlany jako off, oznacza to, że próbkowanie oczekiwania jest wyłączone, mimo wartości ustawionej dla pgms_wait_sampling.query_capture_mode. on on, off
pgms_wait_sampling.query_capture_mode Które oświadczenia musi śledzić rozszerzenie pgms_wait_sampling. none none, all

Uwaga / Notatka

pg_qs.query_capture_mode pgms_wait_sampling.query_capture_modezastępuje . Jeśli pg_qs.query_capture_mode wartość to none, pgms_wait_sampling.query_capture_mode ustawienie nie ma żadnego wpływu.

Użyj witryny Azure Portal , aby uzyskać lub ustawić inną wartość parametru.

Widoki i funkcje

Możesz wykonywać zapytania dotyczące informacji zarejestrowanych przez magazyn zapytań i usuwać je przy użyciu niektórych widoków i funkcji dostępnych w query_store schemacie azure_sys bazy danych. Każdy, kto posiada rolę publiczną w PostgreSQL, może używać tych widoków do wyświetlania danych w store zapytań. Te widoki są dostępne tylko w bazie danych azure_sys .

Zapytania są normalizowane poprzez analizę ich struktury i ignorując wszystko, co nie jest semantycznie istotne, na przykład literały, stałe, aliasy lub różnice w wielkości liter.

Jeśli dwa zapytania są semantycznie identyczne, nawet jeśli używają różnych aliasów dla tych samych przywoływanych kolumn i tabel, są one identyfikowane z tym samym query_id. Jeśli dwa zapytania różnią się tylko wartościami literalnymi używanymi w nich, to są również identyfikowane tym samym query_id. W przypadku zapytań zidentyfikowanych tym samym query_id, ich sql_query_text to zapytanie, które zostało wykonane jako pierwsze od momentu, gdy magazyn zapytań zaczął rejestrować aktywność lub od ostatniego usunięcia utrwalonych danych, w wyniku uruchomienia funkcji query_store.qs_reset.

Jak działa normalizacja zapytań

Poniżej przedstawiono kilka przykładów, aby spróbować zilustrować, jak działa normalizacja:

Załóżmy, że tworzysz tabelę z następującą instrukcją:

create table tableOne (columnOne int, columnTwo int);

Włączasz zbieranie danych magazynu zapytań, a jeden lub wielu użytkowników wykonuje następujące zapytania w tej dokładnej kolejności:

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

Wszystkie poprzednie zapytania współdzielą te same query_id. Repozytorium zapytań przechowuje tekst pierwszego zapytania wykonanego po włączeniu zbierania danych. W związku z tym byłoby to select * from tableOne;.

Następujący zestaw zapytań, po normalizacji, nie pasuje do poprzedniego zestawu zapytań, ponieważ klauzula WHERE sprawia, że są one semantycznie różne:

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;

Jednak wszystkie zapytania w tym ostatnim zestawie współużytkują te same query_id, a tekst użyty do zidentyfikowania ich wszystkich to pierwsze zapytanie w partii select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.

Na zakończenie przedstawiamy kilka zapytań, których identyfikatory query_id nie pasują do tych z poprzedniej grupy, oraz powód, dla którego nie pasują.

Zapytanie:

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

Przyczyna braku dopasowania: Lista kolumn odwołuje się do tych samych dwóch kolumn (columnOne i ColumnTwo), ale kolejność ich odwołania jest odwrócona, od columnOne, ColumnTwo w poprzedniej partii do ColumnTwo, columnOne w tym zapytaniu.

Zapytanie:

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

Powód braku dopasowania: Kolejność, w której wyrażenia są oceniane w klauzuli WHERE, została zmieniona z columnOne = ? and ColumnTwo = ? w poprzedniej partii na ColumnTwo = ? and columnOne = ? w tym zapytaniu.

Zapytanie:

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

Przyczyna braku dopasowania: pierwsze wyrażenie na liście kolumn nie jest już columnOne, lecz funkcja abs obliczona z columnOne (abs(columnOne)), która nie jest semantycznie równoważna.

Zapytanie:

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

Przyczyna braku dopasowania: pierwsze wyrażenie w klauzuli WHERE nie ocenia już równości columnOne z literałem, ale z wynikiem funkcji ceiling obliczonej na literał, który nie jest semantycznie równoważny.

Widoki

query_store.qs_view

Ten widok zwraca wszystkie dane, które są przechowywane w wspierających tabelach magazynu zapytań. Dane, które są nadal rejestrowane w pamięci dla obecnie aktywnego przedziału czasu, nie są widoczne, dopóki ten przedział nie dobiegnie końca i jego nietrwałe dane w pamięci tymczasowej zostaną zebrane i utrwalone w tabelach przechowywanych na dysku. Ten widok zwraca inny wiersz dla każdej odrębnej bazy danych (db_id), użytkownika (user_id) i zapytania (query_id).

Nazwa Typ Dokumentacja Opis
runtime_stats_entry_id Bigint powiedział: Identyfikator z tabeli runtime_stats_entries.
user_id Oid pg_authid.oid Identyfikator OID użytkownika, który wykonał instrukcję .
db_id Oid pg_database.oid Identyfikator OID bazy danych, w której wykonano instrukcję.
query_id Bigint powiedział: Wewnętrzny kod skrótu obliczany z drzewa analizy wyrażenia.
query_sql_text varchar(10000) Tekst oświadczenia przedstawiciela. Różne zapytania o tej samej strukturze są grupowane razem; ten tekst jest tekstem pierwszego zapytania w klastrze. Wartość domyślna maksymalnej długości tekstu zapytania to 6000 i można ją zmodyfikować przy użyciu parametru pg_qs.max_query_text_lengthmagazynu zapytań . Jeśli tekst zapytania przekracza tę maksymalną wartość, zostanie obcięty do pierwszych pg_qs.max_query_text_length bajtów.
plan_id Bigint powiedział: Identyfikator planu odpowiadającego temu zapytaniu.
start_time Sygnatura czasowa Zapytania są agregowane według okien czasowych. Parametr pg_qs.interval_length_minutes serwera definiuje przedział czasu tych okien (wartość domyślna to 15 minut). Ta kolumna odpowiada czasowi rozpoczęcia okna, w którym zarejestrowano ten wpis.
end_time Sygnatura czasowa Godzina zakończenia odpowiadająca przedziałowi czasu dla tego wpisu.
calls Bigint powiedział: Ile razy zapytanie zostało wykonane w tym przedziale czasu. Zwróć uwagę, że w przypadku zapytań równoległych liczba wywołań dla każdego wykonania odpowiada 1 procesowi zaplecza, który napędza wykonywanie zapytania, oraz tyle innych jednostek dla każdego procesu roboczego zaplecza, które uruchamia się w celu współpracy przy wykonywaniu równoległych gałęzi drzewa wykonywania.
total_time podwójna precyzja Łączny czas wykonywania zapytania w milisekundach.
min_time podwójna precyzja Minimalny czas wykonywania zapytania w milisekundach.
max_time podwójna precyzja Maksymalny czas wykonywania zapytania w milisekundach.
mean_time podwójna precyzja Średni czas wykonywania zapytania w milisekundach.
stddev_time podwójna precyzja Odchylenie standardowe czasu wykonywania zapytania w milisekundach.
rows Bigint powiedział: Łączna liczba wierszy pobranych lub zmienionych przez instrukcję. Zwróć uwagę, że w przypadku zapytań równoległych liczba wierszy dla każdego wykonania odpowiada liczbie wierszy zwróconych klientowi przez proces zaplecza, który napędza wykonywanie zapytania, plus suma wszystkich wierszy, które każdy proces roboczy zaplecza, uruchomiony w celu współpracy przy wykonywaniu równoległych gałęzi drzewa wykonania, zwraca do procesu zaplecza, który napędza wykonywanie zapytania.
shared_blks_hit Bigint powiedział: Łączna liczba trafień w udostępnioną pamięć podręczną bloków przez instrukcję.
shared_blks_read Bigint powiedział: Łączna liczba bloków współdzielonych odczytanych przez zapytanie.
shared_blks_dirtied Bigint powiedział: Łączna liczba bloków udostępnionych i zmodyfikowanych przez instrukcję.
shared_blks_written Bigint powiedział: Łączna liczba zapisanych bloków współdzielonych przez instrukcję.
local_blks_hit Bigint powiedział: Łączna liczba trafień lokalnej pamięci podręcznej bloków na podstawie instrukcji.
local_blks_read Bigint powiedział: Łączna liczba bloków lokalnych odczytanych przez instrukcję .
local_blks_dirtied Bigint powiedział: Łączna liczba bloków lokalnych zabrudowanych przez instrukcję .
local_blks_written Bigint powiedział: Łączna liczba bloków lokalnych zapisanych przez instrukcję .
temp_blks_read Bigint powiedział: Łączna liczba bloków tymczasowych odczytanych przez instrukcję .
temp_blks_written Bigint powiedział: Łączna liczba bloków tymczasowych zapisanych przez instrukcję .
blk_read_time podwójna precyzja Łączny czas, jaki instrukcja spędziła na odczycie bloków, w milisekundach (jeśli track_io_timing jest włączony, w przeciwnym razie zero).
blk_write_time podwójna precyzja Łączny czas spędzony na zapisywaniu bloków w milisekundach (jeśli track_io_timing jest włączony, w przeciwnym razie zero).
is_system_query typ logiczny (boolowski) Określa, czy rola z user_id = 10 (azuresu) wykonała zapytanie. Ten użytkownik ma przywileje superużytkownika i służy do wykonywania operacji w płaszczyźnie kontrolnej. Ponieważ ta usługa jest zarządzaną usługą PaaS, tylko firma Microsoft jest częścią tej roli administratora.
query_type Tekst Typ operacji reprezentowanej przez zapytanie. Możliwe wartości to unknown, select, update, insert, delete, merge, utility, nothing, undefined.
search_path Tekst Wartość search_path ustawiona w momencie przechwycenia zapytania.
query_parameters Tekst Tekstowa reprezentacja obiektu JSON z wartościami przekazanymi do parametrów pozycyjnych zapytania sparametryzowanego. Ta kolumna wypełnia swoją wartość tylko w dwóch przypadkach: 1) dla nieparametrizowanych zapytań. 2) W przypadku zapytań sparametryzowanych, gdy pg_qs.parameters_capture_mode jest ustawione na capture_first_sample, i jeśli magazyn zapytań może pobrać wartości parametrów zapytania w czasie wykonywania.
parameters_capture_status Tekst Typ operacji reprezentowanej przez zapytanie. Możliwe wartości to succeeded (kwerenda nie została sparametryzowana albo została sparametryzowana i wartości zostały pomyślnie przechwycone), disabled (kwerenda została sparametryzowana, ale parametry nie zostały przechwycone, ponieważ pg_qs.parameters_capture_mode ustawiono na capture_parameterless_only), too_long_to_capture (zapytanie zostało sparametryzowane, ale parametry nie zostały przechwycone, ponieważ długość wynikowego JSON, który miałby zostać wyświetlony w kolumnie query_parameters tego widoku, była uważana za zbyt długą, aby magazyn zapytań mógł ją zapisać), too_many_to_capture (zapytanie zostało sparametryzowane, ale parametry nie zostały przechwycone, ponieważ całkowita liczba parametrów była uważana za zbyt dużą, aby magazyn zapytań mógł je zapisać), serialization_failed (kwerenda została sparametryzowana, ale co najmniej jedna z wartości przekazanych jako parametr nie mogła zostać zserializowana do tekstu).

query_store.query_text_view

Ten widok zwraca dane tekstowe dotyczące zapytań w Query Store. Istnieje jeden wiersz dla każdego odrębnego "query_sql_text".

Nazwa Typ Opis
query_text_id Bigint powiedział: Identyfikator tabeli query_texts
query_sql_text varchar(10000) Tekst oświadczenia przedstawiciela. Różne zapytania o tej samej strukturze są grupowane razem; ten tekst jest tekstem pierwszego zapytania w klastrze.
query_type smallint powiedział: Typ operacji reprezentowanej przez zapytanie. W wersji PostgreSQL <= 14 możliwe wartości to 0 (nieznany), 1 (select), 2 (update), 3 (insert), 4 (delete), 5 (utility), 6 (nic). W wersji PostgreSQL >= 15, możliwe wartości to 0 (nieznany), 1 (select), 2 (update), 3 (insert), 4 (delete), 5 (merge), 6 (utility), 7 (nothing).

query_store.pgms_wait_sampling_view

Ten widok zwraca dane dotyczące zdarzeń oczekiwania w magazynie zapytań. Ten widok zwraca inny wiersz dla każdej odrębnej bazy danych (db_id), użytkownika (user_id), zapytania (query_id) i zdarzenia (zdarzenie).

Nazwa Typ Dokumentacja Opis
start_time Sygnatura czasowa Zapytania są agregowane według okien czasowych. Parametr pg_qs.interval_length_minutes serwera definiuje przedział czasu tych okien (wartość domyślna to 15 minut). Ta kolumna odpowiada czasowi rozpoczęcia okna, w którym zarejestrowano ten wpis.
end_time Sygnatura czasowa Godzina zakończenia odpowiadająca przedziałowi czasu dla tego wpisu.
user_id Oid pg_authid.oid Identyfikator obiektu użytkownika, który wykonał instrukcję .
db_id Oid pg_database.oid Identyfikator obiektu bazy danych, w której wykonano instrukcję.
query_id Bigint powiedział: Wewnętrzny kod skrótu obliczany z drzewa analizy wyrażenia.
event_type Tekst Typ zdarzenia, na który oczekuje backend systemu.
event Tekst Nazwa zdarzenia oczekiwania, jeśli zaplecze systemowe obecnie oczekuje.
calls liczba całkowita Liczba razy, gdy to samo zdarzenie zostało przechwycone.

Uwaga / Notatka

Aby uzyskać listę możliwych wartości w kolumnach event_type i event widoku query_store.pgms_wait_sampling_view, zapoznaj się z oficjalną dokumentacją pg_stat_activity i poszukaj informacji odnoszącej się do kolumn o tych samych nazwach.

QueryStore.WidokPlanówZapytania

Ten widok zwraca plan zapytania, który został użyty do wykonania zapytania. Istnieje jeden wiersz dla każdego unikatowego identyfikatora bazy danych oraz każdego unikatowego identyfikatora zapytania. Magazyn zapytań rejestruje tylko plany zapytań dla zapytań, które nie są wykorzystywane.

Nazwa Typ Dokumentacja Opis
plan_id Bigint powiedział: Wartość skrótu z znormalizowanego planu zapytania wygenerowanego przez firmę EXPLAIN. Jest ona w znormalizowanej postaci, ponieważ wyklucza szacowane koszty węzłów planu oraz użycie buforów.
db_id Oid pg_database.oid Identyfikator OID bazy danych, w której wykonano instrukcję.
query_id Bigint powiedział: Wewnętrzny kod skrótu obliczany z drzewa analizy wyrażenia.
plan_text varchar(10000) Plan wykonania instrukcji podanej jako costs=false, buffers=false i format=text. Identyczne dane wyjściowe jak te generowane przez EXPLAIN.

Funkcje

query_store.qs_reset

Funkcja ta odrzuca wszystkie statystyki zebrane do tej pory przez magazyn zapytań. Odrzuca statystyki dla już zamkniętych okien czasowych, które są już utrwalane w tabelach na dysku. Odrzuca również statystyki dla bieżącego przedziału czasu, które istnieją tylko w pamięci. Tylko członkowie roli administratora serwera (azure_pg_admin) mogą wykonać tę funkcję.

query_store.resetowanie_danych_stagingowych

Ta funkcja odrzuca wszystkie statystyki zebrane w pamięci przez magazyn zapytań (czyli dane w pamięci, które nie zostały jeszcze zapisane na tabele na dysku, które wspierają trwałość zebranych danych dla magazynu zapytań). Tylko członkowie roli administratora serwera (azure_pg_admin) mogą wykonać tę funkcję.

Tryb tylko do odczytu

Gdy serwer elastyczny usługi Azure Database for PostgreSQL jest w trybie tylko do odczytu, na przykład gdy default_transaction_read_only parametr jest ustawiony na on, lub jeśli tryb tylko do odczytu jest automatycznie włączony z powodu osiągnięcia pojemności magazynu, magazyn zapytań nie przechwytuje żadnych danych.

Włączenie magazynu zapytań na serwerze z replikami do odczytu nie powoduje automatycznego włączenia magazynu zapytań w żadnej z replik do odczytu. Nawet jeśli włączysz ją w żadnej z replik do odczytu, magazyn zapytań nie rejestruje zapytań wykonywanych na żadnych replikach do odczytu, ponieważ działają w trybie tylko do odczytu, dopóki nie podwyższysz ich do poziomu podstawowego.

Treści powiązane