Magazyn zapytań w usłudze Azure Database for PostgreSQL — serwer elastyczny

Magazyn zapytań to funkcja na serwerze elastycznym Azure Database for PostgreSQL, która umożliwia śledzenie wydajności zapytań w czasie. Magazyn zapytań upraszcza rozwiązywanie problemów z wydajnością, pomagając szybko znaleźć najdłużej działające i najwięcej zapytań intensywnie korzystających z zasobów. 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 na serwerze elastycznym Azure Database for PostgreSQL.

Włączanie magazynu zapytań

Funkcja Query Store jest dostępna 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. Nie można go włączyć ani wyłączyć dla każdej bazy danych.

Ważne

Nie włączaj funkcji Query Store w warstwie cenowej Burstable, ponieważ powoduje ona problemy z wydajnością.

Włącz magazyn zapytań w Portalu Azure

  1. Zaloguj się do portalu Azure i wybierz serwer elastyczny Azure Database for PostgreSQL.
  2. Wybierz pozycję Parametry 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 przeszukiwać za pomocą widoków.

Uzyskiwanie dostępu do informacji o repozytorium zapytań

Elastyczny serwer usługi Azure Database for PostgreSQL przechowuje dane magazynu zapytań w bazie danych azure_sys. 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 grupują różne zdarzenia oczekiwania w grupy na podstawie podobieństwa. Query Store udostępnia typ zdarzenia oczekiwania, konkretną nazwę zdarzenia oczekiwania i pytanie. Skorelowanie tych informacji oczekiwania ze statystykami środowiska uruchomieniowego zapytań pozwala lepiej zrozumieć, co przyczynia się do charakterystyki wydajności zapytań.

Poniżej przedstawiono kilka przykładów sposobu uzyskiwania większego wglądu w obciążenie przy użyciu statystyk oczekiwania w Query Store:

Obserwacja Action
Długie czasy oczekiwania na blokady Sprawdź teksty zapytań pod kątem zapytań, których dotyczy problem, i zidentyfikuj jednostki docelowe. Sprawdź w Query Store, czy istnieją inne zapytania, które są często wykonywane, mają długi czas trwania i modyfikują tę samą encję. 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 Sklepie Zapytań. Jeśli są zgodne z zapytaniami z wysokim czasem oczekiwania na operacje we/wy, rozważ włączenie funkcji autonomicznego dostrajania, aby sprawdzić, czy może zalecić utworzenie indeksów, które mogą zmniejszyć liczbę odczytów fizycznych 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

Po włączeniu magazynu zapytań dane są zapisywane w oknach agregowania. Długość tych okien jest określana przez parametr pg_qs.interval_length_minutes , który domyślnie wynosi 15 minut. Dla każdego okna magazyn zapytań przechowuje maksymalnie 500 odrębnych zapytań. Atrybuty, które odróżniają unikatowość każdego zapytania, to user_id (identyfikator użytkownika, który wykonuje zapytanie), db_id (identyfikator bazy danych, której kontekst wykonuje zapytanie) i query_id (unikatowa wartość całkowita identyfikującą wykonane zapytanie). Jeśli liczba unikatowych zapytań osiągnie 500 w skonfigurowanym przedziale czasu, Magazyn zapytań usuwa 5% zarejestrowanych zapytań, aby zwolnić miejsce na kolejne. Zapytania zwalniane w pierwszej kolejności to te, które wykonano najmniejszą liczbę razy.

Aby skonfigurować parametry Query Store, użyj następujących opcji:

Parameter Opis Wartość domyślna Range
pg_qs.interval_length_minutes Interwał przechwytywania w minutach dla magazynu zapytań. Definiuje częstotliwość trwałości danych. 15 1 - 30
pg_qs.max_captured_queries Maksymalna liczba zapytań, które magazyn zapytań zachowuje spośród wszystkich zapytań zarejestrowanych podczas każdego interwału przechwytywania. 500 100 - 500
pg_qs.max_plan_size Maksymalna liczba bajtów tekstu planu zapytania zapisywana przez magazyn zapytań. Dłuższe plany są przycinane. 7500 100 - 10000
pg_qs.max_query_text_length Maksymalna długość zapytania, którą może zapisać magazyn zapytań. 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, topall
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 Czy magazyn zapytań powinien zapisywać plany zapytań. off on, off
pg_qs.track_utility Czy magazyn zapytań musi śledzić komendy użytkowe. on on, off

Uwaga / Notatka

Jeśli zmienisz wartość parametru pg_qs.max_query_text_length, tekst wszystkich zapytań zarejestrowanych przez magazyn zapytań, zanim wprowadzisz tę zmianę, nadal będzie używał tych samych query_id i sql_query_text. To zachowanie może sprawiać wrażenie, że nowa wartość nie zostanie zastosowana, ale w przypadku zapytań, których magazyn zapytań nie zarejestrował wcześniej, zobaczysz, że tekst zapytania używa nowo skonfigurowanej maksymalnej długości. To zachowanie wynika z założeń projektu i zostało wyjaśnione w artykule Widoki i funkcje. Jeśli wykonasz query_store.qs_reset, usunie wszystkie informacje zarejestrowane do tej pory w magazynie zapytań, w tym tekst przechwycony dla każdego identyfikatora zapytania. Jeśli którekolwiek z tych zapytań zostanie wykonane ponownie, nowo skonfigurowana maksymalna długość zostanie zastosowana do przechwyconego tekstu.

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

Parameter Opis Wartość domyślna Range
pgms_wait_sampling.history_period Częstotliwość próbkowania zdarzeń oczekiwania, wyrażona w milisekundach. 100 1 - 600000
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 zastępuje pgms_wait_sampling.query_capture_mode. Jeśli pg_qs.query_capture_mode jest none, ustawienie pgms_wait_sampling.query_capture_mode 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 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ń

W poniższych przykładach pokazano, jak działa normalizacja zapytań:

Załóżmy, że tworzysz tabelę przy użyciu następującej instrukcji:

create table tableOne (columnOne int, columnTwo int);

Włączysz zbieranie danych Query Store, a co najmniej jeden użytkownik uruchamia 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 mają ten sam identyfikator zapytania. Query Store przechowuje tekst pierwszego zapytania uruchamianego po włączeniu zbierania danych. W związku z tym tekst 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 mają ten sam identyfikator zapytania. Tekst, który identyfikuje je wszystkie, to tekst pierwszego zapytania w partii: select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.

Na koniec poniższe zapytania nie są zgodne z identyfikatorami zapytań z poprzedniej partii. Powód, dla którego nie są one zgodne, jest wyjaśniony na poniższej liście:

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ść jest odwrócona. Kolejność zmienia się z columnOne, ColumnTwo w poprzedniej partii na ColumnTwo, columnOne w tym zapytaniu.

Zapytanie:

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

Przyczyna braku dopasowania: kolejność, w której wyrażenia w klauzuli WHERE są obliczane, jest odwrócona. Kolejność zmienia się 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.

Views

query_store.qs_view

Ten widok zwraca wszystkie dane, które magazyn zapytań utrwala w swoich tabelach pomocniczych. Dane, które magazyn zapytań nadal rejestruje w pamięci dla aktualnie aktywnego przedziału czasu, nie są widoczne do momentu zakończenia okna czasu, a dane nietrwałe w pamięci są zbierane i utrwalane 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 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 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 wynosi 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 Identyfikator planu odpowiadającego temu zapytaniu.
start_time sygnatura czasowa Zapytania są agregowane według okien czasowych. Parametr pg_qs.interval_length_minutes 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 Ile razy zapytanie zostało wykonane w tym przedziale czasu. W przypadku zapytań równoległych liczba wywołań dla każdego wykonania wynosi 1 dla procesu backendu, który odpowiada za wykonanie zapytania, plus po jednej dodatkowej jednostce na każdy proces roboczy backendu uruchamiany do współpracy przy wykonywaniu równoległych gałęzi drzewa wykonania.
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 Łączna liczba wierszy pobranych lub zmienionych przez instrukcję. W przypadku zapytań równoległych liczba wierszy dla każdego wykonania odpowiada liczbie wierszy zwróconych klientowi przez proces backendu, który steruje wykonaniem zapytania, powiększonej o sumę wszystkich wierszy zwróconych do procesu backendu sterującego wykonaniem zapytania przez każdy proces roboczy backendu uruchomiony w celu współpracy przy wykonywaniu równoległych gałęzi drzewa wykonania.
shared_blks_hit bigint Łączna liczba trafień w udostępnioną pamięć podręczną bloków przez instrukcję.
shared_blks_read bigint Łączna liczba bloków współdzielonych odczytanych przez zapytanie.
shared_blks_dirtied bigint Łączna liczba bloków udostępnionych i zmodyfikowanych przez instrukcję.
shared_blks_written bigint Łączna liczba zapisanych bloków współdzielonych przez instrukcję.
local_blks_hit bigint Łączna liczba trafień lokalnej pamięci podręcznej bloków na podstawie instrukcji.
local_blks_read bigint Łączna liczba bloków lokalnych odczytanych przez instrukcję .
local_blks_dirtied bigint Łączna liczba bloków lokalnych zabrudowanych przez instrukcję .
local_blks_written bigint Łączna liczba bloków lokalnych zapisanych przez instrukcję .
temp_blks_read bigint Łączna liczba bloków tymczasowych odczytanych przez instrukcję .
temp_blks_written bigint Łą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 SMS Typ operacji reprezentowanej przez zapytanie. Możliwe wartości to unknown, select, update, insert, delete, merge, utility, nothing, undefined.
search_path SMS Wartość search_path ustawiona w momencie przechwycenia zapytania.
query_parameters SMS 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 SMS Typ operacji reprezentowanej przez zapytanie. Możliwe wartości to succeeded (zapytanie nie zostało sparametryzowane lub było zapytaniem sparametryzowanym i wartości zostały pomyślnie przechwycone), disabled (zapytanie zostało sparametryzowane, ale parametry nie zostały przechwycone, ponieważ parametr 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 dokumentu JSON, który byłby wyświetlany w kolumnie query_parameters tego widoku, została uznana za zbyt dużą, aby magazyn zapytań mógł ją zachować), too_many_to_capture (zapytanie zostało sparametryzowane, ale parametry nie zostały przechwycone, ponieważ łączna liczba parametrów została uznana za zbyt dużą, aby magazyn zapytań mógł ją zachować), serialization_failed (zapytanie zostało sparametryzowane, ale co najmniej jednej z wartości przekazanych jako parametr nie udało się zserializować 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 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 Typ operacji reprezentowanej przez zapytanie. W wersjach PostgreSQL <= 14 możliwe wartości to 0 (nieznany), 1 (select), 2 (update), 3 (insert), 4 (delete), 5 (utility), 6 (nothing). W wersjach PostgreSQL >= 15 możliwe wartości to 0 (nieznane), 1 (select), 2 (update), 3 (insert), 4 (delete), 5 (merge), 6 (utility), 7 (brak).

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 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 Wewnętrzny kod skrótu obliczany z drzewa analizy wyrażenia.
event_type SMS Typ zdarzenia, na który oczekuje backend systemu.
event SMS 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 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 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.

Functions

query_store.qs_reset

Ta funkcja odrzuca wszystkie statystyki zbierane 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 usuwa wszystkie statystyki zgromadzone w pamięci przez Query Store. Te dane nie zostały jeszcze zapisane w tabelach na dysku, które zapewniają trwałe przechowywanie danych zbieranych przez Query Store. 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 je w żadnej z replik do odczytu, magazyn zapytań nie rejestruje zapytań wykonywanych w żadnych replikach do odczytu. Repliki do odczytu działają w trybie tylko do odczytu do momentu podwyższenia ich do poziomu podstawowego.

Treści powiązane

  • Last updated on