Penggabungan tabel ganda dan operasi agregasi kompleks dapat mengonsumsi sumber daya komputasi dan waktu yang signifikan. Tampilan yang di-materialisasi di AnalyticDB for MySQL mengatasi hal ini dengan melakukan pra-komputasi dan menyimpan hasil kueri yang ditentukan pengguna. Saat menjalankan kueri, AnalyticDB for MySQL dapat langsung membaca hasil pra-komputasi dari tampilan yang di-materialisasi untuk meningkatkan waktu respons. Topik ini menjelaskan cara membuat tampilan yang di-materialisasi.
Prasyarat
Versi kernel adalah 3.1.3.4 atau lebih baru.
Untuk melihat dan memperbarui versi minor, buka bagian Configuration Information pada halaman Cluster Information di AnalyticDB for MySQL console.
Buat tampilan yang di-materialisasi
Izin yang diperlukan
Untuk membuat tampilan yang di-materialisasi, Anda harus memiliki semua izin berikut:
Izin CREATE pada tabel di database tempat Anda ingin membuat tampilan yang di-materialisasi.
Izin SELECT pada kolom tertentu, atau semua kolom, dari semua tabel dasar yang dirujuk dalam tampilan yang di-materialisasi.
Jika Anda ingin membuat tampilan yang di-materialisasi dengan refresh otomatis, Anda juga harus memiliki izin berikut:
Izin untuk menghubungkan ke
'%'(alamat IP apa pun) di AnalyticDB for MySQL.Izin INSERT pada tampilan yang di-materialisasi atau semua tabel di database tempat tampilan tersebut berada. Tanpa izin ini, tampilan yang di-materialisasi tidak dapat direfresh.
Persiapkan tabel dasar
Bagian ini menggunakan tabel customer dan sales sebagai contoh untuk membantu Anda membuat tampilan yang di-materialisasi dengan cepat.
/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- Setel mesin tabel ke XUANWU.
CREATE TABLE customer (
customer_id INT PRIMARY KEY,
customer_name VARCHAR(255),
is_vip Boolean
);/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- Setel mesin tabel ke XUANWU.
CREATE TABLE sales (
sale_id INT PRIMARY KEY,
product_id INT,
customer_id INT,
price DECIMAL(10, 2),
quantity INT,
sale_date TIMESTAMP
);Contoh dalam bagian ini tidak menentukan kelompok sumber daya. Jika Anda tidak menentukan kelompok sumber daya, AnalyticDB for MySQL menggunakan sumber daya komputasi dari kelompok sumber daya interaktif default untuk membuat dan merefresh tampilan yang di-materialisasi. Untuk memahami perbedaan antara kelompok sumber daya interaktif dan job atau menggunakan kelompok sumber daya job, lihat Gunakan sumber daya elastis untuk membuat atau merefresh tampilan yang di-materialisasi.
Buat tampilan yang di-materialisasi yang mendukung refresh lengkap
Anda dapat membuat tampilan yang di-materialisasi yang mendukung refresh lengkap, juga dikenal sebagai tampilan yang di-materialisasi lengkap. Tampilan ini dapat didasarkan pada tabel internal dan eksternal AnalyticDB for MySQL, tampilan yang di-materialisasi yang sudah ada, dan tampilan.
Topik ini menunjukkan cara membuat tampilan yang di-materialisasi dengan refresh penuh bernama join_mv menggunakan tabel dasar customer dan sales, lalu mengonfigurasi tampilan tersebut untuk refresh manual.
CREATE MATERIALIZED VIEW join_mv
REFRESH COMPLETE ON DEMAND
AS
SELECT
sale_id,
SUM(price * quantity) AS price
FROM customer
INNER JOIN (SELECT sale_id,customer_id,price,quantity FROM sales) sales ON customer.customer_id = sales.customer_id
GROUP BY customer.customer_id;Untuk memperbarui data dalam tampilan yang di-materialisasi, jalankan REFRESH MATERIALIZED VIEW join_mv;.
Buat tampilan yang di-materialisasi yang mendukung refresh cepat
Anda dapat membuat tampilan yang di-materialisasi inkremental, yaitu jenis tampilan yang di-materialisasi yang mendukung refresh inkremental, berdasarkan tabel internal di AnalyticDB for MySQL.
Bagian ini menunjukkan cara membuat tampilan yang di-materialisasi cepat berdasarkan beberapa tabel yang digabungkan.
Sebelum membuat tampilan yang di-materialisasi inkremental, selesaikan persiapan berikut:
Periksa apakah kluster Anda menjalankan AnalyticDB for MySQL V3.1.9.0 atau lebih baru.
Aktifkan binary logging di tingkat kluster dan untuk setiap tabel dasar.
Jika aktivasi binary logging untuk tabel dasar gagal, lihat Kesalahan eksekusi kueri: : Can not create FAST materialized view, because demotable doesn't support getting incremental data.
SET ADB_CONFIG BINLOG_ENABLE=true; ALTER TABLE customer binlog=true; ALTER TABLE sales binlog=true;
Buat tampilan yang di-materialisasi cepat bernama sales_mv_incre. Tampilan ini hanya menghitung data dari tabel sales.
CREATE MATERIALIZED VIEW sales_mv_incre
REFRESH FAST NEXT now() + INTERVAL 3 minute
AS
SELECT
sale_id,
SUM(price * quantity) AS price
FROM sales
GROUP BY sale_id;Jika kluster Anda menjalankan AnalyticDB for MySQL V3.2.1.0 atau lebih baru, Anda juga dapat membuat tampilan yang di-materialisasi cepat multi-tabel bernama join_mv_incre, dengan refresh otomatis setiap 3 menit.
CREATE MATERIALIZED VIEW join_mv_incre
REFRESH FAST NEXT now() + INTERVAL 3 minute
AS
SELECT
customer.customer_id,
SUM(sales.price) AS price
FROM customer
INNER JOIN (SELECT customer_id,price FROM sales) sales ON customer.customer_id = sales.customer_id
GROUP BY customer.customer_id;Untuk informasi lebih lanjut tentang sintaks dan contoh lainnya, lihat CREATE MATERIALIZED VIEW.
Lihat tampilan yang di-materialisasi yang sedang dibuat
Jalankan SHOW PROCESSLIST WHERE info LIKE '%CREATE MATERIALIZED VIEW%'; untuk mencantumkan tampilan yang di-materialisasi yang sedang dibuat.
Setiap baris dalam hasil mewakili tampilan yang di-materialisasi yang sedang dibuat. Kolom user menampilkan akun database yang digunakan untuk membuat tampilan tersebut. Kolom status menampilkan status saat ini. Kolom Info berisi pernyataan CREATE lengkap. Untuk informasi lebih lanjut tentang kolom-kolom ini, lihat SHOW PROCESSLIST.
Jika SHOW PROCESSLIST tidak mengembalikan baris apa pun, tampilan yang di-materialisasi telah berhasil dibuat, termasuk skema tabel dan pemuatan data awalnya.
Tulis kueri tabel dasar saat membuat tampilan yang di-materialisasi
Kueri tabel dasar untuk tampilan yang di-materialisasi lengkap
Tampilan yang di-materialisasi lengkap dapat dibuat dari tabel internal dan eksternal AnalyticDB for MySQL, tampilan yang di-materialisasi yang sudah ada, dan tampilan. Tidak ada batasan pada kueri tabel dasar. Untuk informasi lebih lanjut tentang sintaks kueri, lihat SELECT.
Kueri Tabel Dasar Tampilan yang Di-Materialisasi Inkremental
Untuk tampilan yang di-materialisasi dengan refresh inkremental, tabel dasar harus merupakan tabel internal di AnalyticDB for MySQL. Kueri pada tabel dasar harus mematuhi aturan berikut:
SELECT kolom
Jika kueri Anda mencakup fungsi agregat dan klausa GROUP BY, daftar SELECT harus mencakup semua kolom dalam klausa GROUP BY.
Jika kueri Anda mencakup fungsi agregat tetapi tidak memiliki klausa GROUP BY, daftar SELECT hanya boleh berisi kolom konstan dan agregat, atau hanya kolom agregat.
Jika kueri Anda tidak menggunakan agregasi, daftar SELECT harus mencakup semua kolom kunci primer tabel dasar.
Kueri UNION ALL tidak mendukung fungsi agregat. Setiap cabang input harus menghasilkan kolom bernama “union_all_marker”. Kolom ini harus berupa konstan, dan setiap cabang harus menggunakan nilai konstan yang berbeda. Jika tidak, kebenaran data tidak dapat dijamin. Daftar SELECT harus mencakup semua kolom kunci primer tabel dasar. Kunci primer tampilan yang di-materialisasi harus mencakup kolom kunci primer tabel dasar dan kolom union_all_marker.
CREATE MATERIALIZED VIEW demo_union_all_mv (PRIMARY KEY(id, union_all_marker)) REFRESH FAST NEXT now() + INTERVAL 5 minute AS SELECT customer_id as id, "customer" as union_all_marker FROM customer UNION ALL SELECT sale_id as id, "sales" as union_all_marker FROM sales;Semua kolom ekspresi dalam daftar SELECT harus memiliki alias. Gunakan nama yang bermakna, seperti
SUM(price) AS total_price.
Batasan lainnya
Gunakan sumber daya elastis untuk membuat atau merefresh tampilan yang di-materialisasi
Sumber daya elastis mengacu pada sumber daya komputasi dalam kelompok sumber daya job. Membuat dan merefresh tampilan yang di-materialisasi mengonsumsi sumber daya komputasi kluster. Jika Anda tidak menentukan kelompok sumber daya menggunakan MV_PROPERTIES='{"mv_resource_group":"rg_name"}', AnalyticDB for MySQL menggunakan sumber daya komputasi cadangan dari kelompok sumber daya interaktif default (bernama user_default) untuk membuat dan merefresh tampilan yang di-materialisasi.
Jika Anda menentukan kelompok sumber daya job saat membuat tampilan yang di-materialisasi, kelompok tersebut akan digunakan baik untuk pembuatan maupun refresh berikutnya. Anda juga dapat menggunakan "mv_refresh_hints":{"elastic_job_max_acu":"value"} untuk menentukan sumber daya maksimum yang tersedia. Untuk informasi lebih lanjut tentang penggunaannya, lihat mv_properties.
Kelompok sumber daya job berbeda dari kelompok sumber daya interaktif. Dengan kelompok sumber daya job, Anda tidak perlu membeli sumber daya terlebih dahulu, sehingga menghindari pemborosan dan mengurangi biaya. Namun, performa refresh lebih rendah dibandingkan dengan kelompok sumber daya interaktif karena setiap refresh memerlukan penyediaan sumber daya komputasi oleh kelompok sumber daya job sesuai permintaan. Proses ini dapat memakan waktu beberapa detik hingga menit.
Anda dapat menggunakan sumber daya elastis jika kluster Anda memenuhi kedua kondisi berikut:
Kluster menggunakan Edisi Perusahaan, Edisi Dasar, atau Edisi Data Lakehouse.
Kluster menjalankan AnalyticDB for MySQL V3.1.9.3 atau lebih baru.
Gunakan sumber daya elastis dari kelompok sumber daya job bernama my_job_rg untuk membuat dan merefresh tampilan yang di-materialisasi berdasarkan tabel customer dengan prioritas tinggi.
CREATE MATERIALIZED VIEW job_mv
MV_PROPERTIES='{
"mv_resource_group":"my_job_rg",
"mv_refresh_hints":{"query_priority":"HIGH"}
}'
REFRESH COMPLETE ON DEMAND
START WITH now()
NEXT now() + INTERVAL 1 DAY
AS
SELECT * FROM customer;Mekanisme pemicu refresh untuk tampilan yang di-materialisasi
Tampilan yang di-materialisasi mencerminkan keadaan data setelah refresh terakhirnya, yang belum tentu merupakan data terbaru di tabel dasar. Tampilan yang di-materialisasi tidak secara otomatis direfresh pada setiap kueri. Untuk memastikan ketepatan waktu dan akurasi data, Anda dapat mengonfigurasi salah satu pemicu refresh berikut: auto-refresh terjadwal, auto-refresh saat overwrite tabel dasar, atau refresh manual.
Saat Anda merefresh tampilan yang di-materialisasi, sistem akan menerapkan refresh lengkap atau refresh cepat, tergantung pada kebijakan refresh-nya.
Untuk informasi lebih lanjut tentang perbedaan antara pemicu dan kebijakan refresh serta kasus penggunaannya, lihat Refresh tampilan yang di-materialisasi.
Batasan
Batasan umum
Batasan ini berlaku untuk semua tampilan yang di-materialisasi, termasuk tampilan yang di-materialisasi lengkap dan cepat.
Anda tidak dapat menjalankan
INSERT,DELETE, atauUPDATEpada tampilan yang di-materialisasi.Anda tidak dapat menghapus atau mengganti nama tabel dasar, atau kolom dalam tabel dasar, yang dirujuk oleh tampilan yang di-materialisasi. Untuk memodifikasi tabel dasar, Anda harus terlebih dahulu menghapus tampilan yang di-materialisasi.
Secara default, jumlah maksimum tampilan yang di-materialisasi per kluster AnalyticDB for MySQL bergantung pada versi minor:
V3.1.4.7 atau lebih baru: hingga 64 tampilan yang di-materialisasi.
Lebih awal dari V3.1.4.7: hingga delapan tampilan yang di-materialisasi.
CatatanJika Anda mencapai batas tersebut, Anda dapat menghubungi dukungan teknis untuk meminta kuota yang lebih tinggi.
Batasan pada tampilan yang di-materialisasi lengkap
Saat Anda menambah atau menghapus node cadangan, pekerjaan asinkron dinonaktifkan. Karena refresh lengkap merupakan pekerjaan asinkron, refresh tersebut tidak dapat dijalankan selama penskalaan node. Fitur refresh cepat tidak terpengaruh.
Batasan Tampilan yang Di-Materialisasi Inkremental
Batasan tampilan yang di-materialisasi inkremental pada tabel dasar:
Kluster yang lebih awal dari V3.2.6.0 tidak mendukung tabel XUANWU_V2 sebagai tabel dasar untuk tampilan yang di-materialisasi cepat.
Tabel XUANWU_V2 tidak mendukung binary logging.
Kluster yang lebih awal dari V3.2.3.0 tidak mendukung tabel partisi sebagai tabel dasar untuk tampilan yang di-materialisasi cepat.
Kluster yang lebih awal dari V3.2.3.1 tidak mendukung INSERT OVERWRITE atau TRUNCATE pada tabel dasar untuk tampilan yang di-materialisasi cepat. Pernyataan ini akan mengembalikan error.
Jika kueri Anda menggunakan MAX(), MIN(), APPROX_DISTINCT(), atau COUNT(DISTINCT), tabel dasar hanya mendukung INSERT. Operasi yang menghapus data, seperti DELETE, UPDATE, REPLACE, dan INSERT ON DUPLICATE KEY UPDATE, tidak diizinkan.
Kluster yang menjalankan V3.2.5.0 atau lebih baru mendukung binary logging pada tampilan yang di-materialisasi. Oleh karena itu, tampilan yang di-materialisasi dapat berfungsi sebagai tabel dasar, yang memungkinkan Anda membuat tampilan yang di-materialisasi cepat bersarang.
Batasan pada pemicu refresh:
Hanya auto-refresh terjadwal yang didukung, bukan refresh manual. Interval harus antara 5 detik hingga 5 menit.
Batasan pada isi kueri (query_body):
Ekspresi nondeterministik, seperti NOW() atau RAND(), tidak didukung.
Klausa ORDER BY tidak didukung.
Klausa HAVING tidak didukung.
Fungsi window tidak didukung.
Operator himpunan seperti UNION, EXCEPT, dan INTERSECT tidak didukung. UNION ALL didukung pada V3.2.5.0 dan lebih baru.
Hanya INNER JOIN yang didukung. Kolom join harus memenuhi semua kriteria berikut: harus merupakan kolom asli tabel dasar, memiliki tipe data identik, dan diindeks. Anda dapat menggabungkan hingga lima tabel dasar.
Untuk mengaitkan lebih banyak tabel, silakan ke dukungan teknis.
Hanya fungsi agregat berikut yang didukung: COUNT, SUM, MAX, MIN, AVG, APPROX_DISTINCT, dan COUNT(DISTINCT).
AVG tidak mendukung tipe DECIMAL.
COUNT(DISTINCT) hanya mendukung tipe INTEGER.
FAQ
Bagaimana cara menyimpan hanya data satu tahun terakhir dalam tampilan yang di-materialisasi?
Saat mendefinisikan tampilan yang di-materialisasi, gunakan kolom tanggal sebagai kunci partisi (PARTITION BY) dan atur siklus hidup (LIFECYCLE) untuk menyimpan hanya data satu tahun terakhir.
Sebagai contoh, jika tabel sales menerima catatan baru setiap hari, Anda dapat menggunakan kolom sale_date sebagai kunci partisi dan mengatur LIFECYCLE ke 365. Ini akan menyimpan hanya 365 partisi terbaru, yang secara efektif merupakan data satu tahun.
CREATE MATERIALIZED VIEW sales_mv_lifecycle
PARTITION BY VALUE(DATE_FORMAT(sale_date, '%Y%m%d')) LIFECYCLE 365
REFRESH FAST NEXT now() + INTERVAL 100 second
AS
SELECT
sale_date,
SUM(price * quantity) AS price
FROM sales
GROUP BY sale_date;Error umum dan troubleshooting
Kesalahan eksekusi kueri: Tidak dapat membuat tampilan yang di-materialisasi FAST, karena demotable tidak mendukung pengambilan data inkremental
Penyebab: Binary logging tidak diaktifkan untuk tabel dasar demotable, yang digunakan oleh tampilan yang di-materialisasi dengan refresh inkremental. Tampilan yang di-materialisasi dengan refresh inkremental memerlukan binary logging diaktifkan untuk semua tabel dasar yang terlibat.
Solusi: Jalankan ALTER TABLE demotable binlog=true; untuk mengaktifkan binary logging pada tabel dasar.
Jika Anda menerima error XUANWU_V2 engine not support ALTER_BINLOG_ENABLE now, tabel dasar demotable menggunakan mesin XUANWU_V2. XUANWU_V2 tidak mendukung binary logging. Karena Anda tidak dapat mengubah mesin tabel, Anda harus menonaktifkan XUANWU_V2, membuat ulang tabel menggunakan mesin XUANWU, memigrasikan data dari tabel XUANWU_V2 ke tabel XUANWU, lalu membuat tampilan yang di-materialisasi cepat pada tabel XUANWU.
Untuk menonaktifkan XUANWU_V2:
Jika tabel dasar dibuat secara otomatis oleh DTS, zero-ETL, atau sinkronisasi data konsol, nonaktifkan XUANWU_V2 di tingkat kluster. Setelah Anda menonaktifkan XUANWU_V2, semua tabel baru akan menggunakan mesin XUANWU.
Nonaktifkan di tingkat kluster:
SET adb_config RC_DDL_ENGINE_REWRITE_XUANWUV2=false;Jika tabel dasar dibuat secara manual dengan CREATE TABLE dan hanya beberapa yang diperlukan untuk tampilan yang di-materialisasi cepat, Anda dapat menonaktifkan XUANWU_V2 dalam pernyataan CREATE TABLE tersebut. Hanya pernyataan tersebut yang akan membuat tabel XUANWU. Pernyataan CREATE TABLE lainnya tetap membuat tabel XUANWU_V2.
Nonaktifkan di tingkat tabel:
/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */CREATE TABLE ...
Kesalahan eksekusi kueri: : PRIMARY KEY id must output to MV.
Penyebab: Kueri tampilan yang di-materialisasi cepat Anda adalah kueri non-agregat yang tidak memiliki klausa GROUP BY. Dalam kasus ini, kunci primer tampilan yang di-materialisasi harus sama dengan kunci primer tabel dasar, tetapi daftar SELECT menghilangkan kolom kunci primer tabel dasar.
Contoh salah:
CREATE MATERIALIZED VIEW wrong_example1
REFRESH FAST ON DEMAND
NEXT now() + interval 200 second
AS
SELECT product_id,price -- Tabel dasar sales memiliki kunci primer sale_id, tetapi sale_id tidak ada di SELECT.
FROM sales;Solusi: Tambahkan kolom kunci primer tabel dasar ke daftar SELECT.
Contoh benar:
CREATE MATERIALIZED VIEW correct_example1
REFRESH FAST ON DEMAND
NEXT now() + interval 200 second
AS
SELECT sale_id,product_id, price -- Tambahkan kunci primer tabel dasar sale_id ke SELECT.
FROM sales;Kesalahan eksekusi kueri: : MV PRIMARY KEY must be equal to base table PRIMARY KEY.
Penyebab: Kueri tampilan yang di-materialisasi cepat Anda adalah kueri non-agregat yang tidak memiliki klausa GROUP BY. Dalam kasus ini, kunci primer tampilan yang di-materialisasi harus sama dengan kunci primer tabel dasar, tetapi definisi mencakup kolom kunci primer tabel dasar dan kolom non-kunci-primer.
Contoh salah:
CREATE MATERIALIZED VIEW wrong_example2
(PRIMARY KEY(sale_id,product_id)) -- product_id bukan kolom kunci primer tabel dasar sales.
REFRESH FAST ON DEMAND
NEXT now() + interval 200 second
AS
SELECT sale_id,product_id,price
FROM sales;Solusi: Hapus kolom non-kunci-primer dari definisi kunci primer tampilan yang di-materialisasi.
Contoh benar:
CREATE MATERIALIZED VIEW correct_example2
(PRIMARY KEY(sale_id)) -- Hapus product_id dari kunci primer.
REFRESH FAST ON DEMAND
NEXT now() + interval 200 second
AS
SELECT sale_id,product_id,price
FROM sales;Kesalahan eksekusi kueri: : FAST materialized view must define PRIMARY KEY
Penyebab: Error ini memiliki dua kemungkinan penyebab:
Tampilan yang di-materialisasi cepat tidak mendefinisikan kunci primer yang valid.
Kueri menerapkan fungsi pada kolom kunci primer tabel dasar.
Solusi: Pilih perbaikan yang sesuai:
Tidak ada kunci primer valid yang didefinisikan: Perbarui definisi tampilan yang di-materialisasi (mv_definition) agar memenuhi aturan berikut:
Untuk kueri agregat berkelompok (dengan GROUP BY), kunci primer harus berupa kolom GROUP BY. Misalnya, jika
GROUP BY a,b, kunci primer harus kolom a dan b.Untuk kueri agregat tidak berkelompok (tanpa GROUP BY), kunci primer harus berupa konstan.
Untuk kueri non-agregat, kunci primer harus persis sama dengan kunci primer tabel dasar. Misalnya, jika kunci primer tabel dasar adalah PRIMARY KEY(sale_id,sale_date), kunci primer tampilan yang di-materialisasi juga harus PRIMARY KEY(sale_id,sale_date).
Fungsi diterapkan pada kolom kunci primer: Ubah kueri untuk menghapus fungsi dari kolom kunci primer tabel dasar.
Kesalahan eksekusi kueri: Graf gabungan tidak didukung.
Penyebab: Kolom yang digunakan dalam penggabungan multi-tabel memiliki tipe data yang tidak cocok. Contoh: sales INNER JOIN customer ON customer.id=sales.id. Jika customer.id dan sales.id memiliki tipe data berbeda, error ini terjadi.
Solusi: Jalankan ALTER TABLE tablename MODIFY COLUMN columnname newtype; untuk menyelaraskan tipe data. Untuk informasi lebih lanjut, lihat Ubah tipe data kolom.
Kesalahan eksekusi kueri: : Tidak dapat menggunakan join indeks untuk menyegarkan MV cepat ini.
Penyebab: Kolom join tidak memiliki indeks. Contoh: sales INNER JOIN customer ON customer.id=sales.id. Jika customer.id atau sales.id tidak memiliki indeks, error ini terjadi.
Solusi: Jalankan ALTER TABLE tablename ADD KEY idx_name(columnname); untuk menambahkan indeks pada kolom join. Untuk informasi lebih lanjut, lihat Buat indeks.
Kesalahan eksekusi kueri: Kueri melebihi batas memori yang dicadangkan
Penyebab: Kueri melebihi batas memori pada satu node.
Solusi: Pernyataan SQL yang intensif memori biasanya menggunakan operator Aggregation, TopN, Window, atau Join. Anda dapat menggunakan fitur SQL diagnostics untuk mengidentifikasi tahapan dan operator berkonsumsi memori tinggi. Kemudian, Anda dapat mengoptimalkan operator tersebut. Untuk informasi lebih lanjut, lihat Metrik memori dan Gunakan detail tahapan dan task untuk menganalisis kueri.
Referensi
Tampilan yang di-materialisasi: Pelajari konsep, skenario umum, dan pembaruan fitur.
CREATE MATERIALIZED VIEW: Pelajari detail sintaks.
Refresh tampilan yang di-materialisasi: Pelajari kebijakan refresh, pemicu, dan refresh manual.
Kelola tampilan yang di-materialisasi: Pelajari cara mengkueri definisi dan riwayat refresh, mencantumkan semua tampilan yang di-materialisasi, atau menghapus tampilan yang di-materialisasi.
Kueri data dari tampilan yang di-materialisasi: Pelajari cara mengkueri data dari tampilan yang di-materialisasi.