Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menyedot debu dan menganalisis tabel secara manual
Jika database Anda disedot oleh proses autovacuum, sebaiknya hindari menjalankan vakum manual di seluruh database terlalu sering. Vakum manual dapat mengakibatkan I/O beban yang tidak perlu atau lonjakan CPU, dan mungkin juga gagal menghilangkan tupel mati. Jalankan penyedot debu manual table-by-table hanya jika benar-benar diperlukan, seperti ketika rasio tupel hidup dan mati rendah, atau ketika ada celah panjang antara autovacuum. Selain itu, Anda harus menjalankan penyedot debu manual ketika ada aktivitas pengguna minimal.
Autovacuum juga membuat statistik tabel up to date. Ketika Anda menjalankan `ANALYZE` perintah secara manual, itu membangun kembali statistik ini alih-alih memperbaruinya. Membangun kembali statistik ketika mereka sudah diperbarui oleh proses autovacuum reguler dapat menyebabkan pemanfaatan sumber daya sistem.
Kami menyarankan Anda menjalankan perintah [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) dan [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) secara manual dalam skenario berikut:
+ Selama jam sibuk rendah di meja yang lebih sibuk, ketika autovacuuming mungkin tidak cukup.
+ Segera setelah Anda memuat data massal ke dalam tabel target. Dalam hal ini, menjalankan `ANALYZE` secara manual sepenuhnya membangun kembali statistik, yang merupakan pilihan yang lebih baik daripada menunggu autovacuum dimulai.
+ Untuk menyedot tabel sementara (autovacuum tidak dapat mengaksesnya).
Untuk mengurangi I/O dampak ketika Anda menjalankan `ANALYZE` perintah `VACUUM` dan pada aktivitas database bersamaan, Anda dapat menggunakan `vacuum_cost_delay` parameter. Dalam banyak situasi, perintah pemeliharaan seperti `VACUUM` dan `ANALYZE` tidak harus selesai dengan cepat. Namun, perintah ini seharusnya tidak mengganggu kemampuan sistem untuk melakukan operasi database lainnya. Untuk mencegah hal ini, Anda dapat mengaktifkan penundaan vakum berbasis biaya dengan menggunakan parameter. `vacuum_cost_delay` Parameter ini dinonaktifkan secara default untuk `VACUUM` perintah yang dikeluarkan secara manual. Untuk mengaktifkannya, atur ke nilai bukan nol.
## Menjalankan operasi vakum dan pembersihan secara paralel
Opsi `VACUUM` perintah [PARALLEL](https://www.postgresql.org/docs/current/sql-vacuum.html) menggunakan pekerja paralel untuk fase vakum indeks dan pembersihan indeks dan dinonaktifkan secara default. Jumlah pekerja paralel (tingkat paralelisme) ditentukan oleh jumlah indeks dalam tabel dan dapat ditentukan oleh pengguna. Jika Anda menjalankan `VACUUM` operasi paralel tanpa argumen integer, tingkat paralelisme dihitung berdasarkan jumlah indeks dalam tabel.
Parameter berikut membantu Anda mengonfigurasi penyedot debu paralel di Amazon RDS untuk PostgreSQL dan Aurora PostgreSQL yang kompatibel dengan Aurora:
+ [max\$1worker\$1processes](https://www.postgresql.org/docs/current/runtime-config-resource.html) menetapkan jumlah maksimum proses pekerja bersamaan.
+ [min\$1parallel\$1index\$1scan\$1size](https://www.postgresql.org/docs/current/runtime-config-query.html) menetapkan jumlah minimum data indeks yang harus dipindai agar pemindaian paralel dapat dipertimbangkan.
+ [max\$1parallel\$1maintenance\$1workers](https://www.postgresql.org/docs/current/runtime-config-resource.html) menetapkan jumlah maksimum pekerja paralel yang dapat dimulai dengan satu perintah utilitas.
**catatan**
`PARALLEL`Opsi ini hanya digunakan untuk tujuan menyedot debu. Itu tidak mempengaruhi `ANALYZE` perintah.
Contoh berikut menggambarkan perilaku database ketika Anda menggunakan manual `VACUUM` dan `ANALYZE` pada database.
Berikut adalah contoh tabel di mana autovacuum telah dinonaktifkan (hanya untuk tujuan ilustrasi; menonaktifkan autovacuum tidak disarankan):
```
create table t1 ( a int, b int, c int );
alter table t1 set (autovacuum_enabled=false);
```
```
apgl=> \d+ t1
Table "public.t1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+---------+-----------+----------+---------+---------+--------------+-------------
a | integer | | | | plain | |
b | integer | | | | plain | |
c | integer | | | | plain | |
Access method: heap
Options: autovacuum_enabled=false
```
Tambahkan 1 juta baris ke tabel t1:
```
apgl=> select count(*) from t1;
count
1000000
(1 row)
```
Statistik tabel t1:
```
select * from pg_stat_all_tables where relname='t1';
-[ RECORD 1 ]-------+--------
relid | 914744
schemaname | public
relname | t1
seq_scan | 0
seq_tup_read | 0
idx_scan |
idx_tup_fetch |
n_tup_ins | 1000000
n_tup_upd | 0
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 1000000
n_dead_tup | 0
n_mod_since_analyze | 1000000
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0
```
Tambahkan indeks:
```
create index i2 on t1 (b,a);
```
Jalankan `EXPLAIN` perintah (Paket 1):
```
Bitmap Heap Scan on t1 (cost=10521.17..14072.67 rows=5000 width=4)
Recheck Cond: (a = 5)
→ Bitmap Index Scan on i2 (cost=0.00..10519.92 rows=5000 width=0)
Index Cond: (a = 5)
(4 rows)
```
Jalankan `EXPLAIN ANALYZE` perintah (Rencana 2):
```
explain (analyze,buffers,costs off) select a from t1 where b = 5;
QUERY PLAN
Bitmap Heap Scan on t1 (actual time=0.023..0.024 rows=1 loops=1)
Recheck Cond: (b = 5)
Heap Blocks: exact=1
Buffers: shared hit=4
→ Bitmap Index Scan on i2 (actual time=0.016..0.016 rows=1 loops=1)
Index Cond: (b = 5)
Buffers: shared hit=3
Planning Time: 0.054 ms
Execution Time: 0.076 ms
(9 rows)
```
`EXPLAIN ANALYZE `Perintah `EXPLAIN ` dan menampilkan rencana yang berbeda, karena autovacuum dinonaktifkan di atas meja dan `ANALYZE` perintah tidak dilakukan secara manual. Sekarang mari kita perbarui nilai dalam tabel dan buat ulang `EXPLAIN ANALYZE` rencana:
```
update t1 set a=8 where b=5;
explain (analyze,buffers,costs off) select a from t1 where b = 5;
```
`EXPLAIN ANALYZE`Perintah (Paket 3) sekarang menampilkan:
```
apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5;
QUERY PLAN
Bitmap Heap Scan on t1 (actual time=0.075..0.076 rows=1 loops=1)
Recheck Cond: (b = 5)
Heap Blocks: exact=1
Buffers: shared hit=5
→ Bitmap Index Scan on i2 (actual time=0.017..0.017 rows=2 loops=1)
Index Cond: (b = 5)
Buffers: shared hit=3
Planning Time: 0.053 ms
Execution Time: 0.125 ms
```
Jika Anda membandingkan biaya antara Rencana 2 dan Rencana 3 Anda akan melihat perbedaan dalam perencanaan dan waktu pelaksanaan, karena kami belum mengumpulkan statistik.
Sekarang mari kita jalankan manual `ANALYZE` di atas meja, lalu periksa statistik dan buat ulang rencananya:
```
apgl=> analyze t1
apgl→ ;
ANALYZE
Time: 212.223 ms
apgl=> select * from pg_stat_all_tables where relname='t1';
-[ RECORD 1 ]-------+------------------------------
relid | 914744
schemaname | public
relname | t1
seq_scan | 3
seq_tup_read | 1000000
idx_scan | 3
idx_tup_fetch | 3
n_tup_ins | 1000000
n_tup_upd | 1
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 1000000
n_dead_tup | 1
n_mod_since_analyze | 0
last_vacuum |
last_autovacuum |
last_analyze | 2023-04-15 11:39:02.075089+00
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 1
autoanalyze_count | 0
Time: 148.347 ms
```
Jalankan `EXPLAIN ANALYZE` perintah (Paket 4):
```
apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5;
QUERY PLAN
Index Only Scan using i2 on t1 (actual time=0.022..0.023 rows=1 loops=1)
Index Cond: (b = 5)
Heap Fetches: 1
Buffers: shared hit=4
Planning Time: 0.056 ms
Execution Time: 0.068 ms
(6 rows)
Time: 138.462 ms
```
Jika Anda membandingkan semua hasil rencana setelah Anda menganalisis tabel secara manual dan mengumpulkan statistik, Anda akan melihat bahwa Rencana 4 pengoptimal lebih baik daripada yang lain dan juga mengurangi waktu eksekusi kueri. Contoh ini menunjukkan betapa pentingnya menjalankan kegiatan pemeliharaan pada database.
## Menulis ulang seluruh tabel dengan VACUUM FULL
Menjalankan `VACUUM ` perintah dengan `FULL` parameter menulis ulang seluruh isi tabel ke dalam file disk baru tanpa ruang tambahan, dan mengembalikan ruang yang tidak terpakai ke sistem operasi. Operasi ini jauh lebih lambat dan membutuhkan `ACCESS EXCLUSIVE` kunci di setiap meja. Ini juga membutuhkan ruang disk ekstra, karena menulis salinan baru dari tabel dan tidak melepaskan salinan lama sampai operasi selesai.
`VACUUM FULL`dapat berguna dalam kasus-kasus berikut:****
+ Ketika Anda ingin merebut kembali sejumlah besar ruang dari tabel.
+ Saat Anda ingin merebut kembali ruang kembung di tabel kunci non-primer.
Kami menyarankan Anda menggunakan `VACUUM FULL` ketika Anda memiliki tabel kunci non-primer, jika database Anda dapat mentolerir downtime.
Karena `VACUUM FULL` membutuhkan lebih banyak penguncian daripada operasi lain, lebih mahal untuk dijalankan pada basis data penting. Untuk mengganti metode ini, Anda dapat menggunakan `pg_repack ` ekstensi, yang dijelaskan di [bagian selanjutnya](pg-repack.md). Opsi ini mirip dengan `VACUUM FULL` tetapi membutuhkan penguncian minimal dan didukung oleh Amazon RDS for PostgreSQL dan Aurora PostgreSQL yang kompatibel.