Tüm Ürünler
Search
Belge Merkezi

Hologres:Get and analyze slow query logs

Son Güncelleme:Oct 06, 2026

Bir Hologres örneği yavaş yanıt verdiğinde veya sorgular çok uzun sürdüğünde, yavaş sorgu günlükleri sorunu belirlemenize ve teşhis etmenize yardımcı olur. Bu konu, hologres.hg_query_log tablosunun nasıl sorgulanacağını, temel alanların nasıl yorumlanacağını ve performans sorunlarını tespit etmek için tanısal SQL'in nasıl kullanılacağını açıklar.

Sürüm kılavuzu

Sürüm Değişiklik
V0.10 Yavaş sorgu günlükleri tanıtıldı. FAILED durumundaki sorguların günlükleri çalışma zamanı istatistiklerini (bellek, disk okumaları, okunan veri hacmi, CPU süresi veya query_stats) içermez.
V2.2 hg_query_log tablosuna digest sütunu (SQL parmak izi) eklendi.
V2.2.7 log_min_duration_statement parametresinin varsayılan değeri 1.000 ms'den 100 ms'ye değiştirildi.
V3.0.2 100 ms altında çalışan DML ve DQL işlemleri için toplu kayıtlar eklendi. Ayrıca calls ve agg_stats alanları eklendi.
V3.0.27 hg_query_log_retention_time_sec aracılığıyla günlük saklama süresinin değiştirilmesi için destek eklendi.
Bu özellik Hologres V0.10 veya sonraki bir sürümü gerektirir. Örnek sürümünüzü kontrol etmek için Hologres konsolundaki örnek ayrıntıları sayfasına gidin. Daha eski bir örneği yükseltmek için bkz. Yaygın yükseltme hazırlık hataları veya Hologres desteği ile iletişime geçin. Daha fazla bilgi için bkz. Daha fazla çevrimiçi desteği nasıl alabilirim? .

Sınırlamalar

  • Yavaş sorgu günlükleri varsayılan olarak bir ay süreyle saklanır.

  • Tek bir sorgu en fazla 10.000 yavaş sorgu günlüğü girişi döndürür. Bazı alanların uzunluk sınırları vardır — hg_query_log tablosu bölümündeki alan açıklamalarına bakın.

  • Yavaş sorgu günlükleri Hologres meta veri ambarının bir parçasıdır. Başarısız bir yavaş sorgu günlüğü araması iş sorgularınızı etkilemez ve günlüklerin kullanılabilirliği Hologres Hizmet Seviyesi Sözleşmesi (SLA) kapsamında değildir.

Çalışma biçimi

Hologres, yavaş sorgu günlüklerini hologres.hg_query_log sistem tablosunda saklar. Tablo yalnızca tamamlanan SQL deyimlerini kaydeder; devam eden sorgular tabloya yazılmaz. Bu davranış V2, V3 ve sonraki sürümlerde tutarlıdır.

Neler günlüğe kaydedilir:

  • V0.10'a yükselttikten sonra: 100 ms'den uzun süren yavaş DML sorguları ve tüm DDL işlemleri.

  • V3.0.2'den itibaren: 100 ms'den uzun süren sorgular için ayrıntılı kayıtlara ek olarak, 100 ms altında tamamlanan DQL ve DML sorguları için de toplu kayıtlar yazılır.

Toplama işleyişi (V3.0.2+):

Hızlı sorgular (100 ms altı) için sistem, aynı SQL parmak izine (digest) sahip başarılı DQL ve DML sorgularını gruplar. Toplama anahtarı şunlardır: server_addr, usename, datname, warehouse_id, application_name ve digest. Her bağlantı, dakikada bir toplu kayıt gönderir.

hg_query_log tablosu

Tablo, aynı şemayı paylaşan ancak farklı anlamlara sahip iki tür kayıt içerir:

Alan Veri türü Ayrıntılı kayıtlar (100 ms üzeri) Toplu kayıtlar (100 ms altı)
usename text Sorguyu yapan kullanıcı adı. Sorguyu yapan kullanıcı adı.
status text SUCCESS veya FAILED. Her zaman SUCCESS (yalnızca başarılı sorgular toplanır).
query_id text Benzersiz sorgu kimliği. Başarısız bir sorgunun her zaman bir query_id değeri vardır; başarılı bir sorguda olmayabilir. Aynı toplama anahtarına sahip toplama dönemindeki ilk sorgunun query_id değeri.
digest text SQL parmak izi (MD5 karması). V2.2'de eklendi. Daha fazla bilgi için bkz. SQL parmak izi. SQL parmak izi.
datname text Veritabanı adı. Veritabanı adı.
command_tag text Sorgu türü: DML (COPY, DELETE, INSERT, SELECT, UPDATE), DDL (ALTER TABLE, BEGIN, COMMENT, COMMIT, CREATE FOREIGN TABLE, CREATE TABLE, DROP FOREIGN TABLE, DROP TABLE, IMPORT FOREIGN SCHEMA, ROLLBACK, TRUNCATE TABLE) veya Diğer (CALL, CREATE EXTENSION, EXPLAIN, GRANT, SECURITY LABEL). Toplama dönemindeki ilk sorgunun command_tag değeri.
warehouse_id integer Sorgu için kullanılan sanal depo kimliği. Toplama dönemindeki ilk sorgunun sanal depo kimliği.
warehouse_name integer Sorgu için kullanılan sanal depo adı. Toplama dönemindeki ilk sorgunun sanal depo adı.
warehouse_cluster_id integer V3.0.2'de eklendi. Sanal depodaki küme kimliği. Küme kimlikleri 1'den başlar. Toplama dönemindeki ilk sorgunun küme kimliği.
duration integer Milisaniye cinsinden toplam sorgu süresi. Üç aşamaya ayrılır — aşağıya bakın. Toplama dönemindeki tüm sorguların ortalama süresi.
message text Başarısız sorgular için hata mesajı. Boş.
query_start timestamptz Sorgu başlangıç zamanı. Toplama dönemindeki ilk sorgunun query_start değeri.
query_date text Sorgu başlangıç tarihi. Toplama dönemindeki ilk sorgunun query_date değeri.
query text Sorgu metni. Maksimum 51.200 karakter; daha uzun sorgular kırpılır. Toplama dönemindeki ilk sorgunun sorgu metni.
result_rows bigint Döndürülen satır sayısı. INSERT için, eklenen satır sayısı. Toplama dönemindeki tüm sorguların ortalama değeri.
result_bytes bigint Döndürülen bayt sayısı. Ortalama değer.
read_rows bigint Okunan satır sayısı (tam değil; bitmap dizini kullanıldığında gerçek taranan satırlardan farklı olabilir). Ortalama değer.
read_bytes bigint Okunan bayt sayısı. Ortalama değer.
affected_rows bigint DML deyimi tarafından etkilenen satır sayısı. Ortalama değer.
affected_bytes bigint DML deyimi tarafından etkilenen bayt sayısı. Ortalama değer.
memory_bytes bigint Tüm düğümlerdeki kümülatif tepe bellek kullanımı (tam değil). Sorgu tarafından okunan veri miktarını yansıtır. Ortalama değer.
shuffle_bytes bigint Ağ üzerinden karıştırılan tahmini bayt sayısı (tam değil). Ortalama değer.
cpu_time_ms bigint Tüm hesaplama görevlerindeki toplam CPU süresi milisaniye cinsinden (tam değil). Sorgu karmaşıklığını yansıtır. Ortalama değer.
physical_reads bigint Diskten okunan kayıt yığını sayısı. Önbellek isabet oranını yansıtır. Ortalama değer.
pid integer Sorgu hizmetinin işlem kimliği. Toplama dönemindeki ilk sorgunun işlem kimliği.
application_name text Uygulama tanımlayıcısı. Bkz. application_name değerleri. Uygulama türü.
engine_type text[] Kullanılan yürütme motoru. Bkz. Motor türleri. Toplama dönemindeki ilk sorgunun motoru.
client_addr text Kaynak IP adresi (uygulamanın giden IP'si, mutlaka gerçek uygulama IP'si değildir). Toplama dönemindeki ilk sorgunun kaynak adresi.
table_write text Verinin yazıldığı tablo. Toplama dönemindeki ilk sorgunun yazma hedefi.
table_read text[] Verinin okunduğu tablolar. Toplama dönemindeki ilk sorgunun okuma kaynakları.
session_id text Oturum kimliği. Toplama dönemindeki ilk sorgunun oturum kimliği.
session_start timestamptz Bağlantının kurulduğu zaman. Toplama dönemindeki tüm sorguların oturum başlangıç zamanı.
command_id text Komut veya deyim kimliği. Toplama dönemindeki tüm sorguların komut kimliği.
optimization_cost integer Sorgu yürütme planını oluşturma süresi (ms). Yüksek değerler karmaşık bir SQL deyimine işaret eder. Toplama dönemindeki tüm sorguların plan oluşturma süresi.
start_query_cost integer Sorgu başlatma süresi (ms). Yüksek değerler sorgunun kilitler veya kaynaklar için beklediğine işaret eder. Toplama dönemindeki tüm sorguların başlatma süresi.
get_next_cost integer Sorgu yürütme süresi (ms). Yüksek değerler hesaplamanın büyük olduğunu ve yürütmenin uzun sürdüğünü gösterir. Toplama dönemindeki tüm sorguların yürütme süresi.
extended_cost text Diğer zamanlama ayrıntıları, şunları içerir: build_dag (hesaplama yönlendirilmiş asiklik grafiğini (DAG) oluşturma süresi; yüksek değerler yabancı tablolar için yavaş meta veri erişimine işaret eder), prepare_reqs (yürütme motoru için istekleri hazırlama süresi; yüksek değerler yavaş parça adresi çözümlemesine işaret eder) ve Serverless'e özel alanlar (serverless_allocated_cores, serverless_allocated_workers, serverless_resource_used_time_ms). Toplama dönemindeki ilk sorgunun genişletilmiş maliyeti.
plan text Sorgu yürütme planı. Maksimum 102.400 karakter; daha uzun planlar kırpılır. log_min_duration_query_plan tarafından kontrol edilir. Toplama dönemindeki ilk sorgunun yürütme planı.
statistics text Sorgu yürütme istatistikleri. Maksimum 102.400 karakter. log_min_duration_query_stats tarafından kontrol edilir. Toplama dönemindeki ilk sorgunun yürütme istatistikleri.
visualization_info text Sorgu planı görselleştirme verileri. Toplama dönemindeki ilk sorgunun görselleştirme verileri.
query_detail text JSON formatında genişletilmiş sorgu bilgileri. Maksimum 10.240 karakter; daha uzun değerler kırpılır. Toplama dönemindeki ilk sorgunun genişletilmiş bilgileri.
query_extinfo text[] Dizi formatında genişletilmiş sorgu bilgileri. Serverless sorguları için serverless_computing içerir. V2.0.29'dan itibaren hesabın AccessKey ID'sini de yakalar. Not: Yerel hesaplar, Hizmet Bağlantılı Roller (SLR) veya Security Token Service (STS) oturum açmaları için AccessKey ID kaydedilmez. Geçici hesaplar için yalnızca geçici AccessKey ID kaydedilir. Toplama dönemindeki ilk sorgunun genişletilmiş bilgileri.
calls INT Ayrıntılı kayıtlar için her zaman 1 (toplama yok). V3.0.2'de eklendi. Toplama döneminde aynı toplama anahtarına sahip sorgu sayısı.
agg_stats JSONB Boş. V3.0.2'de eklendi. Sayısal alanlar (duration, memory_bytes, cpu_time_ms, physical_reads, optimization_cost, start_query_cost, get_next_cost) için MIN, MAX ve AVG istatistikleri.
extended_info JSONB Sorgu Kuyruğu ve Serverless Computing hakkında genişletilmiş bilgiler. Bkz. extended_info değerleri. Boş.

duration dökümünü anlama:

duration alanı toplam sorgu süresini temsil eder ve üç aşamadan oluşur:

Aşama Alan Anlamı Yüksek olduğunda
Plan oluşturma optimization_cost Yürütme planını derleme süresi SQL deyimi karmaşıktır
Başlatma start_query_cost Yürütme başlamadan önceki süre Kilitler veya kaynaklar için bekleniyor
Yürütme get_next_cost Sorguyu çalıştırma süresi Hesaplama büyüktür ve yürütme uzun sürer

Bu üç aşamanın ötesinde ek zamanlama ayrıntıları için extended_cost kullanın.

application_name değerleri

Kaynak Format
Realtime Compute for Apache Flink (VVR) {client_version}_ververica-connector-hologres
Açık kaynak Flink {client_version}_hologres-connector-flink
DataWorks çevrimdışı okuma senkronizasyonu datax_{jobId}
DataWorks çevrimdışı yazma senkronizasyonu {client_version}_datax_{jobId}
DataWorks gerçek zamanlı senkronizasyon {client_version}_streamx_{jobId}
HoloWeb holoweb
MaxCompute yabancı tablo erişimi MaxCompute
Auto Analyze AutoAnalyze
Quick BI QuickBI_public_{version}
DataWorks zamanlama {client_version}_dwscheduler_{tenant_id}_{scheduler_id}_{scheduler_task_id}_{bizdate}_{cyctime}_{scheduler_alisa_id}
Data Security Guard dsg

Diğer uygulamalar için, bağlantı dizesinde application_name değerini açıkça ayarlayın.

Motor türleri

Motor Açıklama
HQE Hologres'in yerel özel mülkiyet motoru. Çoğu sorgu yüksek yürütme verimliliği için HQE kullanır.
PQE PostgreSQL motoru. PQE göründüğünde, bazı SQL operatörleri HQE tarafından yerel olarak desteklenmez. Bunları Sorgu performansını optimize etme bölümünde açıklandığı gibi yeniden yazmak performansı artırabilir.
FixedQE Sabit Plan için yürütme motoru. Nokta okumaları, nokta yazmaları ve PrefixScan gibi sunum tipi SQL'leri verimli bir şekilde işler. Daha önce SDK olarak adlandırılıyordu (V2.2'de yeniden adlandırıldı). Daha fazla bilgi için bkz. Fixed Plan ile SQL yürütmeyi hızlandırma.
PG Sistem tablolarındaki meta veri sorguları için ön uç yerel hesaplama. Kullanıcı tablosu verilerini okumaz. DDL deyimleri de PG kullanır.

extended_info değerleri

extended_info alanı, Serverless Computing yürütmesinin kaynağını kaydeder:

**serverless_computing_source değeri** Anlamı
user_submit Sorgu, Sorgu Kuyruğundan bağımsız olarak Serverless kaynaklarında çalıştırılmak üzere manuel olarak gönderildi.
query_queue Belirtilen sorgu kuyruğundaki tüm sorgular Serverless kaynaklarında çalışır. Bkz. Sorgu kuyruğundaki sorguları yürütmek için Serverless Computing kaynaklarını kullanma.
query_queue_rerun Sorgu, Sorgu Kuyruğunun büyük sorgu denetimi özelliği tarafından Serverless kaynaklarında otomatik olarak yeniden çalıştırıldı. Bkz. Büyük sorgu denetimi.

serverless_computing_source değeri query_queue_rerun olduğunda, query_id_of_triggered_rerun alanı da görünür ve yeniden çalıştırma deyiminin orijinal sorgu kimliğini gösterir.

Ön koşullar

Yavaş sorgu günlüklerini görüntülemek için aşağıdaki izinlerden birine ihtiyacınız vardır:

View logs for all databases in an instance:

  • Superuser: Aşağıdaki komutu çalıştırın. Alibaba Cloud account ID ifadesini gerçek kullanıcı adıyla değiştirin. RAM kullanıcıları için p4_AccountID (RAM kullanıcı adı değil, hesap kimliği) kullanın.

    ALTER USER "Alibaba Cloud account ID" SUPERUSER;
  • pg_read_all_stats grubu (superuser olmayanlar için): Bu gruba eklenmeniz için bir superuser ile iletişime geçin.

    -- Standard PostgreSQL authorization
    GRANT pg_read_all_stats TO "Alibaba Cloud account ID";
    
    -- Simple permission model (SPM)
    CALL spm_grant('pg_read_all_stats', 'Alibaba Cloud account ID');
    
    -- Schema-level permission model (SLPM)
    CALL slpm_grant('pg_read_all_stats', 'Alibaba Cloud account ID');

View logs for the current database only:

SPM veya SLPM'yi etkinleştirin ve kullanıcıyı db_admin rolüne ekleyin.

-- SPM
CALL spm_grant('<db_name>_admin', 'Alibaba Cloud account ID');

-- SLPM
CALL slpm_grant('<db_name>.admin', 'Alibaba Cloud account ID');

Normal kullanıcılar yalnızca geçerli veritabanındaki kendi sorgularını görüntüleyebilir ve ek kurulum gerekmez.

Yavaş sorgu günlüklerini görüntüleme

Hologres, yavaş sorgu günlüklerini görüntülemek için iki yol sunar. Görsel keşif için HoloWeb'i kullanın; özel filtreler, zaman aralıkları ve dışa aktarma için SQL'i kullanın.

Yöntem En uygun olduğu durum Kısıtlamalar
HoloWeb Görsel keşif ve eğilim analizi Yalnızca superuser; yalnızca son 7 gün
SQL (hg_query_log tablosu) Özel zaman aralıkları, filtreleme ve dışa aktarma Uygun izinler gerekir

HoloWeb'de görüntüleme

  1. HoloWeb konsolunda oturum açın.

  2. Üst gezinme çubuğunda, Diagnostics and Optimization seçeneğine tıklayın.

  3. Sol gezinme bölmesinde, Historical Slow Query seçeneğine tıklayın.

  4. Historical Slow Query sayfasının üst kısmındaki sorgu koşullarını ayarlayın. Parametrelerin açıklaması için bkz. Geçmiş Yavaş Sorgular.

  5. Search seçeneğine tıklayın. Sonuçlar iki alanda görünür:

    • Sorgu Eğilimi Analizi: Zaman içinde yavaş ve başarısız sorguların sıklığını göstererek sorunlu dönemleri belirlemenize yardımcı olur.

    • Sorgular: Her yavaş veya başarısız sorgu için ayrıntılı bilgileri listeler. Görüntülenecek sütunları seçmek için Customize Columns seçeneğine tıklayın.

SQL ile sorgulama

Tam esneklik için hologres.hg_query_log tablosunu doğrudan sorgulayın. Hazır SQL örnekleri için bkz. Sorguları teşhis etme.

SQL parmak izi

V2.2'den itibaren, hg_query_log içindeki digest sütunu her sorgu için bir SQL parmak izi saklar. SELECT, INSERT, DELETE ve UPDATE için Hologres, parmak izi olarak bir MD5 karması hesaplar.

digest mi yoksa query_id mi kullanmalı:

  • Aynı türdeki sorguları gruplandırmak ve analiz etmek için digest kullanın; örneğin, hangi sorgu desenlerinin ortalama olarak en çok CPU tükettiğini bulmak için.

  • Belirli bir sorgu yürütmesini izlemek için query_id kullanın; örneğin, belirli bir başarısız sorgunun tam ayrıntılarını almak için.

Parmak izleri nasıl hesaplanır:

  • Parmak izleri yalnızca SELECT, INSERT, DELETE ve UPDATE için toplanır.

  • Boşluklar yoksayılır (boşluklar, satır sonları, sekmeler).

  • Sabit değerler yoksayılır: SELECT * FROM t WHERE a > 1 ve SELECT * FROM t WHERE a > 2 aynı parmak izini üretir.

  • Dizi eleman sayıları yoksayılır: WHERE a IN (1, 2) ve WHERE a IN (3, 4, 5) aynı parmak izini üretir.

  • Sabit verili INSERT için, parmak izi eklenen satır sayısından etkilenmez.

  • Harf durumu Hologres sorgu kurallarını takip eder.

  • Parmak izi, veritabanı adını ve tam nitelikli şemayı içerir, bu nedenle SELECT * FROM t ve SELECT * FROM public.t yalnızca t public şemasındaysa ve her iki sorgu da aynı tabloya başvuruyorsa aynı parmak izine sahiptir.

Sorguları teşhis etme

Aşağıdaki SQL örnekleri en yaygın teşhis senaryolarını kapsar. Tüm sorgular hologres.hg_query_log hedeflidir.

Günlükteki tüm sorguları sayma (varsayılan: son bir ay):

SELECT count(*) FROM hologres.hg_query_log;

Örnek çıktı — son bir ayda 44 yavaş sorgu:

 count
-------
    44
(1 row)

Kullanıcı başına yavaş sorguları sayma:

SELECT usename AS "User",
       count(1) AS "Query count"
FROM hologres.hg_query_log
GROUP BY usename
ORDER BY count(1) DESC;

Örnek çıktı:

        User         | Query count
---------------------+-------------
 1111111111111111    |          27
 2222222222222222    |          11
 3333333333333333    |           4
 4444444444444444    |           2
(4 rows)

Kimliğe göre belirli bir sorguyu arama:

SELECT * FROM hologres.hg_query_log WHERE query_id = '13001450118416xxxx';

Döndürülen alanların açıklaması için bkz. hg_query_log tablosu.

Son 10 dakikadaki kaynak yoğun sorguları bulma:

Hedef zaman pencerenize uyacak şekilde aralığı ayarlayın.

SELECT status           AS "Status",
       duration         AS "Duration (ms)",
       query_start      AS "Start time",
       (read_bytes / 1048576)::text || ' MB'  AS "Data read",
       (memory_bytes / 1048576)::text || ' MB' AS "Memory",
       (shuffle_bytes / 1048576)::text || ' MB' AS "Shuffle",
       (cpu_time_ms / 1000)::text || ' s'    AS "CPU time",
       physical_reads   AS "Disk reads",
       query_id         AS "Query ID",
       query::char(30)
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '10 min'
ORDER BY duration DESC,
         read_bytes DESC,
         shuffle_bytes DESC,
         memory_bytes DESC,
         cpu_time_ms DESC,
         physical_reads DESC
LIMIT 100;

Örnek çıktı:

 Status  | Duration (ms) |       Start time       | Data read | Memory | Shuffle | CPU time | Disk reads |       Query ID     |         query
---------+---------------+------------------------+-----------+--------+---------+----------+------------+--------------------+--------------------------------
 SUCCESS |           149 | 2021-03-30 23:45:01+08 | 0 MB      | 25 MB  | 454 MB  | 321 s    |          0 | 13001450118416xxxx | explain analyze SELECT  * FROM
 SUCCESS |           137 | 2021-03-30 23:49:18+08 | 247 MB    | 21 MB  | 213 MB  | 803 s    |       7771 | 13001491818416xxxx | explain analyze SELECT  * FROM
 FAILED  |            53 | 2021-03-30 23:48:43+08 | 0 MB      | 0 MB   | 0 MB    | 0 s      |          0 | 13001484318416xxxx | SELECT ds::bigint / 0 FROM pub
(3 rows)

Senaryo: Bir örnek sürüm yükseltmesinden sonra yüksek CPU veya bellek kullanımını teşhis etme

Bu sorgu, Hologres örneğiniz yeni bir sürüme yükseltildikten sonra CPU veya bellek kullanımının arttığı durumlarda özellikle kullanışlıdır. Yüksek kaynak tüketimine neden olan sorguları belirlemek için:

  1. CPU veya bellek kullanımının anormal derecede yüksek olduğu dönemi kapsamak için WHERE yan tümcesindeki zaman aralığını ayarlayın. Örneğin, interval '10 min' ifadesini artışın olduğu zaman penceresine uygun bir aralıkla değiştirin.

  2. CPU yoğun sorguları bulmak için ORDER BY cpu_time_ms DESC veya bellek yoğun sorguları bulmak için ORDER BY memory_bytes DESC ekleyin.

  3. Belirli sorguları ve sahiplerini belirlemek için sonuçlardaki query_id, usename ve query sütunlarını kontrol edin, ardından bu sorguları buna göre analiz edin ve optimize edin.

Süreyi aşamalara göre ayırma:

Hangi aşamanın (optimization_cost, start_query_cost veya get_next_cost) gecikmenin çoğundan sorumlu olduğunu belirlemek için bunu kullanın. Her aşamayla ilgili ayrıntılar için hg_query_log tablosu bölümündeki süre döküm tablosuna bakın.

SELECT status              AS "Status",
       duration            AS "Duration (ms)",
       optimization_cost   AS "Optimization cost (ms)",
       start_query_cost    AS "Startup cost (ms)",
       get_next_cost       AS "Execution cost (ms)",
       duration - optimization_cost - start_query_cost - get_next_cost AS "Other cost (ms)",
       query_id            AS "Query ID",
       query::char(30)
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '10 min'
ORDER BY duration DESC,
         start_query_cost DESC,
         optimization_cost,
         get_next_cost DESC,
         duration - optimization_cost - start_query_cost - get_next_cost DESC
LIMIT 100;

Örnek çıktı:

 Status  | Duration (ms) | Optimization cost (ms) | Startup cost (ms) | Execution cost (ms) | Other cost (ms) |       Query ID     |         query
---------+---------------+------------------------+-------------------+---------------------+-----------------+--------------------+--------------------------------
 SUCCESS |          4572 |                    521 |               320 |                3726 |               5 | 6000260625679xxxx  | -- /* user: wang ip: xxx.xx.x
 SUCCESS |          1490 |                    538 |                98 |                 846 |               8 | 12000250867886xxxx | -- /* user: lisa ip: xxx.xx.x
 SUCCESS |          1230 |                    502 |                95 |                 625 |               8 | 26000512070295xxxx | -- /* user: zhang ip: xxx.xx.
(3 rows)

Saat başına sorgu hacmini ve okunan veriyi görüntüleme (son 3 saat):

SELECT date_trunc('hour', query_start) AS query_start,
       count(1)           AS query_count,
       sum(read_bytes)    AS read_bytes,
       sum(cpu_time_ms)   AS cpu_time_ms
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '3 h'
GROUP BY 1;

Trafiği dün aynı pencereyle karşılaştırma:

SELECT query_date,
       count(1)           AS query_count,
       sum(read_bytes)    AS read_bytes,
       sum(cpu_time_ms)   AS cpu_time_ms
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '3 h'
GROUP BY query_date
UNION ALL
SELECT query_date,
       count(1)           AS query_count,
       sum(read_bytes)    AS read_bytes,
       sum(cpu_time_ms)   AS cpu_time_ms
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '1d 3h'
  AND query_start <= now() - interval '1d'
GROUP BY query_date;

Bir zaman penceresindeki ilk başarısız sorguyu bulma:

SELECT status              AS "Status",
       regexp_replace(message, '\n', ' ')::char(150) AS "Error message",
       duration            AS "Duration (ms)",
       query_start         AS "Start time",
       query_id            AS "Query ID",
       query::char(100)    AS "Query"
FROM hologres.hg_query_log
WHERE query_start BETWEEN '2021-03-25 17:00:00'::timestamptz
                      AND '2021-03-25 17:42:00'::timestamptz + interval '2 min'
  AND status = 'FAILED'
ORDER BY query_start ASC
LIMIT 100;

Örnek çıktı:

 Status |                        Error message                        | Duration (ms) |       Start time       |      Query ID      | Query
--------+--------------------------------------------------------------+---------------+------------------------+--------------------+-------
 FAILED | Query:[1070285448673xxxx] code: kActorInvokeError msg: "..." |          1460 | 2021-03-25 17:28:54+08 | 1070285448673xxxx  | S...
 FAILED | Query:[1016285560553xxxx] code: kActorInvokeError msg: "..." |           131 | 2021-03-25 17:28:55+08 | 1016285560553xxxx  | S...
(2 rows)

Dünden yeni sorgu desenlerini bulma (toplam sayı):

Bir önceki güne kıyasla ilk kez görünen sorgular, parmak izine göre gruplandırılmış.

SELECT COUNT(1)
FROM (
    SELECT DISTINCT t1.digest
    FROM hologres.hg_query_log t1
    WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
      AND t1.query_start < CURRENT_DATE
      AND NOT EXISTS (
          SELECT 1
          FROM hologres.hg_query_log t2
          WHERE t2.digest = t1.digest
            AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
      )
      AND digest IS NOT NULL
) AS a;

Örnek çıktı — dün 10 yeni sorgu deseni:

 count
-------
    10
(1 row)

Dünden yeni sorgu desenlerini bulma (türe göre):

SELECT a.command_tag,
       COUNT(1)
FROM (
    SELECT DISTINCT t1.digest, t1.command_tag
    FROM hologres.hg_query_log t1
    WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
      AND t1.query_start < CURRENT_DATE
      AND NOT EXISTS (
          SELECT 1
          FROM hologres.hg_query_log t2
          WHERE t2.digest = t1.digest
            AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
      )
      AND t1.digest IS NOT NULL
) AS a
GROUP BY 1
ORDER BY 2 DESC;

Örnek çıktı:

 command_tag | count
-------------+-------
 INSERT      |     8
 SELECT      |     2
(2 rows)

Dünden yeni sorgu desenlerini bulma (ayrıntılı):

SELECT a.usename, a.status, a.query_id, a.digest,
       a.datname, a.command_tag, a.query, a.cpu_time_ms, a.memory_bytes
FROM (
    SELECT DISTINCT
        t1.usename, t1.status, t1.query_id, t1.digest,
        t1.datname, t1.command_tag, t1.query, t1.cpu_time_ms, t1.memory_bytes
    FROM hologres.hg_query_log t1
    WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
      AND t1.query_start < CURRENT_DATE
      AND NOT EXISTS (
          SELECT 1
          FROM hologres.hg_query_log t2
          WHERE t2.digest = t1.digest
            AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
      )
      AND t1.digest IS NOT NULL
) AS a;

Dünden yeni sorgu desenlerini bulma (saate göre):

SELECT to_char(a.query_start, 'HH24') AS query_start_hour,
       a.command_tag,
       COUNT(1)
FROM (
    SELECT DISTINCT t1.query_start, t1.digest, t1.command_tag
    FROM hologres.hg_query_log t1
    WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
      AND t1.query_start < CURRENT_DATE
      AND NOT EXISTS (
          SELECT 1
          FROM hologres.hg_query_log t2
          WHERE t2.digest = t1.digest
            AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
      )
      AND t1.digest IS NOT NULL
) AS a
GROUP BY 1, 2
ORDER BY 3 DESC;

Örnek çıktı — dün saat 21:00'de 8 INSERT deseni; saat 11:00 ve 13:00'te her biri 1 SELECT deseni:

 query_start_hour | command_tag | count
------------------+-------------+-------
               21 | INSERT      |     8
               11 | SELECT      |     1
               13 | SELECT      |     1
(3 rows)

Parmak izine göre yavaş sorguları sayma (dün):

SELECT digest,
       command_tag,
       count(1)
FROM hologres.hg_query_log
WHERE query_start >= CURRENT_DATE - INTERVAL '1 day'
  AND query_start < CURRENT_DATE
GROUP BY 1, 2
ORDER BY 3 DESC;

Ortalama CPU süresi en yüksek olan ilk 10 sorgu desenini bulma (son gün):

SELECT digest,
       avg(cpu_time_ms)
FROM hologres.hg_query_log
WHERE query_start >= CURRENT_DATE - INTERVAL '1 day'
  AND query_start < CURRENT_DATE
  AND digest IS NOT NULL
  AND usename != 'system'
  AND cpu_time_ms IS NOT NULL
GROUP BY 1
ORDER BY 2 DESC
LIMIT 10;

Ortalama bellek kullanımı en yüksek olan ilk 10 sorgu desenini bulma (son hafta):

SELECT digest,
       avg(memory_bytes)
FROM hologres.hg_query_log
WHERE query_start >= CURRENT_DATE - INTERVAL '7 day'
  AND query_start < CURRENT_DATE
  AND digest IS NOT NULL
  AND memory_bytes IS NOT NULL
GROUP BY 1
ORDER BY 2 DESC
LIMIT 10;

Yapılandırma parametreleri

Nelerin günlüğe kaydedileceğini ve ne kadar ayrıntının yakalanacağını kontrol etmek için bu GUC parametrelerini kullanın.

log_min_duration_statement

Günlüğe kaydetme için minimum sorgu süresini kontrol eder.

  • Varsayılan: 100 ms (V2.2.7'den itibaren; önceki sürümlerde varsayılan 1.000 ms'dir).

  • Minimum değer: 100 ms.

  • Yavaş sorgu günlüklerini tamamen devre dışı bırakmak için -1 olarak ayarlayın.

  • Yalnızca superuser'lar bunu veritabanı düzeyinde değiştirebilir. Normal kullanıcılar bunu oturum düzeyinde değiştirebilir.

  • Değişiklikler yalnızca yeni sorgular için geçerlidir.

-- Database level (superuser only)
ALTER DATABASE dbname SET log_min_duration_statement = '250ms';

-- Session level
SET log_min_duration_statement = '250ms';

log_min_duration_query_stats

Bir sorgu için yürütme istatistiklerinin yakalanıp yakalanmayacağını kontrol eder.

  • Varsayılan: 10 saniyeden uzun süren sorgular için istatistikleri kaydeder.

  • İstatistik toplamayı devre dışı bırakmak için -1 olarak ayarlayın.

  • İstatistikler önemli depolama alanı kullanır. Bu değeri yalnızca hedefli sorun giderme için düşürün; ardından geri yükleyin.

  • Değişiklikler yalnızca yeni sorgular için geçerlidir.

-- Database level (superuser only)
ALTER DATABASE dbname SET log_min_duration_query_stats = '20s';

-- Session level
SET log_min_duration_query_stats = '20s';

log_min_duration_query_plan

Bir sorgu için yürütme planının yakalanıp yakalanmayacağını kontrol eder.

  • Varsayılan: 10 saniyeden uzun süren sorgular için planları kaydeder.

  • Plan yakalamayı devre dışı bırakmak için -1 olarak ayarlayın.

  • Geçici sorun giderme için bunun yerine EXPLAIN kullanın; planı günlüğe kaydetmeden anında döndürür.

  • Değişiklikler yalnızca yeni sorgular için geçerlidir.

-- Database level (superuser only)
ALTER DATABASE dbname SET log_min_duration_query_plan = '10s';

-- Session level
SET log_min_duration_query_plan = '10s';

Günlük saklama süresini değiştirme

V3.0.27'den itibaren, yavaş sorgu günlüklerinin ne kadar süreyle saklanacağını veritabanı düzeyinde değiştirebilirsiniz.

ALTER DATABASE <db_name> SET hg_query_log_retention_time_sec = 2592000;
Yön Ayrıntı
Birim Saniye
Aralık 3–30 gün (259.200–2.592.000 saniye)
Kapsam Yalnızca yeni günlükler (mevcut günlükler orijinal saklama sürelerini korur)
Uygulama alanı Yalnızca yeni bağlantılar
Temizleme Süresi dolan günlükler eşzamansız olarak değil, hemen silinir

Yavaş sorgu günlüklerini dışa aktarma

Uzun vadeli depolama veya analiz için hg_query_log verilerini bir Hologres iç tablosuna, MaxCompute yabancı tablosuna veya OSS'e dışa aktarın.

Dışa aktarmadan önce not edin:

  • INSERT INTO ... SELECT ... FROM hologres.hg_query_log komutunu çalıştıran hesabın hg_query_log erişimine sahip olması gerekir. Örnek çapında dışa aktarmalar için superuser veya pg_read_all_stats izinleri gereklidir; aksi takdirde dışa aktarılan veriler eksik olur.

  • query_start dizinlenmiş bir sütundur. Performansı artırmak ve kaynak kullanımını azaltmak için WHERE yan tümcesine her zaman dahil edin.

  • WHERE yan tümcesinde query_start üzerine işlevler uygulamayın; bu, dizinin kullanılmasını engeller.

    -- Correct: use range conditions on query_start directly
    WHERE query_start >= '2022-08-03' AND query_start < '2022-08-04'
    
    -- Incorrect: wrapping query_start in a function bypasses the index
    WHERE to_char(query_start, 'yyyymmdd') = '20220101'

Bir Hologres iç tablosuna dışa aktarma

-- Step 1: Create the target table
CREATE TABLE query_log_download (
    usename text,
    status text,
    query_id text,
    datname text,
    command_tag text,
    duration integer,
    message text,
    query_start timestamp with time zone,
    query_date text,
    query text,
    result_rows bigint,
    result_bytes bigint,
    read_rows bigint,
    read_bytes bigint,
    affected_rows bigint,
    affected_bytes bigint,
    memory_bytes bigint,
    shuffle_bytes bigint,
    cpu_time_ms bigint,
    physical_reads bigint,
    pid integer,
    application_name text,
    engine_type text[],
    client_addr text,
    table_write text,
    table_read text[],
    session_id text,
    session_start timestamp with time zone,
    trans_id text,
    command_id text,
    optimization_cost integer,
    start_query_cost integer,
    get_next_cost integer,
    extended_cost text,
    plan text,
    statistics text,
    visualization_info text,
    query_detail text,
    query_extinfo text[]
);

-- Step 2: Export logs for a specific date
INSERT INTO query_log_download
SELECT
    usename, status, query_id, datname, command_tag, duration, message,
    query_start, query_date, query, result_rows, result_bytes, read_rows,
    read_bytes, affected_rows, affected_bytes, memory_bytes, shuffle_bytes,
    cpu_time_ms, physical_reads, pid, application_name, engine_type,
    client_addr, table_write, table_read, session_id, session_start,
    trans_id, command_id, optimization_cost, start_query_cost, get_next_cost,
    extended_cost, plan, statistics, visualization_info, query_detail, query_extinfo
FROM hologres.hg_query_log
WHERE query_start >= '2022-08-03'
  AND query_start < '2022-08-04';

Bir MaxCompute yabancı tablosuna dışa aktarma

  1. MaxCompute'te, verileri almak için bölümlenmiş bir tablo oluşturun:

    CREATE TABLE IF NOT EXISTS mc_holo_query_log (
        username        STRING COMMENT 'The username for the query',
        status          STRING COMMENT 'The final status of the query: success or failed',
        query_id        STRING COMMENT 'The query ID',
        datname         STRING COMMENT 'The name of the database for the query',
        command_tag     STRING COMMENT 'The type of query',
        duration        BIGINT COMMENT 'The query duration in milliseconds (ms)',
        message         STRING COMMENT 'The error message',
        query           STRING COMMENT 'The text content of the query',
        read_rows       BIGINT COMMENT 'The number of rows read by the query',
        read_bytes      BIGINT COMMENT 'The number of bytes read by the query',
        memory_bytes    BIGINT COMMENT 'The peak memory consumption on a single node (not exact)',
        shuffle_bytes   BIGINT COMMENT 'The estimated number of bytes for data shuffle (not exact)',
        cpu_time_ms     BIGINT COMMENT 'The total CPU time in milliseconds (not exact)',
        physical_reads  BIGINT COMMENT 'The number of physical reads',
        application_name STRING COMMENT 'The query application type',
        engine_type     ARRAY<STRING> COMMENT 'The engine used for the query',
        table_write     STRING COMMENT 'The table to which the SQL statement writes data',
        table_read      ARRAY<STRING> COMMENT 'The table from which the SQL statement reads data',
        plan            STRING COMMENT 'The execution plan for the query',
        optimization_cost BIGINT COMMENT 'The time to generate the query execution plan',
        start_query_cost  BIGINT COMMENT 'The query startup time',
        get_next_cost     BIGINT COMMENT 'The query execution duration',
        extended_cost   STRING COMMENT 'Other detailed costs of the query',
        query_detail    STRING COMMENT 'Other extended information about the query (JSON format)',
        query_extinfo   ARRAY<STRING> COMMENT 'Other extended information about the query (ARRAY format)',
        query_start     STRING COMMENT 'The query start time',
        query_date      STRING COMMENT 'The query start date'
    ) COMMENT 'Hologres instance query log'
    PARTITIONED BY (ds STRING COMMENT 'stat date')
    LIFECYCLE 365;
    
    ALTER TABLE mc_holo_query_log ADD PARTITION (ds=20220803);
  2. Hologres'te, MaxCompute tablosunu bir yabancı tablo olarak içe aktarın ve günlükleri dışa aktarın:

    IMPORT FOREIGN SCHEMA project_name LIMIT TO (mc_holo_query_log)
    FROM SERVER odps_server INTO public;
    
    INSERT INTO mc_holo_query_log
    SELECT
        usename AS username, status, query_id, datname, command_tag, duration,
        message, query, read_rows, read_bytes, memory_bytes, shuffle_bytes,
        cpu_time_ms, physical_reads, application_name, engine_type,
        table_write, table_read, plan, optimization_cost, start_query_cost,
        get_next_cost, extended_cost, query_detail, query_extinfo,
        query_start, query_date,
        '20220803'
    FROM hologres.hg_query_log
    WHERE query_start >= '2022-08-03'
      AND query_start < '2022-08-04';

SSS

Hologres V1.1'de döndürülen satır sayıları ve okunan satır sayıları eksik.

Bu durum, etkilenen V1.1 sürümlerinde yavaş sorgu günlüğü toplamanın eksik olmasından kaynaklanır. V1.1.36 ile V1.1.49 arasında, tam istatistikleri toplamak için aşağıdaki GUC parametresini etkinleştirin:

-- Database level (recommended — set once per database)
ALTER DATABASE <db_name> SET hg_experimental_force_sync_collect_execution_statistics = ON;

-- Session level
SET hg_experimental_force_sync_collect_execution_statistics = ON;

<db_name> ifadesini veritabanı adınızla değiştirin.

Örneğiniz V1.1.36'dan önceyse, bkz. Yaygın yükseltme hazırlık hataları veya Hologres desteği ile iletişime geçin. Daha fazla bilgi için bkz. Daha fazla çevrimiçi desteği nasıl alabilirim? .

Bu davranış, V1.1.49 ve sonraki sürümlerde varsayılan olarak çözülmüştür.

Yavaş sorgu günlüklerindeki süre Fetching zamanını içerir mi?

Hayır. Hologres yavaş sorgu günlüklerindeki duration alanı yalnızca sunucu tarafı yürütme süresini ölçer; bu süre, plan oluşturma (optimization_cost), başlatma (start_query_cost) ve hesaplama (get_next_cost) aşamalarından oluşur. İstemcinin sonuç verilerini getirmesi için harcadığı zamanı (Fetching aşaması) içermez.

Quick BI gibi bir BI aracından gelen sorgular, HoloWeb'den veya komut satırından çalıştırılan aynı SQL deyimine kıyasla önemli ölçüde daha uzun sürüyorsa, yaygın nedenler şunlardır:

  • BI aracı, yüksek paralellik altında genel yanıt süresini artıran birden çok sorguyu eşzamanlı olarak gönderir.

  • get_next_cost alanı, sonuç verilerinin sunucudan istemciye gönderilmesi için ağ aktarım süresini içerir. Yüksek bir get_next_cost değeri, yavaş sunucu tarafı hesaplamadan ziyade istemci tarafı veri alma gecikmesini yansıtabilir.

Sunucu tarafı ve istemci tarafı gecikmelerini ayırt etmek için sorguyu EXPLAIN ANALYZE ile çalıştırın ve get_next_cost alanını inceleyin. Düşük optimization_cost ve start_query_cost ile birlikte yüksek bir get_next_cost değeri, genellikle sürenin sorgu yürütmesinden ziyade veri aktarımı için harcandığını gösterir.

Sırada ne var

Örneğinizdeki etkin sorguları izlemek ve yönetmek için bkz. Sorguları yönetme.