Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
#
Bagian ini mengeksplorasi alasan tambahan yang dapat mencegah penyedot debu membuat kemajuan. Masalah-masalah ini saat ini tidak dapat diidentifikasi secara langsung oleh fungsi. `postgres_get_av_diag()`
**Topics**
+ [Halaman tidak valid](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [Inkonsistensi indeks](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [Tingkat transaksi yang sangat tinggi](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Halaman tidak valid
Kesalahan halaman yang tidak valid terjadi ketika PostgreSQL mendeteksi ketidakcocokan dalam checksum halaman saat mengakses halaman tersebut. Isinya tidak dapat dibaca, mencegah autovacuum membekukan tupel. Ini secara efektif menghentikan proses pembersihan. Kesalahan berikut ditulis ke dalam log PostgreSQL:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Tentukan jenis objek**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
Dari pesan kesalahan, jalur `base/16403/186752608` memberikan informasi berikut:
+ “base” adalah nama direktori di bawah direktori data PostgreSQL.
+ “16403" adalah database OID, yang dapat Anda cari di katalog sistem. `pg_database`
+ “186752608" adalah`relfilenode`, yang dapat Anda gunakan untuk mencari skema dan nama objek dalam katalog sistem. `pg_class`
Dengan memeriksa output dari query berikut dalam database yang terkena dampak, Anda dapat menentukan jenis objek. Query berikut mengambil informasi objek untuk oid: 186752608. Ganti OID dengan yang relevan dengan kesalahan yang Anda temui.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Untuk informasi selengkapnya, lihat [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html)dokumentasi PostgreSQL untuk semua jenis objek yang didukung, yang dicatat oleh kolom di. `relkind` `pg_class`
**Bimbingan**
Solusi paling efektif untuk masalah ini bergantung pada konfigurasi instans Amazon RDS spesifik Anda dan jenis data yang dipengaruhi oleh halaman yang tidak konsisten.
**Jika jenis objek adalah indeks:**
Membangun kembali indeks direkomendasikan.
+ **Menggunakan `CONCURRENTLY` opsi** — Sebelum PostgreSQL versi 12, membangun kembali indeks memerlukan kunci tabel eksklusif, membatasi akses ke tabel. Dengan PostgreSQL versi 12, dan versi yang lebih baru, opsi `CONCURRENTLY` ini memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintah:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Meskipun `CONCURRENTLY` tidak terlalu mengganggu, itu bisa lebih lambat di meja yang sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan.
[Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL REINDEX.](https://www.postgresql.org/docs/current/sql-reindex.html)
+ **Menggunakan `INDEX_CLEANUP FALSE` opsi** — Jika indeksnya besar dan diperkirakan membutuhkan banyak waktu untuk menyelesaikannya, Anda dapat membuka blokir autovacuum dengan menjalankan manual sambil mengecualikan indeks. `VACUUM FREEZE` Fungsi ini tersedia di PostgreSQL versi 12 dan versi yang lebih baru.
Melewati indeks akan memungkinkan Anda untuk melewati proses vakum dari indeks yang tidak konsisten dan mengurangi masalah sampul. Namun, ini tidak akan menyelesaikan masalah halaman tidak valid yang mendasarinya. Untuk sepenuhnya mengatasi dan menyelesaikan masalah halaman yang tidak valid, Anda masih perlu membangun kembali indeks.
**Jika jenis objek adalah tampilan terwujud:**
Jika terjadi kesalahan halaman yang tidak valid pada tampilan yang terwujud, masuk ke database yang terkena dampak dan segarkan untuk menyelesaikan halaman yang tidak valid:
Segarkan tampilan terwujud:
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Jika penyegaran gagal, coba buat ulang:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Menyegarkan atau membuat ulang tampilan terwujud akan mengembalikannya tanpa memengaruhi data tabel yang mendasarinya.
**Untuk semua jenis objek lainnya:**
Untuk semua jenis objek lainnya, hubungi AWS dukungan.
## Inkonsistensi indeks
Indeks yang tidak konsisten secara logis dapat mencegah autovacuum membuat kemajuan. Kesalahan berikut atau kesalahan serupa dicatat selama fase vakum indeks atau ketika indeks diakses oleh pernyataan SQL.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Bimbingan**
Bangun kembali indeks atau lewati indeks menggunakan manual`INDEX_CLEANUP`. `VACUUM FREEZE` Untuk informasi tentang cara membangun kembali indeks, lihat [Jika jenis objek adalah indeks](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Menggunakan opsi CONCURRENT** - Sebelum PostgreSQL versi 12, membangun kembali indeks memerlukan kunci tabel eksklusif, membatasi akses ke tabel. Dengan PostgreSQL versi 12, dan versi yang lebih baru, opsi CONCURRENT memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintah:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Sementara CONCURRENT kurang mengganggu, itu bisa lebih lambat pada tabel sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan. Untuk informasi selengkapnya, lihat [REINDEX dalam dokumentasi](https://www.postgresql.org/docs/current/sql-reindex.html) *PostgreSQL*.
+ **Menggunakan opsi INDEX\$1CLEANUP FALSE** — Jika indeksnya besar dan diperkirakan membutuhkan banyak waktu untuk menyelesaikannya, Anda dapat membuka blokir autovacuum dengan menjalankan VACUUM FREEZE manual sambil mengecualikan indeks. Fungsi ini tersedia di PostgreSQL versi 12 dan versi yang lebih baru.
Melewati indeks akan memungkinkan Anda untuk melewati proses vakum dari indeks yang tidak konsisten dan mengurangi masalah sampul. Namun, ini tidak akan menyelesaikan masalah halaman tidak valid yang mendasarinya. Untuk sepenuhnya mengatasi dan menyelesaikan masalah halaman yang tidak valid, Anda masih perlu membangun kembali indeks.
## Tingkat transaksi yang sangat tinggi
Di PostgreSQL, tingkat transaksi yang tinggi dapat secara signifikan memengaruhi kinerja autovacuum, yang mengarah pada pembersihan tupel mati yang lebih lambat dan peningkatan risiko sampul ID transaksi. Anda dapat memantau tingkat transaksi dengan mengukur perbedaan `max(age(datfrozenxid))` antara dua periode waktu, biasanya per detik. Selain itu, Anda dapat menggunakan metrik penghitung berikut dari RDS Performance Insights untuk mengukur tingkat transaksi (jumlah xact\$1commit dan xact\$1rollback) yang merupakan jumlah total transaksi.
| Penghitung | Jenis | Unit | Metrik |
| --- | --- | --- | --- |
| xact\$1commit | Transaksi | Commit per detik | db.Transactions.xact\$1commit |
| xact\$1rollback | Transaksi | Pemulihan per detik | db.Transactions.xact\$1rollback |
Peningkatan yang cepat menunjukkan beban transaksi yang tinggi, yang dapat membanjiri autovacuum, menyebabkan kembung, perselisihan kunci, dan potensi masalah kinerja. Hal ini dapat berdampak negatif pada proses autovacuum dalam beberapa cara:
+ **Aktivitas Tabel:** Tabel spesifik yang disedot dapat mengalami volume transaksi yang tinggi, menyebabkan penundaan.
+ **Sistem Sumber Daya** Sistem secara keseluruhan mungkin kelebihan beban, sehingga sulit bagi autovacuum untuk mengakses sumber daya yang diperlukan agar berfungsi secara efisien.
Pertimbangkan strategi berikut untuk memungkinkan autovacuum beroperasi lebih efektif dan mengikuti tugasnya:
1. Kurangi tingkat transaksi jika memungkinkan. Pertimbangkan untuk mengelompokkan atau mengelompokkan transaksi serupa jika memungkinkan.
1. Targetkan tabel yang sering diperbarui dengan `VACUUM FREEZE` operasi manual setiap malam, mingguan, atau dua mingguan selama jam sibuk.
1. Pertimbangkan untuk meningkatkan kelas instans Anda untuk mengalokasikan lebih banyak sumber daya sistem untuk menangani volume transaksi dan autovacuum yang tinggi.