Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Tugas DBA umum untuk Amazon RDS for PostgreSQL
Administrator database (DBAs) melakukan berbagai tugas saat mengelola Amazon RDS for PostgreSQL DB instance. Jika Anda seorang DBA yang sudah terbiasa dengan PostgreSQL, Anda perlu menyadari beberapa perbedaan penting antara menjalankan PostgreSQL di perangkat keras Anda dan RDS for PostgreSQL. Misalnya, karena ini adalah layanan terkelola, Amazon RDS tidak mengizinkan akses shell ke instans DB Anda. Ini berarti Anda tidak memiliki akses langsung ke file `pg_hba.conf` dan file konfigurasi lainnya. Untuk RDS for PostgreSQL, perubahan yang biasanya dilakukan pada file konfigurasi PostgreSQL dari instans on-premise dibuat ke grup parameter DB kustom yang terkait dengan instans DB RDS for PostgreSQL. Untuk informasi selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Anda juga tidak dapat mengakses file log dengan cara yang sama seperti yang Anda lakukan dengan instans PostgreSQL on-premise. Untuk mempelajari pencatatan selengkapnya, lihat [](USER_LogAccess.Concepts.PostgreSQL.md).
Sebagai contoh lain, Anda tidak memiliki akses ke akun PostgreSQL `superuser`. Di RDS for PostgreSQL, peran `rds_superuser` merupakan peran yang paling istimewa, dan diberikan ke `postgres` pada saat penyiapan. Meskipun Anda telah terbiasa menggunakan PostgreSQL on-premise atau baru menggunakan RDS for PostgreSQL, sebaiknya Anda memahami peran `rds_superuser`, serta cara bekerja dengan peran, pengguna, grup, dan izin. Untuk informasi selengkapnya, lihat [Memahami peran dan izin PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Berikut ini adalah beberapa tugas DBA umum untuk RDS for PostgreSQL.
**Topics**
+ [
# Koleksi didukung di Aurora
](PostgreSQL-Collations.md)
+ [
# Memahami peran dan izin PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [
# Penanganan koneksi mati di PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [
# Mengelola jumlah objek tinggi di Amazon RDS untuk PostgreSQL Amazon Aurora
](PostgreSQL.HighObjectCount.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [
## Bekerja dengan mekanisme pencatatan log yang didukung oleh RDS for PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [
# Mengelola file sementara dengan PostgreSQL
](PostgreSQL.ManagingTempFiles.md)
+ [
## Menggunakan pgBadger untuk analisis log dengan PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [
## Menggunakan PGSnapper untuk memantau PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [
#
](PostgreSQL.CustomCasts.md)
+ [
# Praktik Terbaik untuk Kueri Paralel di PostgreSQL RDS untuk PostgreSQL
](PostgreSQL.ParallelQueries.md)
+ [
# Bekerja dengan parameter pada instans DB RDS for PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Koleksi didukung di Aurora
Kolasi adalah serangkaian aturan yang menentukan cara pengurutan dan perbandingan string karakter yang disimpan di basis data. Kolasi memiliki peran mendasar dalam sistem komputer dan dimasukkan sebagai bagian dari sistem operasi. Kolasi berubah dari waktu ke waktu ketika karakter baru ditambahkan ke bahasa atau ketika aturan urutan berubah.
Pustaka kolasi menentukan aturan dan algoritma khusus untuk kolasi. Pustaka kolasi paling populer yang digunakan dalam PostgreSQL adalah GNU C (glibc) dan komponen Internasionalisasi untuk Unicode (ICU). Secara default, RDS for PostgreSQL menggunakan kolasi glibc yang mencakup urutan karakter unicode untuk urutan karakter multi-byte.
Saat Anda membuat instans DB di RDS for PostgreSQL baru, ini akan memeriksa sistem operasi untuk kolasi yang tersedia. Parameter PostgreSQL dari perintah `CREATE DATABASE`, `LC_COLLATE`, dan `LC_CTYPE` digunakan untuk menentukan kolasi, yang merupakan kolasi default dalam basis data tersebut. Atau, Anda juga dapat menggunakan parameter `LOCALE` di `CREATE DATABASE` untuk menetapkan parameter ini. Parameter ini menentukan kolasi default untuk string karakter dalam basis data dan aturan untuk mengklasifikasikan karakter sebagai huruf, angka, atau simbol. Anda juga dapat memilih kolasi untuk digunakan pada kolom, indeks, atau kueri.
RDS for PostgreSQL bergantung pada pustaka glibc di sistem operasi untuk dukungan kolasi. Instans RDS for PostgreSQL diperbarui secara berkala dengan versi terbaru sistem operasi. Pembaruan ini terkadang menyertakan versi pustaka glibc yang lebih baru. Jarang sekali versi glibc yang lebih baru mengubah tata urutan atau kolasi beberapa karakter, yang dapat menyebabkan data diurutkan secara berbeda atau menghasilkan entri indeks yang tidak valid. Jika terjadi masalah terkait tata urutan kolasi selama pembaruan, Anda mungkin perlu membuat ulang indeks.
Untuk memperkecil potensi dampak pembaruan glibc, RDS for PostgreSQL kini menyertakan pustaka kolasi default independen. Pustaka kolasi ini tersedia di RDS for PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23, dan rilis versi minor yang lebih baru. Pustaka ini kompatibel dengan glibc 2.26-59.amzn2, dan menyediakan stabilitas tata urutan untuk mencegah kesalahan hasil kueri.
# Memahami peran dan izin PostgreSQL
Bila Anda membuat menggunakan, akun administrator dibuat pada saat yang sama. Konsol Manajemen AWS Secara default, akun tersebut akan dinamakan `postgres`, seperti yang ditunjukkan pada gambar berikut:
![\[Identitas login default untuk Kredensial di halaman Buat basis data adalah postgres.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Anda dapat memilih nama lain daripada menerima nama default (`postgres`). Jika ya, nama yang Anda pilih harus dimulai dengan huruf dan terdiri atas 1 hingga 16 karakter alfanumerik. Untuk menyederhanakan, kami merujuk ke akun pengguna utama ini dengan nilai default-nya (`postgres`) di seluruh panduan ini.
Jika Anda menggunakan `create-db-instance` AWS CLI bukan Konsol Manajemen AWS, Anda membuat nama dengan meneruskannya dengan `master-username` parameter dalam perintah. Untuk informasi selengkapnya, lihat [Membuat instans DB Amazon RDS](USER_CreateDBInstance.md).
Baik Anda menggunakan Konsol Manajemen AWS, API AWS CLI, atau Amazon RDS, dan apakah Anda menggunakan `postgres` nama default atau memilih nama yang berbeda, akun pengguna database pertama ini adalah anggota `rds_superuser` grup dan memiliki `rds_superuser` hak istimewa.
**Topics**
+ [
# Memahami peran rds\$1superuser
](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [
# Mengontrol akses pengguna ke basis data PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [
# Menyerahkan dan mengendalikan manajemen kata sandi pengguna
](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [
# Menggunakan SCRAM untuk enkripsi kata sandi PostgreSQL
](PostgreSQL_Password_Encryption_configuration.md)
# Memahami peran rds\$1superuser
Dalam PostgreSQL, *peran* dapat menentukan pengguna, grup, atau sekumpulan izin tertentu yang diberikan kepada grup atau pengguna untuk berbagai objek dalam basis data. Perintah PostgreSQL untuk `CREATE USER` dan `CREATE GROUP` telah digantikan oleh `CREATE ROLE` yang lebih umum dengan properti khusus untuk membedakan pengguna basis data. Pengguna basis data dapat dianggap sebagai peran dengan hak akses LOGIN.
**catatan**
Perintah `CREATE USER` dan `CREATE GROUP` masih dapat digunakan. Untuk informasi selengkapnya, lihat [Database Roles](https://www.postgresql.org/docs/current/user-manag.html) dalam dokumentasi PostgreSQL.
Pengguna `postgres` adalah pengguna basis data dengan hak akses tertinggi di instans DB RDS for PostgreSQL. Pengguna tersebut memiliki karakteristik yang ditentukan oleh pernyataan `CREATE ROLE` berikut.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Properti`NOSUPERUSER`, `NOREPLICATION`, `INHERIT`, dan `VALID UNTIL 'infinity'` merupakan opsi default untuk CREATE ROLE, kecuali ditentukan lain.
Secara default, `postgres` memiliki hak akses yang diberikan kepada peran `rds_superuser`, serta izin untuk membuat peran dan basis data. Peran `rds_superuser` mengizinkan pengguna `postgres` untuk melakukan tindakan berikut:
+ Menambahkan ekstensi yang tersedia untuk digunakan dengan Amazon RDS. Untuk informasi selengkapnya, lihat [Menggunakan fitur PostgreSQL yang didukung oleh Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Buat peran dan berikan hak akses kepada pengguna. Untuk informasi selengkapnya, lihat [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) dan [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) dalam dokumentasi PostgreSQL.
+ Membuat basis data. Untuk informasi selengkapnya, lihat [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) dalam dokumentasi PostgreSQL.
+ Berikan hak akses `rds_superuser` untuk peran pengguna yang tidak memiliki hak akses ini, dan cabut hak akses sesuai kebutuhan. Sebaiknya berikan peran ini hanya untuk pengguna yang menjalankan tugas superuser. Dengan kata lain, Anda dapat memberikan peran ini kepada administrator database (DBAs) atau administrator sistem.
+ Berikan (dan cabut) peran `rds_replication` kepada pengguna basis data yang tidak memiliki peran `rds_superuser`.
+ Berikan (dan cabut) peran `rds_password` kepada pengguna basis data yang tidak memiliki peran `rds_superuser`.
+ Dapatkan informasi status tentang semua koneksi basis data dengan menggunakan tampilan `pg_stat_activity`. Bila diperlukan, `rds_superuser` dapat menghentikan semua koneksi menggunakan `pg_terminate_backend` atau `pg_cancel_backend`.
Dalam pernyataan `CREATE ROLE postgres...`, Anda dapat melihat bahwa peran pengguna `postgres` secara khusus melarang izin `superuser` PostgreSQL. RDS for PostgreSQL adalah layanan terkelola, jadi Anda tidak dapat mengakses OS host, dan terhubung menggunakan akun `superuser` PostgreSQL. Banyak tugas yang memerlukan akses `superuser` pada PostgreSQL mandiri dikelola secara otomatis oleh Amazon RDS.
Untuk informasi selengkapnya tentang pemberian hak akses, lihat [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) dalam dokumentasi PostgreSQL.
Peran `rds_superuser` adalah satu dari beberapa peran yang *telah ditentukan* dalam . instans DB RDS for PostgreSQL.
**catatan**
Dalam PostgreSQL 13 dan rilis sebelumnya, peran yang *telah ditentukan* dikenal sebagai peran *default*.
Dalam daftar berikut, Anda akan menemukan beberapa peran standar lainnya yang dibuat secara otomatis untuk yang baru. instans DB RDS for PostgreSQL. Peran yang telah ditentukan dan hak aksesnya tidak dapat diubah. Anda tidak dapat menghapus, mengganti nama, atau memodifikasi hak akses untuk peran yang telah ditentukan ini. Mencoba untuk melakukannya akan mengakibatkan kesalahan.
+ **rds\$1password** — Peran yang dapat mengubah kata sandi dan mengatur batasan kata sandi untuk pengguna basis data. `rds_superuser`Peran diberikan dengan peran ini secara default, dan dapat memberikan peran tersebut kepada pengguna database. Untuk informasi selengkapnya, lihat [Mengontrol akses pengguna ke basis data PostgreSQLMengontrol akses pengguna ke PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ Untuk RDS untuk PostgreSQL versi yang lebih tua dari 14`rds_password`, peran dapat mengubah kata sandi dan mengatur batasan kata sandi untuk pengguna database dan pengguna dengan peran. `rds_superuser` Dari RDS untuk PostgreSQL versi 14 dan yang lebih baru`rds_password`, peran dapat mengubah kata sandi dan mengatur batasan kata sandi hanya untuk pengguna database. Hanya pengguna dengan `rds_superuser` peran yang dapat melakukan tindakan ini pada pengguna lain yang memiliki `rds_superuser` peran.
+ **rdsadmin** — Peran yang dibuat untuk menangani banyak tugas manajemen yang dilakukan oleh administrator dengan hak akses `superuser` pada basis data PostgreSQL mandiri. Peran ini digunakan secara internal oleh RDS for PostgreSQL untuk banyak tugas manajemen.
+ **rdstopmgr** - Peran yang digunakan secara internal oleh Amazon RDS untuk mendukung deployment multi-AZ.
+ **rds\$1reserved** — Peran yang digunakan secara internal oleh Amazon RDS untuk mencadangkan koneksi database.
# Melihat peran dan hak istimewa mereka
Anda dapat melihat peran yang telah ditentukan dan hak istimewanya di RDS untuk instans PostgreSQL DB menggunakan perintah yang berbeda tergantung pada versi PostgreSQL Anda. Untuk melihat semua peran yang telah ditentukan, Anda dapat terhubung ke RDS untuk instans PostgreSQL DB dan menjalankan perintah berikut menggunakan. `psql`
**Untuk `psql` 15 dan versi sebelumnya**
Connect ke RDS Anda untuk PostgreSQL DB instance dan gunakan perintah di psql: `\du`
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Untuk `psql` 16 dan versi yang lebih baru**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Untuk memeriksa keanggotaan peran tanpa ketergantungan versi, Anda dapat menggunakan kueri SQL berikut:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
Dalam output, Anda dapat melihat bahwa `rds_superuser` itu bukan peran pengguna basis data (tidak dapat masuk), tetapi memiliki hak akses dari banyak peran lainnya. Anda juga dapat melihat bahwa pengguna basis data `postgres` adalah anggota peran `rds_superuser`. Seperti disebutkan sebelumnya, `postgres` adalah nilai default di halaman **Buat basis data** konsol Amazon RDS. Jika Anda memilih nama lain, nama itu akan ditampilkan dalam daftar peran.
# Mengontrol akses pengguna ke basis data PostgreSQL
Basis data baru di PostgreSQL selalu dibuat dengan serangkaian hak akses default dalam skema `public` basis data yang memungkinkan semua pengguna dan peran basis data untuk membuat objek. Hak akses ini memungkinkan pengguna basis data untuk terhubung ke basis data, misalnya, dan membuat tabel sementara saat terhubung.
Agar dapat mengontrol dengan lebih baik akses pengguna ke instans basis data yang Anda buat di instans DB RDS for PostgreSQL, sebaiknya Anda mencabut hak akses `public` default. Setelah melakukannya, Anda kemudian memberikan hak akses khusus untuk pengguna basis data secara lebih rinci, seperti yang diperlihatkan dalam prosedur berikut ini.
**Untuk menyiapkan peran dan hak akses untuk instans basis data baru**
Misalnya, Anda sedang menyiapkan basis data pada instans DB RDS for PostgreSQL yang baru dibuat untuk digunakan oleh beberapa peneliti, yang semuanya membutuhkan akses baca-tulis ke basis data.
1. Gunakan `psql` (atau pgAdmin) untuk menghubungkan ke instans DB RDS for PostgreSQL Anda:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Saat diminta, masukkan kata sandi Anda. Klien `psql` menghubungkan dan menampilkan basis data koneksi administratif default, `postgres=>`, sebagai perintah.
1. Untuk mencegah pengguna basis data membuat objek dalam skema `public`, lakukan tindakan berikut:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Selanjutnya, buat instans basis data baru:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Cabut semua hak akses dari skema `PUBLIC` pada basis data baru ini.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Buat peran untuk pengguna basis data.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Berikan pengguna basis data yang memiliki peran ini kemampuan untuk terhubung ke basis data.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Berikan semua hak akses pada basis data ini kepada semua pengguna dengan peran `lab_tech`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Buat pengguna basis data, sebagai berikut:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Beri hak akses terkait peran lab\$1tech kepada dua pengguna ini:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
Pada titik ini, `lab_user1` dan `lab_user2` dapat terhubung ke basis data `lab_db`. Contoh ini tidak mengikuti praktik terbaik untuk penggunaan perusahaan, yang mungkin termasuk membuat beberapa instans basis data, skema yang berbeda, dan pemberian izin terbatas. Untuk informasi yang lebih lengkap dan skenario tambahan lainnya, lihat [Mengelola Pengguna dan Peran PostgreSQL](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Untuk informasi selengkapnya tentang hak akses di PostgreSQL, lihat perintah [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) dalam dokumentasi PostgreSQL.
# Menyerahkan dan mengendalikan manajemen kata sandi pengguna
Sebagai DBA, Anda mungkin perlu menyerahkan manajemen kata sandi pengguna. Atau, Anda juga dapat mencegah pengguna basis data mengubah kata sandi mereka atau mengonfigurasi ulang batasan kata sandi, seperti masa pakai kata sandi. Untuk memastikan bahwa hanya pengguna basis data yang Anda pilih yang dapat mengubah pengaturan kata sandi, Anda dapat mengaktifkan fitur manajemen kata sandi terbatas. Bila mengaktifkan fitur ini, hanya pengguna basis data yang telah diberikan peran `rds_password` yang dapat mengelola kata sandi.
**catatan**
Untuk menggunakan manajemen kata sandi terbatas, instans DB RDS for PostgreSQL harus menjalankan PostgreSQL 10.6 atau versi lebih tinggi.
Secara default, fitur ini dalam keadaan `off`, seperti yang ditunjukkan berikut:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Untuk mengaktifkan fitur ini, Anda harus menggunakan grup parameter kustom dan mengubah pengaturan `rds.restrict_password_commands` ke 1. Pastikan untuk melakukan booting ulang instans DB RDS for PostgreSQL agar pengaturan dapat berlaku.
Dalam keadaan fitur ini aktif, hak akses `rds_password` diperlukan untuk perintah SQL berikut:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Mengganti nama role (`ALTER ROLE myrole RENAME TO newname`) juga dibatasi jika password menggunakan algoritma MD5 hashing.
Jika fitur ini dalam keadaan aktif, mencoba salah satu perintah SQL ini tanpa izin peran `rds_password` akan menghasilkan kesalahan berikut:
```
ERROR: must be a member of rds_password to alter passwords
```
Sebaiknya Anda memberikan `rds_password` hanya untuk beberapa peran yang Anda gunakan semata untuk manajemen kata sandi. Jika memberikan hak akses `rds_password` kepada pengguna basis data yang tidak memiliki hak akses `rds_superuser`, Anda juga harus memberi mereka atribut `CREATEROLE`.
Pastikan Anda memverifikasi persyaratan kata sandi seperti kedaluwarsa dan kompleksitas yang diperlukan di sisi klien. Jika Anda menggunakan utilitas sisi klien Anda sendiri untuk perubahan terkait kata sandi, utilitas tersebut harus menjadi anggota `rds_password` dan memiliki hak akses `CREATE ROLE`.
# Menggunakan SCRAM untuk enkripsi kata sandi PostgreSQL
The *Salted Challenge Response Authentication Mechanism (SCRAM)* adalah alternatif dari algoritma message digest (MD5) default PostgreSQL untuk mengenkripsi kata sandi. Mekanisme otentikasi SCRAM dianggap lebih aman daripada. MD5 Untuk mempelajari selengkapnya tentang dua pendekatan berbeda untuk mengamankan kata sandi ini, lihat [Password Authentication](https://www.postgresql.org/docs/14/auth-password.html) dalam dokumentasi PostgreSQL.
Kami menyarankan Anda menggunakan SCRAM daripada MD5 sebagai skema enkripsi kata sandi untuk cluster DB Anda. Instans DB RDS for PostgreSQL. Ini adalah mekanisme respons tantangan kriptografi yang menggunakan algoritma scram-sha-256 untuk autentikasi dan enkripsi kata sandi.
Anda mungkin perlu memperbarui pustaka untuk aplikasi klien Anda agar dapat mendukung SCRAM. Misalnya, versi JDBC sebelum 42.2.0 tidak mendukung SCRAM. Untuk informasi selengkapnya, lihat [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) dalam dokumentasi Driver JDBC PostgreSQL. Untuk daftar driver PostgreSQL dan dukungan SCRAM lainnya, lihat [List of drivers](https://wiki.postgresql.org/wiki/List_of_drivers) dalam dokumentasi PostgreSQL.
RDS for PostgreSQL versi 13.1 dan lebih tinggi mendukung scram-sha-256. Versi ini juga memungkinkan Anda mengonfigurasi instans DB agar mengharuskan SCRAM, seperti yang dibahas dalam prosedur berikut.
## Menyiapkan untuk memerlukan SCRAM
Anda dapat meminta instans DB RDS for PostgreSQL untuk hanya menerima kata sandi yang menggunakan algoritma scram-sha-256.
**penting**
Untuk Proksi RDS yang ada dengan basis data PostgreSQL, jika Anda mengubah autentikasi basis data untuk hanya menggunakan `SCRAM`, proksi akan menjadi tidak tersedia selama maksimal 60 detik. Untuk menghindari masalah ini, lakukan salah satu tindakan berikut:
Pastikan basis data mengizinkan autentikasi `SCRAM` dan `MD5`.
Untuk hanya menggunakan autentikasi `SCRAM`, buat proksi baru, migrasikan lalu lintas aplikasi Anda ke proksi baru, lalu hapus proksi yang sebelumnya terkait dengan basis data.
Sebelum melakukan perubahan pada sistem, pastikan Anda telah memahami proses lengkapnya, sebagai berikut:
+ Dapatkan informasi semua peran dan enkripsi kata sandi untuk semua pengguna basis data.
+ Periksa kembali pengaturan parameter instans DB RDS for PostgreSQL untuk parameter yang mengontrol enkripsi kata sandi.
+ Jika instans DB RDS for PostgreSQL menggunakan grup parameter default, maka Anda harus membuat grup parameter DB kustom, lalu menerapkannya ke instans DB RDS for PostgreSQL agar Anda dapat memodifikasi parameter saat diperlukan. Jika instans DB RDS for PostgreSQL menggunakan grup parameter kustom, Anda dapat memodifikasi parameter yang diperlukan nanti selama prosesnya sesuai kebutuhan.
+ Ubah parameter `password_encryption` ke `scram-sha-256`.
+ Beri tahu semua pengguna basis data bahwa mereka perlu memperbarui kata sandi. Lakukan hal yang sama untuk akun `postgres` Anda. Kata sandi baru telah dienkripsi dan disimpan menggunakan algoritma scram-sha-256.
+ Verifikasikan bahwa semua kata sandi telah dienkripsi menggunakan jenis enkripsi tersebut.
+ Jika semua kata sandi menggunakan scram-sha-256, Anda dapat mengubah parameter `rds.accepted_password_auth_method` dari `md5+scram` ke `scram-sha-256`.
**Awas**
Setelah Anda mengubah `rds.accepted_password_auth_method` ke scram-sha-256 saja, setiap pengguna (peran) dengan kata sandi terenkripsi `md5` tidak dapat terhubung.
### Bersiap-siap untuk meminta SCRAM untuk
Sebelum membuat perubahan apa pun pada instans DB RDS for PostgreSQL, periksa semua akun pengguna basis data yang ada. Periksa juga jenis enkripsi yang digunakan untuk kata sandi. Anda dapat melakukan semua tugas ini menggunakan ekstensi `rds_tools`. Untuk melihat versi PostgreSQL yang `rds_tools` didukung, [lihat Versi ekstensi untuk Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) for PostgreSQL.
**Untuk mendapatkan daftar pengguna (peran) basis data dan metode enkripsi kata sandi**
1. Gunakan `psql` untuk terhubung ke instans DB RDS for PostgreSQL Anda, sebagaimana yang ditunjukkan di bawah ini.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Instal ekstensi `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Dapatkan daftar peran dan enkripsi.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Anda akan melihat output yang mirip dengan berikut ini.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Membuat grup parameter DB kustom
**catatan**
Jika instans DB RDS for PostgreSQL sudah menggunakan grup parameter kustom, Anda tidak perlu membuat grup parameter yang baru.
Untuk ringkasan grup parameter Amazon RDS, lihat [Bekerja dengan parameter pada instans DB RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Jenis enkripsi kata sandi yang digunakan untuk kata sandi yang diatur dalam satu parameter, `password_encryption`. Enkripsi yang diizinkan oleh instans DB RDS for PostgreSQL diatur dalam parameter lain, `rds.accepted_password_auth_method`. Mengubah salah satu dari nilai default ini mengharuskan Anda membuat grup parameter DB kustom, lalu menerapkannya ke instans.
Anda juga dapat menggunakan Konsol Manajemen AWS atau RDS API untuk membuat DB. Untuk informasi lebih lanjut, lihat
Anda kini dapat mengaitkan grup parameter kustom dengan instans DB.
**Untuk membuat parameter DB**
1. Gunakan perintah CLI `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` untuk membuat grup parameter DB kustom. Contoh ini menggunakan `postgres13` sebagai sumber untuk grup parameter kustom ini.
Untuk Linux, macOS, atau Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Untuk Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Gunakan perintah CLI `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` untuk menerapkan grup parameter kustom ini ke klaster DB RDS for PostgreSQL.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Untuk Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Untuk menyinkronkan ulang instans DB RDS for PostgreSQL dengan grup parameter DB kustom, Anda perlu melakukan boot ulang instans primer dan semua instans lain klaster. Untuk meminimalkan dampak pada pengguna Anda, jadwalkan proses ini agar berlangsung selama masa pemeliharaan rutin.
### Mengonfigurasi enkripsi kata sandi agar menggunakan SCRAM
Mekanisme enkripsi kata sandi yang digunakan oleh instans DB RDS for PostgreSQL diatur dalam grup parameter DB dalam parameter `password_encryption`. Nilai yang diizinkan tidak ditentukan, `md5`, atau `scram-sha-256`. Nilai default bergantung pada versi RDS for PostgreSQL, sebagai berikut:
+ RDS for PostgreSQL 14 dan versi di atasnya – Default adalah `scram-sha-256`
+ RDS for PostgreSQL 13 – Default adalah `md5`
Dengan grup parameter DB kustom yang terhubung ke instans DB RDS for PostgreSQL, Anda dapat memodifikasi nilai untuk parameter enkripsi kata sandi.
![\[Berikutnya, konsol RDS akan menunjukkan nilai default parameter password_encryption untuk RDS for PostgreSQL.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Untuk mengubah pengaturan enkripsi kata sandi menjadi scram-sha-256**
+ Ubah nilai enkripsi kata sandi menjadi scram-sha-256, sebagaimana ditunjukkan berikut ini. Perubahan dapat langsung diterapkan karena parameternya dinamis, jadi mulai ulang tidak diperlukan agar perubahan diterapkan.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Untuk Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Memigrasikan kata sandi untuk peran pengguna ke SCRAM
Anda dapat memigrasikan kata sandi untuk peran pengguna ke SCRAM sebagaimana dijelaskan berikut.
**Untuk memigrasikan kata sandi pengguna (peran) basis data dari MD5 ke SCRAM**
1. Masuk sebagai pengguna administrator (nama pengguna default, `postgres`) sebagaimana ditunjukkan berikut.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Periksa pengaturan parameter `password_encryption` pada instans DB RDS for PostgreSQL menggunakan perintah berikut.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Ubah nilai parameter ini menjadi scram-sha-256. Untuk informasi selengkapnya, lihat [Mengonfigurasi enkripsi kata sandi agar menggunakan SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Periksa kembali nilainya untuk memastikan bahwa sekarang diatur ke`scram-sha-256`, sebagai berikut.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Beri tahu semua pengguna basis data untuk mengubah kata sandi mereka. Pastikan juga untuk mengubah kata sandi Anda sendiri untuk akun `postgres` (pengguna basis data dengan hak akses `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Ulangi proses tersebut untuk semua basis data di Anda. instans DB RDS for PostgreSQL.
### Mengubah parameter untuk mengharuskan SCRAM
Ini adalah langkah terakhir dalam proses. Setelah Anda membuat perubahan dalam prosedur berikut, setiap akun pengguna (peran) yang masih menggunakan enkripsi `md5` untuk kata sandi tidak dapat masuk ke . instans DB RDS for PostgreSQL.
`rds.accepted_password_auth_method` menentukan metode enkripsi yang instans DB RDS for PostgreSQL menerima untuk kata sandi pengguna selama proses masuk. Nilai default-nya adalah `md5+scram`, yang berarti bahwa salah satu metode diterima. Pada gambar berikut, Anda dapat menemukan pengaturan default untuk parameter ini.
![\[Konsol RDS menunjukkan nilai default dan yang diizinkan untuk parameter rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Nilai yang diizinkan untuk parameter ini adalah `md5+scram` atau `scram` saja. Mengubah nilai parameter ini ke `scram` akan menjadikannya sebagai persyaratan.
**Untuk mengubah nilai parameter agar mengharuskan autentikasi SCRAM untuk kata sandi**
1. Verifikasikan bahwa semua kata sandi pengguna basis data untuk semua basis data di instans DB RDS for PostgreSQL menggunakan `scram-sha-256` untuk enkripsi kata sandi. Untuk melakukannya, buat kueri `rds_tools` untuk peran (pengguna) dan jenis enkripsi, sebagai berikut.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Ulangi kueri di semua instans DB dalam Anda. Instans DB RDS for PostgreSQL.
Jika semua kata sandi menggunakan scram-sha-256, Anda dapat melanjutkan.
1. Ubah nilai autentikasi kata sandi yang diterima menjadi scram-sha-256, sebagai berikut.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Untuk Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Penanganan koneksi mati di PostgreSQL
Koneksi mati terjadi ketika sesi database tetap aktif di server meskipun aplikasi klien telah ditinggalkan atau dihentikan secara tidak normal. Situasi ini biasanya muncul ketika proses klien macet atau berhenti secara tak terduga tanpa menutup koneksi database mereka dengan benar atau membatalkan permintaan yang sedang berlangsung.
PostgreSQL secara efisien mengidentifikasi dan membersihkan koneksi mati saat proses server menganggur atau mencoba mengirim data ke klien. Namun, deteksi menantang untuk sesi yang menganggur, menunggu masukan klien, atau menjalankan kueri secara aktif. Untuk menangani skenario ini, PostgreSQL `tcp_keepalives_*` menyediakan,, dan parameter. `tcp_user_timeout` `client_connection_check_interval`
**Topics**
+ [
## Memahami TCP keepalive
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [
##
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [
## Kasus penggunaan untuk pengaturan TCP keepalive
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [
## Praktik terbaik
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Memahami TCP keepalive
TCP Keepalive adalah mekanisme tingkat protokol yang membantu menjaga dan memverifikasi integritas koneksi. Setiap koneksi TCP mempertahankan pengaturan tingkat kernel yang mengatur perilaku keepalive. Ketika timer keepalive kedaluwarsa, sistem melakukan hal berikut:
+ Mengirim paket probe tanpa data dan set flag ACK.
+ Mengharapkan respons dari titik akhir jarak jauh sesuai dengan spesifikasi. TCP/IP
+ Mengelola status koneksi berdasarkan respons atau kekurangannya.
##
| Parameter | Deskripsi | Nilai default |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Menentukan jumlah detik tidak aktif sebelum mengirim pesan keepalive. | 300 |
| tcp\$1keepalives\$1interval | Menentukan jumlah detik antara transmisi ulang pesan keepalive yang tidak diakui. | 30 |
| tcp\$1keepalives\$1count | Pesan keepalive maksimum yang hilang sebelum menyatakan koneksi mati | 2 |
| tcp\$1user\$1timeout | Menentukan berapa lama (dalam Millidetik) data yang tidak diakui dapat tetap sebelum menutup sambungan secara paksa. | 0 |
| client\$1connection\$1check\$1interval | Mengatur interval (dalam Millidetik) untuk memeriksa status koneksi klien selama kueri yang berjalan lama. Ini memastikan deteksi koneksi tertutup yang lebih cepat. | 0 |
## Kasus penggunaan untuk pengaturan TCP keepalive
### Menjaga sesi idle tetap hidup
Untuk mencegah koneksi idle dihentikan oleh firewall atau router karena tidak aktif:
+ Konfigurasikan `tcp_keepalives_idle` untuk mengirim paket keepalive secara berkala.
### Mendeteksi koneksi mati
Untuk mendeteksi koneksi mati dengan segera:
+ Sesuaikan`tcp_keepalives_idle`,`tcp_keepalives_interval`, dan`tcp_keepalives_count`. Misalnya, dengan default Aurora PostgreSQL, dibutuhkan sekitar satu menit (2 probe × 30 detik) untuk mendeteksi koneksi mati. Menurunkan nilai-nilai ini dapat mempercepat deteksi.
+ Gunakan `tcp_user_timeout` untuk menentukan waktu tunggu maksimum untuk pengakuan.
Pengaturan TCP keepalive membantu kernel mendeteksi koneksi mati, tetapi PostgreSQL mungkin tidak bertindak sampai soket digunakan. Jika sesi menjalankan kueri panjang, koneksi mati mungkin hanya terdeteksi setelah kueri selesai. Di PostgreSQL 14 dan versi yang lebih tinggi`client_connection_check_interval`, dapat mempercepat deteksi koneksi mati dengan melakukan polling soket secara berkala selama eksekusi kueri.
## Praktik terbaik
+ **Tetapkan interval keepalive yang wajar:** Tune`tcp_user_timeout`,`tcp_keepalives_idle`, `tcp_keepalives_count` dan `tcp_keepalives_interval` untuk menyeimbangkan kecepatan deteksi dan penggunaan sumber daya.
+ **Optimalkan untuk lingkungan Anda:** Sejajarkan pengaturan dengan perilaku jaringan, kebijakan firewall, dan kebutuhan sesi.
+ **Memanfaatkan fitur PostgreSQL: Gunakan `client_connection_check_interval` di PostgreSQL** 14 dan versi yang lebih tinggi untuk pemeriksaan koneksi yang efisien.
#
Kami sangat menyarankan Anda menggunakan fitur autovacuum untuk menjaga kondisi instans DB PostgreSQL Anda. Autovacuum akan mengotomatiskan awal perintah VACUUM dan ANALYZE. Kemudian memeriksa tabel yang memuat banyak tuple yang dimasukkan, diperbarui, atau dihapus. Setelah pemeriksaan ini, autovacuum akan mengambil kembali penyimpanan dengan menghapus data usang atau tuple dari basis data PostgreSQL.
Secara default, autovacuum diaktifkan untuk RDS untuk PostgreSQL PostgreSQL DB instance yang Anda buat menggunakan salah satu grup parameter PostgreSQL DB default. Parameter konfigurasi lain yang terkait dengan fitur autovacuum juga diatur secara default. Karena parameter default ini cukup umum, Anda dapat memanfaatkannya dengan menyetel beberapa parameter yang terkait dengan fitur autovacuum untuk beban kerja spesifik Anda.
Untuk informasi tingkat tinggi, lihat[Praktik terbaik untuk menggunakan PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [
## Mengalokasikan memori untuk autovacuum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [
## Mengurangi kemungkinan penyelesaian ID transaksi
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [
# Menentukan apakah tabel di basis data Anda perlu divakum atau tidak
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [
# Menentukan tabel mana yang saat ini memenuhi syarat untuk autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [
# Menentukan apakah autovacuum saat ini sedang berjalan atau tidak, dan berapa lama durasinya
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [
# Melakukan pembekuan vakum manual
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [
# Mengindeks ulang tabel saat autovacuum berjalan
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [
# Mengelola autovacuum dengan indeks berukuran besar
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [
# Parameter lain yang memengaruhi autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [
# Mengatur parameter autovacuum tingkat tabel
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [
# Melakukan log aktivitas autovacuum dan vakum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [
# Memahami perilaku autovacuum dengan database yang tidak valid
](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Mengalokasikan memori untuk autovacuum
Salah satu parameter paling penting yang memengaruhi kinerja autovacuum adalah parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). Dalam RDS untuk PostgreSQL PostgreSQL versi 14 dan `autovacuum_work_mem` sebelumnya, parameter diatur ke -1, menunjukkan bahwa pengaturan digunakan sebagai gantinya. `maintenance_work_mem` Untuk semua versi lainnya, `autovacuum_work_mem` ditentukan oleh GREATEST (\$1DBInstanceClassMemory/32768\$1, 65536).
Operasi vakum manual selalu menggunakan `maintenance_work_mem` pengaturan, dengan pengaturan default GREATEST (\$1DBInstanceClassMemory/63963136 \$11024\$1, 65536), dan juga dapat disesuaikan pada tingkat sesi menggunakan perintah untuk operasi manual yang lebih bertarget. `SET` `VACUUM`
Memori `autovacuum_work_mem` menentukan untuk autovacuum untuk menampung pengidentifikasi tupel mati () untuk indeks penyedot debu. `pg_stat_all_tables.n_dead_tup`
Saat melakukan perhitungan untuk menentukan nilai `autovacuum_work_mem` parameter, perhatikan hal-hal berikut:
+ Jika Anda mengatur parameter terlalu rendah, proses vakum mungkin harus memindai tabel beberapa kali untuk menyelesaikan pekerjaannya. Pemindaian berulang seperti ini dapat berdampak negatif pada performa. Untuk contoh yang lebih besar, pengaturan `maintenance_work_mem` atau `autovacuum_work_mem` setidaknya 1 GB dapat meningkatkan kinerja tabel penyedot debu dengan jumlah tupel mati yang tinggi. Namun, dalam PostgreSQL versi 16 dan sebelumnya, penggunaan memori vakum dibatasi pada 1 GB, yang cukup untuk memproses sekitar 179 juta tupel mati dalam satu lintasan. Jika tabel memiliki lebih banyak tupel mati daripada ini, vakum perlu membuat beberapa lintasan melalui indeks tabel, secara signifikan meningkatkan waktu yang dibutuhkan. Dimulai dengan PostgreSQL versi 17, tidak ada batasan 1 GB, dan autovacuum dapat memproses lebih dari 179 juta tupel dengan menggunakan pohon radix.
Pengenal Tuple berukuran 6 byte. Untuk memperkirakan memori yang diperlukan untuk menyedot indeks tabel, kueri `pg_stat_all_tables.n_dead_tup` untuk menemukan jumlah tupel mati, lalu kalikan angka ini dengan 6 untuk menentukan memori yang diperlukan untuk menyedot debu indeks dalam satu lintasan. Anda dapat menggunakan kueri berikut:
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ Parameter `autovacuum_work_mem` bekerja secara bersama-sama dengan parameter `autovacuum_max_workers`. Setiap pekerja di antara `autovacuum_max_workers` dapat menggunakan memori yang Anda alokasikan. Jika Anda memiliki banyak tabel kecil, alokasikan lebih banyak parameter `autovacuum_max_workers` dan lebih sedikit parameter `autovacuum_work_mem`. Jika Anda memiliki tabel besar (lebih besar dari 100 GB), alokasikan lebih banyak memori dan lebih sedikit proses pekerja. Anda harus memiliki cukup memori yang dialokasikan agar berhasil di tabel terbesar Anda. Jadi, pastikan bahwa kombinasi proses pekerja dan memori sama dengan total memori yang ingin Anda alokasikan.
## Mengurangi kemungkinan penyelesaian ID transaksi
Dalam beberapa kasus, pengaturan kelompok parameter yang terkait dengan autovacuum mungkin tidak cukup agresif untuk mencegah penyelesaian ID transaksi. Untuk mengatasi hal ini, RDS untuk PostgreSQL yang menyesuaikan nilai parameter autovacuum secara otomatis. *Autovacuum adaptif* Penjelasan terperinci tentang [TransactionID wraparound](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) dapat ditemukan dalam dokumentasi PostgreSQL.
`rds.adaptive_autovacuum` Kami sangat menyarankan Anda untuk tetap mengaktifkan parameter dinamis ini. Namun, untuk menonaktifkan penyesuaian parameter autovacuum adaptif, atur parameter `rds.adaptive_autovacuum` ke 0 atau nonaktifkan.
Sampul ID transaksi masih dimungkinkan bahkan ketika Amazon RDS Aurora RDS menyetel parameter autovacuum. Kami mendorong Anda untuk menerapkan CloudWatch alarm Amazon untuk sampul ID transaksi. Untuk informasi selengkapnya, lihat posting [Menerapkan sistem peringatan dini untuk sampul ID transaksi di RDS untuk PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) di Blog Database. AWS
Dengan penyetelan parameter autovacuum adaptif diaktifkan, Amazon RDS mulai menyesuaikan parameter autovacuum ketika CloudWatch metrik `MaximumUsedTransactionIDs` mencapai nilai parameter atau 500.000.000, mana yang lebih besar. `autovacuum_freeze_max_age`
Amazon RDS terus menyesuaikan parameter untuk autovacuum jika tabel terus menuju ke penyelesaian ID transaksi. Setiap penyesuaian ini secara khusus mengalokasikan lebih banyak sumber daya ke autovacuum untuk menghindari penyelesaian. Amazon RDS memperbarui parameter terkait autovacuum berikut ini:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS akan memodifikasi parameter ini hanya jika nilai yang baru membuat autovacuum lebih agresif. Parameter dimodifikasi dalam memori di instans DB. Nilai di grup parameter tidak diubah. Untuk melihat pengaturan dalam memori saat ini, gunakan perintah PostgreSQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html) SQL.
Jika Amazon RDS memodifikasi salah satu parameter autovacuum ini, Amazon RDS akan menghasilkan peristiwa untuk instans DB yang terdampak. Acara ini terlihat di Konsol Manajemen AWS dan melalui Amazon RDS API. Setelah `MaximumUsedTransactionIDs` CloudWatch metrik kembali di bawah ambang batas, Amazon RDS mengatur ulang parameter terkait autovacuum dalam memori kembali ke nilai yang ditentukan dalam grup parameter. Kemudian, Amazon RDS akan menghasilkan peristiwa lain yang sesuai dengan perubahan ini.
# Menentukan apakah tabel di basis data Anda perlu divakum atau tidak
Anda dapat menggunakan kueri berikut untuk menunjukkan jumlah transaksi yang tidak dibekukan dalam database. `datfrozenxid`Kolom `pg_database` baris database adalah batas bawah pada transaksi normal yang IDs muncul di database itu. Kolom ini adalah minimum dari nilai per tabel `relfrozenxid` di dalam basis data.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Sebagai contoh, hasil dari menjalankan kueri sebelumnya adalah sebagai berikut.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Ketika usia database mencapai 2 miliar transaksi IDs, sampul ID transaksi (XID) terjadi dan database menjadi read-only. Anda dapat menggunakan kueri ini untuk menghasilkan metrik dan menjalankannya beberapa kali dalam sehari. Secara default, autovacuum diatur untuk menjaga usia transaksi tidak lebih dari 200.000.000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Contoh strategi pemantauan mungkin terlihat seperti ini:
+ Tetapkan nilai `autovacuum_freeze_max_age` hingga 200 juta transaksi.
+ Jika sebuah tabel mencapai 500 juta transaksi yang tidak dibekukan, itu memicu alarm tingkat keparahan rendah. Tidak ada yang dengan nilai ini, tetapi dapat mengindikasikan bahwa autovacuum tidak dapat diteruskan.
+ Jika tabel berumur 1 miliar, indikasi ini harus diperlakukan sebagai peringatan untuk diambil tindakan. Umumnya, Anda ingin mempertahankan usia tabel mendekati `autovacuum_freeze_max_age` karena alasan performa. Sebaiknya Anda menyelidiki hal ini menggunakan rekomendasi berikut.
+ Jika tabel mencapai 1,5 miliar transaksi yang tidak divakum, ini akan memicu alarm dengan keparahan tingkat tinggi. Bergantung pada seberapa cepat database Anda menggunakan transaksi IDs, alarm ini dapat menunjukkan bahwa sistem kehabisan waktu untuk menjalankan autovacuum. Dalam hal ini, sebaiknya Anda segera menyelesaikan proses ini.
Jika tabel terus-menerus melanggar ambang batas ini, ubah parameter autovacuum Anda. Secara default, menggunakan VACUUM secara manual (yang menonaktifkan penundaan berbasis biaya) bersifat lebih agresif dibandingkan menggunakan autovacuum default, tetapi juga lebih mengganggu sistem secara keseluruhan.
Sebaiknya lakukan hal berikut:
+ Waspada dan aktifkan mekanisme pemantauan agar Anda dapat mengetahui usia transaksi Anda yang paling lama.
Untuk informasi tentang membuat proses yang memperingatkan Anda tentang sampul ID transaksi, lihat posting Blog AWS Database [Menerapkan sistem peringatan dini untuk sampul ID transaksi di Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/).
+ Untuk tabel yang lebih sibuk, lakukan pembekuan vakum manual secara teratur selama pemeliharaan, selain mengandalkan autovacuum. Untuk informasi cara melakukan pembekuan vakum manual, lihat [Melakukan pembekuan vakum manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Menentukan tabel mana yang saat ini memenuhi syarat untuk autovacuum
Sering kali, ada satu atau dua tabel yang harus divakum. Tabel dengan nilai `relfrozenxid` lebih besar dari jumlah transaksi dalam `autovacuum_freeze_max_age` selalu menjadi target autovacuum. Sebaliknya, jika jumlah tuple yang dibuat usang sejak VACUUM terakhir melebihi “ambang batas vakum”, tabel akan divakum.
[Ambang batas autovacuum](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) didefinisikan sebagai:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
di mana `vacuum base threshold` ada`autovacuum_vacuum_threshold`, `vacuum scale factor` adalah`autovacuum_vacuum_scale_factor`, dan `number of tuples` adalah`pg_class.reltuples`.
Saat Anda terkoneksi ke basis data, jalankan kueri berikut untuk melihat daftar tabel yang dianggap oleh autovacuum telah memenuhi syarat untuk divakum.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Menentukan apakah autovacuum saat ini sedang berjalan atau tidak, dan berapa lama durasinya
Jika harus memvakum tabel secara manual, pastikan Anda bisa menentukan apakah autovacuum saat ini sedang berjalan atau tidak. Jika sudah berjalan, Anda mungkin perlu menyesuaikan parameter agar berjalan lebih efisien, atau mematikan autovacuum sementara sehingga Anda dapat menjalankan VACUUM secara manual.
Gunakan kueri berikut untuk menentukan apakah autovacuum berjalan, berapa lama sudah berjalan, dan apakah sedang menunggu sesi lainnya atau tidak.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Setelah menjalankan kueri, Anda akan melihat hasil yang serupa dengan yang berikut ini.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Beberapa masalah dapat menyebabkan sesi autovacuum yang lama (yaitu beberapa hari). Masalah yang paling umum adalah nilai parameter [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) Anda diatur terlalu rendah untuk ukuran tabel atau laju pembaruan.
Sebaiknya Anda menggunakan rumus berikut untuk menetapkan nilai parameter `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Sesi autovacuum yang singkat juga dapat mengindikasikan adanya masalah:
+ Sesi ini dapat mengindikasikan bahwa `autovacuum_max_workers` tidak cukup untuk beban kerja Anda. Dalam hal ini, Anda perlu menetapkan jumlah pekerja.
+ Itu dapat mengindikasikan adanya kerusakan indeks (kesalahan pada autovacuum dan mulai ulang di hal yang sama, tetapi tidak ada kemajuan). Dalam hal ini, jalankan `vacuum freeze verbose table` manual untuk mengetahui penyebab pastinya.
# Melakukan pembekuan vakum manual
Anda mungkin dapat melakukan vakum manual di tabel yang memiliki proses vakum yang sudah berjalan. Cara ini berguna jika Anda telah mengidentifikasi tabel dengan usia yang mendekati 2 miliar transaksi (atau di atas ambang batas yang Anda pantau).
Langkah-langkah berikut ini merupakan panduan, yang disertai dengan beberapa variasi proses. Misalnya, selama pengujian, anggaplah Anda menemukan bahwa nilai parameter [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) diatur terlalu kecil dan Anda harus segera mengambil tindakan di tabel. Namun, mungkin pada saat ini Anda tidak ingin mengembalikan instans. Dengan menggunakan kueri di bagian sebelumnya, Anda dapat menentukan tabel mana yang menjadi masalah dan melihat sesi autovacuum yang berjalan lama. Anda tahu bahwa Anda perlu mengubah pengaturan parameter `maintenance_work_mem`, tetapi Anda juga harus mengambil tindakan cepat dan memvakum tabel yang dimaksud. Prosedur berikut menunjukkan tindakan apa yang harus dilakukan dalam situasi ini.
**Untuk melakukan pembekuan vakum secara manual**
1. Buka dua sesi ke basis data yang berisi tabel yang ingin divakum. Untuk sesi kedua, gunakan "layar" atau peralatan lain yang dapat mempertahankan sesi jika koneksi terputus.
1. Dalam sesi pertama, dapatkan ID proses (PID) dari sesi autovacuum yang berjalan di tabel.
Jalankan kueri berikut untuk mendapatkan PID dari sesi autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Dalam sesi kedua, hitung jumlah memori yang Anda butuhkan untuk menjalankan operasi ini. Dalam contoh ini, kita akan menentukan bahwa kita mampu menggunakan memori hingga 2 GB untuk operasi ini sehingga kita menetapkan [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) untuk sesi saat ini hingga 2 GB.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Dalam sesi kedua, munculkan perintah `vacuum freeze verbose` untuk tabel. Pengaturan verbose berguna karena Anda tetap dapat melihat aktivitas pembekuan tersebut meskipun tidak ada laporan kemajuannya di PostgreSQL saat ini.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Dalam sesi satu, jika autovacuum memblokir sesi vakum, `pg_stat_activity` menunjukkan bahwa `T` menunggu adalah sesi vakum Anda. Dalam hal ini, akhiri proses autovacuum sebagai berikut.
```
SELECT pg_terminate_backend('the_pid');
```
**catatan**
Beberapa versi Amazon RDS Aurora yang lebih rendah tidak dapat menghentikan proses autovacuum menggunakan perintah sebelumnya dan gagal dengan kesalahan berikut:. `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`
Di titik ini, sesi Anda dimulai. Autovacuum restart segera karena tabel ini mungkin yang tertinggi dalam daftar pekerjaannya.
1. Mulai perintah `vacuum freeze verbose` di sesi kedua, lalu akhiri proses autovacuum di sesi pertama.
# Mengindeks ulang tabel saat autovacuum berjalan
Jika indeks rusak, autovacuum tetap akan terus memproses tabel lalu gagal. Jika mencoba vakum manual dalam situasi ini, Anda akan menerima pesan kesalahan seperti berikut ini.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Saat indeks rusak dan autovacuum mencoba untuk tetap berjalan di tabel, maka Anda bersaing dengan sesi autovacuum yang sudah berjalan. Jika Anda mengeluarkan perintah “[REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html)“, kunci eksklusif akan diambil di tabel. Operasi penulisan, dan juga operasi membaca yang menggunakan indeks spesifik tersebut, akan diblokir.
**Untuk mengindeks ulang tabel saat autovacuum berjalan di tabel**
1. Buka dua sesi ke basis data yang berisi tabel yang ingin divakum. Untuk sesi kedua, gunakan "layar" atau peralatan lain yang dapat mempertahankan sesi jika koneksi terputus.
1. Dalam sesi pertama, dapatkan PID dari sesi autovacuum yang berjalan di tabel.
Jalankan kueri berikut untuk mendapatkan PID dari sesi autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Dalam sesi kedua, munculkan perintah pengindeksan ulang.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Dalam sesi pertama, jika autovacuum memblokir proses, Anda akan melihat di `pg_stat_activity` bahwa proses menunggu untuk sesi vakum diberi tanda "T". Dalam hal ini, Anda mengakhiri proses autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
Di titik ini, sesi Anda dimulai. Perlu diperhatikan bahwa proses autovacuum akan segera dimulai ulang karena tabel ini mungkin merupakan urutan tertinggi di daftar pekerjaan.
1. Mulai perintah Anda di sesi kedua, lalu akhiri proses autovacuum di sesi 1.
# Mengelola autovacuum dengan indeks berukuran besar
Sebagai bagian dari operasinya, *autovacuum* akan melakukan beberapa [fase vakum](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) saat berjalan di tabel. Sebelum tabel dibersihkan, semua indeksnya akan divakum terlebih dahulu. Fase menghapus beberapa indeks berukuran besar akan menghabiskan banyak waktu dan sumber daya. Oleh karena itu, sebagai praktik terbaik, pastikan Anda mengontrol jumlah indeks di tabel dan menyingkirkan indeks yang tidak digunakan.
Untuk proses ini, pertama-tama periksa ukuran indeks keseluruhan. Kemudian, tentukan apakah ada indeks yang berpotensi tidak digunakan dan dapat dihapus seperti yang ditunjukkan dalam contoh berikut.
**Untuk memeriksa ukuran tabel beserta indeksnya**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
Dalam contoh ini, ukuran indeks lebih besar dari tabel. Perbedaan ini dapat menyebabkan masalah performa karena indeks membengkak atau tidak digunakan sehingga berdampak pada operasi autovacuum serta operasi penyisipan.
**Untuk memeriksa indeks yang tidak digunakan**
Dengan menggunakan tampilan [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), Anda dapat memeriksa seberapa sering indeks digunakan dengan kolom `idx_scan`. Dalam contoh berikut, indeks yang tidak digunakan memiliki nilai `idx_scan` dari `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**catatan**
Statistik ini bersifat inkremental sejak statistik diatur ulang. Misalkan Anda memiliki indeks yang hanya digunakan pada akhir kuartal bisnis atau hanya untuk laporan tertentu. Ada kemungkinan bahwa indeks ini belum digunakan sejak statistik diatur ulang. Untuk informasi selengkapnya, lihat [Fungsi Statistik](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS). Indeks yang digunakan untuk menerapkan keunikan tidak akan memiliki pemindaian yang dilakukan dan tidak boleh diidentifikasi sebagai indeks yang tidak digunakan. Untuk mengidentifikasi indeks yang tidak digunakan, Anda harus memiliki pengetahuan mendalam tentang aplikasi dan pertanyaannya.
Untuk memeriksa kapan statistik terakhir basis data disetel ulang, gunakan [ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Melakukan vakum di tabel secepat mungkin
**RDS untuk PostgreSQL 12 dan versi lebih tinggi**
Jika Anda memiliki terlalu banyak indeks dalam tabel besar, instans DB Anda mungkin mendekati penyelesaian ID transaksi (XID), yaitu saat penghitung XID mendekati nol. Jika tidak terkendali, situasi ini dapat mengakibatkan kehilangan data. Namun, Anda dapat dengan cepat melakuan vakum di tabel tanpa harus membersihkan indeks. Dalam RDS untuk PostgreSQL 12 dan versi lebih tinggi, Anda dapat menggunakan VACUUM dengan klausa [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Jika sesi autovacuum sudah berjalan, Anda harus menghentikannya agar dapat memulai VACUUM manual. Untuk informasi cara melakukan pembekuan vakum manual, lihat [Melakukan pembekuan vakum manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**catatan**
Melewatkan pembersihan indeks secara teratur menyebabkan indeks kembung, yang menurunkan kinerja pemindaian. Indeks mempertahankan baris mati, dan tabel mempertahankan pointer garis mati. Akibatnya, `pg_stat_all_tables.n_dead_tup` meningkat hingga autovacuum atau VACUUM manual dengan pembersihan indeks berjalan. Sebagai praktik terbaik, gunakan prosedur ini hanya untuk mencegah pembungkus ID transaksi.
**RDS untuk PostgreSQL 11 dan versi lama**
Namun, dalam RDS untuk PostgreSQL 11 dan versi lama, satu-satunya cara agar vakum dapat selesai lebih cepat adalah dengan mengurangi jumlah indeks di tabel. Menghapus sementara indeks dapat memengaruhi rencana kueri. Sebaiknya Anda menghapus sementara indeks yang tidak digunakan terlebih dahulu, lalu menghapus sementara indeks saat penyelesaian XID sangat dekat. Setelah proses vakum selesai, Anda dapat membuat ulang indeks ini.
# Parameter lain yang memengaruhi autovacuum
Kueri berikut menunjukkan nilai dari beberapa parameter yang secara langsung memengaruhi autovacuum dan perilakunya. [Parameter autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) dijelaskan dengan lengkap dalam dokumentasi PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Meskipun semua ini memengaruhi autovacuum, beberapa hal yang paling penting adalah:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Mengatur parameter autovacuum tingkat tabel
Anda dapat mengatur [parameter penyimpanan](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) terkait autovacuum di tingkat tabel, dan biasanya cara ini bisa lebih baik daripada harus mengubah perilaku seluruh basis data. Untuk tabel besar, Anda mungkin perlu mengatur pengaturan yang agresif dan tidak ingin membuat autovacuum berperilaku seperti itu untuk semua tabel.
Kueri berikut menunjukkan tabel mana yang saat ini memiliki opsi tingkat tabel.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Pengaturan ini mungkin berguna pada tabel yang jauh lebih besar daripada tabel lainnya, misalnya. Misalkan Anda memiliki satu tabel berukuran 300 GB dan 30 table lainnya berukuran kurang dari 1 GB. Dalam hal ini, Anda dapat mengatur beberapa parameter khusus untuk tabel besar sehingga tidak perlu mengubah perilaku dari seluruh sistem.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Melakukan tindakan ini akan menonaktifkan penundaan autovacuum berbasis biaya untuk tabel ini dengan mengorbankan lebih banyak penggunaan sumber daya di sistem Anda. Biasanya, jeda autovacuum untuk `autovacuum_vacuum_cost_delay` setiap kali `autovacuum_cost_limit` tercapai. Untuk mengetahui detail selengkapnya, lihat dokumentasi PostgreSQL tentang [pemvakuman berbasis biaya](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Melakukan log aktivitas autovacuum dan vakum
Informasi mengenai aktivitas autovacuum dikirim ke `postgresql.log` berdasarkan level yang ditentukan dalam parameter `rds.force_autovacuum_logging_level`. Berikut ini adalah nilai yang diizinkan untuk parameter ini dan versi PostgreSQL dengan nilai berupa pengaturan default:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 dan versi lebih tinggi)
+ `error`, log `fatal`, `panic`
`rds.force_autovacuum_logging_level` berfungsi dengan parameter `log_autovacuum_min_duration`. Nilai parameter `log_autovacuum_min_duration` adalah ambang batas (dalam milidetik) tempat tindakan autovacuum dicatat. Pengaturan `-1` tidak mencatat apa pun, sedangkan pengaturan 0 mencatat semua tindakan. Seperti halnya`rds.force_autovacuum_logging_level`, nilai default untuk `log_autovacuum_min_duration` bergantung pada versi, sebagai berikut:
+ `10000 ms` – PostgreSQL 14, PostgreSQL 13, PostgreSQL 12, dan PostgreSQL 11
+ `(empty)` – Tidak ada nilai default untuk PostgreSQL 10 dan PostgreSQL 9.6
Sebaiknya Anda mengatur `rds.force_autovacuum_logging_level` ke `WARNING`. Sebaiknya Anda juga mengatur `log_autovacuum_min_duration` ke nilai dari 1000 hingga 5000. Pengaturan aktivitas 5000 log yang membutuhkan waktu lebih dari 5.000 milidetik. Pengaturan apa pun selain -1 juga akan mencatat pesan jika tindakan autovacuum dilewati karena kunci yang bertentangan atau hubungan yang dihapus sementara secara bersamaan. Untuk informasi selengkapnya, lihat [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) dalam dokumentasi PostgreSQL.
Untuk memecahkan masalah, Anda dapat mengubah parameter `rds.force_autovacuum_logging_level` ke salah satu level debug, dari `debug1` hingga `debug5` untuk informasi panjang. Sebaiknya Anda menggunakan pengaturan debug untuk jangka waktu singkat dan hanya untuk tujuan pemecahan masalah. Untuk mempelajari selengkapnya, lihat [When to log](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) dalam dokumentasi PostgreSQL.
**catatan**
PostgreSQL memungkinkan akun `rds_superuser` untuk melihat sesi autovacuum di `pg_stat_activity`. Misalnya, Anda dapat mengidentifikasi dan mengakhiri sesi autovacuum yang memblokintah agar tidak berjalan, atau berjalan lebih lambat daripada perintah vakum yang dikeluarkan secara manual.
# Memahami perilaku autovacuum dengan database yang tidak valid
Nilai `-2` baru diperkenalkan ke `datconnlimit` kolom dalam `pg_database` katalog untuk menunjukkan database yang telah terputus di tengah operasi DROP DATABASE sebagai tidak valid.
Nilai baru ini tersedia dari
+ 15.4 dan semua versi yang lebih tinggi
+ 14.9 dan versi yang lebih tinggi
+ 13.12 dan versi yang lebih tinggi
+ 12.16 dan versi yang lebih tinggi
+ 11.21 dan versi yang lebih tinggi
Database yang tidak valid tidak memengaruhi kemampuan autovacuum untuk membekukan fungsionalitas untuk database yang valid. Autovacuum mengabaikan database yang tidak valid. Akibatnya, operasi vakum reguler akan terus berfungsi dengan baik dan efisien untuk semua database yang valid di lingkungan PostgreSQL Anda.
**Topics**
+ [
## Memantau ID transaksi
](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [
## Menyesuaikan kueri pemantauan
](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [
## Menyelesaikan masalah database yang tidak valid
](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Memantau ID transaksi
`age(datfrozenxid)`Fungsi ini biasa digunakan untuk memantau usia transaksi ID (XID) database untuk mencegah pembungkus ID transaksi.
Karena database yang tidak valid dikecualikan dari autovacuum, penghitung ID transaksi (XID) mereka dapat mencapai nilai maksimum`2 billion`, membungkus, dan melanjutkan siklus ini tanpa batas waktu. `- 2 billion` Kueri khas untuk memantau sampul ID Transaksi mungkin terlihat seperti:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Namun, dengan diperkenalkannya nilai -2 untuk`datconnlimit`, database yang tidak valid dapat memiringkan hasil kueri ini. Karena database ini tidak valid dan tidak boleh menjadi bagian dari pemeriksaan pemeliharaan rutin, mereka dapat menyebabkan positif palsu, membuat Anda percaya bahwa `age(datfrozenxid)` itu lebih tinggi daripada yang sebenarnya.
## Menyesuaikan kueri pemantauan
Untuk memastikan pemantauan yang akurat, Anda harus menyesuaikan kueri pemantauan untuk mengecualikan database yang tidak valid. Ikuti kueri yang disarankan ini:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Kueri ini memastikan bahwa hanya database yang valid yang dipertimbangkan dalam `age(datfrozenxid)` perhitungan, memberikan refleksi sebenarnya dari usia ID transaksi di seluruh lingkungan PostgreSQL Anda.
## Menyelesaikan masalah database yang tidak valid
Saat mencoba menyambung ke database yang tidak valid, Anda mungkin menemukan pesan galat yang mirip dengan berikut ini:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Selain itu, jika `log_min_messages` parameter disetel ke `DEBUG2` atau lebih tinggi, Anda mungkin melihat entri log berikut yang menunjukkan bahwa proses autovacuum melewatkan database yang tidak valid:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Untuk mengatasi masalah ini, ikuti yang `HINT` disediakan selama upaya koneksi. Connect ke database yang valid menggunakan akun master RDS Anda atau akun database dengan `rds_superuser` peran tersebut, dan jatuhkan database yang tidak valid.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
#
[Di PostgreSQL, menyedot debu sangat penting untuk memastikan kesehatan database karena merebut kembali penyimpanan dan mencegah masalah pembungkus ID transaksi.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) Namun, ada kalanya penyedot debu dapat dicegah agar tidak beroperasi seperti yang diinginkan, yang dapat mengakibatkan penurunan kinerja, pembengkakan penyimpanan, dan bahkan memengaruhi ketersediaan instans DB Anda dengan sampul ID transaksi. Oleh karena itu, mengidentifikasi dan menyelesaikan masalah ini sangat penting untuk kinerja dan ketersediaan database yang optimal. Baca [Memahami autovacuum di Amazon RDS untuk lingkungan PostgreSQL untuk](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) mempelajari lebih lanjut tentang autovacuum.
`postgres_get_av_diag()`Fungsi ini membantu mengidentifikasi masalah yang mencegah atau menunda kemajuan vakum yang agresif. Saran disediakan, yang mungkin termasuk perintah untuk menyelesaikan masalah yang dapat diidentifikasi atau panduan untuk diagnostik lebih lanjut di mana masalah tidak dapat diidentifikasi. Penghambat vakum agresif dilaporkan ketika usia melebihi ambang batas [autovacuum adaptif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) RDS sebesar 500 juta transaksi. IDs
**Berapa usia ID transaksi?**
`age()`Fungsi untuk transaksi IDs menghitung jumlah transaksi yang telah terjadi sejak ID transaksi yang tidak dibekukan tertua untuk database (`pg_database.datfrozenxid`) atau tabel (`pg_class.relfrozenxid`). Nilai ini menunjukkan aktivitas database sejak operasi vakum agresif terakhir dan menyoroti kemungkinan beban kerja untuk proses VACUUM yang akan datang.
**Apa itu vakum agresif?**
Operasi VACUUM yang agresif melakukan pemindaian komprehensif semua halaman dalam tabel, termasuk yang biasanya dilewati selama reguler. VACUUMs Pemindaian menyeluruh ini bertujuan untuk “membekukan” transaksi IDs mendekati usia maksimum mereka, secara efektif mencegah situasi yang dikenal sebagai [sampul ID transaksi](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
`postgres_get_av_diag()`Untuk melaporkan pemblokir, pemblokir harus berusia setidaknya 500 juta transaksi.
**Topics**
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
#
`postgres_get_av_diag()`Fungsi ini saat ini tersedia dalam RDS berikut untuk PostgreSQL Aurora PostgreSQL versi :
+ 17.2 dan versi 17 yang lebih tinggi
+ 16.7 dan versi 16 yang lebih tinggi
+ 15.11 dan versi 15 yang lebih tinggi
+ 14.16 dan versi 14 yang lebih tinggi
+ 13.19 dan 13 versi yang lebih tinggi
Untuk menggunakan`postgres_get_av_diag()`, buat `rds_tools` ekstensi.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Verifikasi bahwa ekstensi diinstal.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Verifikasi bahwa fungsi tersebut dibuat.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
#
`postgres_get_av_diag()` Kueri harus dieksekusi dalam database dengan ID transaksi tertua untuk hasil yang akurat. Untuk informasi selengkapnya tentang menggunakan database dengan ID transaksi tertua, lihat [Tidak terhubung ke database dengan usia ID transaksi terlama](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
`postgres_get_av_diag()`Fungsi mengembalikan tabel dengan informasi berikut:
**pemblokir**
Menentukan kategori aktivitas database yang memblokir vakum.
+ [Pernyataan aktif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Idle pada transaksi](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transaksi yang disiapkan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot replikasi logis](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Baca replika dengan slot replikasi fisik](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Baca replika dengan replikasi streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabel sementara](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**basis data**
Menentukan nama database jika berlaku dan didukung. Ini adalah database di mana aktivitas sedang berlangsung dan memblokir atau akan memblokir autovacuum. Ini adalah database yang harus Anda sambungkan dan ambil tindakan.
**blocker\$1identifier**
Menentukan pengenal aktivitas yang memblokir atau akan memblokir autovacuum. Pengidentifikasi dapat berupa ID proses bersama dengan pernyataan SQL, transaksi yang disiapkan, alamat IP replika baca, dan nama slot replikasi, baik logis atau fisik.
**wait\$1event**
Menentukan [acara tunggu acara](PostgreSQL.Tuning.md) sesi pemblokiran dan berlaku untuk blocker berikut:
+ Pernyataan aktif
+ Idle pada transaksi
**autovacum\$1lagging\$1by**
Menentukan jumlah transaksi yang autovacuum tertinggal dalam pekerjaan backlog-nya per kategori.
**saran**
Menentukan saran untuk menyelesaikan blocker. Instruksi ini mencakup nama database tempat aktivitas ada jika berlaku, ID Proses (PID) sesi jika berlaku, dan tindakan yang akan diambil.
**suggested\$1action**
Menyarankan tindakan yang perlu diambil untuk menyelesaikan pemblokir.
#
Autovacuum melakukan penyedot debu agresif dan menurunkan usia transaksi IDs hingga di bawah ambang batas yang ditentukan oleh parameter instans RDS Anda. `autovacuum_freeze_max_age` Anda dapat melacak usia ini menggunakan CloudWatch metrik Amazon`MaximumUsedTransactionIDs`.
Untuk menemukan pengaturan `autovacuum_freeze_max_age` (yang memiliki default 200 juta transaksi IDs) untuk instans Amazon RDS Anda, Anda dapat menggunakan kueri berikut:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Perhatikan bahwa `postgres_get_av_diag()` hanya memeriksa penghambat vakum agresif ketika usia melebihi ambang batas [autovacuum adaptif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) Amazon RDS sebesar 500 juta transaksi. IDs `postgres_get_av_diag()`Untuk mendeteksi pemblokir, pemblokir harus berusia setidaknya 500 juta transaksi.
`postgres_get_av_diag()`Fungsi ini mengidentifikasi jenis blocker berikut:
**Topics**
+ [
## Pernyataan aktif
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [
## Idle pada transaksi
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [
## Transaksi yang disiapkan
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [
## Slot replikasi logis
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [
## Replika baca
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [
## Tabel sementara
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Pernyataan aktif
Dalam PostgreSQL, pernyataan aktif adalah pernyataan SQL yang saat ini sedang dijalankan oleh database. Ini termasuk kueri, transaksi, atau operasi apa pun yang sedang berlangsung. Saat memantau via`pg_stat_activity`, kolom status menunjukkan bahwa proses dengan PID yang sesuai aktif.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi pernyataan yang merupakan pernyataan aktif.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Tindakan yang disarankan**
Mengikuti panduan di `suggestion` kolom, pengguna dapat terhubung ke database di mana pernyataan aktif hadir dan, seperti yang ditentukan dalam `suggested_action` kolom, disarankan untuk hati-hati meninjau opsi untuk mengakhiri sesi. Jika penghentian aman, Anda dapat menggunakan `pg_terminate_backend()` fungsi untuk mengakhiri sesi. Tindakan ini dapat dilakukan oleh administrator (seperti akun master RDS) atau pengguna dengan `pg_terminate_backend()` hak istimewa yang diperlukan.
**Awas**
Sesi yang dihentikan akan membatalkan (`ROLLBACK`) perubahan yang dibuatnya. Tergantung pada kebutuhan Anda, Anda mungkin ingin menjalankan kembali pernyataan tersebut. Namun, disarankan untuk melakukannya hanya setelah proses autovacuum menyelesaikan operasi vakum agresifnya.
## Idle pada transaksi
Pernyataan transaksi yang menganggur mengacu pada setiap sesi yang telah membuka transaksi eksplisit (seperti dengan mengeluarkan `BEGIN` pernyataan), melakukan beberapa pekerjaan, dan sekarang menunggu klien untuk melewati lebih banyak pekerjaan atau memberi sinyal akhir transaksi dengan mengeluarkan`COMMIT`,`ROLLBACK`, atau `END` (yang akan menghasilkan implisit). `COMMIT`
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi `idle in transaction` pernyataan sebagai pemblokir.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Tindakan yang disarankan**
Seperti yang ditunjukkan dalam `suggestion` kolom, Anda dapat terhubung ke database tempat idle dalam sesi transaksi hadir dan mengakhiri sesi menggunakan fungsi. `pg_terminate_backend()` Pengguna dapat menjadi pengguna admin Anda (akun master RDS) atau pengguna dengan `pg_terminate_backend()` hak istimewa.
**Awas**
Sesi yang dihentikan akan membatalkan (`ROLLBACK`) perubahan yang dibuatnya. Tergantung pada kebutuhan Anda, Anda mungkin ingin menjalankan kembali pernyataan tersebut. Namun, disarankan untuk melakukannya hanya setelah proses autovacuum menyelesaikan operasi vakum agresifnya.
## Transaksi yang disiapkan
[PostgreSQL memungkinkan transaksi yang merupakan bagian dari strategi komit dua fase yang disebut transaksi siap.](https://www.postgresql.org/docs/current/sql-prepare-transaction.html) Ini diaktifkan dengan mengatur `max_prepared_transactions` parameter ke nilai bukan nol. Transaksi yang disiapkan dirancang untuk memastikan bahwa transaksi tahan lama dan tetap tersedia bahkan setelah database crash, restart, atau pemutusan klien. Seperti transaksi reguler, mereka diberi ID transaksi dan dapat memengaruhi autovacuum. Jika dibiarkan dalam keadaan siap, autovacuum tidak dapat melakukan freeezing dan dapat menyebabkan penutupan ID transaksi.
Ketika transaksi dibiarkan dipersiapkan tanpa batas waktu tanpa diselesaikan oleh manajer transaksi, mereka menjadi transaksi yang disiapkan yatim piatu. Satu-satunya cara untuk memperbaikinya adalah dengan melakukan atau mengembalikan transaksi menggunakan `ROLLBACK PREPARED` perintah `COMMIT PREPARED` atau, masing-masing.
**catatan**
Ketahuilah bahwa cadangan yang diambil selama transaksi yang disiapkan akan tetap berisi transaksi tersebut setelah restorasi. Lihat informasi berikut tentang cara menemukan dan menutup transaksi tersebut.
`postgres_get_av_diag()`Fungsi ini menampilkan output berikut ketika mengidentifikasi pemblokir yang merupakan transaksi yang disiapkan.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Tindakan yang disarankan**
Seperti disebutkan di kolom saran, sambungkan ke database tempat transaksi yang disiapkan berada. Berdasarkan `suggested_action` kolom, hati-hati meninjau apakah akan melakukan salah satu `COMMIT` atau`ROLLBACK`, dan menyetujui tindakan.
Untuk memantau transaksi yang disiapkan secara umum, PostgreSQL menawarkan tampilan katalog yang disebut. `pg_prepared_xacts` Anda dapat menggunakan kueri berikut untuk menemukan transaksi yang disiapkan.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Slot replikasi logis
Tujuan dari slot replikasi adalah untuk menahan perubahan yang tidak dikonsumsi sampai mereka direplikasi ke server target. [Untuk informasi lebih lanjut, lihat Replikasi Logis PostgreSQL.](https://www.postgresql.org/docs/current/logical-replication.html)
Ada dua jenis slot replikasi logis.
**Slot replikasi logis tidak aktif**
Ketika replikasi dihentikan, log transaksi yang tidak dikonsumsi tidak dapat dihapus, dan slot replikasi menjadi tidak aktif. Meskipun slot replikasi logis yang tidak aktif saat ini tidak digunakan oleh pelanggan, itu tetap di server, yang mengarah ke retensi file WAL dan mencegah penghapusan log transaksi lama. Ini dapat meningkatkan penggunaan disk dan secara khusus memblokir autovacuum dari membersihkan tabel katalog internal, karena sistem harus menjaga informasi LSN agar tidak ditimpa. Jika tidak ditangani, hal ini dapat mengakibatkan kembung katalog, penurunan kinerja, dan peningkatan risiko kekosongan sampul, yang berpotensi menyebabkan downtime transaksi.
**Slot replikasi logis aktif tapi lambat**
Terkadang penghapusan tupel mati katalog tertunda karena penurunan kinerja replikasi logis. Keterlambatan replikasi ini memperlambat pembaruan `catalog_xmin` dan dapat menyebabkan katalog kembung dan vakum sampul.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan slot replikasi logis sebagai pemblokir.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Tindakan yang disarankan**
Untuk mengatasi masalah ini, periksa konfigurasi replikasi untuk masalah dengan skema target atau data yang mungkin menghentikan proses penerapan. Alasan paling umum adalah sebagai berikut:
+ Kolom hilang
+ Tipe data yang tidak kompatibel
+ Ketidakcocokan data
+ Tabel hilang
Jika masalah terkait dengan masalah infrastruktur:
+ Masalah jaringan - [Bagaimana cara mengatasi masalah dengan Amazon RDS DB dalam status jaringan yang tidak kompatibel?](https://repost.aws/knowledge-center/rds-incompatible-network) .
+ Database atau instans DB tidak tersedia karena alasan berikut:
+ Instans replika kehabisan penyimpanan - Tinjau [instans Amazon RDS DB kehabisan penyimpanan](https://repost.aws/knowledge-center/rds-out-of-storage) untuk informasi tentang menambahkan penyimpanan.
+ Parameter Tidak Kompatibel - Tinjau [Bagaimana cara memperbaiki instans Amazon RDS DB yang macet dalam status parameter yang tidak kompatibel?](https://repost.aws/knowledge-center/rds-incompatible-parameters) untuk informasi lebih lanjut tentang bagaimana Anda dapat menyelesaikan masalah.
Jika instans Anda berada di luar AWS jaringan atau aktif AWS EC2, konsultasikan dengan administrator Anda tentang cara mengatasi masalah ketersediaan atau terkait infrastruktur.
**Menjatuhkan slot yang tidak aktif**
**Awas**
Perhatian: Sebelum menjatuhkan slot replikasi, pastikan dengan hati-hati bahwa ia tidak memiliki replikasi yang sedang berlangsung, tidak aktif, dan dalam keadaan tidak dapat dipulihkan. Menjatuhkan slot sebelum waktunya dapat mengganggu replikasi atau menyebabkan kehilangan data.
Setelah memastikan bahwa slot replikasi tidak lagi diperlukan, jatuhkan untuk memungkinkan autovacuum melanjutkan. Kondisi ini `active = 'f'` memastikan bahwa hanya slot yang tidak aktif yang dijatuhkan.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Replika baca
Saat `hot_standby_feedback` pengaturan diaktifkan untuk [replika baca Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), pengaturan ini mencegah autovacuum pada database utama menghapus baris mati yang mungkin masih diperlukan oleh kueri yang berjalan pada replika baca. Ini mempengaruhi semua jenis replika baca fisik termasuk yang dikelola dengan atau tanpa slot replikasi. Perilaku ini diperlukan karena kueri yang berjalan pada replika siaga mengharuskan baris tersebut tetap tersedia di primer yang mencegah [konflik dan pembatalan kueri](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT).
**Baca replika dengan slot replikasi fisik**
Slot ini memastikan database utama menyimpan file Write-Ahead Log penting sampai replika memprosesnya, menjaga konsistensi data bahkan selama gangguan jaringan.
Dimulai dengan RDS untuk PostgreSQL , semua replika menggunakan slot replikasi. Pada versi sebelumnya, hanya replika lintas wilayah yang menggunakan slot replikasi.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan replika baca dengan slot replikasi fisik sebagai pemblokir.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Baca replika dengan replikasi streaming**
Amazon RDS memungkinkan pengaturan replika baca tanpa slot replikasi fisik di versi yang lebih lama, hingga versi 13. Pendekatan ini mengurangi overhead dengan memungkinkan primer untuk mendaur ulang file WAL lebih agresif, yang menguntungkan di lingkungan dengan ruang disk terbatas dan dapat mentolerir sesekali. ReplicaLag Namun, tanpa slot, siaga harus tetap sinkron untuk menghindari file WAL yang hilang. Amazon RDS menggunakan file WAL yang diarsipkan untuk membantu replika catch up jika tertinggal, tetapi proses ini memerlukan pemantauan yang cermat dan bisa lambat.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan replika baca streaming sebagai pemblokir.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Tindakan yang disarankan**
Seperti yang direkomendasikan di `suggested_action` kolom, tinjau opsi ini dengan cermat untuk membuka blokir autovacuum.
+ **Mengakhiri kueri** — Mengikuti panduan di kolom saran, Anda dapat terhubung ke replika baca, seperti yang ditentukan dalam kolom suggested\$1action, disarankan untuk hati-hati meninjau opsi untuk mengakhiri sesi. Jika penghentian dianggap aman, Anda dapat menggunakan `pg_terminate_backend()` fungsi ini untuk mengakhiri sesi. Tindakan ini dapat dilakukan oleh administrator (seperti akun master RDS) atau pengguna dengan hak istimewa pg\$1terminate\$1backend () yang diperlukan.
Anda dapat menjalankan perintah SQL berikut pada replika baca untuk mengakhiri kueri yang mencegah vakum pada primer membersihkan baris lama. Nilai dilaporkan dalam output fungsi: `backend_xmin`
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Nonaktifkan umpan balik siaga panas** - Pertimbangkan untuk menonaktifkan `hot_standby_feedback` parameter jika menyebabkan penundaan vakum yang signifikan.
`hot_standby_feedback`Parameter ini memungkinkan replika baca untuk menginformasikan primer tentang aktivitas kuerinya, mencegah primer menyedot debu tabel atau baris yang digunakan pada siaga. Meskipun ini memastikan stabilitas kueri pada siaga, ini dapat secara signifikan menunda penyedotan debu pada primer. Menonaktifkan fitur ini memungkinkan primer untuk melanjutkan dengan menyedot debu tanpa menunggu siaga untuk mengejar ketinggalan. Namun, ini dapat menyebabkan pembatalan kueri atau kegagalan pada siaga jika mencoba mengakses baris yang telah disedot oleh primer.
+ **Hapus replika baca jika tidak diperlukan** — Jika replika baca tidak lagi diperlukan, Anda dapat menghapusnya. Ini akan menghapus overhead replikasi terkait dan memungkinkan primer untuk mendaur ulang log transaksi tanpa ditahan oleh replika.
## Tabel sementara
[Tabel sementara](https://www.postgresql.org/docs/current/sql-createtable.html), dibuat menggunakan `TEMPORARY` kata kunci, berada dalam skema temp, misalnya pg\$1temp\$1xxx, dan hanya dapat diakses oleh sesi yang membuatnya. Tabel sementara dijatuhkan saat sesi berakhir. Namun, tabel ini tidak terlihat oleh proses autovacuum PostgreSQL, dan harus disedot secara manual oleh sesi yang membuatnya. Mencoba menyedot tabel suhu dari sesi lain tidak berpengaruh.
Dalam keadaan yang tidak biasa, tabel sementara ada tanpa sesi aktif yang memilikinya. Jika sesi kepemilikan berakhir secara tak terduga karena kecelakaan fatal, masalah jaringan, atau peristiwa serupa, tabel sementara mungkin tidak dibersihkan, meninggalkannya sebagai tabel “yatim piatu”. Ketika proses autovacuum PostgreSQL mendeteksi tabel sementara yatim piatu, ia mencatat pesan berikut:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi tabel sementara sebagai pemblokir. Agar fungsi menampilkan output yang terkait dengan tabel sementara dengan benar, itu perlu dieksekusi dalam database yang sama di mana tabel tersebut ada.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Tindakan yang disarankan**
Ikuti instruksi yang diberikan di `suggestion` kolom output untuk mengidentifikasi dan menghapus tabel sementara yang mencegah autovacuum berjalan. Gunakan perintah berikut untuk menjatuhkan tabel sementara yang dilaporkan oleh`postgres_get_av_diag()`. Ganti nama tabel berdasarkan output yang disediakan oleh `postgres_get_av_diag()` fungsi.
```
DROP TABLE my_temp_schema.my_temp_table;
```
Kueri berikut dapat digunakan untuk mengidentifikasi tabel sementara:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
#
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.
#
Bagian ini membahas faktor-faktor yang sering berkontribusi pada kinerja vakum yang lebih lambat dan bagaimana mengatasi masalah ini.
**Topics**
+ [
## Vakum indeks besar
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [
## Terlalu banyak tabel atau database untuk vakum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [
## Vakum agresif (untuk mencegah pembungkus) sedang berjalan
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Vakum indeks besar
VACUUM beroperasi melalui fase berurutan: inisialisasi, pemindaian tumpukan, penyedot debu indeks dan tumpukan, pembersihan indeks, pemotongan tumpukan, dan pembersihan akhir. Selama pemindaian tumpukan, proses memangkas halaman, mendefragmen, dan membekukannya. Setelah menyelesaikan pemindaian heap, VACUUM membersihkan indeks, mengembalikan halaman kosong ke sistem operasi, dan melakukan tugas pembersihan akhir seperti menyedot debu peta ruang kosong dan memperbarui statistik.
Penyedot debu indeks mungkin memerlukan beberapa lintasan ketika `maintenance_work_mem` (atau`autovacuum_work_mem`) tidak cukup untuk memproses indeks. Di PostgreSQL 16 dan sebelumnya, batas memori 1 GB untuk menyimpan IDs tupel mati sering memaksa beberapa pass pada indeks besar. PostgreSQL 17 `TidStore` memperkenalkan, yang secara dinamis mengalokasikan memori alih-alih menggunakan array alokasi tunggal. Ini menghilangkan batasan 1 GB, menggunakan memori lebih efisien, dan mengurangi kebutuhan untuk beberapa pemindaian indeks per setiap indeks.
Indeks besar mungkin masih memerlukan beberapa pass di PostgreSQL 17 jika memori yang tersedia tidak dapat mengakomodasi seluruh pemrosesan indeks sekaligus. Biasanya, indeks yang lebih besar mengandung lebih banyak tupel mati yang membutuhkan banyak lintasan.
**Mendeteksi operasi vakum yang lambat**
`postgres_get_av_diag()`Fungsi ini dapat mendeteksi ketika operasi vakum berjalan lambat karena memori yang tidak mencukupi. Untuk informasi lebih lanjut tentang fungsi ini, lihat[](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
`postgres_get_av_diag()`Fungsi mengeluarkan pemberitahuan berikut ketika memori yang tersedia tidak cukup untuk menyelesaikan penyedot debu indeks dalam satu lintasan.
**`rds_tools`1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools`1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**catatan**
`postgres_get_av_diag()`Fungsi ini bergantung pada `pg_stat_all_tables.n_dead_tup` untuk memperkirakan jumlah memori yang diperlukan untuk penyedot debu indeks.
Ketika `postgres_get_av_diag()` fungsi mengidentifikasi operasi vakum lambat yang memerlukan beberapa pemindaian indeks karena tidak mencukupi`autovacuum_work_mem`, itu akan menghasilkan pesan berikut:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Bimbingan**
Anda dapat menerapkan solusi berikut menggunakan manual `VACUUM FREEZE` untuk mempercepat pembekuan tabel.
**Tingkatkan memori untuk menyedot debu**
Seperti yang disarankan oleh `postgres_get_av_diag()` fungsi, disarankan untuk meningkatkan `autovacuum_work_mem` parameter untuk mengatasi kendala memori potensial pada tingkat instance. Meskipun `autovacuum_work_mem` merupakan parameter dinamis, penting untuk dicatat bahwa agar pengaturan memori baru diterapkan, daemon autovacuum perlu me-restart pekerjanya. Untuk mencapai ini:
1. Konfirmasikan bahwa pengaturan baru sudah ada.
1. Hentikan proses yang saat ini menjalankan autovacuum.
Pendekatan ini memastikan bahwa alokasi memori yang disesuaikan diterapkan pada operasi autovacuum baru.
Untuk hasil yang lebih cepat, pertimbangkan untuk melakukan `VACUUM FREEZE` operasi secara manual dengan `maintenance_work_mem` pengaturan yang ditingkatkan dalam sesi Anda:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Jika Anda menggunakan Amazon RDS dan menemukan bahwa Anda memerlukan memori tambahan untuk mendukung nilai yang lebih tinggi untuk `maintenance_work_mem` atau`autovacuum_work_mem`, pertimbangkan untuk meningkatkan ke kelas instans dengan lebih banyak memori. Ini dapat menyediakan sumber daya yang diperlukan untuk meningkatkan operasi vakum manual dan otomatis, yang mengarah pada peningkatan kinerja vakum dan basis data secara keseluruhan.
**Nonaktifkan INDEX\$1CLEANUP**
Manual `VACUUM` di PostgreSQL versi 12 dan yang lebih baru memungkinkan melewatkan fase pembersihan indeks, sementara autovacuum darurat di PostgreSQL versi 14 dan yang lebih baru melakukan ini secara otomatis berdasarkan parameter. [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE)
**Awas**
Melewatkan pembersihan indeks dapat menyebabkan indeks kembung dan berdampak negatif pada kinerja kueri. Untuk mengurangi ini, pertimbangkan untuk mengindeks ulang atau menyedot debu indeks yang terpengaruh selama jendela pemeliharaan.
Untuk panduan tambahan tentang penanganan indeks besar, lihat dokumentasi di[Mengelola autovacuum dengan indeks berukuran besar](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Penyedot debu indeks paralel**
Dimulai dengan PostgreSQL 13, indeks dapat disedot dan dibersihkan secara paralel secara default menggunakan `VACUUM` manual, dengan satu proses vacuum worker ditetapkan untuk setiap indeks. Namun, untuk PostgreSQL untuk menentukan apakah operasi vakum memenuhi syarat untuk eksekusi paralel, kriteria khusus harus dipenuhi:
+ Setidaknya harus ada dua indeks.
+ `max_parallel_maintenance_workers`Parameter harus diatur ke setidaknya 2.
+ Ukuran indeks harus melebihi `min_parallel_index_scan_size` batas, yang defaultnya 512KB.
Anda dapat menyesuaikan `max_parallel_maintenance_workers` pengaturan berdasarkan jumlah v yang CPUs tersedia di instans Amazon RDS Anda dan jumlah indeks di atas meja untuk mengoptimalkan waktu penyelesaian vakum.
Untuk informasi selengkapnya, lihat [Penyedot debu paralel di Amazon RDS untuk PostgreSQL dan Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Terlalu banyak tabel atau database untuk vakum
Seperti disebutkan dalam dokumentasi [The Autovacuum Daemon PostgreSQL, daemon autovacuum](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') beroperasi melalui beberapa proses. Ini termasuk peluncur autovacuum persisten yang bertanggung jawab untuk memulai proses pekerja autovacuum untuk setiap database dalam sistem. Peluncur menjadwalkan pekerja ini untuk memulai kira-kira setiap `autovacuum_naptime` detik per database.
Dengan database 'N', pekerja baru memulai kira-kira setiap [`autovacuum_naptime`/N detik]. Namun, jumlah total pekerja bersamaan dibatasi oleh `autovacuum_max_workers` pengaturan. Jika jumlah database atau tabel yang membutuhkan penyedot debu melebihi batas ini, database atau tabel berikutnya akan diproses segera setelah pekerja tersedia.
Ketika banyak tabel besar atau database memerlukan penyedot debu secara bersamaan, semua pekerja autovacuum yang tersedia dapat menjadi sibuk untuk durasi yang lama, menunda pemeliharaan pada tabel dan database lain. Di lingkungan dengan tingkat transaksi tinggi, kemacetan ini dapat dengan cepat meningkat dan berpotensi menyebabkan masalah vakum sampul dalam instans Amazon RDS Anda.
Ketika `postgres_get_av_diag()` mendeteksi sejumlah besar tabel atau database, ia memberikan rekomendasi berikut:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Bimbingan**
**Tingkatkan autovacuum\$1max\$1workers**
Untuk mempercepat penyedotan debu, kami sarankan untuk menyesuaikan `autovacuum_max_workers` parameter untuk memungkinkan lebih banyak pekerja autovacuum bersamaan. Jika kemacetan kinerja tetap ada, pertimbangkan untuk meningkatkan instans Amazon RDS Anda ke kelas dengan lebih banyak v, yang selanjutnya dapat meningkatkan kemampuan pemrosesan CPUs paralel.
## Vakum agresif (untuk mencegah pembungkus) sedang berjalan
Usia database (MaximumUsedTransactionIDs) di PostgreSQL hanya berkurang ketika vakum agresif (untuk mencegah sampul) berhasil diselesaikan. Sampai kekosongan ini selesai, usia akan terus meningkat tergantung pada tingkat transaksi.
`postgres_get_av_diag()`Fungsi ini menghasilkan yang berikut `NOTICE` ketika mendeteksi vakum yang agresif. Namun, itu hanya memicu output ini setelah vakum telah aktif setidaknya selama dua menit.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Untuk informasi lebih lanjut tentang vakum agresif, lihat [Saat vakum agresif sudah berjalan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Anda dapat memverifikasi apakah vakum agresif sedang berlangsung dengan kueri berikut:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Anda dapat menentukan apakah itu vakum agresif (untuk mencegah sampul) dengan memeriksa kolom kueri di output. Ungkapan “untuk mencegah sampul” menunjukkan bahwa itu adalah kekosongan yang agresif.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Misalnya, Anda memiliki pemblokir pada usia transaksi 1 miliar dan tabel yang membutuhkan vakum agresif untuk mencegah pemblokiran pada usia transaksi yang sama. Selain itu, ada pemblokir lain pada usia transaksi 750 juta. Setelah menyelesaikan pemblokir pada usia transaksi 1 miliar, usia transaksi tidak akan langsung turun menjadi 750 juta. Ini akan tetap tinggi sampai tabel yang membutuhkan vakum agresif atau transaksi apa pun dengan usia di atas 750 juta selesai. Selama periode ini, usia transaksi klaster PostgreSQL Anda akan terus meningkat. Setelah proses vakum selesai, usia transaksi akan turun menjadi 750 juta tetapi akan mulai meningkat lagi hingga penyedotan lebih lanjut selesai. Siklus ini akan berlanjut selama kondisi ini tetap ada, hingga usia transaksi akhirnya turun ke level yang dikonfigurasi untuk instans Amazon RDS Anda, yang ditentukan oleh. `autovacuum_freeze_max_age`
#
`postgres_get_av_diag()`Fungsi ini menyediakan pesan PEMBERITAHUAN berikut:
**Ketika usia belum mencapai ambang pemantauan**
Ambang batas pemantauan `postgres_get_av_diag()` untuk mengidentifikasi pemblokir adalah 500 juta transaksi secara default. Jika `postgres_get_av_diag()` menghasilkan PEMBERITAHUAN berikut, ini menunjukkan bahwa usia transaksi belum mencapai ambang batas ini.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Tidak terhubung ke database dengan usia ID transaksi tertua**
`postgres_get_av_diag()`Fungsi ini memberikan output paling akurat saat terhubung ke database dengan usia ID transaksi tertua. Database dengan usia ID transaksi tertua yang dilaporkan oleh `postgres_get_av_diag()` akan berbeda dari “my\$1database” dalam kasus Anda. Jika Anda tidak terhubung ke database yang benar, PEMBERITAHUAN berikut akan dibuat:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Menghubungkan ke database dengan usia transaksi tertua penting karena alasan berikut:
+ **Mengidentifikasi pemblokir tabel sementara:** Karena metadata untuk tabel sementara khusus untuk setiap database, mereka biasanya ditemukan dalam database tempat mereka dibuat. Namun, jika tabel sementara kebetulan menjadi pemblokir teratas dan berada di database dengan transaksi tertua, ini bisa menyesatkan. Menghubungkan ke database yang benar memastikan identifikasi akurat dari pemblokir tabel sementara.
+ **Mendiagnosis vakum lambat:** Metadata indeks dan informasi jumlah tabel bersifat spesifik basis data dan diperlukan untuk mendiagnosis masalah vakum lambat.
**Database dengan transaksi tertua berdasarkan usia ada pada database rdsadmin atau template0**
Dalam kasus tertentu, `rdsadmin` atau `template0` database dapat diidentifikasi sebagai database dengan usia ID transaksi tertua. Jika ini terjadi, `postgres_get_av_diag()` akan mengeluarkan PEMBERITAHUAN berikut:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Verifikasi bahwa pemblokir yang terdaftar tidak berasal dari salah satu dari dua database ini. Jika pemblokir dilaporkan ada di salah satu `rdsadmin` atau`template0`, hubungi dukungan karena basis data ini tidak dapat diakses pengguna dan memerlukan intervensi.
Sangat tidak mungkin bagi `template0` database `rdsadmin` atau untuk berisi pemblokir teratas.
**Saat vakum agresif sudah berjalan**
`postgres_get_av_diag()`Fungsi ini dirancang untuk melaporkan ketika proses vakum agresif berjalan, tetapi hanya memicu keluaran ini setelah vakum aktif setidaknya selama 1 menit. Penundaan yang disengaja ini membantu mengurangi kemungkinan positif palsu. Dengan menunggu, fungsi memastikan bahwa hanya penyedot debu yang efektif dan signifikan yang dilaporkan, yang mengarah pada pemantauan aktivitas vakum yang lebih akurat dan andal.
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut ketika mendeteksi satu atau lebih vakum agresif yang sedang berlangsung.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Sebagaimana ditunjukkan dalam PEMBERITAHUAN, terus memantau kinerja vakum. Untuk informasi lebih lanjut tentang vakum agresif lihat [Vakum agresif (untuk mencegah pembungkus) sedang berjalan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Saat autovacuum dimatikan**
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut jika autovacuum dinonaktifkan pada instance database Anda:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Autovacuum adalah fitur penting dari RDS Anda untuk PostgreSQL PostgreSQL PostgreSQL DB instance yang memastikan kelancaran operasi database. Ini secara otomatis menghapus versi baris lama, merebut kembali ruang penyimpanan, dan mencegah kembung tabel, membantu menjaga tabel dan indeks tetap efisien untuk kinerja optimal. Selain itu, ini melindungi terhadap sampul ID transaksi, yang dapat menghentikan transaksi di instans Amazon RDS Anda. Menonaktifkan autovacuum dapat menyebabkan penurunan jangka panjang dalam kinerja dan stabilitas database. Kami menyarankan Anda untuk tetap menggunakannya setiap saat.
Mematikan autovacuum tidak menghentikan penyedot debu agresif. Ini masih akan terjadi setelah tabel Anda mencapai `autovacuum_freeze_max_age` ambang batas.
**Jumlah transaksi yang tersisa sangat rendah**
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut ketika vakum sampul sudah dekat. PEMBERITAHUAN ini dikeluarkan ketika instans Amazon RDS Anda berjarak 100 juta transaksi dari kemungkinan menolak transaksi baru.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Tindakan segera Anda diperlukan untuk menghindari downtime database. Anda harus memonitor operasi penyedot debu Anda dan mempertimbangkan secara manual memulai database yang `VACUUM FREEZE` terpengaruh untuk mencegah kegagalan transaksi.
# Mengelola jumlah objek tinggi di Amazon RDS untuk PostgreSQL Amazon Aurora
Sementara keterbatasan PostgreSQL bersifat teoritis, memiliki jumlah objek yang sangat tinggi dalam database akan menyebabkan dampak kinerja yang nyata pada berbagai operasi. Dokumentasi ini mencakup beberapa jenis objek umum yang, ketika memiliki jumlah total yang tinggi dapat menyebabkan beberapa kemungkinan dampak.
Tabel berikut memberikan ringkasan jenis objek dan potensi dampaknya:
**Jenis objek dan dampak potensial**
| Jenis Objek | Autovacuum | Replikasi Logis | Upgrade Versi Utama | pg\$1dump/pg\$1restore | Kinerja Umum | Instans Mulai Ulang |
| --- | --- | --- | --- | --- | --- | --- |
| [Hubungan](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Tabel sementara](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tabel yang tidak tersumbat](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partisi](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [File sementara](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Urutan](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Benda besar](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Hubungan
Tidak ada batasan keras khusus mengenai jumlah tabel dalam database PostgreSQL. Batas teoritis sangat tinggi, tetapi ada batasan praktis lain yang perlu diingat selama desain database.
**Dampak: Autovacuum tertinggal**
Autovacuum dapat berjuang untuk mengikuti pertumbuhan ID transaksi atau kembung meja karena kurangnya pekerja dibandingkan dengan jumlah pekerjaan.
**Tindakan yang disarankan:** Ada beberapa faktor untuk menyetel autovacuum agar sesuai dengan jumlah tabel tertentu dan beban kerja yang diberikan. Lihat [Praktik terbaik untuk bekerja dengan PostgreSQL autovacuum Praktik terbaik untuk bekerja dengan PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) yang sesuai. Gunakan utilitas [postgres\$1get\$1av\$1diag utilitas ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) untuk memantau masalah dengan pertumbuhan ID transaksi.
**Dampak: Peningkatan versi utama/pg\$1dump dan pulihkan**
Amazon RDS menggunakan opsi “--link” selama eksekusi pg\$1upgrade untuk menghindari keharusan membuat salinan file data, metadata skema masih diperlukan untuk dikembalikan ke versi baru database. Bahkan dengan parallel pg\$1restore, jika ada sejumlah besar hubungan ini akan meningkatkan jumlah downtime.
**Dampak: Degradasi kinerja umum**
Degradasi kinerja umum karena ukuran katalog. Setiap tabel dan kolom terkait akan menambah`pg_attribute`, `pg_class` dan `pg_depend` tabel yang sering digunakan dalam operasi database normal. Tidak akan ada acara tunggu tertentu yang terlihat, tetapi efisiensi buffer bersama akan terpengaruh.
**Tindakan yang disarankan:** Periksa tabel kembung secara teratur untuk tabel spesifik ini dan sesekali lakukan a `VACUUM FULL` pada tabel tertentu ini. Ketahuilah bahwa `VACUUM FULL` pada tabel katalog memerlukan `ACCESS EXCLUSIVE` kunci yang berarti tidak ada kueri lain yang dapat mengaksesnya sampai operasi selesai.
**Dampak: Kelelahan deskriptor file**
Kesalahan: “keluar dari deskriptor file: Terlalu banyak file terbuka di sistem; lepaskan dan coba lagi”. `max_files_per_process`Parameter PostgreSQL menentukan berapa banyak file yang dapat dibuka setiap proses. Jika ada sejumlah besar koneksi yang bergabung dengan sejumlah besar tabel, dimungkinkan untuk mencapai batas ini.
**Tindakan yang disarankan:**
+ Menurunkan nilai parameter `max_files_per_process` dapat membantu meringankan kesalahan ini. Setiap proses dan subproses (misalnya, query paralel) dapat membuka jumlah file ini, dan jika kueri bergabung dengan beberapa tabel, batas ini dapat habis.
+ Kurangi jumlah keseluruhan koneksi dan gunakan kumpulan koneksi seperti Amazon RDS [Proxy ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) atau solusi lain seperti. PgBouncer Untuk mempelajari lebih lanjut, lihat situs [PgBouncer web](https://www.pgbouncer.org/).
**Dampak: Kelelahan Inode**
Kesalahan: “Tidak ada ruang tersisa di perangkat”. Jika ini diamati ketika ada banyak ruang kosong penyimpanan, ini disebabkan oleh kehabisan inode. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) memberikan visibilitas untuk inode yang digunakan dan jumlah maksimum yang tersedia untuk host Anda.
**Ambang batas perkiraan:** [Jutaan](#PostgreSQL.HighObjectCount.Note)
## Tabel sementara
Menggunakan tabel sementara berguna untuk data uji atau hasil antara dan merupakan pola umum yang terlihat di banyak mesin database. Implikasi penggunaan berat di PostgreSQL harus dipahami untuk menghindari beberapa jebakan. Setiap tabel sementara yang dibuat dan dijatuhkan akan menambahkan baris ke tabel katalog sistem, yang ketika menjadi kembung, akan menyebabkan masalah kinerja umum.
**Dampak: Autovacuum tertinggal**
Tabel sementara tidak disedot oleh autovacuum tetapi akan mempertahankan transaksi IDs selama keberadaannya dan dapat menyebabkan sampul jika tidak dihapus.
**Tindakan yang disarankan:** Tabel sementara akan hidup selama sesi yang membuatnya atau dapat dijatuhkan secara manual. Praktik terbaik untuk menghindari transaksi jangka panjang dengan tabel sementara akan mencegah tabel ini berkontribusi pada pertumbuhan ID transaksi maksimum yang digunakan.
**Dampak: Degradasi kinerja umum**
Degradasi kinerja umum karena ukuran katalog. Ketika sesi terus membuat dan menjatuhkan tabel sementara, itu akan menambah`pg_attribute`, `pg_class` dan `pg_depend` tabel yang sering digunakan dalam operasi database normal. Tidak akan ada acara tunggu tertentu yang terlihat, tetapi efisiensi buffer bersama akan terpengaruh.
**Tindakan yang disarankan:**
+ Periksa tabel kembung secara teratur untuk tabel khusus ini dan sesekali lakukan `VACUUM FULL` pada tabel tertentu ini. Ketahuilah bahwa `VACUUM FULL` pada tabel katalog memerlukan `ACCESS EXCLUSIVE` kunci yang berarti tidak ada kueri lain yang dapat mengaksesnya sampai operasi selesai.
+ Jika tabel sementara banyak digunakan, sebelum peningkatan versi utama, tabel katalog khusus ini sangat disarankan untuk mengurangi waktu henti. `VACUUM FULL`
**Praktik terbaik umum:**
+ Kurangi penggunaan tabel sementara dengan menggunakan ekspresi tabel umum untuk menghasilkan hasil antara. Ini kadang-kadang dapat mempersulit pertanyaan yang diperlukan, tetapi akan menghilangkan dampak yang tercantum di atas.
+ Gunakan kembali tabel sementara dengan menggunakan `TRUNCATE` perintah untuk menghapus konten alih-alih melakukan drop/create langkah-langkah. Ini juga akan menghilangkan masalah pertumbuhan ID transaksi yang disebabkan oleh tabel sementara.
**Ambang perkiraan:** [Puluhan ribu](#PostgreSQL.HighObjectCount.Note)
## Tabel yang tidak tersumbat
Tabel yang tidak tercatat dapat menawarkan peningkatan kinerja karena tidak akan menghasilkan informasi WAL apa pun. Mereka harus digunakan dengan hati-hati karena mereka tidak menawarkan daya tahan selama pemulihan kerusakan database karena mereka akan terpotong. Ini adalah operasi yang mahal di PostgreSQL karena setiap tabel yang tidak tersumbat dipotong secara serial. Meskipun operasi ini cepat untuk sejumlah kecil tabel yang tidak tercatat, ketika jumlahnya ribuan, itu dapat mulai menambahkan penundaan penting selama startup.
**Dampak: Replikasi logis**
Tabel yang tidak tercatat umumnya tidak termasuk dalam replikasi logis, termasuk Penerapan [Biru/Hijau Penerapan Biru/Hijau](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) .
**Dampak: Waktu henti yang diperpanjang selama pemulihan**
Selama status database apa pun yang melibatkan pemulihan kerusakan basis data seperti reboot Multi-AZ dengan failover, point-in-time pemulihan Amazon RDS, dan peningkatan versi utama Amazon RDS, operasi serial pemotongan tabel yang tidak tercatat akan terjadi. Hal ini dapat menyebabkan pengalaman downtime yang jauh lebih tinggi dari yang diharapkan.
**Tindakan yang disarankan:**
+ Minimalkan penggunaan tabel yang tidak tercatat hanya untuk data yang dapat diterima untuk hilang selama operasi pemulihan kerusakan database.
+ Minimalkan penggunaan tabel yang tidak tercatat karena perilaku pemotongan serial saat ini dapat menyebabkan startup database memakan banyak waktu.
**Praktik terbaik umum:**
+ Tabel yang tidak tersumbat tidak aman untuk crash. Memulai point-in-time pemulihan, yang melibatkan pemulihan crash, membutuhkan waktu yang signifikan di PostgreSQL karena ini adalah proses serial yang memotong setiap tabel.
**Ambang perkiraan:** [Ribuan](#PostgreSQL.HighObjectCount.Note)
## Partisi
Partisi dapat meningkatkan kinerja kueri dan menyediakan organisasi data yang logis. Dalam skenario ideal, partisi diatur sehingga pemangkasan partisi dapat digunakan selama perencanaan dan pelaksanaan kueri. Menggunakan terlalu banyak partisi dapat berdampak negatif pada kinerja kueri dan pemeliharaan basis data. Pilihan cara mempartisi tabel harus dibuat dengan hati-hati, karena kinerja perencanaan dan pelaksanaan kueri dapat dipengaruhi secara negatif oleh desain yang buruk. Lihat dokumentasi [PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) untuk detail tentang partisi.
**Dampak: Degradasi kinerja umum**
Terkadang perencanaan overhead waktu akan meningkat dan menjelaskan rencana untuk pertanyaan Anda akan menjadi lebih rumit, sehingga sulit untuk mengidentifikasi peluang penyetelan. Untuk versi PostgreSQL lebih awal dari 18, banyak partisi dengan beban kerja tinggi dapat menyebabkan menunggu. `LWLock:LockManager`
**Tindakan yang disarankan:** Tentukan jumlah minimum partisi yang akan memungkinkan Anda untuk menyelesaikan kedua organisasi data Anda sementara pada saat yang sama menyediakan eksekusi kueri kinerja.
**Dampak: Kompleksitas pemeliharaan**
Jumlah partisi yang sangat tinggi akan menimbulkan kesulitan pemeliharaan seperti pra-pembuatan dan penghapusan. Autovacuum akan memperlakukan partisi sebagai hubungan normal dan harus melakukan pembersihan rutin, oleh karena itu membutuhkan cukup banyak pekerja untuk menyelesaikan tugas.
**Tindakan yang disarankan:**
+ Pastikan Anda membuat partisi sehingga beban kerja tidak diblokir saat partisi baru diperlukan (misalnya, partisi berbasis bulanan) dan partisi lama diluncurkan.
+ Pastikan Anda memiliki cukup pekerja autovacuum untuk melakukan pemeliharaan pembersihan normal semua partisi.
**Ambang perkiraan:** [Ratusan](#PostgreSQL.HighObjectCount.Note)
## File sementara
Berbeda dari tabel sementara yang disebutkan di atas, file sementara dibuat oleh PostgreSQL ketika kueri kompleks mungkin melakukan beberapa operasi pengurutan atau hash pada saat yang sama, dengan setiap operasi menggunakan memori instance untuk menyimpan hasil hingga nilai yang ditentukan dalam parameter. `work_mem` Jika memori instans tidak cukup, file sementara akan dibuat untuk menyimpan hasil. Lihat [Mengelola file sementara](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) untuk detail selengkapnya tentang file sementara. Jika beban kerja Anda menghasilkan sejumlah besar file-file ini, mungkin ada beberapa dampak.
**Dampak: Kelelahan deskriptor file**
Kesalahan: “keluar dari deskriptor file: Terlalu banyak file terbuka di sistem; lepaskan dan coba lagi”. `max_files_per_process`Parameter PostgreSQL menentukan berapa banyak file yang dapat dibuka setiap proses. Jika ada sejumlah besar koneksi yang bergabung dengan sejumlah besar tabel, dimungkinkan untuk mencapai batas ini.
**Tindakan yang disarankan:**
+ Menurunkan nilai parameter `max_files_per_process` dapat membantu meringankan kesalahan ini. Setiap proses dan subproses (misalnya, query paralel) dapat membuka jumlah file ini, dan jika kueri bergabung dengan beberapa tabel, batas ini dapat habis.
+ Kurangi jumlah keseluruhan koneksi dan gunakan kumpulan koneksi seperti [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) atau solusi lain seperti. PgBouncer Untuk mempelajari lebih lanjut, lihat situs [PgBouncer web](https://www.pgbouncer.org/).
**Dampak: Kelelahan Inode**
Kesalahan: “Tidak ada ruang tersisa di perangkat”. Jika ini diamati ketika ada banyak ruang kosong penyimpanan, ini disebabkan oleh kehabisan inode. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) menyediakan visibilitas untuk inode yang digunakan dan jumlah maksimum yang tersedia untuk host Anda.
**Praktik terbaik umum:**
+ Pantau penggunaan file temp Anda dengan [Performance Insights Performance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) .
+ Sesuaikan kueri yang menghasilkan file sementara yang signifikan untuk melihat apakah mungkin untuk mengurangi jumlah total file temp.
**Ambang perkiraan:** [Ribuan](#PostgreSQL.HighObjectCount.Note)
## Urutan
Urutan adalah objek yang mendasari yang digunakan untuk penambahan kolom otomatis di PostgreSQL dan mereka memberikan keunikan dan kunci untuk data. Ini dapat digunakan pada tabel individu tanpa konsekuensi selama operasi normal dengan satu pengecualian replikasi logis.
Di PostgreSQL, replikasi logis saat ini tidak mereplikasi nilai urutan saat ini ke pelanggan mana pun. Untuk mempelajari selengkapnya, lihat [halaman Pembatasan dalam dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Dampak: Waktu peralihan yang diperpanjang**
Jika Anda berencana untuk menggunakan [Amazon RDS Blue/Green Deployment](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) untuk semua jenis perubahan konfigurasi atau upgrade, penting untuk memahami dampak dari sejumlah besar urutan pada switchover. Salah satu fase terakhir dari peralihan akan menyinkronkan nilai urutan saat ini, dan jika ada beberapa ribu, ini akan meningkatkan waktu peralihan keseluruhan.
**Tindakan yang disarankan:** Jika beban kerja database Anda memungkinkan penggunaan UUID bersama alih-alih sequence-per-table pendekatan, ini akan mengurangi langkah sinkronisasi selama peralihan.
**Ambang perkiraan:** [Ribuan](#PostgreSQL.HighObjectCount.Note)
## Benda besar
Objek besar disimpan dalam tabel sistem tunggal bernama pg\$1largeobject. Setiap objek besar juga memiliki entri dalam tabel sistem pg\$1largeobject\$1metadata. Objek-objek ini dibuat, dimodifikasi dan dibersihkan jauh berbeda dari hubungan standar. Benda besar tidak ditangani oleh autovacuum dan harus dibersihkan secara berkala melalui proses terpisah yang disebut vacuumlo. Lihat mengelola objek besar dengan modul lo untuk contoh mengelola objek besar.
**Dampak: Replikasi logis**
Objek besar saat ini tidak direplikasi di PostgreSQL selama replikasi logis. Untuk mempelajari selengkapnya, lihat [halaman Pembatasan dalam dokumentasi PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). Dalam konfigurasi [Biru/Hijau](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) , ini berarti objek besar di lingkungan biru tidak direplikasi ke lingkungan hijau.
**Dampak: Peningkatan versi utama**
Upgrade dapat kehabisan memori dan gagal jika ada jutaan objek besar dan instance tidak dapat menanganinya selama peningkatan. Proses upgrade versi utama PostgreSQL terdiri dari dua fase luas: membuang skema melalui pg\$1dump dan memulihkannya melalui pg\$1restore. Jika database Anda memiliki jutaan objek besar, Anda perlu memastikan instance Anda memiliki memori yang cukup untuk menangani pg\$1dump dan pg\$1restore selama peningkatan dan menskalakannya ke jenis instance yang lebih besar.
**Praktik terbaik umum:**
+ Gunakan utilitas vacuumlo secara teratur untuk menghapus benda besar yatim piatu yang mungkin Anda miliki.
+ Pertimbangkan untuk menggunakan tipe data BYTEA untuk menyimpan objek besar Anda dalam database.
**Ambang batas perkiraan:** [Jutaan](#PostgreSQL.HighObjectCount.Note)
## Perkiraan ambang batas
Ambang batas perkiraan yang disebutkan dalam topik ini hanya digunakan untuk memberikan perkiraan seberapa jauh skala sumber daya tertentu. Mereka mewakili rentang umum di mana dampak yang dijelaskan menjadi lebih mungkin, tetapi perilaku aktual tergantung pada beban kerja, ukuran instance, dan konfigurasi spesifik Anda. Meskipun dimungkinkan untuk melampaui perkiraan ini, perawatan dan pemeliharaan harus dipatuhi untuk menghindari dampak yang tercantum.
#
TOAST (The Oversized-Attribute Storage Technique) adalah fitur PostgreSQL yang dirancang untuk menangani nilai data besar yang melebihi ukuran blok database 8KB yang khas. PostgreSQL tidak mengizinkan baris fisik menjangkau beberapa blok. Ukuran blok bertindak sebagai batas atas pada ukuran baris. TOAST mengatasi batasan ini dengan membagi nilai bidang besar menjadi potongan yang lebih kecil. Ini menyimpannya secara terpisah dalam tabel TOAST khusus yang terhubung ke tabel utama. Untuk informasi selengkapnya, lihat mekanisme penyimpanan [PostgreSQL TOAST](https://www.postgresql.org/docs/current/storage-toast.html) dan dokumentasi implementasi.
**Topics**
+ [
## Memahami operasi TOAST
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [
## Mengidentifikasi tantangan kinerja
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [
## Rekomendasi
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [
## Memantau
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Memahami operasi TOAST
TOAST melakukan kompresi dan menyimpan nilai bidang besar di luar jalur. TOAST memberikan OID unik (Object Identifier) untuk setiap potongan data besar yang disimpan dalam tabel TOAST. Tabel utama menyimpan ID nilai TOAST dan ID relasi pada halaman untuk mereferensikan baris yang sesuai dalam tabel TOAST. Hal ini memungkinkan PostgreSQL untuk secara efisien menemukan dan mengelola potongan TOAST ini. Namun, seiring bertambahnya tabel TOAST, sistem berisiko melelahkan tersedia OIDs, yang menyebabkan penurunan kinerja dan potensi waktu henti karena penipisan OID.
### Pengidentifikasi objek di TOAST
Object Identifier (OID) adalah pengidentifikasi unik seluruh sistem yang digunakan oleh PostgreSQL untuk referensi objek database seperti tabel, indeks, dan fungsi. Pengidentifikasi ini memainkan peran penting dalam operasi internal PostgreSQL, memungkinkan database untuk secara efisien menemukan dan mengelola objek.
Untuk tabel dengan kumpulan data yang memenuhi syarat untuk pemanggangan, PostgreSQL OIDs menetapkan untuk mengidentifikasi secara unik setiap potongan data berukuran besar yang disimpan dalam tabel TOAST terkait. Sistem mengaitkan setiap potongan dengan a`chunk_id`, yang membantu PostgreSQL mengatur dan menemukan potongan ini secara efisien dalam tabel TOAST.
## Mengidentifikasi tantangan kinerja
Manajemen OID PostgreSQL bergantung pada penghitung 32-bit global sehingga membungkus setelah menghasilkan 4 miliar nilai unik. Sementara cluster database berbagi penghitung ini, alokasi OID melibatkan dua langkah selama operasi TOAST:
+ **Penghitung global untuk alokasi** - Penghitung global memberikan OID baru di seluruh cluster.
+ **Pencarian lokal untuk konflik** - Tabel TOAST memastikan OID baru tidak bertentangan dengan yang OIDs sudah ada yang sudah digunakan dalam tabel tertentu.
Degradasi kinerja dapat terjadi ketika:
+ Tabel TOAST memiliki fragmentasi tinggi atau penggunaan OID padat, yang menyebabkan keterlambatan dalam menetapkan OID.
+ Sistem sering mengalokasikan dan menggunakan kembali OIDs di lingkungan dengan churn data tinggi atau tabel lebar yang menggunakan TOAST secara ekstensif.
Untuk informasi selengkapnya, lihat batas ukuran [tabel PostgreSQL TOAST](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit) dan dokumentasi alokasi OID:
Penghitung global menghasilkan OIDs dan membungkus sekitar setiap 4 miliar nilai, sehingga dari waktu ke waktu, sistem menghasilkan nilai yang sudah digunakan lagi. PostgreSQL mendeteksi itu dan mencoba lagi dengan OID berikutnya. INSERT yang lambat dapat terjadi jika ada nilai OID bekas yang sangat lama tanpa celah di tabel TOAST. Tantangan ini menjadi lebih terasa saat ruang OID terisi, yang mengarah ke penyisipan dan pembaruan yang lebih lambat.
### Mengidentifikasi masalah
+ `INSERT`Pernyataan sederhana membutuhkan waktu lebih lama dari biasanya dengan cara yang tidak konsisten dan acak.
+ Penundaan hanya terjadi untuk `INSERT` dan `UPDATE` pernyataan yang melibatkan operasi TOAST.
+ Entri log berikut muncul di log PostgreSQL ketika sistem berjuang untuk menemukan tersedia di tabel TOAST: OIDs
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights menunjukkan tingginya jumlah sesi aktif rata-rata (AAS) yang terkait dengan `LWLock:buffer_io` dan acara `LWLock:OidGenLock` tunggu.
Anda dapat menjalankan kueri SQL berikut untuk mengidentifikasi transaksi INSERT yang berjalan lama dengan peristiwa tunggu:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Contoh hasil kueri yang menampilkan operasi INSERT dengan waktu tunggu yang diperpanjang:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Mengisolasi masalah
+ **Uji sisipan kecil** — Masukkan catatan yang lebih kecil dari `toast_tuple_target` ambang batas. Ingat bahwa kompresi diterapkan sebelum penyimpanan TOAST. Jika ini beroperasi tanpa masalah kinerja, masalahnya terkait dengan operasi TOAST.
+ **Uji tabel baru** - Buat tabel baru dengan struktur yang sama dan masukkan catatan yang lebih besar dari`toast_tuple_target`. Jika ini berfungsi tanpa masalah, masalah dilokalkan ke alokasi OID tabel asli.
## Rekomendasi
Pendekatan berikut dapat membantu menyelesaikan masalah pertentangan TOAST OID.
+ **Pembersihan dan arsip data** - Tinjau dan hapus data usang atau tidak perlu untuk dikosongkan untuk penggunaan di OIDs masa mendatang, atau mengarsipkan data. Pertimbangkan batasan berikut:
+ Skalabilitas terbatas, karena pembersihan di masa depan mungkin tidak selalu memungkinkan.
+ Kemungkinan operasi VACUUM yang berjalan lama untuk menghilangkan tupel mati yang dihasilkan.
+ **Menulis ke tabel baru** - Buat tabel baru untuk sisipan future dan gunakan `UNION ALL` tampilan untuk menggabungkan data lama dan baru untuk kueri. Tampilan ini menyajikan data gabungan dari tabel lama dan baru, yang memungkinkan kueri untuk mengaksesnya sebagai satu tabel. Pertimbangkan batasan berikut:
+ Pembaruan pada tabel lama mungkin masih menyebabkan kelelahan OID.
+ **Partisi atau Shard** - Partisi data tabel atau pecahan untuk skalabilitas dan kinerja yang lebih baik. Pertimbangkan batasan berikut:
+ Peningkatan kompleksitas dalam logika kueri dan pemeliharaan, potensi kebutuhan untuk perubahan aplikasi untuk menangani data yang dipartisi dengan benar.
## Memantau
### Menggunakan tabel sistem
Anda dapat menggunakan tabel sistem PostgreSQL untuk memantau pertumbuhan penggunaan OID.
**Awas**
Tergantung pada jumlah OIDs dalam tabel TOAST, mungkin perlu waktu untuk menyelesaikannya. Kami menyarankan Anda menjadwalkan pemantauan selama jam kerja untuk meminimalkan dampak.
Blok anonim berikut menghitung jumlah berbeda yang OIDs digunakan di setiap tabel TOAST dan menampilkan informasi tabel induk:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Contoh output yang menampilkan statistik penggunaan OID dengan tabel TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
Blok anonim berikut mengambil OID maksimum yang ditetapkan untuk setiap tabel TOAST yang tidak kosong:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Contoh output menampilkan potongan maksimum IDs untuk tabel TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Menggunakan Performance Insights
Peristiwa tunggu `LWLock:buffer_io` dan `LWLock:OidGenLock` muncul di Performance Insights selama operasi yang memerlukan penetapan Object Identifiers () baru. OIDs Sesi Aktif Rata-Rata Tinggi (AAS) untuk acara ini biasanya menunjukkan pertengkaran selama penugasan OID dan manajemen sumber daya. Ini sangat umum di lingkungan dengan churn data tinggi, penggunaan data besar yang ekstensif, atau pembuatan objek yang sering.
#### LWLock:buffer\$1io
`LWLock:buffer_io`adalah acara tunggu yang terjadi ketika sesi PostgreSQL I/O menunggu operasi pada buffer bersama selesai. Ini biasanya terjadi ketika database membaca data dari disk ke memori atau menulis halaman yang dimodifikasi dari memori ke disk. Peristiwa `BufferIO` tunggu memastikan konsistensi dengan mencegah beberapa proses mengakses atau memodifikasi buffer yang sama saat I/O operasi sedang berlangsung. Kejadian tinggi dari peristiwa tunggu ini dapat mengindikasikan kemacetan disk atau I/O aktivitas berlebihan dalam beban kerja database.
Selama operasi TOAST:
+ PostgreSQL OIDs mengalokasikan untuk objek besar dan memastikan keunikannya dengan memindai indeks tabel TOAST.
+ Indeks TOAST yang besar mungkin memerlukan akses beberapa halaman untuk memverifikasi keunikan OID. Ini menghasilkan peningkatan I/O disk, terutama ketika kumpulan buffer tidak dapat menyimpan semua halaman yang diperlukan.
Ukuran indeks secara langsung mempengaruhi jumlah halaman buffer yang perlu diakses selama operasi ini. Bahkan jika indeks tidak membengkak, ukurannya yang tipis dapat meningkatkan buffer I/O, terutama di lingkungan dengan konkurensi tinggi atau churn tinggi. [Untuk informasi lebih lanjut, lihat:Bufferio LWLock wait event troubleshooting guide.](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html)
#### LWLock:OidGenLock
`OidGenLock`adalah peristiwa tunggu yang terjadi ketika sesi PostgreSQL sedang menunggu untuk mengalokasikan pengenal objek baru (OID). Kunci ini memastikan bahwa OIDs dihasilkan secara berurutan dan aman, memungkinkan hanya satu proses untuk menghasilkan OIDs pada satu waktu.
Selama operasi TOAST:
+ **Alokasi OID untuk potongan dalam tabel TOAST -** PostgreSQL menetapkan potongan dalam tabel OIDs TOAST saat mengelola catatan data besar. Setiap OID harus unik untuk mencegah konflik dalam katalog sistem.
+ **Konkurensi tinggi** — Karena akses ke generator OID berurutan, ketika beberapa sesi secara bersamaan membuat objek yang membutuhkan OIDs, pertengkaran dapat terjadi. `OidGenLock` Ini meningkatkan kemungkinan sesi menunggu alokasi OID selesai.
+ **Ketergantungan pada akses katalog sistem** — Mengalokasikan OIDs memerlukan pembaruan ke tabel katalog sistem bersama seperti dan. `pg_class` `pg_type` Jika tabel ini mengalami aktivitas berat (karena operasi DDL yang sering), itu dapat meningkatkan pertentangan kunci untuk. `OidGenLock`
+ **Permintaan alokasi OID yang tinggi** - TOAST beban kerja yang berat dengan catatan data yang besar memerlukan alokasi OID yang konstan, meningkatkan perselisihan.
Faktor tambahan yang meningkatkan pertentangan OID:
+ **Pembuatan objek yang sering** - Beban kerja yang sering membuat dan menjatuhkan objek, seperti tabel sementara, memperkuat pertentangan pada penghitung OID global.
+ **Penguncian penghitung global** - Penghitung OID global diakses secara serial untuk memastikan keunikan, menciptakan satu titik pertikaian di lingkungan konkurensi tinggi.
## Bekerja dengan mekanisme pencatatan log yang didukung oleh RDS for PostgreSQL
Ada beberapa parameter, ekstensi, dan item lain yang dapat dikonfigurasi dan Anda atur untuk mencatat aktivitas yang terjadi di instans DB PostgreSQL. Sumber daya yang dimaksud meliputi:
+ Parameter `log_statement` dapat digunakan untuk mencatat aktivitas pengguna di basis data PostgreSQL. Untuk mempelajari pencatatan log RDS for PostgreSQL dan cara memantau log selengkapnya, lihat [](USER_LogAccess.Concepts.PostgreSQL.md).
+ Parameter `rds.force_admin_logging_level` mencatat tindakan yang dilakukan oleh pengguna internal Amazon RDS (rdsadmin) di basis data instans DB. Parameter ini akan menulis output ke kesalahan log PostgreSQL. Nilai yang diizinkan adalah `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, log, `fatal`, dan `panic`. Nilai default-nya adalah `disabled`.
+ Parameter `rds.force_autovacuum_logging_level` dapat diatur untuk mengambil berbagai operasi autovacuum di log kesalahan PostgreSQL. Untuk informasi selengkapnya, lihat [Melakukan log aktivitas autovacuum dan vakum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ Ekstensi PostgreSQL Audit (pgAaudit) dapat diinstal dan dikonfigurasi untuk mengambil aktivitas di tingkat sesi atau di tingkat objek. Untuk informasi selengkapnya, lihat [Menggunakan pgAudit untuk mencatat aktivitas database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ Dengan ekstensi `log_fdw`, Anda dapat mengakses log mesin basis data menggunakan SQL. Untuk informasi selengkapnya, lihat [Menggunakan ekstensi log\$1fdw untuk mengakses log DB dengan SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ Pustaka `pg_stat_statements` ditentukan sebagai default untuk parameter `shared_preload_libraries` dalam RDS for PostgreSQL versi 10 dan yang lebih baru. Pustaka inilah yang dapat Anda gunakan untuk menganalisis kueri yang sedang berjalan. Pastikan `pg_stat_statements` diatur dalam grup parameter DB Anda. Untuk informasi cara memantau instans DB RDS for PostgreSQL menggunakan informasi yang disediakan pustaka ini selengkapnya, lihat [Statistik SQL untuk RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ Parameter `log_hostname` mengambil log nama host dari setiap koneksi klien. Untuk RDS for PostgreSQL versi 12 dan versi yang lebih baru, parameter ini diatur ke `off` secara default. Jika diaktifkan, pastikan Anda memantau waktu koneksi sesi. Ketika diaktifkan, layanan menggunakan permintaan pencarian terbalik sistem nama domain (DNS) untuk mendapatkan nama host klien yang membuat koneksi dan menambahkannya ke log PostgreSQL. Hal ini memberikan dampak nyata selama koneksi sesi. Sebaiknya mengaktifkan parameter ini hanya untuk memecahkan masalah.
Secara umum, tujuan pencatatan log adalah agar DBA dapat memantau, menyesuaikan performa, dan memecahkan masalah. Banyak log diunggah secara otomatis ke Amazon CloudWatch atau Performance Insights. Di sini, log diurutkan dan dikelompokkan agar dapat memberikan metrik lengkap untuk instans DB Anda. Untuk mempelajari pemantauan dan metrik Amazon RDS selengkapnya, lihat [Memantau metrik dalam instans Amazon RDS](CHAP_Monitoring.md).
# Mengelola file sementara dengan PostgreSQL
Di PostgreSQL, kueri kompleks mungkin melakukan beberapa operasi pengurutan atau hash pada saat yang sama, dengan setiap operasi menggunakan memori instance untuk menyimpan hasil hingga nilai yang ditentukan dalam parameter. [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) Jika memori instans tidak cukup, file sementara akan dibuat untuk menyimpan hasil. Hasil ini ditulis ke disk untuk menyelesaikan eksekusi kueri. Kemudian, file-file ini secara otomatis dihapus setelah kueri selesai. Dalam RDS for PostgreSQL, file ini disimpan di Amazon EBS pada volume data. Untuk informasi selengkapnya, lihat [Penyimpanan instans DB Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Anda dapat memantau `FreeStorageSpace` metrik yang diterbitkan CloudWatch untuk memastikan bahwa instans DB Anda memiliki ruang penyimpanan gratis yang cukup. Untuk informasi selengkapnya, lihat [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).
Sebaiknya gunakan Amazon RDS Optimized Read cluster untuk beban kerja yang melibatkan beberapa kueri bersamaan yang meningkatkan penggunaan file sementara. instance ini menggunakan penyimpanan tingkat blok solid state drive (SSDNVMe) berbasis Non-Volatile Memory Express () lokal untuk menempatkan file sementara. Untuk informasi selengkapnya, lihat [Meningkatkan performa kueri untuk RDS for PostgreSQL dengan Amazon RDS Optimized Reads](USER_PostgreSQL.optimizedreads.md).
Anda dapat menggunakan parameter dan fungsi berikut untuk mengelola file sementara dalam instans Anda.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – Parameter ini membatalkan kueri apa pun yang melebihi ukuran temp\$1files dalam KB. Batas ini mencegah kueri apa pun berjalan tanpa henti dan menghabiskan ruang disk dengan file sementara. Anda dapat memperkirakan nilai menggunakan hasil dari parameter `log_temp_files`. Sebagai praktik terbaik, periksa perilaku beban kerja dan tetapkan batas sesuai dengan estimasi. Contoh berikut menunjukkan bagaimana kueri dibatalkan saat melampaui batas.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – Parameter ini mengirimkan pesan ke postgresql.log ketika file sementara dari sebuah sesi dihapus. Parameter ini menghasilkan log setelah kueri berhasil diselesaikan. Oleh karena itu, ini mungkin tidak membantu dalam memecahkan masalah kueri yang aktif dan berjalan lama.
Contoh berikut menunjukkan bahwa ketika kueri berhasil diselesaikan, entri dicatat dalam file postgresql.log, sedangkan file sementara dibersihkan.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – Fungsi yang tersedia dari RDS untuk PostgreSQL 13 dan versi yang lebih baru ini memberikan visibilitas terhadap penggunaan file sementara saat ini. Kueri yang sudah selesai tidak muncul di hasil fungsi. Dalam contoh berikut, Anda dapat melihat hasil dari fungsi ini.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
Nama file mencakup ID pemrosesan (PID) dari sesi yang menghasilkan file sementara. Kueri yang lebih maju, seperti pada contoh berikut, melakukan penjumlahan file sementara untuk setiap PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – Jika Anda mengaktifkan parameter pg\$1stat\$1statements, Anda dapat melihat rata-rata penggunaan file sementara per panggilan. Anda dapat mengidentifikasi query\$1id dari kueri dan menggunakannya untuk memeriksa penggunaan file sementara seperti yang ditunjukkan pada contoh berikut.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** – Di dasbor Wawasan Performa, Anda dapat melihat penggunaan file sementara dengan mengaktifkan metrik **temp\$1bytes** dan **temp\$1files**. Kemudian, Anda dapat melihat rata-rata kedua metrik ini dan melihat sejauh mana kesesuaiannya dengan beban kerja kueri. Tampilan dalam Wawasan Performa tidak secara khusus menampilkan kueri yang menghasilkan file sementara. Namun, jika Anda menggabungkan Wawasan Performa dengan kueri yang ditampilkan untuk `pg_ls_tmpdir`, Anda dapat memecahkan masalah, menganalisis, dan menentukan perubahan dalam beban kerja kueri.
Untuk informasi selengkapnya tentang cara menganalisis metrik dan kueri dengan Performance Insights, lihat. [Menganalisis metrik dengan dasbor Wawasan Performa](USER_PerfInsights.UsingDashboard.md)
Untuk contoh melihat penggunaan file sementara dengan Performance Insights, lihat [Melihat penggunaan file sementara dengan Performance Insights](PostgreSQL.ManagingTempFiles.Example.md)
# Melihat penggunaan file sementara dengan Performance Insights
**Anda dapat menggunakan Performance Insights untuk melihat penggunaan file sementara dengan mengaktifkan metrik **temp\$1bytes dan temp\$1files**.** Tampilan di Performance Insights tidak menampilkan kueri spesifik yang menghasilkan file sementara, namun jika Anda menggabungkan Performance Insights dengan kueri yang ditampilkan`pg_ls_tmpdir`, Anda dapat memecahkan masalah, menganalisis, dan menentukan perubahan dalam beban kerja kueri.
1. Di dasbor Wawasan Performa, pilih **Kelola Metrik**.
1. Pilih **Metrik basis data**, lalu pilih metrik **temp\$1bytes** dan **temp\$1files** seperti yang ditunjukkan pada gambar berikut.
![\[Metrik ditampilkan dalam grafik.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Di tab **SQL Teratas**, pilih ikon **Preferensi**.
1. Di jendela **Preferensi**, aktifkan statistik berikut agar muncul di tab **SQL Teratas** dan pilih **Lanjutkan**.
+ Temp writes/detik
+ Temp reads/detik
+ Tmp blk write/panggilan
+ Tmp blk read/panggilan
1. File sementara rusak saat digabungkan kueri yang ditampilkan untuk `pg_ls_tmpdir`, seperti yang ditunjukkan pada contoh berikut.
![\[Kueri yang menampilkan penggunaan file sementara.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Peristiwa `IO:BufFileRead` dan `IO:BufFileWrite` terjadi ketika kueri teratas di beban kerja Anda sering membuat file sementara. Anda dapat menggunakan Wawasan Performa untuk mengidentifikasi kueri teratas yang menunggu pada `IO:BufFileRead` dan `IO:BufFileWrite` dengan meninjau Sesi Aktif Rata-rata (AAS) di bagian Muatan Basis Data dan SQL Teratas.
![\[IO: BufFileRead dan IO: BufFileWrite dalam grafik.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Untuk informasi selengkapnya tentang cara menganalisis kueri teratas dan muatan berdasarkan peristiwa tunggu dengan Wawasan Performa, lihat [Ikhtisar SQL tab Top](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Anda harus mengidentifikasi dan menyetel kueri yang menyebabkan peningkatan penggunaan file sementara dan peristiwa tunggu terkait. Untuk informasi lebih lanjut tentang peristiwa tunggu dan remediasi ini, lihat [IO: BufFileRead dan IO: BufFileWrite IO](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html).
**catatan**
Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) mengontrol ketika operasi pengurutan kehabisan memori dan hasilnya ditulis ke dalam file sementara. Sebaiknya Anda tidak mengubah pengaturan parameter ini lebih tinggi dari nilai default karena akan memungkinkan setiap sesi basis data mengonsumsi lebih banyak memori. Selain itu, satu sesi yang melakukan penggabungan dan pengurutan kompleks dapat melakukan operasi paralel di mana setiap operasi mengonsumsi memori.
Sebagai praktik terbaik, ketika Anda memiliki laporan besar dengan beberapa penggabungan dan pengurutan, atur parameter ini pada tingkat sesi dengan menggunakan perintah `SET work_mem`. Kemudian, perubahan hanya diterapkan pada sesi saat ini dan tidak mengubah nilai secara global.
## Menggunakan pgBadger untuk analisis log dengan PostgreSQL
Anda dapat menggunakan penganalisis log seperti [pgBadger](http://dalibo.github.io/pgbadger/) untuk menganalisis log PostgreSQL. Dokumentasi pgBadger menyatakan bahwa pola %l (baris log untuk sesi atau proses) harus merupakan bagian dari awalan. Namun, jika Anda memberikan RDS `log_line_prefix` saat ini sebagai parameter pgBadger, laporan tetap akan dihasilkan.
Misalnya, perintah berikut memformat file log Amazon RDS for PostgreSQL tertanggal 04-02-2014 dengan benar menggunakan pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Menggunakan PGSnapper untuk memantau PostgreSQL
Anda dapat menggunakannya PGSnapper untuk membantu pengumpulan berkala Amazon RDS for PostgreSQL statistik dan metrik terkait kinerja. Untuk informasi selengkapnya, lihat [Memantau kinerja Amazon RDS for PostgreSQL menggunakan. PGSnapper](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/)
#
**Jenis casting** di PostgreSQL adalah proses mengubah nilai dari satu tipe data ke tipe data lainnya. PostgreSQL menyediakan cast bawaan untuk banyak konversi umum, tetapi Anda juga dapat membuat cast khusus untuk menentukan bagaimana konversi tipe tertentu harus berperilaku.
Pemeran menentukan cara melakukan konversi dari satu tipe data ke tipe data lainnya. Misalnya, mengubah teks `'123'` menjadi bilangan bulat`123`, atau numerik `45.67` menjadi teks. `'45.67'`
[Untuk informasi lengkap tentang konsep dan sintaks casting PostgreSQL, lihat PostgreSQL CREATE CAST Documentation.](https://www.postgresql.org/docs/current/sql-createcast.html)
Dimulai dengan 14.20, 15.15, 16.11, 17.7, dan 18.1, Anda dapat menggunakan ekstensi rds\$1casts untuk menginstal cast tambahan untuk tipe bawaan, sambil tetap dapat membuat gips Anda sendiri untuk jenis kustom.
**Topics**
+ [
## Menginstal dan menggunakan ekstensi rds\$1casts
](#PostgreSQL.CustomCasts.Installing)
+ [
## Cast yang didukung
](#PostgreSQL.CustomCasts.Supported)
+ [
## Membuat atau menjatuhkan gips
](#PostgreSQL.CustomCasts.Creating)
+ [
## Membuat gips khusus dengan strategi konteks yang tepat
](#PostgreSQL.CustomCasts.BestPractices)
## Menginstal dan menggunakan ekstensi rds\$1casts
Untuk membuat `rds_casts` ekstensi, sambungkan ke sebagai dan jalankan perintah berikut: `rds_superuser`
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Cast yang didukung
Buat ekstensi di setiap database tempat Anda ingin menggunakan cast kustom. Setelah membuat ekstensi, gunakan perintah berikut untuk melihat semua gips yang tersedia:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Fungsi ini mencantumkan kombinasi pemeran yang tersedia (tipe sumber, tipe target, konteks paksaan, dan fungsi pemeran). Misalnya, jika Anda ingin membuat `text` untuk `numeric` sebagai `implicit` pemain. Anda dapat menggunakan kueri berikut untuk mengetahui apakah pemeran tersedia untuk dibuat:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
Ekstensi rds\$1casts menyediakan dua jenis fungsi konversi untuk setiap pemeran:
+ *fungsi \$1inout* - Gunakan mekanisme I/O konversi standar PostgreSQL, berperilaku identik dengan cast yang dibuat dengan metode INOUT
+ *\$1fungsi khusus* - Berikan logika konversi yang disempurnakan yang menangani kasus tepi, seperti mengonversi string kosong ke nilai NULL untuk menghindari kesalahan konversi
`inout`Fungsi mereplikasi perilaku casting asli PostgreSQL, sementara `custom` fungsi memperluas fungsionalitas ini dengan menangani skenario yang tidak dapat diakomodasi oleh cast INOUT standar, seperti mengonversi string kosong menjadi bilangan bulat.
## Membuat atau menjatuhkan gips
Anda dapat membuat dan melepaskan gips yang didukung menggunakan dua metode:
### Cast kreasi
**Metode 1: Menggunakan perintah CREATE CAST asli**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Metode 2: Menggunakan fungsi rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
`create_cast`Fungsi mengambil ID dari `list_supported_casts()` output. Metode ini lebih sederhana dan memastikan Anda menggunakan fungsi dan kombinasi konteks yang benar. Id ini dijamin tetap sama di berbagai versi postgres.
Untuk memverifikasi pemeran berhasil dibuat, kueri katalog sistem pg\$1cast:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
`castcontext`Kolom menunjukkan: `e` untuk EXPLISIT, `a` untuk ASSIGNMENT, atau `i` untuk IMPLISIT.
### Menjatuhkan gips
**Metode 1: Menggunakan perintah DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Metode 2: Menggunakan fungsi rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
`drop_cast`Fungsi ini mengambil ID yang sama yang digunakan saat membuat pemeran. Metode ini memastikan Anda menjatuhkan pemeran yang tepat yang dibuat dengan ID yang sesuai.
## Membuat gips khusus dengan strategi konteks yang tepat
Saat membuat beberapa cast untuk tipe integer, kesalahan ambiguitas operator dapat terjadi jika semua cast dibuat sebagai IMPLISIT. Contoh berikut menunjukkan masalah ini dengan membuat dua cast implisit dari teks ke lebar integer yang berbeda:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
Kesalahan terjadi karena PostgreSQL tidak dapat menentukan cast implisit mana yang akan digunakan saat membandingkan kolom integer dengan nilai teks. Baik pemeran implisit int4 dan int8 adalah kandidat yang valid, menciptakan ambiguitas.
Untuk menghindari ambiguitas operator ini, gunakan konteks ASSIGNMENT untuk lebar bilangan bulat yang lebih kecil dan konteks IMPLISIT untuk lebar bilangan bulat yang lebih besar:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Dengan strategi ini, hanya pemeran int8 yang implisit, sehingga PostgreSQL dapat dengan jelas menentukan pemeran mana yang akan digunakan.
# Praktik Terbaik untuk Kueri Paralel di PostgreSQL RDS untuk PostgreSQL
Eksekusi query paralel adalah fitur di PostgreSQL yang memungkinkan query SQL tunggal untuk dipecah menjadi tugas-tugas yang lebih kecil yang diproses secara bersamaan oleh beberapa proses pekerja latar belakang. Alih-alih mengeksekusi kueri sepenuhnya dalam satu proses backend, PostgreSQL dapat mendistribusikan bagian dari kueri, seperti pemindaian, gabungan, agregasi, atau penyortiran, di beberapa inti CPU. *Proses pemimpin* mengoordinasikan eksekusi ini dan mengumpulkan hasil dari pekerja *paralel*.
Namun, untuk sebagian besar beban kerja produksi, terutama sistem OLTP konkurensi tinggi, kami sarankan untuk menonaktifkan eksekusi kueri paralel otomatis. Meskipun paralelisme dapat mempercepat kueri pada kumpulan data besar dalam analitik atau pelaporan beban kerja, paralelisme menimbulkan risiko signifikan yang seringkali lebih besar daripada manfaatnya di lingkungan produksi yang sibuk.
Eksekusi paralel juga memperkenalkan overhead yang signifikan. Setiap pekerja paralel adalah proses backend PostgreSQL lengkap, yang membutuhkan proses forking (menyalin struktur memori dan menginisialisasi status proses) dan otentikasi (memakan slot koneksi dari batas Anda). `max_connections` Setiap pekerja juga mengkonsumsi memorinya sendiri, termasuk `work_mem` untuk operasi penyortiran dan hashing, dengan beberapa pekerja per kueri, penggunaan memori berlipat ganda dengan cepat (misalnya, 4 pekerja × 64MB `work_mem` = 256MB per kueri). Akibatnya, query paralel dapat mengkonsumsi sumber daya sistem yang jauh lebih banyak daripada kueri proses tunggal. Jika tidak disetel dengan benar, mereka dapat menyebabkan saturasi CPU (beberapa pekerja melebihi kapasitas pemrosesan yang tersedia), peningkatan peralihan konteks (sistem operasi sering beralih di antara banyak proses pekerja, menambahkan overhead dan mengurangi throughput), atau kelelahan koneksi (karena setiap pekerja paralel mengkonsumsi slot koneksi, satu kueri dengan 4 pekerja menggunakan total 5 koneksi, 1 pemimpin\$14 pekerja, yang dapat dengan cepat menghabiskan kumpulan koneksi Anda di bawah konkurensi tinggi, mencegah yang baru koneksi klien dan menyebabkan kegagalan aplikasi). Masalah ini sangat parah di bawah beban kerja konkurensi tinggi di mana beberapa kueri dapat mencoba eksekusi paralel secara bersamaan.
PostgreSQL memutuskan apakah akan menggunakan paralelisme berdasarkan perkiraan biaya. Dalam beberapa kasus, perencana dapat secara otomatis beralih ke paket paralel jika tampak lebih murah bahkan ketika itu tidak ideal dalam praktiknya. Ini bisa terjadi jika statistik indeks sudah ketinggalan zaman atau jika bloat membuat pemindaian berurutan tampak lebih menarik daripada pencarian indeks. Karena perilaku ini, rencana paralel otomatis terkadang dapat memperkenalkan regresi dalam kinerja kueri atau stabilitas sistem.
Untuk mendapatkan manfaat maksimal dari query paralel di PostgreSQL RDS untuk PostgreSQL, penting untuk menguji dan menyetelnya berdasarkan beban kerja Anda, memantau dampak sistem, dan menonaktifkan pemilihan paket paralel otomatis demi kontrol tingkat kueri.
## Parameter Konfigurasi
PostgreSQL menggunakan beberapa parameter untuk mengontrol perilaku dan ketersediaan query paralel. Memahami dan menyetel ini sangat penting untuk mencapai kinerja yang dapat diprediksi:
| Parameter | Deskripsi | Default |
| --- | --- | --- |
| max\$1parallel\$1workers | Jumlah maksimum proses pekerja latar belakang yang dapat berjalan secara total | TERBESAR (\$1 DBInstance VCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Jumlah maksimum pekerja per node rencana kueri (misalnya, perGather) | 2 |
| parallel\$1setup\$1cost | Biaya perencana ditambahkan untuk memulai infrastruktur query paralel | 1000 |
| parallel\$1tuple\$1cost | Biaya per tupel diproses dalam mode paralel (berdampak pada keputusan perencana) | 0.1 |
| force\$1parallel\$1mode | Memaksa perencana untuk menguji rencana paralel (off,on,regress) | off |
### Pertimbangan Utama
+ `max_parallel_workers`mengontrol total kumpulan pekerja paralel. Jika disetel terlalu rendah, beberapa kueri mungkin kembali ke eksekusi serial.
+ `max_parallel_workers_per_gather`mempengaruhi berapa banyak pekerja yang dapat digunakan oleh satu kueri. Nilai yang lebih tinggi meningkatkan konkurensi, tetapi juga penggunaan sumber daya.
+ `parallel_setup_cost`dan `parallel_tuple_cost` mempengaruhi model biaya perencana. Menurunkan ini dapat membuat rencana paralel lebih mungkin untuk dipilih.
+ `force_parallel_mode`berguna untuk pengujian tetapi tidak boleh digunakan dalam produksi kecuali diperlukan.
**catatan**
Nilai default `max_parallel_workers` parameter dihitung secara dinamis berdasarkan ukuran instance menggunakan `GREATEST($DBInstanceVCPU/2, 8)` rumus. Ini berarti bahwa ketika Anda menskalakan Anda ke ukuran komputasi yang lebih besar dengan lebih banyak vCPUs, jumlah maksimum pekerja paralel yang tersedia akan meningkat secara otomatis. Akibatnya, kueri yang sebelumnya dijalankan secara serial atau dengan paralelisme terbatas tiba-tiba dapat memanfaatkan lebih banyak pekerja paralel setelah operasi peningkatan skala, berpotensi menyebabkan peningkatan tak terduga dalam penggunaan koneksi, pemanfaatan CPU, dan konsumsi memori. Penting untuk memantau perilaku query paralel setelah peristiwa penskalaan komputasi dan menyesuaikan `max_parallel_workers_per_gather` jika perlu untuk mempertahankan penggunaan sumber daya yang dapat diprediksi.
## Identifikasi Penggunaan Kueri Paralel
Kueri dapat beralih ke paket paralel berdasarkan distribusi data atau statistik. Contoh:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Kueri ini mungkin menggunakan indeks untuk data terbaru, tetapi beralih ke pemindaian sekuensial paralel untuk data historis.
Anda dapat mencatat rencana eksekusi kueri dengan memuat `auto_explain` modul. Untuk mempelajari lebih lanjut, lihat [Mencatat rencana eksekusi kueri](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) di pusat AWS pengetahuan.
Anda dapat memantau [Wawasan CloudWatch Database](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) untuk peristiwa tunggu terkait Kueri Paralel. Untuk mempelajari lebih lanjut tentang peristiwa tunggu terkait Permintaan Paralel, buka acara tunggu [IPC:Parallel](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html)
Dari PostgreSQL versi 18, Anda dapat memantau aktivitas pekerja paralel menggunakan kolom baru di dan: [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
+ `parallel_workers_to_launch`: Jumlah pekerja paralel yang direncanakan akan diluncurkan
+ `parallel_workers_launched`: Jumlah pekerja paralel yang benar-benar diluncurkan
Metrik ini membantu mengidentifikasi perbedaan antara paralelisme terencana dan aktual, yang dapat menunjukkan kendala sumber daya atau masalah konfigurasi. Gunakan kueri berikut untuk memantau eksekusi paralel:
Untuk metrik pekerja paralel tingkat Database:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Untuk metrik pekerja paralel tingkat kueri
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Cara Mengontrol Paralelisme
Ada beberapa cara untuk mengontrol paralelisme kueri, masing-masing dirancang untuk skenario dan persyaratan yang berbeda.
Untuk menonaktifkan paralelisme otomatis secara global, [parameter Anda](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html) untuk disetel:
```
max_parallel_workers_per_gather = 0;
```
Untuk pengaturan persisten dan spesifik pengguna, perintah ALTER ROLE menyediakan cara untuk mengatur parameter yang akan berlaku untuk semua sesi future untuk pengguna tertentu.
Contoh:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;`memastikan bahwa setiap kali pengguna ini terhubung ke database, sesi mereka akan menggunakan pengaturan pekerja paralel ini bila diperlukan.
Kontrol tingkat sesi dapat dicapai dengan menggunakan perintah SET, yang memodifikasi parameter selama sesi database saat ini. Ini sangat berguna ketika Anda perlu menyesuaikan pengaturan sementara tanpa memengaruhi pengguna lain atau sesi future. Setelah disetel, parameter ini tetap berlaku hingga diatur ulang secara eksplisit atau sampai sesi berakhir. Perintahnya mudah:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Untuk kontrol yang lebih terperinci, SET LOCAL memungkinkan Anda memodifikasi parameter untuk satu transaksi. Ini sangat ideal ketika Anda perlu menyesuaikan pengaturan untuk serangkaian kueri tertentu dalam transaksi, setelah itu pengaturan secara otomatis kembali ke nilai sebelumnya. Pendekatan ini membantu mencegah efek yang tidak diinginkan pada operasi lain dalam sesi yang sama.
## Mendiagnosis Perilaku Kueri Paralel
Gunakan `EXPLAIN (ANALYZE, VERBOSE)` untuk mengonfirmasi apakah kueri menggunakan eksekusi paralel:
+ Carilah node seperti`Gather`,`Gather Merge`, atau`Parallel Seq Scan`.
+ Bandingkan rencana dengan dan tanpa paralelisme.
Untuk menonaktifkan paralelisme sementara untuk perbandingan:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Bekerja dengan parameter pada instans DB RDS for PostgreSQL
Dalam beberapa kasus, Anda mungkin membuat instans DB RDS for PostgreSQL tanpa menentukan grup parameter kustom. Jika demikian, instans DB Anda dibuat menggunakan grup parameter default untuk versi PostgreSQL yang dipilih. Misalnya, Anda membuat instans DB RDS for PostgreSQL menggunakan PostgreSQL 13.3. Dalam hal ini, instans DB dibuat menggunakan nilai dalam grup parameter untuk rilis PostgreSQL 13, `default.postgres13`.
Anda juga dapat membuat grup parameter DB kustom Anda sendiri. Anda perlu melakukan ini jika ingin memodifikasi pengaturan untuk instans DB RDS for PostgreSQL dari nilai default-nya. Untuk mempelajari caranya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Anda dapat melacak pengaturan pada instans DB RDS for PostgreSQL melalui beberapa cara berbeda. Anda dapat menggunakan Konsol Manajemen AWS, AWS CLI, atau Amazon RDS API. Anda juga dapat membuat kueri pada nilai dari tabel `pg_settings` PostgreSQL instans Anda, seperti yang ditunjukkan berikut.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Untuk mempelajari selengkapnya tentang nilai yang ditampilkan dari kueri ini, lihat [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) dalam dokumentasi PostgreSQL.
Berhati-hatilah saat mengubah pengaturan untuk `max_connections` dan `shared_buffers` pada instans DB RDS for PostgreSQL. Misalnya, Anda memodifikasi pengaturan untuk `max_connections` atau `shared_buffers`, dan Anda menggunakan nilai yang terlalu tinggi untuk beban kerja yang sebenarnya. Dalam hal ini, maka instans DB RDS for PostgreSQL tidak akan dimulai. Jika ini terjadi, Anda akan melihat kesalahan seperti berikut di `postgres.log`.
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Namun, Anda tidak dapat mengubah nilai pengaturan apa pun yang terdapat dalam grup parameter DB RDS for PostgreSQL. Untuk mengubah pengaturan setiap parameter, buat grup parameter DB kustom. Kemudian, ubah pengaturan di grup kustom tersebut, lalu terapkan grup parameter kustom ke instans DB RDS for PostgreSQL. Untuk mempelajari selengkapnya, lihat [Grup parameter untuk RDS](USER_WorkingWithParamGroups.md).
Ada dua jenis parameter dalam RDS untuk PostgreSQL.
+ **Parameter statis** – Parameter statis mengharuskan instans DB RDS for PostgreSQL di-boot ulang setelah perubahan agar nilai baru dapat diterapkan.
+ **Parameter dinamis** – Parameter dinamis tidak memerlukan boot ulang setelah mengubah pengaturannya.
**catatan**
Jika instans DB RDS for PostgreSQL menggunakan grup parameter DB kustom Anda sendiri, Anda dapat mengubah nilai parameter dinamis pada instans DB yang sedang berjalan. Anda dapat melakukan ini dengan menggunakan Konsol Manajemen AWS, AWS CLI, atau Amazon RDS API.
Jika memiliki hak istimewa untuk melakukan tindakan ini, Anda juga dapat mengubah nilai parameter menggunakan perintah `ALTER DATABASE`, `ALTER ROLE`, dan `SET`.
## Daftar parameter instans DB RDS for PostgreSQL
Tabel berikut mencantumkan beberapa (tetapi tidak semua) parameter yang tersedia dalam instans DB RDS for PostgreSQL. Untuk melihat semua parameter yang tersedia, Anda menggunakan [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI perintah. Misalnya, untuk mendapatkan daftar semua parameter yang tersedia di grup parameter default untuk RDS for PostgreSQL versi 13, jalankan perintah berikut ini.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Anda juga dapat menggunakan Konsol. Pilih **Grup parameter** dari menu Amazon RDS, lalu pilih grup parameter yang tersedia di menu Wilayah AWS.
| Nama parameter | Apply\$1Type | Deskripsi |
| --- | --- | --- |
| `application_name` | Dinamis | Mengatur nama aplikasi yang akan dilaporkan dalam statistik dan log. |
| `archive_command` | Dinamis | Menetapkan perintah shell yang akan dipanggil untuk mengarsipkan file WAL. |
| `array_nulls` | Dinamis | Memungkinkan input elemen NULL dalam array. |
| `authentication_timeout` | Dinamis | Mengatur waktu maksimum yang diizinkan untuk menyelesaikan autentikasi klien. |
| `autovacuum` | Dinamis | Memulai subproses autovacuum. |
| `autovacuum_analyze_scale_factor` | Dinamis | Jumlah penyisipan, pembaruan, atau penghapusan tuple sebelum dianalisis sebagai pecahan dari reltuple. |
| `autovacuum_analyze_threshold` | Dinamis | Jumlah minimum penyisipan, pembaruan, atau penghapusan tuple sebelum dianalisis. |
| `autovacuum_freeze_max_age` | Statis | Usia untuk melakukan autovacuum tabel guna mencegah penyelesaian ID transaksi. |
| `autovacuum_naptime` | Dinamis | Waktu tidur selama autovacuum berjalan. |
| `autovacuum_max_workers` | Statis | Mengatur jumlah maksimum proses pekerja autovacuum yang berjalan secara bersamaan. |
| `autovacuum_vacuum_cost_delay` | Dinamis | Penundaan biaya vakum, dalam milidetik, untuk autovacuum. |
| `autovacuum_vacuum_cost_limit` | Dinamis | Jumlah biaya vakum yang tersedia sebelum napping, untuk autovacuum. |
| `autovacuum_vacuum_scale_factor` | Dinamis | Jumlah pembaruan atau penghapusan tuple sebelum divakum sebagai pecahan dari retuple. |
| `autovacuum_vacuum_threshold` | Dinamis | Jumlah minimum pembaruan atau penghapusan tuple sebelum divakum. |
| `backslash_quote` | Dinamis | Mengatur apakah garis miring terbalik (\$1) diizinkan dalam string literal atau tidak. |
| `bgwriter_delay` | Dinamis | Waktu tidur latar belakang penulis di sela-sela putaran. |
| `bgwriter_lru_maxpages` | Dinamis | Jumlah maksimum halaman LRU penulis latar belakang yang akan dibersihkan per putaran. |
| `bgwriter_lru_multiplier` | Dinamis | Kelipatan dari penggunaan buffer rata-rata yang akan dikosongkan per putaran. |
| `bytea_output` | Dinamis | Mengatur format output untuk byte. |
| `check_function_bodies` | Dinamis | Memeriksa konten fungsi selama CREATE FUNCTION. |
| `checkpoint_completion_target` | Dinamis | Waktu yang dihabiskan untuk membersihkan buffer kotor selama operasi titik pemeriksaan, sebagai bagian dari interval titik pemeriksaan. |
| `checkpoint_segments` | Dinamis | Mengatur jarak maksimum dalam segmen log antara titik pemeriksaan write-ahead log (WAL). |
| `checkpoint_timeout` | Dinamis | Mengatur waktu maksimum antara titik pemeriksaan WAL otomatis. |
| `checkpoint_warning` | Dinamis | Mengaktifkan peringatan jika segmen titik pemeriksaan diisi lebih sering daripada ini. |
| `client_connection_check_interval` | Dinamis | Menetapkan interval waktu di antara pemeriksaan pemutusan koneksi saat menjalankan kueri. |
| `client_encoding` | Dinamis | Mengatur pengenkodean set karakter klien. |
| `client_min_messages` | Dinamis | Mengatur tingkatan pesan yang dikirimkan kepada klien. |
| `commit_delay` | Dinamis | Mengatur penundaan dalam mikrodetik antara transaksi commit dan melakukan pembersihan WAL ke disk. |
| `commit_siblings` | Dinamis | Mengatur minimum transaksi terbuka serentak sebelum melakukan commit\$1delay. |
| `constraint_exclusion` | Dinamis | Memungkinkan perencana untuk menggunakan batasan agar dapat mengoptimalkan kueri. |
| `cpu_index_tuple_cost` | Dinamis | Menetapkan perkiraan perencana untuk biaya pemrosesan setiap entri indeks selama pemindaian indeks. |
| `cpu_operator_cost` | Dinamis | Menetapkan perkiraan perencana untuk biaya pemrosesan setiap operator atau panggilan fungsi. |
| `cpu_tuple_cost` | Dinamis | Menetapkan perkiraan perencana untuk biaya pemrosesan setiap tuple (baris). |
| `cursor_tuple_fraction` | Dinamis | Menetapkan perkiraan perencana untuk pecahan dari baris kursor yang akan diambil. |
| `datestyle` | Dinamis | Mengatur format tampilan nilai tanggal dan waktu. |
| `deadlock_timeout` | Dinamis | Mengatur waktu menunggu kunci sebelum memeriksa deadlock. |
| `debug_pretty_print` | Dinamis | Mengindentasi tampilan hierarki penguraian dan rencana. |
| `debug_print_parse` | Dinamis | Membuat log hierarki penguraian setiap kueri. |
| `debug_print_plan` | Dinamis | Membuat log rencana eksekusi setiap kueri. |
| `debug_print_rewritten` | Dinamis | Membuat log hierarki penguraian yang ditulis ulang oleh setiap kueri. |
| `default_statistics_target` | Dinamis | Mengatur target statistik default. |
| `default_tablespace` | Dinamis | Mengatur tablespace default untuk membuat tabel dan indeks. |
| `default_transaction_deferrable` | Dinamis | Mengatur status default yang dapat ditangguhkan dari transaksi baru. |
| `default_transaction_isolation` | Dinamis | Menetapkan tingkat isolasi transaksi dari setiap transaksi baru. |
| `default_transaction_read_only` | Dinamis | Mengatur status hanya-baca default dari transaksi baru. |
| `default_with_oids` | Dinamis | Membuat tabel baru dengan object IDs (OIDs) secara default. |
| `effective_cache_size` | Dinamis | Mengatur asumsi perencana ukuran cache disk. |
| `effective_io_concurrency` | Dinamis | Jumlah permintaan serentak yang dapat ditangani secara efisien oleh subsistem disk. |
| `enable_bitmapscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian bitmap oleh perencana. |
| `enable_hashagg` | Dinamis | Memungkinkan penggunaan rencana agregasi hash oleh perencana. |
| `enable_hashjoin` | Dinamis | Memungkinkan penggunaan rencana hash join oleh perencana. |
| `enable_indexscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian indeks oleh perencana. |
| `enable_material` | Dinamis | Memungkinkan penggunaan materialisasi oleh perencana. |
| `enable_mergejoin` | Dinamis | Memungkinkan penggunaan rencana merge join oleh perencana. |
| `enable_nestloop` | Dinamis | Memungkinkan penggunaan rencana nested-loop join oleh perencana. |
| `enable_seqscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian sekuensial oleh perencana. |
| `enable_sort` | Dinamis | Memungkinkan penggunaan langkah singkat eksplisit oleh perencana. |
| `enable_tidscan` | Dinamis | Memungkinkan penggunaan rencana pemindaian TID oleh perencana. |
| `escape_string_warning` | Dinamis | Memperingatkan tentang escape garis miring terbalik (\$1) dalam string literal biasa. |
| `extra_float_digits` | Dinamis | Mengatur jumlah digit yang ditampilkan untuk nilai floating-point. |
| `from_collapse_limit` | Dinamis | Mengatur ukuran daftar FROM yang tidak menciutkan subkueri. |
| `fsync` | Dinamis | Memaksa sinkronisasi pembaruan ke disk. |
| `full_page_writes` | Dinamis | Menulis halaman penuh ke WAL saat pertama kali dimodifikasi setelah titik pemeriksaan. |
| `geqo` | Dinamis | Memungkinkan pengoptimalan kueri genetik. |
| `geqo_effort` | Dinamis | GEQO: upaya digunakan untuk mengatur default parameter GEQO lainnya. |
| `geqo_generations` | Dinamis | GEQO: jumlah iterasi algoritma. |
| `geqo_pool_size` | Dinamis | GEQO: jumlah individu dalam populasi. |
| `geqo_seed` | Dinamis | GEQO: seed untuk pemilihan jalur acak. |
| `geqo_selection_bias` | Dinamis | GEQO: tekanan selektif di dalam populasi. |
| `geqo_threshold` | Dinamis | Mengatur ambang batas item FROM yang menggunakan GEQO. |
| `gin_fuzzy_search_limit` | Dinamis | Mengatur hasil maksimum yang diperbolehkan untuk pencarian akurat oleh GIN. |
| `hot_standby_feedback` | Dinamis | Menentukan apakah hot standby mengirimkan pesan umpan balik ke standby utama atau standby hulu. |
| `intervalstyle` | Dinamis | Mengatur format tampilan nilai interval. |
| `join_collapse_limit` | Dinamis | Menetapkan ukuran daftar FROM yang tidak meratakan konsep JOIN. |
| `lc_messages` | Dinamis | Mengatur bahasa untuk menampilkan pesan. |
| `lc_monetary` | Dinamis | Menetapkan lokal untuk memformat jumlah uang. |
| `lc_numeric` | Dinamis | Mengatur lokal untuk memformat angka. |
| `lc_time` | Dinamis | Mengatur lokal untuk memformat nilai tanggal dan waktu. |
| `log_autovacuum_min_duration` | Dinamis | Mengatur waktu berjalan minimum yang akan membuat log tindakan autovacuum. |
| `log_checkpoints` | Dinamis | Membuat log setiap titik pemeriksaan. |
| `log_connections` | Dinamis | Membuat log setiap koneksi yang berhasil. |
| `log_disconnections` | Dinamis | Membuat log dari akhir sebuah sesi, termasuk durasinya. |
| `log_duration` | Dinamis | Membuat log durasi setiap pernyataan SQL yang diselesaikan. |
| `log_error_verbosity` | Dinamis | Mengatur panjang pesan yang dicatat. |
| `log_executor_stats` | Dinamis | Menulis statistik performa pelaksana ke log server. |
| `log_filename` | Dinamis | Mengatur pola nama file untuk file log. |
| `log_file_mode` | Dinamis | Mengatur izin file untuk file log. Nilai default-nya adalah 0644. |
| `log_hostname` | Dinamis | Membuat log nama host dalam log koneksi. Pada PostgreSQL 12 dan versi yang lebih baru, parameter ini 'nonaktif' secara default. Saat diaktifkan, koneksi akan menggunakan pencarian balik DNS untuk mendapatkan nama host yang terambil ke log koneksi. Jika mengaktifkan parameter ini, Anda harus memantau dampaknya pada waktu yang diperlukan agar dapat membuat koneksi. |
| `log_line_prefix ` | Dinamis | Mengontrol informasi yang diawali untuk setiap baris log. |
| `log_lock_waits` | Dinamis | Membuat log waktu tunggu kunci yang panjang. |
| `log_min_duration_statement` | Dinamis | Menetapkan waktu berjalan minimum yang akan Membuat log pernyataan. |
| `log_min_error_statement` | Dinamis | Menyebabkan semua pernyataan yang menghasilkan kesalahan pada atau di atas level ini dicatat. |
| `log_min_messages` | Dinamis | Mengatur tingkat pesan yang dicatat. |
| `log_parser_stats` | Dinamis | Menulis statistik performa pengurai ke log server. |
| `log_planner_stats` | Dinamis | Menulis statistik performa perencana ke log server. |
| `log_rotation_age` | Dinamis | Rotasi file log otomatis akan terjadi setelah N menit. |
| `log_rotation_size` | Dinamis | Rotasi file log otomatis akan terjadi setelah N kilobita. |
| `log_statement` | Dinamis | Mengatur jenis pernyataan yang dicatat. |
| `log_statement_stats` | Dinamis | Menulis statistik performa kumulatif ke log server. |
| `log_temp_files` | Dinamis | Membuat log penggunaan file sementara yang lebih besar dari angka kilobyte ini. |
| `log_timezone` | Dinamis | Mengatur zona waktu yang akan digunakan dalam pesan log. |
| `log_truncate_on_rotation` | Dinamis | Memotong file log yang ada dengan nama yang sama selama rotasi log. |
| `logging_collector` | Statis | Mulai subproses untuk menangkap and/or csvlog keluaran stderr ke dalam file log. |
| `maintenance_work_mem` | Dinamis | Mengatur memori maksimum yang akan digunakan untuk operasi pemeliharaan. |
| `max_connections` | Statis | Mengatur jumlah maksimum koneksi serentak. |
| `max_files_per_process` | Statis | Mengatur jumlah maksimum file yang terbuka secara bersamaan untuk setiap proses server. |
| `max_locks_per_transaction` | Statis | Menetapkan jumlah maksimum kunci per transaksi. |
| `max_pred_locks_per_transaction` | Statis | Menetapkan jumlah maksimum kunci predikat per transaksi. |
| `max_prepared_transactions` | Statis | Menetapkan jumlah maksimum transaksi yang disiapkan secara bersamaan. |
| `max_stack_depth` | Dinamis | Mengatur kedalaman tumpukan maksimum, dalam kilobita. |
| `max_standby_archive_delay` | Dinamis | Mengatur penundaan maksimum sebelum membatalkan kueri saat hot standby sedang memproses data WAL yang diarsipkan. |
| `max_standby_streaming_delay` | Dinamis | Mengatur penundaan maksimum sebelum membatalkan kueri saat hot standby sedang memproses data WAL yang dialirkan. |
| max\$1wal\$1size | Dinamis | Menetapkan ukuran WAL (MB) yang memicu titik pemeriksaan. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Gunakan perintah berikut pada instans Amazon RDS for PostgreSQL DB untuk melihat nilainya saat ini: SHOW max_wal_size;
|
| min\$1wal\$1size | Dinamis | Mengatur ukuran minimum untuk menyusutkan WAL. Untuk PostgreSQL versi 9.6 dan yang sebelumnya, pengaturan min\$1wal\$1size berada dalam unit 16 MB. Untuk PostgreSQL versi 10 dan yang lebih baru, pengaturan min\$1wal\$1size berada dalam unit 1 MB. |
| `quote_all_identifiers` | Dinamis | Menambahkan tanda kutip (") ke semua pengidentifikasi ketika membuat fragmen SQL. |
| `random_page_cost` | Dinamis | Mengatur perkiraan perencana untuk biaya dari halaman disk yang diambil secara tidak berurutan. Parameter ini tidak memiliki nilai kecuali manajemen rencana kueri (QPM) diaktifkan. Saat QPM aktif, nilai default-nya adalah 4. |
| rds.adaptive\$1autovacuum | Dinamis | Secara otomatis menyesuaikan parameter autovacuum setiap kali ambang batas ID transaksi terlampaui. |
| rds.force\$1ssl | Dinamis | Membutuhkan penggunaan koneksi SSL. Nilai default diatur ke 1 (aktif) untuk RDS for PostgreSQL versi 15. Semua RDS for PostgreSQL versi utama 14 lainnya dan yang lebih lama memiliki nilai default yang disetel ke 0 (nonaktif). |
| `rds.local_volume_spill_enabled` | Statis | Memungkinkan penulisan file tumpahan logis ke volume lokal. |
| `rds.log_retention_period` | Dinamis | Mengatur retensi log sedemikian rupa sehingga Amazon RDS dapat menghapus log PostgreSQL yang lebih lama dari n menit. |
| rds.rds\$1superuser\$1reserved\$1connections | Statis | Menetapkan jumlah slot koneksi yang disediakan untuk rds\$1superusers. Parameter ini hanya tersedia dalam versi 15 dan sebelumnya. [Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL reserved\$1connections.](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS) |
| `rds.replica_identity_full` | Dinamis | Ketika Anda mengatur parameter ini ke`on`, itu akan mengganti pengaturan identitas replika `FULL` untuk semua tabel database. Ini berarti semua nilai kolom ditulis ke log tulis depan (WAL), terlepas dari `REPLICA IDENTITY FULL` pengaturan Anda. Mengaktifkan parameter ini dapat meningkatkan IOPS instance database Anda karena pencatatan WAL tambahan. |
| rds.restrict\$1password\$1commands | Statis | Membatasi individu yang dapat mengelola kata sandi untuk pengguna yang memiliki peran rds\$1password. Atur parameter ini ke 1 untuk mengaktifkan pembatasan kata sandi. Default-nya adalah 0. |
| `search_path` | Dinamis | Menetapkan urutan pencarian skema untuk nama yang tidak memenuhi syarat skema. |
| `seq_page_cost` | Dinamis | Mengatur perkiraan perencana untuk biaya dari halaman disk yang diambil secara berurutan. |
| `session_replication_role` | Dinamis | Menetapkan perilaku sesi untuk pemicu dan aturan penulisan ulang. |
| `shared_buffers` | Statis | Mengatur jumlah buffer memori bersama yang digunakan oleh server. |
| `shared_preload_libraries ` | Statis | Memigrasi pustaka bersama untuk dimuat ke instans DB RDS for PostgreSQL. Nilai yang didukung meliputi auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler, dan plrust. |
| `ssl` | Dinamis | Mengaktifkan koneksi SSL. |
| `sql_inheritance` | Dinamis | Menyebabkan subtabel disertakan secara default dalam berbagai perintah. |
| `ssl_renegotiation_limit` | Dinamis | Menetapkan jumlah lalu lintas untuk dikirim dan diterima sebelum melakukan negosiasi ulang kunci enkripsi. |
| `standard_conforming_strings` | Dinamis | Menyebabkan string ... memperlakukan garis miring terbalik secara literal. |
| `statement_timeout` | Dinamis | Menetapkan durasi maksimum yang diizinkan untuk setiap pernyataan. |
| `synchronize_seqscans` | Dinamis | Memungkinkan pemindaian berurutan yang disinkronkan. |
| `synchronous_commit` | Dinamis | Mengatur tingkat sinkronisasi transaksi saat ini. |
| `tcp_keepalives_count` | Dinamis | Jumlah maksimum pengiriman ulang keepalive TCP. |
| `tcp_keepalives_idle` | Dinamis | Waktu antara penerbitan keepalive TCP. |
| `tcp_keepalives_interval` | Dinamis | Waktu antara pengiriman ulang keepalive TCP. |
| `temp_buffers` | Dinamis | Mengatur jumlah maksimum buffer sementara yang digunakan oleh setiap sesi. |
| temp\$1file\$1limit | Dinamis | Mengatur ukuran maksimum file sementara dapat berkembang dalam KB. |
| `temp_tablespaces` | Dinamis | Mengatur tablespace yang akan digunakan untuk tabel sementara dan mengurutkan file. |
| `timezone` | Dinamis | Mengatur zona waktu untuk menampilkan dan menginterpretasikan stempel waktu. Internet Assigned Numbers Authority (IANA) menerbitkan zona waktu baru di [https://www.iana.org/time-zones](https://www.iana.org/time-zones) beberapa kali dalam setahun. Setiap kali RDS mengeluarkan rilis pemeliharaan minor PostgreSQL yang baru, rilis tersebut akan dikirimkan beserta data zona waktu terbaru pada saat rilis. Jika menggunakan versi RDS for PostgreSQL terbaru, Anda akan memiliki data zona waktu terbaru dari RDS. Untuk memastikan bahwa instans DB Anda memiliki data zona waktu terbaru, sebaiknya tingkatkan ke versi mesin DB yang lebih baru. Anda tidak dapat mengubah tabel zona waktu dalam instans DB PostgreSQL secara manual. RDS tidak memodifikasi atau mengatur ulang data zona waktu dari instans DB yang berjalan. Data zona waktu baru diinstal hanya ketika Anda melakukan peningkatan versi mesin basis data. |
| `track_activities` | Dinamis | Mengumpulkan informasi cara menjalankan perintah. |
| `track_activity_query_size` | Statis | Mengatur ukuran terpesan untuk pg\$1stat\$1activity.current\$1query, dalam byte. |
| `track_counts` | Dinamis | Mengumpulkan statistik aktivitas basis data. |
| `track_functions` | Dinamis | Mengumpulkan statistik tingkat fungsi aktivitas basis data. |
| `track_io_timing` | Dinamis | Mengumpulkan statistik waktu pada I/O aktivitas database. |
| `transaction_deferrable` | Dinamis | Menunjukkan apakah akan menunda transaksi hanya-baca berseri sampai bisa dimulai tanpa ada kegagalan serialisasi. |
| `transaction_isolation` | Dinamis | Menetapkan tingkat isolasi transaksi saat ini. |
| `transaction_read_only` | Dinamis | Mengatur status hanya-baca transaksi saat ini. |
| `transform_null_equals` | Dinamis | Memperlakukan expr=NULL sebagai expr IS NULL. |
| `update_process_title` | Dinamis | Memperbarui judul proses untuk menampilkan perintah SQL yang aktif. |
| `vacuum_cost_delay` | Dinamis | Penundaan biaya vakum dalam milidetik. |
| `vacuum_cost_limit` | Dinamis | Jumlah biaya vakum yang tersedia sebelum napping. |
| `vacuum_cost_page_dirty` | Dinamis | Biaya vakum untuk halaman yang kotor karena vakum. |
| `vacuum_cost_page_hit` | Dinamis | Biaya vakum untuk halaman yang ditemukan di cache buffer. |
| `vacuum_cost_page_miss` | Dinamis | Biaya vakum untuk halaman yang tidak ditemukan dalam cache buffer. |
| `vacuum_defer_cleanup_age` | Dinamis | Jumlah transaksi yang harus ditangguhkan dengan vakum dan hot cleanup, jika ada. |
| `vacuum_freeze_min_age` | Dinamis | Usia minimum saat vakum harus membekukan baris tabel. |
| `vacuum_freeze_table_age` | Dinamis | Usia saat vakum harus memindai seluruh tabel untuk membekukan tuple. |
| `wal_buffers` | Statis | Mengatur jumlah buffer halaman disk dalam memori bersama untuk WAL. |
| `wal_writer_delay` | Dinamis | Waktu tidur penulis WAL antara beberapa pengosongan WAL. |
| `work_mem` | Dinamis | Mengatur memori maksimum yang akan digunakan untuk ruang kerja kueri. |
| `xmlbinary` | Dinamis | Menetapkan cara pengenkodean nilai biner dalam XML. |
| `xmloption` | Dinamis | Menetapkan apakah data XML dalam operasi penguraian implisit dan serialisasi dianggap sebagai dokumen atau fragmen konten. |
Amazon RDS menggunakan unit PostgreSQL default untuk semua parameter. Tabel berikut menunjukkan unit default PostgreSQL untuk setiap parameter.
| Nama parameter | Unit |
| --- | --- |
| `archive_timeout` | detik |
| `authentication_timeout` | detik |
| `autovacuum_naptime` | detik |
| `autovacuum_vacuum_cost_delay` | milidetik |
| `bgwriter_delay` | milidetik |
| `checkpoint_timeout` | detik |
| `checkpoint_warning` | detik |
| `deadlock_timeout` | milidetik |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | milidetik |
| `log_autovacuum_min_duration` | milidetik |
| `log_min_duration_statement` | milidetik |
| `log_rotation_age` | menit |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | milidetik |
| `max_standby_streaming_delay` | milidetik |
| `post_auth_delay` | detik |
| `pre_auth_delay` | detik |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | milidetik |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | detik |
| `tcp_keepalives_interval` | detik |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | milidetik |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | milidetik |
| `wal_segment_size` | B |
| `wal_sender_timeout` | milidetik |
| `wal_writer_delay` | milidetik |
| `wal_receiver_status_interval` | detik |