Ketika tabel dasar dari sumber data tabel dinamis berubah, tabel dinamis tersebut akan melakukan refresh untuk memperbarui datanya. Tabel dinamis menjalankan tugas refresh secara otomatis di latar belakang berdasarkan waktu mulai dan interval refresh yang telah dikonfigurasi. Topik ini menjelaskan cara melihat dan memelihara tugas refresh tabel dinamis.
Pemantauan dan Peringatan
Metrik pemantauan
Mulai dari Hologres V4.0.8, tabel dinamis menyediakan metrik pemantauan berikut untuk membantu Anda mengelola tugas refresh:
QPS kegagalan refresh tabel dinamis tingkat instans (jumlah/detik)
Metrik ini menunjukkan jumlah kueri per detik (QPS) dari tugas refresh yang gagal di seluruh tabel dinamis dalam suatu instans. Metrik ini mencerminkan kesehatan keseluruhan proses refresh. Biasanya, nilai ini harus mendekati nol. Jika nilainya terus-menerus tidak nol atau meningkat signifikan, kemungkinan besar tugas refresh gagal berulang kali. Buka Konsol HoloWeb untuk meninjau tugas yang gagal dan segera menyelesaikan masalahnya.
Latensi data tabel dinamis (detik)
Metrik ini menunjukkan latensi data setiap tabel dinamis dalam suatu instans relatif terhadap data terbaru di tabel dasar hulu atau titik waktu tertentu. Satuannya adalah detik. Metrik ini mencerminkan kesegaran data. Tetapkan ambang batas peringatan latensi yang wajar sesuai kebutuhan Anda. Jika latensi terus meningkat, kemungkinan penyebabnya meliputi:
Tugas refresh terus-menerus gagal atau auto-refresh dijeda. Buka halaman manajemen tabel dinamis di Konsol HoloWeb untuk menyelidiki masalah tersebut.
Volume data yang berubah di sumber data hulu sangat besar, dan sumber daya instans yang tidak mencukupi memperlambat proses refresh. Lakukan investigasi dengan meninjau metrik pemantauan Hologres seperti durasi refresh.
Durasi tugas refresh tabel dinamis yang sedang berjalan (ms)
Metrik ini menunjukkan berapa lama tugas refresh saat ini untuk setiap tabel dinamis dalam suatu instans telah berjalan. Satuannya adalah milidetik. Gunakan metrik ini untuk mendeteksi apakah epoch refresh semakin panjang. Konfigurasikan peringatan durasi refresh untuk masing-masing tabel berdasarkan skenario bisnis Anda. Jika metrik ini tiba-tiba meningkat atau tetap jauh lebih tinggi dibanding rata-rata historisnya, selidiki kemungkinan penyebabnya seperti bottleneck sumber daya instans atau perubahan volume data hulu.
QPM kegagalan refresh tabel dinamis (jumlah/menit)
Metrik ini menunjukkan jumlah tugas refresh yang gagal per menit untuk setiap tabel dinamis dalam suatu instans. Metrik ini membantu menilai stabilitas refresh pada satu tabel. Biasanya, nilai ini harus nol. Kegagalan sesekali—seperti yang disebabkan oleh tekanan sistem atau peningkatan instans—umumnya dapat diabaikan jika refresh berikutnya berhasil. Jika metrik ini tetap lebih besar dari nol untuk suatu tabel dalam periode waktu tertentu, hal ini menunjukkan adanya masalah persisten pada tugas refresh tabel tersebut. Selidiki dan selesaikan masalah tersebut menggunakan pesan error di log kegagalan tabel dinamis.
Peringatan
Anda dapat mengonfigurasi aturan peringatan untuk tugas refresh tabel dinamis di Cloud Monitor guna mendeteksi anomali secara cepat. Untuk informasi selengkapnya, lihat Cloud Monitor.
Lihat tugas refresh
Lihat tugas refresh yang sedang berjalan
Lihat menggunakan hologres.hg_dynamic_table_refresh_activity
Anda dapat menggunakan tabel sistem hologres.hg_dynamic_table_refresh_activity untuk melihat tugas refresh yang sedang berjalan—termasuk refresh penuh dan bertahap—serta konsumsi sumber dayanya. Untuk informasi lebih lanjut tentang bidang-bidang dalam tabel sistem hologres.hg_dynamic_table_refresh_activity, lihat tabel sistem hologres.hg_dynamic_table_refresh_activity.
Tabel sistem ini hanya didukung di Hologres V3.0, serta V4.0.8 dan versi yang lebih baru.
-- Lihat tugas refresh yang sedang berjalan
SELECT
pid,
query_id,
refresh_mode,
'RUNNING' as status,
refresh_start,
extract(epoch from duration) as duration, -- milidetik
serverless_queue_time_ms::bigint / 1000 AS serverless_queue_time_sec,
serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_sec,
serverless_allocated_cores
FROM
hologres.hg_dynamic_table_refresh_activity
WHERE datname = '${database}'
AND table_write = quote_ident('${schema}') || '.' || quote_ident('${tableName}')
ORDER BY refresh_start DESC
limit 2000;Lihat menggunakan hg_stat_activity
Anda dapat menggunakan tampilan sistem hg_stat_activity untuk melihat tugas refresh yang sedang berjalan. Tampilannya berbeda tergantung pada mode refresh di hg_stat_activity:
Refresh penuh: Muncul pernyataan `INSERT`.
Refresh bertahap: Muncul tugas `Refresh`.
Lihat tugas refresh menggunakan metrik pemantauan
Anda dapat memeriksa metrik seperti QPS, catatan per detik (RPS), dan latensi untuk memastikan status eksekusi tugas refresh tabel dinamis. Jenis `Command Type` bernilai `refresh` menunjukkan tugas refresh tabel dinamis. Untuk informasi selengkapnya tentang metrik pemantauan, lihat metrik pemantauan konsol Hologres.
Jika tugas refresh tabel dinamis dijalankan pada sumber daya Serverless Computing, Anda juga dapat melihat statusnya di metrik Serverless Computing terkait.
Anda dapat membuat aturan peringatan untuk tugas refresh tabel dinamis di Cloud Monitor. Untuk informasi selengkapnya, lihat Cloud Monitor.
Lihat riwayat tugas refresh
Lihat menggunakan hologres.hg_dynamic_table_refresh_history
Tabel sistem hologres.hg_dynamic_table_refresh_history mencatat riwayat semua tugas refresh tabel dinamis selama sebulan terakhir, termasuk refresh penuh, bertahap, dan manual. Untuk informasi lebih lanjut tentang bidang-bidang dalam tabel sistem hologres.hg_dynamic_table_refresh_history, lihat tabel sistem hologres.hg_dynamic_table_refresh_history.
Secara default, catatan selama sebulan terakhir disimpan. Anda tidak dapat mengkueri data yang lebih lama dari satu bulan.
Hanya pemilik tabel yang dapat melihat riwayat refresh mereka sendiri, sedangkan Superuser dapat melihat semua catatan refresh.
Contoh 1: Lihat catatan refresh bertahap dari hari kemarin.
-- Contoh 1: Lihat catatan refresh bertahap selama sehari terakhir SELECT query_id, refresh_mode, status, refresh_start, duration, refresh_latency / 1000 AS refresh_latency_second, serverless_allocated_cores, queue_time_ms::bigint / 1000 AS queue_time_second, serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second FROM hologres.hg_dynamic_table_refresh_history WHERE refresh_start >= CURRENT_DATE - INTERVAL '1 day' AND dynamic_table_name = '<dynamic_table>' AND refresh_mode = 'incremental' ORDER BY refresh_start DESC limit 100;Contoh 2: Lihat semua tugas refresh di instans saat ini dari hari kemarin.
-- Lihat semua catatan refresh di instans selama sehari terakhir SELECT query_id, refresh_mode, status, refresh_start, duration, refresh_latency / 1000 AS refresh_latency_second, serverless_allocated_cores, queue_time_ms::bigint / 1000 AS queue_time_second, serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second FROM hologres.hg_dynamic_table_refresh_history where refresh_start >= CURRENT_DATE - INTERVAL '1 day'Contoh 3: Lihat catatan refresh untuk tabel tertentu dari hari kemarin.
-- Lihat catatan refresh untuk tabel tertentu selama sehari terakhir SELECT query_id, refresh_mode, status, refresh_start, duration, refresh_latency / 1000 AS refresh_latency_second, serverless_allocated_cores, queue_time_ms::bigint / 1000 AS queue_time_second, serverless_resource_used_time_ms::bigint / 1000 AS serverless_resource_used_time_second FROM hologres.hg_dynamic_table_refresh_history where schema_name='<scehma_name>' and dynamic_table_name='<dynamic_table>' and refresh_start >= CURRENT_DATE - INTERVAL '1 day'
Untuk tabel dinamis full-refresh yang dibuat dengan sintaks lama versi 3.0, hologres.hg_dynamic_table_refresh_history mungkin tidak mencerminkan status keberhasilan atau kegagalan refresh yang sebenarnya. Refresh yang gagal mungkin tampak sebagai `Success`. Untuk mengambil status riwayat refresh yang sebenarnya dari tabel dinamis full-refresh yang dibuat dengan sintaks 3.0, lakukan langkah-langkah berikut:
Ambil
cron_job_namedarihologres.hg_dynamic_table_properties.Gunakan
cron_job_nameuntuk mengkueri catatan eksekusi tugas Cron dihologres.hg_user_cron_tasks.
-- Dapatkan cron_job_name
SELECT property_value AS cron_job_name
FROM hologres.hg_dynamic_table_properties
WHERE dynamic_table_name = '<dt_name>' AND property_key = 'cron_job_name';
-- Kueri catatan eksekusi tugas Cron berdasarkan cron_job_name
SELECT *
FROM hologres.hg_user_cron_tasks
WHERE jobname = '<cron_job_name>'
ORDER BY start_time DESC;Lihat menggunakan log kueri lambat
Anda dapat melihat tugas refresh tabel dinamis di log kueri lambat. `Command Type`-nya adalah `refresh`. Untuk informasi selengkapnya tentang cara melihat log kueri lambat, lihat Lihat dan analisis log kueri lambat.
Lihat rencana eksekusi tugas refresh
Seperti kueri biasa, Anda dapat menggunakan EXPLAIN dan EXPLAIN ANALYZE untuk melihat rencana eksekusi dan informasi waktu proses tugas refresh. Hal ini membantu Anda mengidentifikasi bottleneck performa dan mengoptimalkan kueri lebih lanjut. Contoh berikut menunjukkan cara melakukannya:
explain refresh dynamic table hmtest.dt_order_lineitem;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------
Gather (cost=0.00..10.13 rows=1 width=16)
-> Insert (cost=0.00..10.13 rows=1 width=16)
-> Redistribution (cost=0.00..10.11 rows=1 width=16)
-> Final HashAggregate (cost=0.00..10.11 rows=1 width=16)
Group Key: orders.o_orderpriority
-> Redistribution (cost=0.00..10.11 rows=10 width=16)
Hash Key: orders.o_orderpriority
-> Partial HashAggregate (cost=0.00..10.11 rows=10 width=16)
Group Key: orders.o_orderpriority
-> Hash Left Semi Join (cost=0.00..10.11 rows=1000 width=8)
Hash Cond: (orders.o_orderkey = lineitem.l_orderkey)
-> Redistribution (cost=0.00..5.03 rows=1000 width=16)
Hash Key: orders.o_orderkey
-> Local Gather (cost=0.00..5.01 rows=1000 width=16)
-> Seq Scan on orders (cost=0.00..5.01 rows=1000 width=16)
Filter: ((o_orderdate >= '1996-07-01 00:00:00+08'::timestamp with time zone) AND (o_orderdate < '199
6-10-01 00:00:00+08'::timestamp with time zone))
-> Hash (cost=5.03..5.03 rows=1000 width=8)
-> Redistribution (cost=0.00..5.03 rows=1000 width=8)
Hash Key: lineitem.l_orderkey
-> Local Gather (cost=0.00..5.03 rows=1000 width=8)
-> Seq Scan on lineitem (cost=0.00..5.03 rows=1000 width=8)
Filter: (l_commitdate < l_receiptdate)
Optimizer: HQO version 2.1.0
(23 rows)Tetapkan durasi timeout refresh
Seperti kueri biasa, Anda dapat menetapkan durasi timeout untuk tugas refresh tabel dinamis.
Pengaturan tingkat tabel
Saat membuat tabel dinamis, Anda dapat menetapkan durasi timeout tugas refresh yang berlaku untuk semua tugas refresh tabel tersebut. Kode SQL berikut menggunakan dataset publik tpch_10g sebagai contoh. Sebelum menjalankan kode, pastikan Anda telah berhasil mengimpor dataset publik tpch_10g. Untuk informasi selengkapnya, lihat Buat tugas untuk mengimpor dataset publik.
-- Tetapkan durasi timeout tugas refresh saat membuat tabel.
CREATE DYNAMIC TABLE tpch_q1_batch
WITH (
refresh_mode='full',
auto_refresh_enable='true',
full_auto_refresh_interval='1 hours',
refresh_guc_statement_timeout='30 mins'-- Durasi timeout refresh adalah 30 menit
)
AS
SELECT
l_returnflag,
l_linestatus,
SUM(l_quantity) AS sum_qty,
SUM(l_extendedprice) AS sum_base_price,
SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
AVG(l_quantity) AS avg_qty,
AVG(l_extendedprice) AS avg_price,
AVG(l_discount) AS avg_disc,
COUNT(*) AS count_order
FROM
hologres_dataset_tpch_10.lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
l_returnflag,
l_linestatus;Pengaturan tingkat session
Saat melakukan refresh manual, Anda dapat menetapkan durasi timeout menggunakan parameter Grand Unified Configuration (GUC) tingkat session. Berikut adalah contoh pernyataan SQL:
SET statement_timeout = <time>;
refresh DYNAMIC TABLE <dynamic_schema_name.dynamic_table_name>;Untuk informasi selengkapnya tentang pengaturan, lihat Ubah durasi timeout untuk kueri aktif.
Tetapkan menggunakan `refresh with option`
Saat melakukan refresh manual, Anda juga dapat menggunakan refresh ... with (refresh_guc_statement_timeout = '...') untuk menentukan durasi timeout untuk refresh saat ini. Berikut adalah contohnya.
REFRESH DYNAMIC TABLE <schema_name.table_name> WITH (
refresh_guc_statement_timeout = '30 mins'
);Refresh manual
Anda dapat melakukan refresh manual pada tabel dinamis. Sintaksnya sebagai berikut:
REFRESH DYNAMIC TABLE <schema_name.table_name>;Jika auto-refresh diaktifkan dalam properti tabel, refresh manual akan berjalan paralel dengan tugas auto-refresh. Kedua tugas berjalan normal. Sistem memastikan hanya satu salinan data terbaru yang disimpan.
Batalkan tugas refresh
Tabel dinamis yang dibuat dengan sintaks 3.1 baru
Batalkan tugas refresh yang sedang berjalan
Untuk tabel dinamis yang dibuat dengan sintaks 3.1 baru, pertama-tama kueri query_job_id dari tugas refresh yang sedang berjalan di hologres.hg_dynamic_table_refresh_log, lalu batalkan tugas tersebut menggunakan hologres.hg_internal_cancel_query_job.
-- Dapatkan query_job_id
SELECT query_job_id
FROM hologres.hg_dynamic_table_refresh_log('<dt_name>')
WHERE status = 'Running';
-- Batalkan tugas refresh berdasarkan query_job_id
SELECT hologres.hg_internal_cancel_query_job('<query_job_id>');Hanya Superuser yang dapat membatalkan tugas refresh menggunakan hologres.hg_internal_cancel_query_job.
Batalkan semua tugas refresh untuk suatu tabel
Jika tugas refresh dikonfigurasi untuk tabel dinamis, Anda dapat menjalankan pernyataan ALTER TABLE untuk membatalkan semua tugas refresh berikutnya di tingkat tabel. Untuk mengaktifkan kembali refresh, lihat ALTER DYNAMIC TABLE.
ALTER DYNAMIC TABLE [ IF EXISTS ] [<schema>.]<table_name> SET (auto_refresh_enable=false);Gunakan operasi ini dengan hati-hati. Jika tidak, data berikutnya mungkin tidak diperbarui.
Tabel dinamis yang dibuat dengan sintaks 3.0
Batalkan tugas refresh yang sedang berjalan
Jika tugas refresh berjalan dalam waktu lama tanpa selesai atau menunjukkan masalah seperti tersendat, Anda dapat membatalkan tugas refresh yang sedang berjalan menggunakan pg_cancel_backend.
Jalankan perintah berikut untuk membatalkan satu tugas refresh yang sedang berjalan.
-- pid adalah ID tugas refresh. Anda dapat memperoleh query_id dengan melihat tugas refresh.
SELECT pg_cancel_backend(<pid>);Parameter `pid` adalah ID tugas refresh. Anda dapat memperoleh ID tugas refresh (`query_id`) dengan melihat tugas refresh tersebut. Untuk informasi selengkapnya, lihat Lihat tugas refresh.
Metode pembatalan tugas refresh yang sedang berjalan secara batch sama seperti untuk kueri biasa. Untuk informasi selengkapnya, lihat Hentikan kueri.
Batalkan semua tugas refresh untuk suatu tabel
Jika tugas refresh dikonfigurasi untuk tabel dinamis, Anda dapat menggunakan perintah ALTER DYNAMIC TABLE untuk membatalkan semua tugas refresh berikutnya di tingkat tabel.
ALTER DYNAMIC TABLE [IF EXISTS ] [<schema>.]<table_name> set (auto_refresh_enable=false);Gunakan operasi ini dengan hati-hati. Jika tidak, data berikutnya mungkin tidak diperbarui.