쿼리 저장소를 사용하여 성능 모니터링
적용 대상: 
Azure Database for PostgreSQL - 유연한 서버
쿼리 저장소는 시간에 따른 쿼리 성능을 추적하는 방법을 제공하는 Azure Database for PostgreSQL 유연한 서버의 기능입니다. 쿼리 저장소는 가장 오래 실행되고 리소스를 많이 사용하는 쿼리를 빠르게 찾을 수 있도록 하여 성능 문제 해결을 간소화합니다. 쿼리 저장소는 쿼리 및 런타임 통계의 기록을 자동으로 캡처하고 검토를 위해 유지합니다. 시간별 사용 패턴을 볼 수 있도록 데이터를 시간별로 분할합니다. 모든 사용자, 데이터베이스 및 쿼리에 대한 데이터는 Azure Database for PostgreSQL 유연한 서버 인스턴스에 명명된 azure_sys 데이터베이스에 저장됩니다.
쿼리 저장소 사용
쿼리 저장소는 추가 비용 없이 사용할 수 있습니다. 옵트인 기능이므로 서버에서 기본적으로 사용하도록 설정되지 않습니다. 쿼리 저장소는 지정된 서버의 모든 데이터베이스에 대해 전역적으로 사용하거나 사용하지 않도록 설정할 수 있으며 데이터베이스별로 사용하거나 사용하지 않도록 설정할 수 없습니다.
Important
성능에 영향을 줄 수 있으므로 버스트 가능 가격 책정 계층에서 쿼리 저장소를 사용하도록 설정하지 마세요.
Azure Portal에서 쿼리 저장소 사용
- Azure Portal에 로그인하고 Azure Database for PostgreSQL 유연한 서버 인스턴스를 선택합니다.
- 메뉴의 설정 섹션에서 서버 매개 변수를 선택합니다.
pg_qs.query_capture_mode매개 변수를 검색합니다.- 최상위 쿼리 또는 중첩된 쿼리(함수 또는 프로시저 내에서 실행되는 쿼리)를 추적할지에 따라 값을
top설정하거나all저장을 선택합니다. 첫 번째 데이터 일괄 처리가 데이터베이스에 유지되는 데 최대 20분이azure_sys걸립니다.
쿼리 저장소 대기 샘플링 사용
pgms_wait_sampling.query_capture_mode매개 변수를 검색합니다.- 값을
all로 설정하고 저장합니다.
쿼리 저장소의 정보
쿼리 저장소는 다음 두 개의 저장소로 구성됩니다.
- 쿼리 실행 통계 정보를 지속하기 위한 런타임 통계 저장소.
- 대기 통계 정보를 지속하기 위한 대기 통계 저장소.
쿼리 저장소를 사용하는 일반적인 시나리오는 다음과 같습니다.
- 지정된 기간에 쿼리가 실행된 횟수를 확인하는 경우
- 시간 창에서 쿼리의 평균 실행 시간을 비교하여 큰 변형을 확인합니다.
- 지난 몇 시간 동안 가장 오래 실행되는 쿼리를 식별하는 경우.
- 리소스에서 대기 중인 최상위 N개 쿼리를 식별하는 경우.
- 특정 쿼리에 대한 대기의 특성을 이해합니다.
공간 사용량을 최소화하기 위해 런타임 통계 저장소의 런타임 실행 통계가 고정된 구성 가능 기간을 통해 집계됩니다. 이러한 저장소의 정보는 보기를 사용하여 쿼리할 수 있습니다.
쿼리 저장소 정보 액세스
쿼리 저장소 데이터는 Azure Database for PostgreSQL 유연한 서버 인스턴스의 데이터베이스에 저장 azure_sys 됩니다.
다음 쿼리는 쿼리 저장소에 기록된 쿼리에 대한 정보를 반환합니다.
SELECT * FROM query_store.qs_view;
그리고 이 쿼리는 대기 통계에 대한 정보를 반환합니다.
SELECT * FROM query_store.pgms_wait_sampling_view;
대기 쿼리 찾기
대기 이벤트 유형은 유사성을 기준으로 서로 다른 대기 이벤트를 버킷으로 결합합니다. 쿼리 저장소는 대기 이벤트 유형, 특정 대기 이벤트 이름 및 해당 쿼리를 제공합니다. 이 대기 정보를 쿼리 런타임 통계와 상호 연관시킬 수 있다는 것은 쿼리 성능 특성에 영향을 미치는 내용을 더 잘 이해할 수 있음을 의미합니다.
다음은 쿼리 저장소의 대기 통계를 사용하여 워크로드에 대한 더 많은 인사이트를 얻는 방법의 몇 가지 예입니다.
| 관찰 | 작업 |
|---|---|
| 높은 잠금 대기 | 영향을 받는 쿼리에 대한 쿼리 텍스트를 확인하고 대상 엔터티를 식별합니다. 쿼리 저장소에서 자주 실행되거나 기간이 높고 동일한 엔터티를 수정하는 다른 쿼리를 찾습니다. 이러한 쿼리를 식별한 후 애플리케이션 논리를 변경하여 동시성을 개선하거나 덜 제한적인 격리 수준을 사용하는 것이 좋습니다. |
| 높은 버퍼 IO 대기 | 쿼리 저장소에서 실제 읽기 수가 많은 쿼리를 찾습니다. 쿼리가 높은 IO 대기와 일치하는 경우 자동화된 인덱스 튜닝 기능을 사용하도록 설정하여 해당 쿼리에 대한 실제 읽기 수를 줄일 수 있는 일부 인덱스를 만드는 것이 좋습니다. |
| 높은 메모리 대기 | 쿼리 저장소에서 상위 메모리 사용 쿼리를 찾습니다. 이러한 쿼리는 영향을 받는 쿼리의 추가 진행을 지연시킬 수 있습니다. |
구성 옵션
쿼리 저장소를 사용하도록 설정하면 pg_qs.interval_length_minutes 서버 매개 변수(기본값: 15분)에 의해 결정되는 길이의 집계 창에 데이터를 저장합니다. 각 창에 대해 창당 최대 500개의 고유 쿼리를 저장합니다. 각 쿼리의 고유성을 구분하는 특성은 user_id(쿼리를 실행하는 사용자의 식별자), db_id(쿼리가 실행되는 컨텍스트의 데이터베이스 식별자) 및 query_id(실행된 쿼리를 고유하게 식별하는 정수 값)입니다. 구성된 간격 동안 고유 쿼리 수가 500에 도달하면 기록된 쿼리 중 5%가 할당 취소되어 더 많은 공간을 확보할 수 있습니다. 먼저 할당 취소된 항목은 최소 횟수만큼 실행된 항목입니다.
다음 옵션은 쿼리 저장소 매개 변수를 구성하는 데 사용할 수 있습니다.
| 매개 변수 | 설명 | 기본값 | 범위 |
|---|---|---|---|
pg_qs.interval_length_minutes (*) |
쿼리 저장소에 대한 캡처 간격(분)입니다. 데이터 지속성의 빈도를 정의합니다. | 15 |
1 - 30 |
pg_qs.is_enabled_fs |
내부 사용 전용: 이 매개 변수는 기능 재정의 스위치로 사용됩니다. 이 값이 해제된 것으로 표시되면 에 대해 설정된 값에도 불구하고 쿼리 저장소를 사용할 수 pg_qs.query_capture_mode없습니다. |
on |
on, off |
pg_qs.max_plan_size |
쿼리 저장소별 쿼리 계획 텍스트에서 저장된 최대 바이트 수; 더 긴 계획이 잘립니다. | 7500 |
100 - 10000 |
pg_qs.max_query_text_length |
저장할 수 있는 최대 쿼리 길이입니다. 더 긴 쿼리가 잘립니다. | 6000 |
100 - 10000 |
pg_qs.parameters_capture_mode |
쿼리 위치 매개 변수를 캡처할지 여부 및 시기입니다. | capture_parameterless_only |
capture_parameterless_only, capture_first_sample |
pg_qs.query_capture_mode |
추적할 문입니다. | none |
none, , topall |
pg_qs.retention_period_in_days |
쿼리 저장소에 대한 보존 기간(일)입니다. 이전 데이터는 자동으로 삭제됩니다. | 7 |
1 - 30 |
pg_qs.store_query_plans |
쿼리 계획을 쿼리 저장소에 저장할지 여부입니다. | off |
on, off |
pg_qs.track_utility |
쿼리 저장소가 유틸리티 명령을 추적해야 하는지 여부입니다. | on |
on, off |
(*) 값 변경 내용을 적용하려면 서버를 다시 시작해야 하는 정적 서버 매개 변수입니다.
다음 옵션은 특히 대기 통계에 적용됩니다.
| 매개 변수 | 설명 | 기본값 | 범위 |
|---|---|---|---|
pgms_wait_sampling.history_period |
대기 이벤트가 샘플링되는 빈도(밀리초)입니다. | 100 |
1 - 600000 |
pgms_wait_sampling.is_enabled_fs |
내부 사용 전용: 이 매개 변수는 기능 재정의 스위치로 사용됩니다. 로 off표시되는 경우 대기 샘플링은 에 대해 pgms_wait_sampling.query_capture_mode설정된 값에도 불구하고 사용하지 않도록 설정됩니다. |
on |
on, off |
pgms_wait_sampling.query_capture_mode |
확장에서 pgms_wait_sampling 추적해야 하는 문입니다. |
none |
none, all |
참고 항목
pg_qs.query_capture_mode 를 대체합니다 pgms_wait_sampling.query_capture_mode. 이 none경우 pg_qs.query_capture_mode 설정에 pgms_wait_sampling.query_capture_mode 영향을 주지 않습니다.
Azure Portal을 사용하여 매개 변수에 대한 다른 값을 가져오거나 설정합니다.
보기 및 함수
쿼리 저장소에서 기록된 정보를 쿼리하거나 데이터베이스 스키마 azure_sys 에서 사용할 수 있는 query_store 일부 보기 및 함수를 사용하여 삭제할 수 있습니다. PostgreSQL 공용 역할의 모든 사용자는 이러한 보기를 사용하여 쿼리 저장소의 데이터를 볼 수 있습니다. 이러한 보기는 azure_sys 데이터베이스에서만 사용 가능합니다.
쿼리는 구조를 확인하고 리터럴, 상수, 별칭 또는 대/소문자 차이와 같이 의미 체계상 중요하지 않은 항목을 무시하여 정규화됩니다.
두 쿼리가 의미 체계상 동일한 경우 동일한 참조 열과 테이블에 대해 서로 다른 별칭을 사용하더라도 동일한 query_id로 식별됩니다. 두 쿼리가 사용된 리터럴 값만 다른 경우에도 동일한 query_id로 식별됩니다. 동일한 query_id 식별된 쿼리의 경우 해당 sql_query_text 쿼리 저장소가 기록 작업을 시작한 이후 처음 실행된 쿼리 또는 함수 query_store.qs_reset이 실행되었기 때문에 마지막으로 지속된 데이터가 삭제된 이후의 쿼리입니다.
쿼리 정규화가 작동하는 방식
다음은 이 정규화가 어떻게 작동하는지 설명하기 위한 몇 가지 예입니다.
다음 문을 사용하여 테이블을 만든다고 가정해 보겠습니다.
create table tableOne (columnOne int, columnTwo int);
쿼리 저장소 데이터 수집을 사용하도록 설정하면 단일 또는 여러 사용자가 정확한 순서에 따라 다음 쿼리를 실행합니다.
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";
이전 쿼리는 모두 동일한 query_id를 공유합니다. 그리고 쿼리 저장소가 보관하는 텍스트는 데이터 수집을 사용하도록 설정한 후 실행된 첫 번째 쿼리의 텍스트입니다. 따라서 select * from tableOne;이 됩니다.
다음 쿼리 집합은 정규화되면 WHERE 절로 인해 의미 체계상 다르기 때문에 이전 쿼리 집합과 일치하지 않습니다.
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;
그러나 이 마지막 집합의 모든 쿼리는 동일한 query_id를 공유하며 이를 식별하는 데 사용되는 텍스트는 모두 일괄 처리 select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;의 첫 번째 쿼리의 텍스트입니다.
마지막으로 이전 일괄 처리에 있는 쿼리의 query_id 일치하지 않는 일부 쿼리와 그렇지 않은 이유를 찾습니다.
쿼리:
select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
일치하지 않는 이유: 열 목록은 동일한 두 열(columnOne 및 ColumnTwo)을 참조하지만 참조되는 순서는 이전 일괄 처리에서 columnOne, ColumnTwo 이 쿼리로 ColumnTwo, columnOne 반대로 바뀝니다.
쿼리:
select * from tableOne where columnTwo = 25 and columnOne = 25;
일치하지 않는 이유: WHERE 절에서 평가된 식이 참조되는 순서가 이전 일괄 처리의 columnOne = ? and ColumnTwo = ?에서 이 쿼리의 ColumnTwo = ? and columnOne = ?으로 반전되었습니다.
쿼리:
select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;
일치하지 않는 이유: 열 목록의 columnOne 첫 번째 식은 더 이상 계산되지 않지만 의미상 동일하지 않은 함수abs(abs(columnOne))를 통해 columnOne 평가됩니다.
쿼리:
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;
일치하지 않는 이유: WHERE 절의 columnOne 첫 번째 식은 더 이상 리터럴과의 같음을 평가하지 않고 리터럴에 대해 계산된 함수 ceiling 의 결과로 의미상 동일하지 않습니다.
뷰
query_store.qs_view
이 뷰는 쿼리 저장소의 지원 테이블에 유지되는 모든 데이터를 반환합니다. 현재 활성 기간 동안 메모리 내 데이터를 기록 중인 데이터는 시간 창이 끝날 때까지 표시되지 않으며 메모리 내 휘발성 데이터가 수집되어 디스크에 저장된 테이블에 유지됩니다. 이 보기는 각 개별 데이터베이스(db_id), 사용자(user_id) 및 쿼리(query_id)에 대해 서로 다른 행을 반환합니다.
| 이름 | Type | 참조 | 설명 |
|---|---|---|---|
runtime_stats_entry_id |
bigint | runtime_stats_entries 테이블의 ID입니다. | |
user_id |
oid | pg_authid.oid | 문을 실행한 사용자의 OID입니다. |
db_id |
oid | pg_database.oid | 문이 실행된 데이터베이스의 OID입니다. |
query_id |
bigint | 문의 구문 분석 트리에서 계산된 내부 해시 코드입니다. | |
query_sql_text |
varchar(10000) | 대표 문의 텍스트. 동일한 구조의 서로 다른 쿼리가 함께 클러스터되고, 이 텍스트는 클러스터에 있는 첫 번째 쿼리의 텍스트입니다. 최대 쿼리 텍스트 길이의 기본값은 6000이며 쿼리 저장소 매개 변수 pg_qs.max_query_text_length를 사용하여 수정할 수 있습니다. 쿼리의 텍스트가 이 최대값을 초과하면 첫 번째 pg_qs.max_query_text_length 바이트로 잘립니다. |
|
plan_id |
bigint | 이 쿼리에 해당하는 계획의 ID입니다. | |
start_time |
timestamp | 쿼리는 시간 창별로 집계됩니다. 서버 매개 변수 pg_qs.interval_length_minutes 는 해당 창의 시간 범위를 정의합니다(기본값은 15분). 이 열은 이 항목이 기록된 창의 시작 시간에 해당합니다. |
|
end_time |
timestamp | 이 항목의 기간에 해당하는 종료 시간입니다. | |
calls |
bigint | 이 기간 동안 쿼리가 실행된 횟수입니다. 병렬 쿼리의 경우 각 실행에 대한 호출 수는 쿼리 실행을 구동하는 백 엔드 프로세스의 경우 1에 해당하며 실행 트리의 병렬 분기를 실행하는 공동 작업을 실행하기 위해 시작되는 각 백 엔드 작업자 프로세스에 대한 다른 많은 단위에 해당합니다. | |
total_time |
double precision | 총 쿼리 실행 시간(밀리초)입니다. | |
min_time |
double precision | 최소 쿼리 실행 시간(밀리초)입니다. | |
max_time |
double precision | 최대 쿼리 실행 시간(밀리초)입니다. | |
mean_time |
double precision | 평균 쿼리 실행 시간(밀리초)입니다. | |
stddev_time |
double precision | 쿼리 실행 시간(밀리초)의 표준 편차입니다. | |
rows |
bigint | 문이 영향을 미치거나 검색하는 총 행 수입니다. 병렬 쿼리의 경우 각 실행의 행 수는 쿼리 실행을 구동하는 백 엔드 프로세스에 의해 클라이언트에 반환되는 행 수와 실행 트리의 병렬 분기 실행을 공동으로 실행하기 위해 시작된 각 백 엔드 작업자 프로세스의 모든 행 합계에 해당하며 쿼리 실행을 구동하는 백 엔드 프로세스로 돌아갑니다. | |
shared_blks_hit |
bigint | 문을 통해 공유되는 총 블록 캐시 적중 수입니다. | |
shared_blks_read |
bigint | 문이 읽은 총 공유 블록 수입니다. | |
shared_blks_dirtied |
bigint | 문에 의해 변경된 총 공유 블록 수입니다. | |
shared_blks_written |
bigint | 문이 쓴 총 공유 블록 수입니다. | |
local_blks_hit |
bigint | 문에 의한 총 로컬 블록 캐시 적중 수입니다. | |
local_blks_read |
bigint | 문이 읽은 총 로컬 블록 수입니다. | |
local_blks_dirtied |
bigint | 문에 의해 변경된 총 로컬 블록 수입니다. | |
local_blks_written |
bigint | 문이 쓴 총 로컬 블록 수입니다. | |
temp_blks_read |
bigint | 문이 읽은 총 임시 블록 수입니다. | |
temp_blks_written |
bigint | 문이 쓴 총 임시 블록 수입니다. | |
blk_read_time |
double precision | 문이 블록을 읽는 데 사용한 총 시간(밀리초)(track_io_timing이 사용하도록 설정된 경우, 이외의 경우에는 0)입니다. | |
blk_write_time |
double precision | 문이 블록을 쓰는 데 사용한 총 시간(밀리초)(track_io_timing이 사용하도록 설정된 경우, 이외의 경우에는 0)입니다. | |
is_system_query |
부울 값 | user_id = 10(azuresu)의 역할이 쿼리를 실행했는지 여부를 결정합니다. 해당 사용자는 슈퍼 사용자 권한을 가지며 컨트롤 플레인 작업을 수행하는 데 사용됩니다. 이 서비스는 관리되는 PaaS 서비스이므로 Microsoft만 슈퍼 사용자 역할에 속합니다. | |
query_type |
text | 쿼리가 나타내는 작업 형식입니다. 가능한 값은 unknown, select, update, insert, delete, merge, utility, nothing, undefined입니다. |
|
search_path |
text | 쿼리를 캡처할 때 설정된 search_path 값입니다. | |
query_parameters |
text | 매개 변수가 있는 쿼리의 위치 매개 변수에 전달된 값이 있는 JSON 개체의 텍스트 표현입니다. 이 열은 매개 변수가 없는 쿼리의 경우 1)의 두 경우에만 해당 값을 채웁니다. 2) 매개 변수가 있는 쿼리의 경우, 쿼리 pg_qs.parameters_capture_mode 저장소가 capture_first_sample실행 시 쿼리의 매개 변수 값을 가져올 수 있는 경우 |
|
parameters_capture_status |
text | 쿼리가 나타내는 작업 형식입니다. 가능한 값은 succeeded (쿼리가 매개 변수화되지 않았거나 매개 변수가 있는 쿼리이고 값이 성공적으로 캡처됨), disabled (쿼리가 매개 변수화되었지만 매개 변수가 설정capture_parameterless_only되었기 때문에 pg_qs.parameters_capture_mode 캡처되지 않음), too_long_to_capture (쿼리는 매개 변수화되었지만 이 보기의 열에 query_parameters 표시될 결과 JSON의 길이가 쿼리 저장소가 지속되는 데 지나치게 긴 것으로 간주되어 매개 변수가 캡처되지 않았습니다.) too_many_to_capture (쿼리는 매개 변수화되었지만 총 매개 변수 수가 쿼리 저장소를 유지하기에 과도한 것으로 간주되어 매개 변수가 캡처되지 않았습니다.) serialization_failed (쿼리는 매개 변수화되었지만 매개 변수로 전달된 값 중 하나 이상을 텍스트로 serialize할 수 없습니다). |
query_store.query_texts_view
이 보기는 쿼리 저장소의 쿼리 텍스트 데이터를 반환합니다. 각각의 고유한 query_sql_text에 대해 하나의 행이 있습니다.
| 이름 | 타입 | 설명 |
|---|---|---|
query_text_id |
bigint | query_texts 테이블의 ID |
query_sql_text |
varchar(10000) | 대표 문의 텍스트. 동일한 구조의 서로 다른 쿼리가 함께 클러스터되고, 이 텍스트는 클러스터에 있는 첫 번째 쿼리의 텍스트입니다. |
query_type |
smallint | 쿼리가 나타내는 작업 형식입니다. PostgreSQL 버전 <= 14에서 가능한 값은 0(알 수 없음), 1(선택), 2(업데이트), 3(삽입), 4(삭제), 5(유틸리티), 6(없음)입니다. PostgreSQL 버전 >= 15에서 가능한 값은 0(알 수 없음), 1(선택), 2(업데이트), 3(삽입), 4(삭제), 5(병합), 6(유틸리티), 7(없음)입니다. |
query_store.pgms_wait_sampling_view
이 보기는 쿼리 저장소의 대기 이벤트 데이터를 반환합니다. 이 보기는 각 개별 데이터베이스(db_id), 사용자(user_id), 쿼리(query_id) 및 이벤트(event)에 대해 서로 다른 행을 반환합니다.
| 이름 | Type | 참조 | 설명 |
|---|---|---|---|
start_time |
timestamp | 쿼리는 시간 창별로 집계됩니다. 서버 매개 변수 pg_qs.interval_length_minutes 는 해당 창의 시간 범위를 정의합니다(기본값은 15분). 이 열은 이 항목이 기록된 창의 시작 시간에 해당합니다. |
|
end_time |
timestamp | 이 항목의 기간에 해당하는 종료 시간입니다. | |
user_id |
oid | pg_authid.oid | 문을 실행한 사용자의 개체 식별자입니다. |
db_id |
oid | pg_database.oid | 문이 실행된 데이터베이스의 개체 식별자입니다. |
query_id |
bigint | 문의 구문 분석 트리에서 계산된 내부 해시 코드입니다. | |
event_type |
text | 백 엔드가 대기 중인 이벤트 유형입니다. | |
event |
text | 백 엔드가 현재 대기 중인 경우 대기 이벤트 이름입니다. | |
calls |
정수 | 동일한 이벤트가 캡처된 횟수입니다. |
참고 항목
보기의 열 query_store.pgms_wait_sampling_view 및 event 열에서 event_type 가능한 값 목록은 pg_stat_activity 공식 설명서를 참조하고 이름이 같은 열을 참조하는 정보를 찾습니다.
query_store.query_plans_view
이 보기는 쿼리를 실행하는 데 사용된 쿼리 계획을 반환합니다. 각각의 개별 데이터베이스 ID 및 쿼리 ID당 하나의 행이 있습니다. 쿼리 저장소는 비수용성 쿼리에 대한 쿼리 계획만 기록합니다.
| 이름 | Type | 참조 | 설명 |
|---|---|---|---|
plan_id |
bigint | EXPLAIN에 의해 생성된 정규화된 쿼리 계획의 해시 값입니다. 계획 노드의 예상 비용 및 버퍼 사용량을 제외하므로 정규화된 형식입니다. | |
db_id |
oid | pg_database.oid | 문이 실행된 데이터베이스의 OID입니다. |
query_id |
bigint | 문의 구문 분석 트리에서 계산된 내부 해시 코드입니다. | |
plan_text |
varchar(10000) | cost=false, buffers=false 및 format=text가 지정된 문의 실행 계획입니다. EXPLAIN에서 생성한 출력과 동일한 출력입니다. |
함수
query_store.qs_reset
이 함수는 지금까지 쿼리 저장소에서 수집한 모든 통계를 삭제합니다. 디스크 테이블에 이미 유지되어 있는 이미 닫힌 시간 창에 대한 통계를 삭제합니다. 또한 메모리에만 존재하는 현재 시간 창에 대한 통계를 삭제합니다. 서버 관리자 역할(azure_pg_admin)의 멤버만 이 함수를 실행할 수 있습니다.
query_store.staging_data_reset
이 함수는 쿼리 저장소에 의해 메모리 내 수집된 모든 통계(즉, 쿼리 저장소에 대해 수집된 데이터의 지속성을 지원하는 디스크 테이블에 아직 플러시되지 않은 메모리의 데이터)를 삭제합니다. 서버 관리자 역할(azure_pg_admin)의 멤버만 이 함수를 실행할 수 있습니다.
읽기 전용 모드
Azure Database for PostgreSQL 유연한 서버 인스턴스가 읽기 전용 모드인 경우(예: 매개 변수가 설정된 on경우default_transaction_read_only) 또는 스토리지 용량에 도달하여 읽기 전용 모드가 자동으로 사용하도록 설정된 경우 쿼리 저장소는 데이터를 캡처하지 않습니다.
읽기 복제본이 있는 서버에서 쿼리 저장소를 사용하도록 설정해도 읽기 복제본에서 쿼리 저장소를 자동으로 사용하도록 설정하지는 않습니다. 읽기 복제본에서 사용하도록 설정하더라도 쿼리 저장소는 읽기 복제본을 기본 복제본으로 승격할 때까지 읽기 전용 모드에서 작동하기 때문에 모든 읽기 복제본에서 실행된 쿼리를 기록하지 않습니다.
Azure Database for PostgreSQL 제품 팀과 제안 및 버그를 공유합니다.
관련 콘텐츠
- Azure Database for PostgreSQL - 유연한 서버의 쿼리 저장소에 대한 사용 시나리오입니다.
- Azure Database for PostgreSQL - 유연한 서버의 쿼리 저장소에 대한 모범 사례입니다.
- Azure Database for PostgreSQL - 유연한 서버의 Query Performance Insight