Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mengelola rencana eksekusi kueri untuk Aurora PostgreSQL
Manajemen rencana kueri Aurora PostgreSQL adalah fitur opsional yang dapat Anda gunakan dengan klaster DB Amazon Aurora Edisi Kompatibel PostgreSQL. Fitur ini dikemas sebagai ekstensi `apg_plan_mgmt` yang dapat Anda instal di klaster DB Aurora PostgreSQL Anda. Manajemen rencana kueri memungkinkan Anda mengelola rencana eksekusi kueri yang dihasilkan oleh pengoptimisasi untuk aplikasi SQL Anda. `apg_plan_mgmt` AWS Ekstensi dibangun di atas fungsionalitas pemrosesan kueri asli dari mesin database PostgreSQL.
Di bagian berikut ini, Anda dapat menemukan informasi tentang fitur manajemen rencana kueri Aurora PostgreSQL, cara mengaturnya, dan cara menggunakannya dengan klaster DB Aurora PostgreSQL Anda. Sebelum memulai, sebaiknya Anda meninjau catatan rilis apa pun untuk versi spesifik ekstensi `apg_plan_mgmt` yang tersedia untuk versi Aurora PostgreSQL Anda. Untuk informasi selengkapnya, lihat [Versi ekstensi apg\$1plan\$1mgmt Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) dalam *Catatan Rilis untuk Aurora PostgreSQL*.
**Topics**
+ [Gambaran umum manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md)
+ [Praktik terbaik untuk manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.BestPractice.md)
+ [Manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Start.md)
+ [Mengambil rencana eksekusi Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md)
+ [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md)
+ [Memeriksa rencana kueri Aurora PostgreSQL dalam tampilan dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md)
+ [Meningkatkan rencana kueri PostgreSQL Aurora](AuroraPostgreSQL.Optimize.Maintenance.md)
+ [Menghapus paket kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Deleting.md)
+ [Mengekspor dan mengimpor rencana terkelola untuk Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md)
+ [Referensi parameter untuk manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Parameters.md)
+ [Referensi fungsi untuk manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Functions.md)
+ [Referensi untuk tampilan apg\$1plan\$1mgmt.dba\$1plans untuk Aurora PostgreSQL Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md)
+ [Fitur lanjutan dalam Manajemen Rencana Kueri](AuroraPostgreSQL.QPM.Advanced.md)
# Gambaran umum manajemen rencana kueri Aurora PostgreSQL
Manajemen rencana kueri Aurora PostgreSQL dirancang untuk memastikan stabilitas rencana terlepas dari perubahan pada basis data yang dapat menyebabkan regresi rencana kueri. *Regresi rencana kueri* terjadi ketika pengoptimal memilih rencana yang kurang optimal untuk pernyataan SQL yang diberikan setelah perubahan sistem atau basis data. Perubahan pada statistik, pembatasan, pengaturan lingkungan, pengikatan parameter kueri, dan peningkatan ke mesin basis data PostgreSQL semuanya dapat menyebabkan regresi rencana.
Dengan manajemen rencana kueri Aurora PostgreSQL, Anda dapat mengendalikan bagaimana dan kapan rencana eksekusi kueri akan berubah. Manfaat manajemen rencana kueri Aurora PostgreSQL meliputi yang berikut ini.
+ Meningkatkan stabilitas rencana dengan memaksa pengoptimal untuk memilih dari sejumlah kecil rencana yang sudah diketahui bagus.
+ Mengoptimalkan rencana secara terpusat lalu mendistribusikan rencana terbaik secara global.
+ Mengidentifikasi indeks yang tidak digunakan dan menilai dampak dari membuat atau menghapus indeks.
+ Secara otomatis mendeteksi rencana biaya minimum baru yang ditemukan oleh pengoptimal.
+ Mencoba fitur-fitur pengoptimal baru dengan risiko lebih rendah karena Anda dapat memilih untuk hanya menyetujui perubahan rencana yang meningkatkan performa.
Anda dapat menggunakan alat yang disediakan oleh manajemen rencana kueri secara proaktif untuk menentukan rencana terbaik untuk kueri tertentu. Atau, Anda dapat menggunakan manajemen rencana kueri untuk bereaksi terhadap perubahan keadaan dan menghindari regresi rencana. Untuk informasi selengkapnya, lihat [Praktik terbaik untuk manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.BestPractice.md).
**Topics**
+ [Pernyataan SQL yang didukung](#AuroraPostgreSQL.Optimize.overview.features)
+ [Batasan manajemen rencana kueri](#AuroraPostgreSQL.Optimize.overview.limitations)
+ [Terminologi manajemen rencana kueri](#AuroraPostgreSQL.Optimize.Start-terminology)
+ [Versi manajemen rencana kueri Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.overview.versions)
+ [Mengaktifkan manajemen rencana kueri Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable)
+ [Meningkatkan manajemen rencana kueri Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade)
+ [Menonaktifkan manajemen rencana kueri Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable.turnoff)
## Pernyataan SQL yang didukung
Manajemen rencana kueri mendukung jenis pernyataan SQL berikut.
+ Pernyataan SELECT, INSERT, UPDATE, atau DELETE, terlepas dari kompleksitasnya.
+ Pernyataan yang disiapkan. Untuk informasi selengkapnya, lihat [PREPARE](https://www.postgresql.org/docs/14/sql-prepare.html) dalam dokumentasi PostgreSQL.
+ Pernyataan dinamis, termasuk yang dijalankan dalam mode segera. Untuk informasi selengkapnya, lihat [Dynamic SQL](https://www.postgresql.org/docs/current/ecpg-dynamic.html) dan [EXECUTE IMMEDIATE](https://www.postgresql.org/docs/current/ecpg-sql-execute-immediate.html) dalam dokumentasi PostgreSQL.
+ Perintah dan pernyataan SQL tersemat. Untuk informasi selengkapnya, lihat [Embedded SQL Commands](https://www.postgresql.org/docs/current/ecpg-sql-commands.html) dalam dokumentasi PostgreSQL.
+ Pernyataan di dalam fungsi bernama. Untuk informasi selengkapnya, lihat [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) dalam dokumentasi PostgreSQL.
+ Pernyataan yang berisi tabel temp.
+ Pernyataan di dalam prosedur dan DO-block.
Anda dapat menggunakan manajemen rencana kueri dengan `EXPLAIN` dalam mode manual untuk menangkap rencana tanpa benar-benar menjalankannya. Untuk informasi selengkapnya, lihat [Menganalisis rencana yang dipilih pengoptimisasi](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Untuk mempelajari selengkapnya tentang mode manajemen rencana kueri (manual, otomatis), lihat [Mengambil rencana eksekusi Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
Manajemen rencana kueri Aurora PostgreSQL mendukung semua fitur bahasa PostgreSQL, termasuk tabel yang dipartisi, pewarisan, keamanan tingkat baris, dan ekspresi tabel umum rekursif (). CTEs Untuk mempelajari selengkapnya tentang fitur bahasa PostgreSQL ini, lihat [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html), [Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html), dan [WITH Queries (Common Table Expressions)](https://www.postgresql.org/docs/current/queries-with.html) serta topik lainnya dalam dokumentasi PostgreSQL.
Untuk informasi tentang berbagai versi fitur manajemen rencana kueri Aurora PostgreSQL, lihat [Aurora PostgreSQL versi ekstensi apg\$1plan\$1mgmt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) dalam *Catatan Rilis untuk Aurora PostgreSQL*.
## Batasan manajemen rencana kueri
Rilis manajemen rencana kueri Aurora PostgreSQL saat ini memiliki batasan berikut.
+ **Rencana tidak ditangkap untuk pernyataan yang mereferensikan relasi sistem** – Pernyataan yang mereferensikan relasi sistem, seperti `pg_class`, tidak ditangkap. Hal ini berlaku berdasarkan desain untuk mencegah sejumlah besar rencana yang dihasilkan sistem yang digunakan secara internal agar tidak ditangkap. Hal ini juga berlaku untuk tabel sistem dalam tampilan.
+ **Kelas instans DB yang lebih besar mungkin diperlukan untuk cluster Aurora PostgreSQL DB Anda** — Bergantung pada beban kerja, manajemen rencana kueri mungkin memerlukan kelas instans DB yang memiliki lebih dari 2 v. CPUs Jumlah `max_worker_processes` dibatasi oleh ukuran kelas instans DB. Jumlah `max_worker_processes` yang disediakan oleh kelas instans DB 2-vCPU (db.t3.medium, misalnya) mungkin tidak cukup untuk beban kerja tertentu. Kami menyarankan Anda memilih kelas instans DB dengan lebih dari 2 v CPUs untuk klaster Aurora PostgreSQL DB Anda jika Anda menggunakan manajemen rencana kueri.
Ketika kelas instans DB tidak dapat mendukung beban kerja, manajemen rencana kueri memunculkan pesan kesalahan seperti berikut ini.
```
WARNING: could not register plan insert background process
HINT: You may need to increase max_worker_processes.
```
Dalam hal ini, Anda harus menaikkan skala klaster DB Aurora PostgreSQL Anda ke ukuran kelas instans DB dengan lebih banyak memori. Untuk informasi selengkapnya, lihat [Mesin DB yang didukung untuk kelas instans DB](Concepts.DBInstanceClass.SupportAurora.md).
+ **Rencana yang sudah disimpan dalam sesi tidak terpengaruh** – Manajemen rencana kueri menyediakan cara untuk memengaruhi rencana kueri tanpa mengubah kode aplikasi. Namun, ketika rencana generik sudah disimpan dalam sesi yang ada dan jika Anda ingin mengubah rencana kueri, maka Anda harus terlebih dahulu mengatur `plan_cache_mode` ke `force_custom_plan` dalam grup parameter klaster DB.
+ `queryid` di `apg_plan_mgmt.dba_plans` dan `pg_stat_statements` dapat menyimpang ketika:
+ Objek dihapus dan dibuat ulang setelah disimpan dalam apg\$1plan\$1mgmt.dba\$1plans.
+ Tabel `apg_plan_mgmt.plans` diimpor dari klaster lain.
Untuk informasi tentang berbagai versi fitur manajemen rencana kueri Aurora PostgreSQL, lihat [Aurora PostgreSQL versi ekstensi apg\$1plan\$1mgmt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) dalam *Catatan Rilis untuk Aurora PostgreSQL*.
## Terminologi manajemen rencana kueri
Istilah berikut digunakan di seluruh topik ini:
**pernyataan terkelola**
Pernyataan SQL yang ditangkap oleh pengoptimal dalam manajemen rencana kueri. Pernyataan terkelola memiliki satu atau beberapa rencana eksekusi kueri yang disimpan dalam tampilan `apg_plan_mgmt.dba_plans`.
**acuan dasar rencana**
Kumpulan rencana yang disetujui untuk pernyataan terkelola tertentu. Artinya, semua rencana untuk pernyataan terkelola yang telah “Disetujui” untuk kolom `status`-nya dalam tampilan `dba_plan`.
**riwayat rencana**
Kumpulan semua rencana yang ditangkap untuk suatu pernyataan terkelola tertentu. Riwayat rencana berisi semua rencana yang ditangkap untuk pernyataan tersebut, terlepas dari statusnya.
**regresi rencana kueri**
Kasus ketika pengoptimal memilih rencana yang kurang optimal dibandingkan dengan sebelum perubahan tertentu dilakukan pada lingkungan basis data, seperti versi PostgreSQL baru atau perubahan statistik.
## Versi manajemen rencana kueri Aurora PostgreSQL
Manajemen rencana kueri didukung oleh semua rilis Aurora PostgreSQL yang tersedia saat ini. Untuk informasi selengkapnya, lihat [Daftar pembaruan Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) dalam *Catatan Rilis untuk Aurora PostgreSQL*.
Fungsionalitas manajemen rencana kueri ditambahkan ke klaster DB Aurora PostgreSQL Anda saat Anda menginstal ekstensi `apg_plan_mgmt`. Berbagai versi Aurora PostgreSQL mendukung versi ekstensi `apg_plan_mgmt` yang berbeda-beda. Kami menyarankan agar Anda meningkatkan ekstensi manajemen rencana kueri ke rilis terbaru untuk versi Aurora PostgreSQL Anda.
**catatan**
Untuk catatan rilis untuk setiap versi ekstensi `apg_plan_mgmt`, lihat [Aurora PostgreSQL versi ekstensi apg\$1plan\$1mgmt](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) dalam *Catatan Rilis untuk Aurora PostgreSQL*.
Anda dapat mengidentifikasi versi yang berjalan di klaster Anda dengan menghubungkan ke instans menggunakan `psql` lalu menggunakan perintah meta \$1dx untuk menampilkan daftar ekstensi seperti yang ditunjukkan berikut.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------------+---------+---------------+-------------------------------------------------------------------
apg_plan_mgmt | 1.0 | apg_plan_mgmt | Amazon Aurora with PostgreSQL compatibility Query Plan Management
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)
```
Output menunjukkan bahwa klaster ini menggunakan ekstensi versi 1.0. Hanya versi `apg_plan_mgmt` tertentu yang tersedia untuk versi Aurora PostgreSQL tertentu. Dalam beberapa kasus, Anda mungkin perlu meningkatkan klaster DB Aurora PostgreSQL ke rilis minor baru atau menerapkan patch sehingga Anda dapat meningkatkan ke manajemen rencana kueri versi terbaru. `apg_plan_mgmt` versi 1.0 yang ditampilkan dalam output berasal dari klaster DB Aurora PostgreSQL versi 10.17, yang tidak memiliki `apg_plan_mgmt` versi lebih baru. Dalam hal ini, klaster DB Aurora PostgreSQL harus ditingkatkan ke versi PostgreSQL yang lebih baru.
Untuk informasi selengkapnya tentang meningkatkan klaster DB Aurora PostgreSQL Anda ke PostgreSQL versi baru, lihat [Pembaruan mesin database untuk Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
Untuk mempelajari cara meningkatkan ekstensi `apg_plan_mgmt`, lihat [Meningkatkan manajemen rencana kueri Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade).
## Mengaktifkan manajemen rencana kueri Aurora PostgreSQL
Penyiapan manajemen rencana kueri untuk klaster DB Aurora PostgreSQL Anda memerlukan penginstalan ekstensi dan perubahan beberapa pengaturan parameter klaster DB. Anda memerlukan izin `rds_superuser` untuk menginstal ekstensi `apg_plan_mgmt` dan mengaktifkan fitur untuk klaster DB Aurora PostgreSQL.
Saat ekstensi ini diinstal, sebuah peran baru, `apg_plan_mgmt`, akan dibuat. Peran ini memungkinkan pengguna basis data melihat, mengelola, dan memelihara rencana kueri. Sebagai administrator dengan hak akses `rds_superuser`, pastikan untuk memberikan peran `apg_plan_mgmt` kepada pengguna basis data sesuai kebutuhan.
Hanya pengguna dengan peran `rds_superuser` yang dapat menyelesaikan prosedur berikut. `rds_superuser` diperlukan untuk membuat ekstensi `apg_plan_mgmt` dan peran `apg_plan_mgmt`. Pengguna harus diberi peran `apg_plan_mgmt` untuk mengelola ekstensi `apg_plan_mgmt`.
**Mengaktifkan manajemen rencana kueri untuk klaster DB Aurora PostgreSQL Anda**
Langkah-langkah berikut mengaktifkan manajemen rencana kueri untuk semua pernyataan SQL yang dikirimkan ke klaster DB Aurora PostgreSQL. Hal ini dikenal sebagai mode *otomatis*. Untuk mempelajari selengkapnya tentang perbedaan di antara mode, lihat [Mengambil rencana eksekusi Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Buat grup parameter klaster DB kustom untuk klaster DB Aurora PostgreSQL Anda. Anda perlu mengubah parameter tertentu untuk mengaktifkan manajemen rencana kueri dan mengatur perilakunya. Untuk informasi selengkapnya, lihat [Membuat grup parameter DB di ](USER_WorkingWithParamGroups.Creating.md).
1. Buka grup parameter klaster DB kustom dan atur parameter `rds.enable_plan_management` ke `1`, seperti yang ditunjukkan pada gambar berikut ini.
![\[Gambar grup parameter cluster DB.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-qpm-custom-db-cluster-param-change-1.png)
Untuk informasi selengkapnya, lihat [Memodifikasi parameter dalam grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Buat grup parameter DB kustom yang dapat Anda gunakan untuk mengatur parameter rencana kueri di tingkat instans. Untuk informasi selengkapnya, lihat [Membuat grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
1. Ubah instans penulis klaster DB Aurora PostgreSQL untuk menggunakan grup parameter DB kustom. Untuk informasi selengkapnya, lihat [Memodifikasi instans DB dalam klaster DB](Aurora.Modifying.md#Aurora.Modifying.Instance).
1. Ubah klaster DB Aurora PostgreSQL untuk menggunakan grup parameter klaster DB kustom. Untuk informasi selengkapnya, lihat [Memodifikasi klaster DB dengan menggunakan konsol, CLI, dan API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
1. Boot ulang instans DB Anda untuk mengaktifkan pengaturan grup parameter kustom.
1. Hubungkan ke titik akhir instans DB untuk klaster DB Aurora PostgreSQL Anda menggunakan `psql` atau `pgAdmin`. Contoh berikut menggunakan akun `postgres` default untuk peran `rds_superuser`.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=my-db
```
1. Buat ekstensi `apg_plan_mgmt` untuk instans DB Anda, seperti yang ditunjukkan berikut ini.
```
labdb=> CREATE EXTENSION apg_plan_mgmt;
CREATE EXTENSION
```
**Tip**
Instal ekstensi `apg_plan_mgmt` dalam basis data templat untuk aplikasi Anda. Basis data templat default diberi nama `template1`. Untuk mempelajari selengkapnya, lihat [Template Databases](https://www.postgresql.org/docs/current/manage-ag-templatedbs.html) dalam dokumentasi PostgreSQL.
1. Ubah parameter `apg_plan_mgmt.capture_plan_baselines` menjadi `automatic`. Pengaturan ini akan menyebabkan pengoptimal menghasilkan rencana untuk setiap pernyataan SQL yang direncanakan atau dijalankan dua kali atau lebih.
**catatan**
Manajemen rencana kueri juga memiliki mode *manual* yang dapat Anda gunakan untuk pernyataan SQL tertentu. Untuk mempelajari selengkapnya, lihat [Mengambil rencana eksekusi Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Ubah nilai parameter `apg_plan_mgmt.use_plan_baselines` menjadi "on". Parameter ini menyebabkan pengoptimal memilih rencana untuk pernyataan dari acuan dasar rencananya. Untuk mempelajari selengkapnya, lihat [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
**catatan**
Anda dapat mengubah nilai salah satu parameter dinamis ini untuk sesi tanpa perlu mem-boot ulang instans.
Ketika pengaturan manajemen rencana kueri Anda selesai, pastikan untuk memberikan peran `apg_plan_mgmt` kepada setiap pengguna basis data yang perlu melihat, mengelola, atau memelihara rencana kueri.
## Meningkatkan manajemen rencana kueri Aurora PostgreSQL
Kami menyarankan agar Anda meningkatkan ekstensi manajemen rencana kueri ke rilis terbaru untuk versi Aurora PostgreSQL Anda.
1. Hubungkan ke instans penulis klaster DB Aurora PostgreSQL Anda sebagai pengguna yang memiliki hak akses `rds_superuser`. Jika Anda menyimpan nama default saat menyiapkan instans, Anda akan terhubung sebagai `postgres`. Contoh ini menunjukkan cara menggunakan `psql`, tetapi Anda juga dapat menggunakan pgAdmin jika mau.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Jalankan kueri berikut untuk meningkatkan ekstensi.
```
ALTER EXTENSION apg_plan_mgmt UPDATE TO '2.1';
```
1. Gunakan fungsi [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) untuk memperbarui hash semua rencana. Pengoptimal akan memvalidasi semua rencana yang Disetujui, Tidak Disetujui, dan Ditolak untuk memastikan bahwa rencana tersebut masih layak untuk ekstensi versi baru.
```
SELECT apg_plan_mgmt.validate_plans('update_plan_hash');
```
Untuk mempelajari selengkapnya tentang penggunaan fungsi ini, lihat [Memvalidasi rencana](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
1. Gunakan fungsi [apg\$1plan\$1mgmt.reload](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.reload) untuk me-refresh rencana apa pun di memori bersama dengan rencana yang divalidasi dari tampilan dba\$1plans.
```
SELECT apg_plan_mgmt.reload();
```
Untuk mempelajari selengkapnya tentang semua fungsi yang tersedia untuk manajemen rencana kueri, lihat [Referensi fungsi untuk manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Functions.md).
## Menonaktifkan manajemen rencana kueri Aurora PostgreSQL
Anda dapat menonaktifkan manajemen rencana kueri setiap saat dengan menonaktifkan `apg_plan_mgmt.use_plan_baselines` dan `apg_plan_mgmt.capture_plan_baselines`.
```
labdb=> SET apg_plan_mgmt.use_plan_baselines = off;
labdb=> SET apg_plan_mgmt.capture_plan_baselines = off;
```
# Praktik terbaik untuk manajemen rencana kueri Aurora PostgreSQL
Manajemen rencana kueri memungkinkan Anda mengendalikan cara dan waktu perubahan rencana eksekusi kueri. Sebagai DBA, tujuan utama Anda saat menggunakan QPM termasuk mencegah regresi ketika ada perubahan pada basis data Anda, dan mengontrol apakah akan mengizinkan pengoptimisasi menggunakan rencana baru. Di bagian berikut ini, Anda dapat menemukan beberapa praktik terbaik yang direkomendasikan untuk menggunakan manajemen rencana kueri. Pendekatan manajemen rencana yang proaktif dan reaktif berbeda dari segi cara dan waktu persetujuan terhadap penggunaan rencana baru.
**Contents**
+ [Manajemen rencana proaktif untuk membantu mencegah regresi performa](#AuroraPostgreSQL.Optimize.BestPractice.Proactive)
+ [Memastikan stabilitas rencana setelah peningkatan versi mayor](#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade)
+ [Manajemen rencana reaktif untuk mendeteksi dan memperbaiki regresi performa](#AuroraPostgreSQL.Optimize.BestPractice.Reactive)
## Manajemen rencana proaktif untuk membantu mencegah regresi performa
Guna mencegah regresi performa rencana terjadi, Anda perlu *mengembangkan* acuan dasar rencana dengan menjalankan prosedur yang membandingkan performa rencana yang baru ditemukan dengan performa acuan dasar yang sudah ada untuk rencana yang Disetujui, lalu secara otomatis menyetujui rangkaian rencana tercepat sebagai acuan dasar baru. Dengan cara ini, acuan dasar rencana meningkat dari waktu ke waktu seiring rencana yang lebih cepat ditemukan.
1. Di lingkungan pengembangan, temukan pernyataan SQL yang memiliki dampak terbesar pada performa atau throughput sistem. Kemudian, ambil rencana untuk pernyataan tersebut seperti yang dijelaskan dalam [Mengambil rencana secara manual untuk pernyataan SQL tertentu](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Manual) dan [Mengambil rencana secara otomatis](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Ekspor rencana yang diambil dari lingkungan pengembangan lalu impor ke lingkungan produksi. Untuk informasi selengkapnya, lihat [Mengekspor dan mengimpor rencana terkelola untuk Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md).
1. Dalam produksi, jalankan aplikasi Anda dan terapkan penggunaan rencana terkelola yang disetujui. Untuk informasi selengkapnya, lihat [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). Saat aplikasi berjalan, tambahkan juga rencana baru saat pengoptimisasi menemukan rencana tersebut. Untuk informasi selengkapnya, lihat [Mengambil rencana secara otomatis](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Analisis rencana yang belum disetujui dan setujui rencana yang beperforma baik. Untuk informasi selengkapnya, lihat [Mengevaluasi performa rencana](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Saat aplikasi Anda terus berjalan, pengoptimisasi mulai menggunakan rencana baru sesuai kebutuhan.
### Memastikan stabilitas rencana setelah peningkatan versi mayor
Setiap versi mayor PostgreSQL menyertakan penyempurnaan dan perubahan pada pengoptimisasi kueri yang dirancang untuk menaikkan performa. Namun, rencana eksekusi kueri yang dihasilkan oleh pengoptimisasi di versi sebelumnya dapat menyebabkan regresi performa di versi yang ditingkatkan yang lebih baru. Anda dapat menggunakan manajemen rencana kueri untuk mengatasi masalah performa ini dan untuk memastikan stabilitas rencana setelah peningkatan versi mayor.
Pengoptimisasi selalu menggunakan rencana yang Disetujui dengan biaya minimum, meskipun ada lebih dari satu rencana yang Disetujui untuk pernyataan yang sama. Setelah peningkatan, pengoptimisasi mungkin menemukan rencana baru, tetapi rencana tersebut akan disimpan sebagai rencana yang Tidak Disetujui. Rencana ini dilakukan hanya jika disetujui menggunakan gaya reaktif manajemen rencana dengan parameter unapproved\$1plan\$1execution\$1threshold. Anda dapat memaksimalkan stabilitas rencana menggunakan gaya proaktif manajemen rencana dengan parameter evolve\$1plan\$1baselines. Parameter ini membandingkan performa rencana baru dengan rencana lama dan menyetujui atau menolak rencana yang setidaknya 10% lebih cepat dari rencana terbaik berikutnya.
Setelah peningkatan, Anda dapat menggunakan fungsi `evolve_plan_baselines` untuk membandingkan performa rencana sebelum dan sesudah peningkatan menggunakan pengikatan parameter kueri Anda. Langkah-langkah berikut mengasumsikan bahwa Anda telah menggunakan rencana terkelola yang disetujui di lingkungan produksi Anda, seperti yang dijelaskan dalam [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
1. Sebelum peningkatan, jalankan aplikasi Anda bersama pengelola rencana kueri yang berjalan. Saat aplikasi berjalan, tambahkan juga rencana baru saat pengoptimisasi menemukan rencana tersebut. Untuk informasi selengkapnya, lihat [Mengambil rencana secara otomatis](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Evaluasi performa setiap rencana. Untuk informasi selengkapnya, lihat [Mengevaluasi performa rencana](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Setelah peningkatan, analisis kembali rencana Anda yang disetujui menggunakan fungsi `evolve_plan_baselines`. Bandingkan performa sebelum dan sesudah menggunakan pengikatan parameter kueri Anda. Jika rencana baru cepat, Anda dapat menambahkannya ke rencana yang disetujui. Jika lebih cepat dari rencana lain untuk pengikatan parameter yang sama, maka Anda dapat menandai rencana yang lebih lambat sebagai Ditolak.
Untuk informasi selengkapnya, lihat [Menyetujui rencana yang lebih baik](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Approving). Untuk informasi referensi tentang fungsi ini, lihat [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines).
Untuk informasi selengkapnya, lihat artikel [Memastikan performa yang konsisten setelah peningkatan versi mayor dengan Manajemen Rencana Kueri Amazon Aurora Edisi Kompatibel PostgreSQL](https://aws.amazon.com/blogs/database/ensuring-consistent-performance-after-major-version-upgrades-with-amazon-aurora-postgresql-query-plan-management/).
**catatan**
Saat Anda melakukan peningkatan versi mayor menggunakan replikasi logis atau AWS DMS, pastikan Anda mereplikasi skema `apg_plan_mgmt` untuk memastikan rencana yang sudah ada disalin ke instans yang ditingkatkan. Untuk informasi selengkapnya tentang replikasi logis, lihat [Menggunakan replikasi logis untuk melakukan peningkatan versi mayor untuk Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
## Manajemen rencana reaktif untuk mendeteksi dan memperbaiki regresi performa
Dengan memantau aplikasi Anda saat berjalan, Anda dapat mendeteksi rencana yang menyebabkan regresi performa. Saat Anda mendeteksi regresi, Anda dapat secara manual menolak atau memperbaiki rencana yang buruk dengan mengikuti langkah-langkah berikut:
1. Saat aplikasi Anda berjalan, terapkan penggunaan rencana terkelola dan tambahkan secara otomatis rencana yang baru ditemukan sebagai rencana yang tidak disetujui. Untuk informasi lebih lanjut, lihat [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md) dan [Mengambil rencana secara otomatis](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Pantau regresi performa pada aplikasi Anda yang sedang berjalan.
1. Ketika Anda menemukan regresi rencana, atur status rencana menjadi `rejected`. Saat pengoptimisasi kembali menjalankan pernyataan SQL, pengoptimisasi akan secara otomatis mengabaikan rencana yang ditolak dan menggunakan rencana berbeda yang telah disetujui. Untuk informasi selengkapnya, lihat [Menolak atau menonaktifkan rencana yang lebih lambat](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Rejecting).
Dalam beberapa kasus, Anda mungkin lebih memilih untuk memperbaiki rencana yang buruk daripada menolak, menonaktifkan, atau menghapusnya. Gunakan ekstensi `pg_hint_plan` untuk bereksperimen dalam meningkatkan rencana. Dengan `pg_hint_plan`, Anda menggunakan komentar khusus untuk meminta pengoptimisasi mengganti caranya dalam membuat rencana. Lihat informasi yang lebih lengkap di [Memperbaiki rencana menggunakan pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan).
# Manajemen rencana kueri Aurora PostgreSQL
Dengan manajemen rencana kueri diaktifkan untuk klaster DB Aurora PostgreSQL Anda, pengoptimisasi akan menghasilkan dan menyimpan rencana eksekusi kueri untuk pernyataan SQL apa pun yang diproses lebih dari sekali. Pengoptimisasi selalu mengatur status rencana yang pertama kali dibuat dari suatu pernyataan terkelola ke `Approved`, dan menyimpannya di tampilan `dba_plans`.
Rangkaian rencana yang disetujui yang disimpan untuk suatu pernyataan terkelola disebut sebagai *acuan dasar rencana*. Saat aplikasi berjalan, pengoptimisasi dapat membuat rencana tambahan untuk pernyataan terkelola. Pengoptimisasi mengatur rencana tambahan yang diambil ke status `Unapproved`.
Kemudian, Anda dapat memutuskan apakah rencana `Unapproved` berjalan dengan baik dan mengubahnya menjadi `Approved`, `Rejected`, atau `Preferred`. Untuk melakukannya, Anda menggunakan fungsi `apg_plan_mgmt.evolve_plan_baselines` atau fungsi `apg_plan_mgmt.set_plan_status`.
Ketika pengoptimisasi menghasilkan rencana untuk pernyataan SQL, manajemen rencana kueri menyimpan rencana ini dalam tabel `apg_plan_mgmt.plans`. Pengguna basis data yang telah diberi peran `apg_plan_mgmt` dapat melihat detail rencana dengan mengueri tampilan `apg_plan_mgmt.dba_plans`. Misalnya, kueri berikut menampilkan daftar detail untuk rencana yang saat ini ada dalam tampilan untuk klaster DB PostgreSQL Aurora non-produksi.
+ `sql_hash` – Pengidentifikasi untuk pernyataan SQL yang merupakan nilai hash untuk teks yang dinormalisasi dari pernyataan SQL.
+ `plan_hash` – Pengidentifikasi unik untuk rencana yang merupakan kombinasi dari `sql_hash` dan hash rencana.
+ `status` – Status rencana. Pengoptimisasi dapat menjalankan rencana yang disetujui.
+ `enabled` – Menunjukkan apakah rencana siap digunakan (true) atau tidak (false).
+ `plan_outline` – Representasi rencana yang digunakan untuk membuat ulang rencana eksekusi sebenarnya. Operator dalam struktur pohon akan dipetakan ke operator dalam output EXPLAIN.
Tampilan `apg_plan_mgmt.dba_plans` memiliki lebih banyak kolom yang berisi semua detail rencana, misalnya, waktu rencana terakhir digunakan. Untuk detail lengkap, lihat [Referensi untuk tampilan apg\$1plan\$1mgmt.dba\$1plans untuk Aurora PostgreSQL Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
## Normalisasi dan hash SQL
Dalam tampilan `apg_plan_mgmt.dba_plans`, Anda dapat mengidentifikasi pernyataan terkelola dengan nilai hash SQL. Hash SQL dihitung pada representasi ternormalisasi dari pernyataan SQL yang menghilangkan beberapa perbedaan, seperti nilai-nilai literal.
Proses *normalisasi* untuk setiap pernyataan SQL mempertahankan spasi dan huruf besar/kecil, sehingga Anda masih dapat membaca dan memahami inti dari pernyataan SQL tersebut. Normalisasi akan menghapus atau mengganti item berikut.
+ Komentar blok di depan
+ Kata kunci EXPLAIN dan opsi EXPLAIN, serta EXPLAIN ANALYZE
+ Spasi di belakang
+ Semua literal
Sebagai contoh, amati pernyataan berikut.
```
/*Leading comment*/ EXPLAIN SELECT /* Query 1 */ * FROM t WHERE x > 7 AND y = 1;
```
Manajemen rencana kueri menormalkan pernyataan ini seperti yang ditunjukkan:
```
SELECT /* Query 1 */ * FROM t WHERE x > CONST AND y = CONST;
```
Normalisasi memungkinkan hash SQL yang sama digunakan untuk pernyataan SQL serupa yang mungkin hanya berbeda dalam hal nilai literal atau parameternya. Dengan kata lain, bisa ada lebih dari satu rencana untuk hash SQL yang sama, dengan sebuah rencana berbeda yang optimal dalam kondisi yang berbeda-beda.
**catatan**
Pernyataan SQL tunggal yang digunakan dengan berbagai skema akan memiliki rencana yang berbeda-beda karena terikat pada skema tertentu saat runtime. Perencana menggunakan statistik untuk pengikatan skema untuk memilih rencana yang optimal.
Untuk mempelajari selengkapnya tentang cara pengoptimisasi memilih rencana, lihat [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). Di bagian tersebut, Anda dapat mempelajari cara menggunakan `EXPLAIN` dan `EXPLAIN ANALYZE` untuk melihat pratinjau rencana sebelum benar-benar digunakan. Untuk detailnya, lihat [Menganalisis rencana yang dipilih pengoptimisasi](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Untuk gambar yang menguraikan proses untuk memilih rencana, lihat [Bagaimana cara pengoptimisasi memilih rencana yang akan dijalankan](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
# Mengambil rencana eksekusi Aurora PostgreSQL
Manajemen rencana kueri Aurora PostgreSQL menawarkan dua mode berbeda untuk mengambil rencana eksekusi kueri, yaitu otomatis atau manual. Anda memilih mode dengan mengatur nilai `apg_plan_mgmt.capture_plans_baselines` ke `automatic` atau ke `manual`. Anda dapat mengambil rencana eksekusi untuk pernyataan SQL tertentu menggunakan pengambilan rencana manual. Alternatifnya, Anda dapat mengambil semua rencana (atau rencana yang paling lambat) yang dijalankan dua kali atau lebih saat aplikasi Anda berjalan menggunakan pengambilan rencana otomatis.
Saat mengambil rencana, pengoptimisasi selalu mengatur status rencana yang pertama kali diambil untuk suatu pernyataan terkelola menjadi `approved`. Pengoptimisasi selalu mengatur status setiap rencana tambahan yang diambil untuk suatu pernyataan terkelola menjadi `unapproved`. Namun, kadang-kadang lebih dari satu rencana dapat disimpan dengan status `approved`. Hal ini dapat terjadi ketika beberapa rencana dibuat untuk sebuah pernyataan secara paralel dan sebelum rencana pertama untuk pernyataan tersebut ditetapkan.
Untuk mengontrol jumlah maksimum rencana yang dapat diambil dan disimpan di tampilan `dba_plans`, atur parameter `apg_plan_mgmt.max_plans` dalam grup parameter tingkat instans DB Anda. Perubahan pada parameter `apg_plan_mgmt.max_plans` mengharuskan instans DB di-boot ulang agar nilai baru dapat diterapkan. Untuk informasi selengkapnya, lihat parameter [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans).
## Mengambil rencana secara manual untuk pernyataan SQL tertentu
Jika Anda memiliki kumpulan pernyataan SQL yang diketahui untuk dikelola, masukkan pernyataan tersebut ke dalam file skrip SQL lalu ambil rencana secara manual. Hal berikut ini menunjukkan contoh psql tentang cara mengambil rencana kueri secara manual untuk kumpulan pernyataan SQL.
```
psql> SET apg_plan_mgmt.capture_plan_baselines = manual;
psql> \i my-statements.sql
psql> SET apg_plan_mgmt.capture_plan_baselines = off;
```
Setelah mengambil rencana untuk setiap pernyataan SQL, pengoptimisasi menambahkan baris baru ke tampilan `apg_plan_mgmt.dba_plans`.
Kami menyarankan Anda menggunakan pernyataan EXPLAIN atau EXPLAIN EXECUTE di file skrip SQL. Pastikan Anda memasukkan cukup variasi dalam nilai parameter untuk mengambil semua rencana yang diinginkan.
Jika Anda mengetahui rencana yang lebih baik daripada rencana berbiaya minimum dari pengoptimisasi, Anda mungkin dapat memaksa pengoptimisasi untuk menggunakan rencana yang lebih baik. Untuk melakukannya, tentukan satu atau beberapa petunjuk pengoptimal. Untuk informasi selengkapnya, lihat [Memperbaiki rencana menggunakan pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). Untuk membandingkan performa rencana `unapproved` dan `approved` serta menyetujui, menolak, atau menghapusnya, lihat [Mengevaluasi performa rencana](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## Mengambil rencana secara otomatis
Gunakan pengambilan rencana otomatis untuk situasi seperti berikut ini:
+ Anda tidak mengetahui pernyataan SQL spesifik yang ingin Anda kelola.
+ Anda memiliki ratusan atau ribuan pernyataan SQL untuk dikelola.
+ Aplikasi Anda menggunakan API klien. Misalnya, JDBC menggunakan pernyataan yang disiapkan tanpa nama atau pernyataan mode massal yang tidak dapat dinyatakan dalam psql.
**Untuk mengambil rencana secara otomatis**
1. Aktifkan pengambilan rencana otomatis dengan mengatur `apg_plan_mgmt.capture_plan_baselines` ke `automatic` dalam grup parameter tingkat instans DB. Untuk informasi selengkapnya, lihat [Memodifikasi parameter dalam grup parameter DB di ](USER_WorkingWithParamGroups.Modifying.md).
1. Saat aplikasi berjalan, pengoptimisasi mengambil rencana untuk setiap pernyataan SQL yang berjalan setidaknya dua kali.
Saat aplikasi berjalan dengan pengaturan parameter manajemen rencana kueri default, pengoptimisasi mengambil rencana untuk setiap pernyataan SQL yang berjalan setidaknya dua kali. Dengan mengambil semua rencana saat menggunakan pengaturan default, overhead run-time yang diperlukan akan sangat kecil dan hal ini dapat dilakukan dalam produksi.
**Untuk menonaktifkan pengambilan rencana otomatis**
+ Tetapkan parameter `apg_plan_mgmt.capture_plan_baselines` ke `off` dari grup parameter tingkat instans DB.
Untuk mengukur performa rencana yang belum disetujui dan menyetujui, menolak, atau menghapusnya, lihat [Mengevaluasi performa rencana](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
# Menggunakan rencana terkelola Aurora PostgreSQL
Agar pengoptimisasi menggunakan rencana yang diambil untuk pernyataan terkelola Anda, atur parameter `apg_plan_mgmt.use_plan_baselines` ke `true`. Berikut ini adalah contoh instans lokal.
```
SET apg_plan_mgmt.use_plan_baselines = true;
```
Sementara aplikasi berjalan, pengaturan ini menyebabkan pengoptimisasi menggunakan rencana berbiaya minimum, pilihan, atau disetujui yang valid dan diaktifkan untuk setiap pernyataan terkelola.
## Menganalisis rencana yang dipilih pengoptimisasi
Jika parameter `apg_plan_mgmt.use_plan_baselines` diatur ke `true`, Anda dapat menggunakan pernyataan SQL EXPLAIN ANALYZE untuk membuat pengoptimisasi menampilkan rencana yang akan digunakan jika pengoptimisasi akan menjalankan pernyataan tersebut. Berikut adalah contohnya.
```
EXPLAIN ANALYZE EXECUTE rangeQuery (1,10000);
```
```
QUERY PLAN
--------------------------------------------------------------------------
Aggregate (cost=393.29..393.30 rows=1 width=8) (actual time=7.251..7.251 rows=1 loops=1)
-> Index Only Scan using t1_pkey on t1 t (cost=0.29..368.29 rows=10000 width=0) (actual time=0.061..4.859 rows=10000 loops=1)
Index Cond: ((id >= 1) AND (id <= 10000))
Heap Fetches: 10000
Planning time: 1.408 ms
Execution time: 7.291 ms
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1984047223, Plan Hash: 512153379
```
Output ini menunjukkan rencana yang Disetujui dari acuan dasar (baseline) yang akan berjalan. Namun, output ini juga menunjukkan bahwa rencana yang berbiaya lebih rendah ditemukan. Dalam hal ini, Anda perlu mengambil rencana berbiaya minimum yang baru ini dengan mengaktifkan pengambilan rencana otomatis seperti yang dijelaskan dalam [Mengambil rencana secara otomatis](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
Rencana baru selalu diambil oleh pengoptimisasi sebagai `Unapproved`. Gunakan fungsi `apg_plan_mgmt.evolve_plan_baselines` untuk membandingkan rencana dan mengubahnya menjadi disetujui, ditolak, atau dinonaktifkan. Untuk informasi selengkapnya, lihat [Mengevaluasi performa rencana](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## Bagaimana cara pengoptimisasi memilih rencana yang akan dijalankan
Biaya rencana eksekusi adalah perkiraan yang dibuat oleh pengoptimisasi untuk membandingkan beberapa rencana yang berbeda. Saat menghitung biaya rencana, pengoptimal mencakup faktor-faktor seperti CPU dan I/O operasi yang diperlukan oleh rencana itu. Untuk mempelajari selengkapnya tentang perkiraan biaya perencana kueri PostgreSQL, lihat [Query Planning](https://www.postgresql.org/docs/current/runtime-config-query.html) dalam dokumentasi PostgreSQL.
Gambar berikut menunjukkan bagaimana rencana dipilih untuk pernyataan SQL tertentu ketika manajemen rencana kueri aktif, dan ketika tidak.
![\[Alur kerja manajemen rencana kueri Aurora PostgreSQL\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/aurora-query-plan-mgmt_processing-flow.png)
Alurnya adalah sebagai berikut:
1. Pengoptimisasi menghasilkan rencana berbiaya minimum untuk pernyataan SQL.
1. Jika manajemen rencana kueri tidak aktif, rencana pengoptimisasi akan segera dijalankan (A. Jalankan rencana Pengoptimisasi). Manajemen rencana kueri tidak aktif ketika parameter `apg_plan_mgmt.capture_plan_baselines` dan `apg_plan_mgmt.use_plan_baselines` berada pada pengaturan default-nya (masing-masing “off” dan “false”).
Jika tidak, manajemen rencana kueri aktif. Dalam hal ini, pernyataan SQL dan rencana pengoptimisasi untuk pernyataan tersebut akan dinilai lebih lanjut sebelum rencana dipilih.
**Tip**
Pengguna basis data dengan peran `apg_plan_mgmt` dapat secara proaktif membandingkan rencana, mengubah status rencana, dan memaksa penggunaan rencana tertentu sesuai kebutuhan. Untuk informasi selengkapnya, lihat [Meningkatkan rencana kueri PostgreSQL Aurora](AuroraPostgreSQL.Optimize.Maintenance.md).
1. Pernyataan SQL mungkin sudah memiliki rencana yang disimpan oleh manajemen rencana kueri di masa lalu. Rencana disimpan di `apg_plan_mgmt.dba_plans`, bersama dengan informasi tentang pernyataan SQL yang digunakan untuk membuatnya. Informasi tentang rencana akan menyertakan statusnya. Status rencana dapat menentukan apakah rencana tersebut digunakan atau tidak, sebagai berikut.
1. Jika rencana tidak termasuk di antara rencana yang disimpan untuk pernyataan SQL, berarti ini adalah pertama kalinya rencana spesifik ini dihasilkan oleh pengoptimisasi untuk pernyataan SQL yang diberikan. Rencana dikirim ke Pemrosesan Pengambilan Rencana (4).
1. Jika rencana termasuk di antara rencana yang disimpan dan statusnya Disetujui atau Pilihan, rencana ini akan dijalankan (A. Jalankan rencana Pengoptimisasi).
Jika rencana termasuk di antara rencana yang disimpan, tetapi tidak berstatus Disetujui atau Pilihan, rencana ini akan dikirim ke Pemrosesan Pengambilan Rencana (4).
1. Ketika rencana diambil pertama kalinya untuk pernyataan SQL tertentu, status rencana ini selalu diatur ke Disetujui (P1). Jika pengoptimisasi selanjutnya menghasilkan rencana yang sama untuk pernyataan SQL yang sama, status rencana tersebut diubah menjadi Tidak Disetujui (P1\$1n).
Dengan rencana diambil dan statusnya diperbarui, evaluasi berlanjut pada langkah berikutnya (5).
1. *Acuan dasar* rencana terdiri dari riwayat pernyataan SQL dan rencananya dalam berbagai status. Manajemen rencana kueri dapat mempertimbangkan acuan dasar ini saat memilih rencana, tergantung pada apakah opsi Gunakan acuan dasar rencana diaktifkan atau tidak, sebagai berikut.
+ Gunakan acuan dasar rencana “tidak aktif” ketika parameter `apg_plan_mgmt.use_plan_baselines` diatur ke nilai default (`false`). Rencana ini tidak akan dibandingkan dengan acuan dasar (baseline) sebelum dijalankan (A. Jalankan rencana Pengoptimisasi).
+ Gunakan acuan dasar rencana “aktif” saat parameter `apg_plan_mgmt.use_plan_baselines` diatur ke `true`. Rencana tersebut dinilai lebih lanjut menggunakan acuan dasar (6).
1. Rencana tersebut dibandingkan dengan rencana lain untuk pernyataan di acuan dasar.
1. Jika rencana pengoptimisasi termasuk di antara rencana di acuan dasar, statusnya diperiksa (7a).
1. Jika rencana pengoptimisasi tidak termasuk di antara rencana dalam acuan dasar, rencana ini akan ditambahkan ke rencana untuk pernyataan tersebut sebagai rencana `Unapproved` baru.
1. Status rencana diperiksa hanya untuk menentukan apakah statusnya Tidak Disetujui.
1. Jika status rencana Tidak Disetujui, perkiraan biaya rencana ini dibandingkan dengan perkiraan biaya yang ditentukan untuk ambang batas rencana eksekusi yang tidak disetujui.
+ Jika perkiraan biaya rencana di bawah ambang batas, pengoptimisasi akan menggunakannya meskipun rencana ini Tidak Disetujui (A. Jalankan rencana Pengoptimisasi). Umumnya, pengoptimisasi tidak akan menjalankan rencana yang Tidak Disetujui. Namun, ketika parameter `apg_plan_mgmt.unapproved_plan_execution_threshold` menentukan nilai ambang batas biaya, pengoptimisasi akan membandingkan biaya rencana yang Tidak Disetujui dengan ambang batas ini. Jika perkiraan biaya lebih rendah dari ambang batas, pengoptimisasi akan menjalankan rencana. Untuk informasi selengkapnya, lihat [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold).
+ Jika perkiraan biaya rencana tidak di bawah ambang batas, atribut lainnya dari rencana ini akan diperiksa (8a).
1. Jika status rencana adalah apa pun selain Tidak Disetujui, atribut lainnya akan diperiksa (8a).
1. Pengoptimisasi tidak akan menggunakan rencana yang dinonaktifkan. Rencana yang dinonaktifkan adalah rencana yang atribut `enable`-nya diatur ke 'f' (false). Pengoptimisasi juga tidak akan menggunakan rencana yang memiliki status Ditolak.
Pengoptimisasi tidak dapat menggunakan rencana apa pun yang tidak valid. Rencana dapat menjadi tidak valid dari waktu ke waktu ketika objek yang diandalkannya, misalnya indeks dan partisi tabel, dihapus.
1. Jika pernyataan memiliki rencana Pilihan yang diaktifkan dan valid, pengoptimisasi akan memilih rencana berbiaya minimum di antara rencana Pilihan yang disimpan untuk pernyataan SQL ini. Pengoptimisasi kemudian menjalankan rencana Pilihan berbiaya minimum.
1. Jika pernyataan tidak memiliki rencana Pilihan yang diaktifkan dan valid, pernyataan ini akan dinilai pada langkah berikutnya (9).
1. Jika pernyataan memiliki rencana Disetujui yang diaktifkan dan valid, pengoptimisasi akan memilih rencana berbiaya minimum dari berbagai rencana Disetujui yang disimpan untuk pernyataan SQL ini. Pengoptimisasi kemudian menjalankan rencana berbiaya minimum yang Disetujui.
Jika pernyataan tidak memiliki rencana Disetujui yang valid dan diaktifkan, pengoptimisasi akan menggunakan rencana berbiaya minimum (A. Jalankan rencana Pengoptimisasi).
# Memeriksa rencana kueri Aurora PostgreSQL dalam tampilan dba\$1plans
Pengguna dan administrator basis data yang telah diberi peran `apg_plan_mgmt` dapat melihat dan mengelola rencana yang disimpan dalam `apg_plan_mgmt.dba_plans`. Administrator klaster DB Aurora PostgreSQL (seseorang dengan izin `rds_superuser`) harus secara eksplisit memberikan peran ini kepada pengguna basis data yang perlu menggunakan manajemen rencana kueri.
Tampilan `apg_plan_mgmt` berisi riwayat rencana untuk semua pernyataan SQL terkelola untuk setiap basis data pada instans penulis dari klaster DB PostgreSQL Aurora. Tampilan ini memungkinkan Anda memeriksa rencana, statusnya, kapan terakhir digunakan, dan semua detail relevan lainnya.
Seperti yang dibahas dalam [Normalisasi dan hash SQL](AuroraPostgreSQL.Optimize.Start.md#AuroraPostgreSQL.Optimize.Start.hash-and-normalization), setiap rencana terkelola diidentifikasi oleh nilai hash SQL dan nilai hash rencana. Dengan pengidentifikasi ini, Anda dapat menggunakan alat seperti Wawasan Performa Amazon RDS untuk melacak performa rencana individu. Untuk informasi selengkapnya tentang Wawasan Performa, lihat [Menggunakan Wawasan Performa Amazon RDS]( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
## Menampilkan daftar rencana yang dikelola
Untuk menampilkan daftar rencana terkelola, gunakan SELECT pada tampilan `apg_plan_mgmt.dba_plans`. Contoh berikut menampilkan beberapa kolom dalam tampilan `dba_plans` seperti `status`, yang mengidentifikasi rencana yang disetujui dan tidak disetujui.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+------------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Unapproved | t | rangequery
(2 rows)
```
Agar mudah dibaca, kueri dan output yang ditampilkan hanya mencantumkan sebagian kecil kolom dari tampilan `dba_plans`. Untuk informasi selengkapnya, lihat [Referensi untuk tampilan apg\$1plan\$1mgmt.dba\$1plans untuk Aurora PostgreSQL Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
# Meningkatkan rencana kueri PostgreSQL Aurora
Meningkatkan manajemen rencana kueri dengan mengevaluasi kinerja rencana dan memperbaiki rencana. Untuk informasi selengkapnya tentang meningkatkan rencana kueri Anda, lihat topik berikut.
**Topics**
+ [Mengevaluasi performa rencana](#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance)
+ [Memperbaiki rencana menggunakan pg\$1hint\$1plan](#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan)
## Mengevaluasi performa rencana
Setelah pengoptimal mengambil rencana sebagai tidak disetujui, gunakan fungsi `apg_plan_mgmt.evolve_plan_baselines` untuk membandingkan rencana berdasarkan performanya yang sebenarnya. Bergantung pada hasil eksperimen performa Anda, Anda dapat mengubah status rencana dari tidak disetujui ke disetujui atau ditolak. Anda dapat memutuskan untuk menggunakan fungsi `apg_plan_mgmt.evolve_plan_baselines` untuk menonaktifkan rencana secara sementara jika tidak memenuhi persyaratan Anda.
### Menyetujui rencana yang lebih baik
Contoh berikut menunjukkan cara mengubah status rencana terkelola menjadi disetujui menggunakan fungsi `apg_plan_mgmt.evolve_plan_baselines`.
```
SELECT apg_plan_mgmt.evolve_plan_baselines (
sql_hash,
plan_hash,
min_speedup_factor := 1.0,
action := 'approve'
)
FROM apg_plan_mgmt.dba_plans WHERE status = 'Unapproved';
```
```
NOTICE: rangequery (1,10000)
NOTICE: Baseline [ Planning time 0.761 ms, Execution time 13.261 ms]
NOTICE: Baseline+1 [ Planning time 0.204 ms, Execution time 8.956 ms]
NOTICE: Total time benefit: 4.862 ms, Execution time benefit: 4.305 ms
NOTICE: Unapproved -> Approved
evolve_plan_baselines
-----------------------
0
(1 row)
```
Output menampilkan laporan performa untuk pernyataan `rangequery` dengan ikatan parameter 1 dan 10.000. Rencana baru yang belum disetujui (`Baseline+1`) lebih baik daripada rencana terbaik yang telah disetujui sebelumnya (`Baseline`). Untuk mengonfirmasi bahwa rencana yang baru sekarang berstatus `Approved`, periksa tampilan `apg_plan_mgmt.dba_plans`.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
```
```
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+----------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Approved | t | rangequery
(2 rows)
```
Rencana terkelola kini mencakup dua rencana yang disetujui yang merupakan acuan dasar rencana pernyataan. Anda juga dapat memanggil fungsi `apg_plan_mgmt.set_plan_status` untuk mengatur langsung bidang status rencana ke `'Approved'`, `'Rejected'`, `'Unapproved'`, atau `'Preferred'`.
### Menolak atau menonaktifkan rencana yang lebih lambat
Untuk menolak atau menonaktifkan rencana, teruskan `'reject'` atau `'disable' ` sebagai parameter tindakan ke fungsi `apg_plan_mgmt.evolve_plan_baselines`. Contoh ini menonaktifkan setiap rencana `Unapproved` yang diambil yang lebih lambat setidaknya 10 persen dari rencana `Approved` terbaik untuk pernyataan.
```
SELECT apg_plan_mgmt.evolve_plan_baselines(
sql_hash, -- The managed statement ID
plan_hash, -- The plan ID
1.1, -- number of times faster the plan must be
'disable' -- The action to take. This sets the enabled field to false.
)
FROM apg_plan_mgmt.dba_plans
WHERE status = 'Unapproved' AND -- plan is Unapproved
origin = 'Automatic'; -- plan was auto-captured
```
Anda juga dapat secara langsung mengatur rencana ke ditolak atau dinonaktifkan. Untuk secara langsung mengatur bidang yang diaktifkan untuk rencana ke `true` atau `false`, panggil fungsi `apg_plan_mgmt.set_plan_enabled`. Untuk secara langsung mengatur bidang status rencana ke `'Approved'`, `'Rejected'`, `'Unapproved'`, atau `'Preferred'`, panggil fungsi `apg_plan_mgmt.set_plan_status`.
Untuk menghapus rencana yang tidak valid dan yang Anda perkirakan akan tetap tidak valid, gunakan fungsi `apg_plan_mgmt.validate_plans`. Fungsi ini memungkinkan Anda menghapus atau menonaktifkan rencana yang tidak valid. Untuk informasi selengkapnya, lihat [Memvalidasi rencana](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
## Memperbaiki rencana menggunakan pg\$1hint\$1plan
Pengoptimal kueri dirancang dengan baik untuk menemukan rencana yang optimal untuk semua pernyataan, dan pada sebagian besar kasus, pengoptimal menemukan rencana yang baik. Namun, terkadang Anda mungkin tahu bahwa ada rencana yang jauh lebih baik dari yang dihasilkan oleh pengoptimal. Dua cara yang disarankan agar pengoptimal menghasilkan rencana yang diinginkan adalah menggunakan ekstensi `pg_hint_plan` atau mengatur variabel Grand Unified Configuration (GUC) di PostgreSQL:
+ Ekstensi `pg_hint_plan` – Menentukan "petunjuk" untuk memodifikasi cara perencana bekerja menggunakan ekstensi `pg_hint_plan` PostgreSQL. Untuk menginstal dan mempelajari selengkapnya tentang cara menggunakan ekstensi `pg_hint_plan`, lihat [dokumentasi pg\$1hint\$1plan](https://github.com/ossc-db/pg_hint_plan).
+ Variabel GUC – Menulis ulang satu atau beberapa parameter model biaya atau parameter pengoptimal lainnya, seperti `from_collapse_limit` atau `GEQO_threshold`.
Saat Anda menggunakan salah satu teknik ini untuk memaksa pengoptimal kueri agar menggunakan suatu rencana, Anda juga dapat menggunakan manajemen rencana kueri untuk mengambil dan memberlakukan penggunaan rencana baru.
Anda dapat menggunakan ekstensi `pg_hint_plan` untuk mengubah urutan join, metode join, atau jalur akses untuk pernyataan SQL. Anda menggunakan komentar SQL dengan sintaksis `pg_hint_plan` khusus untuk memodifikasi cara pengoptimal membuat rencana. Misalnya, anggaplah pernyataan SQL yang bermasalah memiliki join dua arah.
```
SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Kemudian, anggaplah bahwa pengoptimal memilih urutan join (t1, t2), tetapi Anda tahu bahwa urutan join (t2, t1) lebih cepat. Petunjuk berikut memaksa pengoptimal untuk menggunakan urutan join yang lebih cepat, (t2, t1). Sertakan EXPLAIN sehingga pengoptimal menghasilkan rencana untuk pernyataan SQL, tetapi tanpa menjalankan pernyataan ini. (Output tidak ditampilkan.)
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Langkah-langkah berikut menunjukkan cara menggunakan `pg_hint_plan`.
**Untuk mengubah rencana yang dibuat oleh pengoptimal dan mengambil rencana menggunakan pg\$1hint\$1plan**
1. Aktifkan mode pengambilan manual.
```
SET apg_plan_mgmt.capture_plan_baselines = manual;
```
1. Tentukan petunjuk untuk pernyataan SQL yang ingin diamati.
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Setelah proses ini berjalan, pengoptimal mengambil rencana dalam tampilan `apg_plan_mgmt.dba_plans`. Rencana yang diambil tidak mencakup sintaksis komentar `pg_hint_plan` khusus karena manajemen rencana kueri menormalisasi pernyataan dengan menghapus komentar awal.
1. Lihat rencana terkelola menggunakan tampilan `apg_plan_mgmt.dba_plans`.
```
SELECT sql_hash, plan_hash, status, sql_text, plan_outline
FROM apg_plan_mgmt.dba_plans;
```
1. Atur status rencana menjadi `Preferred`. Tindakan ini memastikan bahwa pengoptimal memilih untuk menjalankannya dan tidak memilih dari rencana yang disetujui, saat rencana berbiaya minimum belum berstatus `Approved` atau `Preferred`.
```
SELECT apg_plan_mgmt.set_plan_status(sql-hash, plan-hash, 'preferred' );
```
1. Nonaktifkan pengambilan rencana manual dan berlakukan penggunaan rencana terkelola.
```
SET apg_plan_mgmt.capture_plan_baselines = false;
SET apg_plan_mgmt.use_plan_baselines = true;
```
Sekarang, ketika pernyataan SQL asli berjalan, pengoptimal memilih rencana `Approved` atau `Preferred`. Jika rencana berbiaya minimum tidak berstatus `Approved` atau `Preferred`, pengoptimal akan memilih rencana `Preferred`.
# Menghapus paket kueri Aurora PostgreSQL
Hapus paket eksekusi yang tidak Anda gunakan atau paket yang tidak valid. Untuk informasi selengkapnya tentang menghapus paket, lihat bagian berikut.
**Topics**
+ [Menghapus rencana](#AuroraPostgreSQL.Optimize.Maintenance.DeletingPlans)
+ [Memvalidasi rencana](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
## Menghapus rencana
Rencana dihapus secara otomatis jika belum digunakan selama lebih dari sebulan, khususnya, 32 hari. Ini adalah pengaturan default untuk parameter `apg_plan_mgmt.plan_retention_period`. Anda dapat mengubah periode retensi rencana ke periode waktu yang lebih lama, atau ke periode waktu yang lebih pendek mulai dari nilai 1. Menentukan jumlah hari sejak rencana terakhir digunakan yang dihitung dengan mengurangi tanggal saat ini dengan tanggal `last_used`. Tanggal `last_used` adalah tanggal terbaru saat pengoptimal memilih rencana sebagai rencana berbiaya minimum atau saat rencana tersebut dijalankan. Tanggal disimpan untuk rencana dalam tampilan `apg_plan_mgmt.dba_plans`.
Kami menyarankan Anda menghapus rencana yang belum digunakan dalam waktu lama atau yang tidak berguna. Setiap rencana memiliki tanggal `last_used` yang diperbarui oleh pengoptimal setiap kali pengoptimal menjalankan rencana atau memilih rencana sebagai rencana berbiaya minimum untuk suatu pernyataan. Periksa tanggal `last_used` terakhir untuk mengidentifikasi rencana yang dapat Anda hapus dengan aman.
Kueri berikut menampilkan tabel tiga kolom dengan jumlah total rencana, rencana yang gagal dihapus, dan rencana yang berhasil dihapus. Kueri tersebut memiliki kueri bersarang yang merupakan contoh cara menggunakan fungsi `apg_plan_mgmt.delete_plan` untuk menghapus semua rencana yang belum dipilih sebagai rencana berbiaya minimum dalam 31 hari terakhir dan statusnya bukan `Rejected`.
```
SELECT (SELECT COUNT(*) from apg_plan_mgmt.dba_plans) total_plans,
COUNT(*) FILTER (WHERE result = -1) failed_to_delete,
COUNT(*) FILTER (WHERE result = 0) successfully_deleted
FROM (
SELECT apg_plan_mgmt.delete_plan(sql_hash, plan_hash) as result
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '31 days')
AND status <> 'Rejected'
) as dba_plans ;
```
```
total_plans | failed_to_delete | successfully_deleted
-------------+------------------+----------------------
3 | 0 | 2
```
Untuk informasi selengkapnya, lihat [apg\$1plan\$1mgmt.delete\$1plan](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.delete_plan).
Untuk menghapus rencana yang tidak valid dan yang Anda perkirakan akan tetap tidak valid, gunakan fungsi `apg_plan_mgmt.validate_plans`. Fungsi ini memungkinkan Anda menghapus atau menonaktifkan rencana yang tidak valid. Untuk informasi selengkapnya, lihat [Memvalidasi rencana](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
**penting**
Jika Anda tidak menghapus rencana yang tidak berguna, Anda mungkin akan kehabisan memori bersama yang dialokasikan untuk manajemen rencana kueri. Untuk mengontrol berapa banyak memori yang tersedia untuk rencana terkelola, gunakan parameter `apg_plan_mgmt.max_plans`. Atur parameter ini di grup parameter DB kustom Anda lalu boot ulang instans DB Anda agar perubahan pada instans diterapkan. Untuk informasi selengkapnya, lihat parameter [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans).
## Memvalidasi rencana
Gunakan fungsi `apg_plan_mgmt.validate_plans` untuk menghapus atau menonaktifkan rencana yang tidak valid.
Rencana dapat menjadi tidak valid atau stale ketika objek yang diandalkan rencana tersebut dihapus, misalnya indeks atau tabel. Namun, rencana mungkin hanya menjadi tidak valid untuk sementara jika objek yang dihapus dibuat kembali. Jika rencana yang tidak valid dapat menjadi valid di lain waktu, mungkin Anda sebaiknya memilih untuk menonaktifkan rencana yang tidak valid atau tidak melakukan apa-apa daripada menghapusnya.
Untuk menemukan dan menghapus semua rencana yang tidak valid dan belum digunakan dalam kurun waktu seminggu, gunakan fungsi `apg_plan_mgmt.validate_plans ` sebagai berikut.
```
SELECT apg_plan_mgmt.validate_plans(sql_hash, plan_hash, 'delete')
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '7 days');
```
Untuk mengaktifkan atau menonaktifkan rencana secara langsung, gunakan fungsi `apg_plan_mgmt.set_plan_enabled`.
# Mengekspor dan mengimpor rencana terkelola untuk Aurora PostgreSQL
Anda dapat mengekspor rencana terkelola Anda dan mengimpornya ke dalam instans DB lain.
**Untuk mengekspor rencana terkelola**
Pengguna dapat menyalin subset tabel `apg_plan_mgmt.plans` ke tabel lain, lalu menyimpannya menggunakan perintah `pg_dump`. Berikut adalah contohnya.
```
CREATE TABLE plans_copy AS SELECT *
FROM apg_plan_mgmt.plans [ WHERE predicates ] ;
```
```
% pg_dump --table apg_plan_mgmt.plans_copy -Ft mysourcedatabase > plans_copy.tar
```
```
DROP TABLE apg_plan_mgmt.plans_copy;
```
**Untuk mengimpor rencana terkelola**
1. Salin file .tar dari rencana terkelola yang diekspor ke sistem tempat rencana tersebut akan dipulihkan.
1. Gunakan perintah `pg_restore` untuk menyalin file .tar ke dalam tabel baru.
```
% pg_restore --dbname mytargetdatabase -Ft plans_copy.tar
```
1. Gabungkan tabel `plans_copy` dengan tabel `apg_plan_mgmt.plans` seperti yang ditunjukkan dalam contoh berikut.
**catatan**
Dalam beberapa kasus, Anda mungkin membuang dari satu versi ekstensi `apg_plan_mgmt` dan memulihkan ke versi yang berbeda. Dalam kasus ini, kolom di tabel rencana mungkin berbeda. Jika ya, tentukan nama kolom tersebut dengan eksplisit dan bukan menggunakan SELECT \$1.
```
INSERT INTO apg_plan_mgmt.plans SELECT * FROM plans_copy
ON CONFLICT ON CONSTRAINT plans_pkey
DO UPDATE SET
status = EXCLUDED.status,
enabled = EXCLUDED.enabled,
-- Save the most recent last_used date
--
last_used = CASE WHEN EXCLUDED.last_used > plans.last_used
THEN EXCLUDED.last_used ELSE plans.last_used END,
-- Save statistics gathered by evolve_plan_baselines, if it ran:
--
estimated_startup_cost = EXCLUDED.estimated_startup_cost,
estimated_total_cost = EXCLUDED.estimated_total_cost,
planning_time_ms = EXCLUDED.planning_time_ms,
execution_time_ms = EXCLUDED.execution_time_ms,
total_time_benefit_ms = EXCLUDED.total_time_benefit_ms,
execution_time_benefit_ms = EXCLUDED.execution_time_benefit_ms;
```
1. Muat ulang rencana terkelola ke dalam memori bersama dan hapus tabel rencana sementara.
```
SELECT apg_plan_mgmt.reload(); -- refresh shared memory
DROP TABLE plans_copy;
```
# Referensi parameter untuk manajemen rencana kueri Aurora PostgreSQL
Anda dapat mengatur preferensi Anda untuk ekstensi `apg_plan_mgmt` dengan menggunakan parameter yang tercantum di bagian ini. Hal ini tersedia dalam parameter klaster DB kustom dan grup parameter DB yang terkait dengan klaster DB Aurora PostgreSQL Anda. Parameter ini mengontrol perilaku fitur manajemen rencana kueri dan bagaimana pengaruhnya terhadap pengoptimisasi. Untuk informasi tentang pengaturan manajemen rencana kueri, lihat [Mengaktifkan manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md#AuroraPostgreSQL.Optimize.Enable). Perubahan pada parameter berikut tidak berpengaruh jika ekstensi `apg_plan_mgmt` tidak diatur seperti yang dijelaskan dalam bagian tersebut. Untuk informasi tentang memodifikasi parameter, lihat [Memodifikasi parameter dalam grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md) dan [Grup parameter DB untuk instans Amazon Aurora DB](USER_WorkingWithDBInstanceParamGroups.md).
**Topics**
+ [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines)
+ [apg\$1plan\$1mgmt.plan\$1capture\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.plan_capture_threshold)
+ [apg\$1plan\$1mgmt.explain\$1hashes](#AuroraPostgreSQL.Optimize.Parameters.explain_hashes)
+ [apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result](#AuroraPostgreSQL.Optimize.Parameters.log_plan_enforcement_result)
+ [apg\$1plan\$1mgmt.max\$1databases](#AuroraPostgreSQL.Optimize.Parameters.max_databases)
+ [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans)
+ [apg\$1plan\$1mgmt.plan\$1hash\$1version](#AuroraPostgreSQL.Optimize.Parameters.plan_hash_version)
+ [apg\$1plan\$1mgmt.plan\$1retention\$1period](#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period)
+ [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold)
+ [apg\$1plan\$1mgmt.use\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.use_plan_baselines)
+ [auto\$1explain.hashes](#AuroraPostgreSQL.Optimize.Parameters.auto_explain.hashes)
## apg\$1plan\$1mgmt.capture\$1plan\$1baselines
Mengambil rencana eksekusi kueri yang dihasilkan oleh pengoptimisasi untuk setiap pernyataan SQL dan menyimpannya dalam tampilan `dba_plans`. Secara default, jumlah maksimum rencana yang dapat disimpan adalah 10.000 seperti yang ditentukan oleh parameter `apg_plan_mgmt.max_plans`. Untuk informasi referensi, lihat [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans).
Anda dapat mengatur parameter ini dalam grup parameter klaster DB kustom atau dalam grup parameter DB kustom. Mengubah nilai parameter ini tidak memerlukan boot ulang.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
Untuk informasi selengkapnya, lihat [Mengambil rencana eksekusi Aurora PostgreSQL](AuroraPostgreSQL.Optimize.CapturePlans.md).
## apg\$1plan\$1mgmt.plan\$1capture\$1threshold
Menentukan ambang batas sehingga jika total biaya rencana eksekusi kueri di bawah ambang batas, rencana tidak akan diambil dalam tampilan `apg_plan_mgmt.dba_plans`.
Mengubah nilai parameter ini tidak memerlukan boot ulang.
| Default | Nilai yang diizinkan | Deskripsi |
| --- | --- | --- |
| 0 | 0 - 1.79769e\$1308 | Menetapkan ambang batas total biaya eksekusi rencana kueri `apg_plan_mgmt` untuk mengambil rencana. |
Untuk informasi selengkapnya, lihat [Memeriksa rencana kueri Aurora PostgreSQL dalam tampilan dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.explain\$1hashes
Menentukan apakah `EXPLAIN [ANALYZE]` menunjukkan `sql_hash` dan `plan_hash` pada akhir output-nya. Mengubah nilai parameter ini tidak memerlukan boot ulang.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result
Menentukan apakah hasil harus dicatat untuk melihat apakah rencana yang dikelola QPM digunakan dengan benar. Ketika rencana generik yang disimpan digunakan, tidak akan ada catatan yang ditulis dalam file log. Mengubah nilai parameter ini tidak memerlukan boot ulang.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.max\$1databases
Menentukan jumlah maksimum basis data pada instans Penulis klaster DB Aurora PostgreSQL Anda yang dapat menggunakan manajemen rencana kueri. Secara default, hingga 10 basis data dapat menggunakan manajemen rencana kueri. Jika Anda memiliki lebih dari 10 basis data pada instans, Anda dapat mengubah nilai pengaturan ini. Untuk mengetahui jumlah basis data pada instans tertentu, hubungkan ke instans menggunakan `psql`. Kemudian, gunakan metacommand psql, `\l`, untuk menampilkan daftar basis data.
Mengubah nilai parameter ini akan mengharuskan Anda mem-boot ulang instans agar pengaturan diterapkan.
| Default | Nilai yang diizinkan | Deskripsi |
| --- | --- | --- |
| 10 | 10-2147483647 | Jumlah maksimum basis data yang dapat menggunakan manajemen rencana kueri pada instans. |
Anda dapat mengatur parameter ini dalam grup parameter klaster DB kustom atau dalam grup parameter DB kustom.
## apg\$1plan\$1mgmt.max\$1plans
Menetapkan jumlah maksimum pernyataan SQL yang dapat dipertahankan oleh manajer rencana kueri dalam tampilan `apg_plan_mgmt.dba_plans`. Sebaiknya atur parameter ini ke `10000` atau lebih tinggi untuk semua versi Aurora PostgreSQL.
Anda dapat mengatur parameter ini dalam grup parameter klaster DB kustom atau dalam grup parameter DB kustom. Mengubah nilai parameter ini akan mengharuskan Anda mem-boot ulang instans agar pengaturan diterapkan.
| Default | Nilai yang diizinkan | Deskripsi |
| --- | --- | --- |
| 10000 | 10-2147483647 | Jumlah maksimum rencana yang dapat disimpan dalam tampilan `apg_plan_mgmt.dba_plans`. Default untuk Aurora PostgreSQL versi 10 dan yang lebih lama adalah 1000. |
Untuk informasi selengkapnya, lihat [Memeriksa rencana kueri Aurora PostgreSQL dalam tampilan dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.plan\$1hash\$1version
Menentukan kasus penggunaan yang dapat dicakup oleh perhitungan plan\$1hash sesuai rancangannya. Versi `apg_plan_mgmt.plan_hash_version` yang lebih tinggi mencakup semua fungsionalitas versi yang lebih rendah. Misalnya, versi 3 mencakup kasus penggunaan yang didukung oleh versi 2.
Perubahan pada nilai parameter ini harus diikuti dengan panggilan ke `apg_plan_mgmt.validate_plans('update_plan_hash')`. Parameter ini memperbarui nilai plan\$1hash di setiap basis data dengan apg\$1plan\$1mgmt diinstal dan entri dalam tabel rencana. Untuk informasi selengkapnya, lihat [Memvalidasi rencana](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.plan\$1retention\$1period
Menentukan jumlah hari untuk mempertahankan rencana dalam tampilan `apg_plan_mgmt.dba_plans`, dan setelah itu, rencana tersebut akan dihapus secara otomatis. Secara default, rencana dihapus ketika 32 hari telah berlalu sejak rencana tersebut terakhir digunakan (kolom `last_used` dalam tampilan `apg_plan_mgmt.dba_plans`). Anda dapat mengubah pengaturan ini ke angka apa pun, 1 dan lebih tinggi.
Mengubah nilai parameter ini akan mengharuskan Anda mem-boot ulang instans agar pengaturan diterapkan.
| Default | Nilai yang diizinkan | Deskripsi |
| --- | --- | --- |
| 32 | 1-2147483647 | Jumlah hari maksimum sejak rencana terakhir digunakan sebelum dihapus. |
Untuk informasi selengkapnya, lihat [Memeriksa rencana kueri Aurora PostgreSQL dalam tampilan dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold
Menentukan ambang batas biaya yang jika tidak tercapai, rencana yang Tidak Disetujui dapat digunakan oleh pengoptimisasi. Secara default ambang batas ini adalah 0, sehingga pengoptimisasi tidak akan menjalankan rencana yang Tidak Disetujui. Jika parameter ini diatur ke ambang batas biaya yang cukup rendah seperti 100, tidak akan ada overhead pemberlakuan rencana pada rencana sederhana (trivial). Anda juga dapat mengatur parameter ini ke nilai yang sangat besar seperti 10000000 menggunakan gaya manajemen rencana reaktif. Hal ini memungkinkan pengoptimisasi menggunakan semua rencana yang dipilih tanpa overhead pemberlakuan rencana. Namun, ketika rencana buruk ditemukan, Anda dapat menandainya secara manual sebagai “ditolak” sehingga tidak akan digunakan di lain waktu.
Nilai parameter ini merepresentasikan perkiraan biaya untuk menjalankan rencana yang diberikan. Jika rencana yang Tidak Disetujui di bawah perkiraan biaya tersebut, pengoptimisasi akan menggunakannya untuk pernyataan SQL. Anda dapat melihat rencana yang diambil dan statusnya (Disetujui, Tidak Disetujui) di tampilan `dba_plans`. Untuk mempelajari selengkapnya, lihat [Memeriksa rencana kueri Aurora PostgreSQL dalam tampilan dba\$1plans](AuroraPostgreSQL.Optimize.ViewPlans.md).
Mengubah nilai parameter ini tidak memerlukan boot ulang.
| Default | Nilai yang diizinkan | Deskripsi |
| --- | --- | --- |
| 0 | 0-2147483647 | Perkiraan biaya rencana yang jika tidak tercapai, akan membuat rencana yang Tidak Disetujui digunakan. |
Untuk informasi selengkapnya, lihat [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md).
## apg\$1plan\$1mgmt.use\$1plan\$1baselines
Menentukan bahwa pengoptimisasi harus menggunakan salah satu rencana Disetujui yang diambil dan disimpan dalam tampilan `apg_plan_mgmt.dba_plans`. Secara default, parameter ini tidak aktif (false), sehingga menyebabkan pengoptimisasi menggunakan rencana berbiaya minimum yang dihasilkannya tanpa penilaian lebih lanjut. Mengaktifkan parameter ini (mengaturnya ke true) akan memaksa pengoptimisasi untuk memilih rencana eksekusi kueri untuk pernyataan dari acuan dasar (baseline) rencananya. Untuk informasi selengkapnya, lihat [Menggunakan rencana terkelola Aurora PostgreSQL](AuroraPostgreSQL.Optimize.UsePlans.md). Untuk menemukan gambar yang menguraikan proses ini, lihat [Bagaimana cara pengoptimisasi memilih rencana yang akan dijalankan](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
Anda dapat mengatur parameter ini dalam grup parameter klaster DB kustom atau dalam grup parameter DB kustom. Mengubah nilai parameter ini tidak memerlukan boot ulang.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
Anda dapat mengevaluasi waktu respons dari berbagai rencana yang diambil dan mengubah status rencana, sesuai kebutuhan. Untuk informasi selengkapnya, lihat [Meningkatkan rencana kueri PostgreSQL Aurora](AuroraPostgreSQL.Optimize.Maintenance.md).
## auto\$1explain.hashes
Menentukan apakah output auto\$1explain menampilkan sql\$1hash dan plan\$1hash. Mengubah nilai parameter ini tidak memerlukan boot ulang.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
# Referensi fungsi untuk manajemen rencana kueri Aurora PostgreSQL
Ekstensi `apg_plan_mgmt` menyediakan fungsi-fungsi berikut.
**Topics**
+ [apg\$1plan\$1mgmt.copy\$1outline](#AuroraPostgreSQL.Optimize.Functions.copy_outline)
+ [apg\$1plan\$1mgmt.delete\$1plan](#AuroraPostgreSQL.Optimize.Functions.delete_plan)
+ [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines)
+ [apg\$1plan\$1mgmt.get\$1explain\$1plan](#AuroraPostgreSQL.Optimize.Functions.get_explain_plan)
+ [apg\$1plan\$1mgmt.plan\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.plan_last_used)
+ [apg\$1plan\$1mgmt.reload](#AuroraPostgreSQL.Optimize.Functions.reload)
+ [apg\$1plan\$1mgmt.set\$1plan\$1enabled](#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled)
+ [apg\$1plan\$1mgmt.set\$1plan\$1status](#AuroraPostgreSQL.Optimize.Functions.set_plan_status)
+ [apg\$1plan\$1mgmt.update\$1plans\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.update_plans_last_used)
+ [apg\$1plan\$1mgmt.validate\$1plans](#AuroraPostgreSQL.Optimize.Functions.validate_plans)
## apg\$1plan\$1mgmt.copy\$1outline
Menyalin hash rencana dan outline rencana SQL tertentu ke hash rencana dan outline rencana SQL target, sehingga akan menimpa hash rencana dan outline rencana target. Fungsi ini tersedia dalam `apg_plan_mgmt` versi 2.3 dan rilis yang lebih tinggi.
**Sintaksis**
```
apg_plan_mgmt.copy_outline(
source_sql_hash,
source_plan_hash,
target_sql_hash,
target_plan_hash,
force_update_target_plan_hash
)
```
**Nilai yang ditampilkan**
Menampilkan 0 ketika penyalinan berhasil. Menampilkan pengecualian untuk input yang tidak valid.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| source\$1sql\$1hash | ID sql\$1hash yang terkait dengan plan\$1hash yang akan disalin ke kueri target. |
| source\$1plan\$1hash | ID plan\$1hash yang akan disalin ke kueri target. |
| target\$1sql\$1hash | ID sql\$1hash kueri yang akan diperbarui dengan hash rencana dan outline rencana sumber. |
| target\$1plan\$1hash | ID plan\$1hash kueri yang akan diperbarui dengan hash rencana dan outline rencana sumber. |
| force\$1update\$1target\$1plan\$1hash | (Opsional) ID target\$1plan\$1hash kueri diperbarui meskipun rencana sumber tidak dapat direproduksi untuk target\$1sql\$1hash. Ketika diatur ke true, fungsi ini dapat digunakan untuk menyalin rencana ke seluruh skema yang memiliki nama dan kolom relasi yang konsisten. |
**Catatan penggunaan**
Fungsi ini memungkinkan Anda untuk menyalin hash rencana dan outline rencana yang menggunakan petunjuk ke pernyataan lain yang serupa, sehingga Anda tidak perlu menggunakan pernyataan petunjuk inline pada setiap peristiwa dalam pernyataan target. Jika kueri target yang diperbarui menghasilkan rencana yang tidak valid, fungsi ini akan memunculkan kesalahan dan mengembalikan pembaruan yang dicoba.
## apg\$1plan\$1mgmt.delete\$1plan
Menghapus rencana terkelola.
**Sintaksis**
```
apg_plan_mgmt.delete_plan(
sql_hash,
plan_hash
)
```
**Nilai yang ditampilkan**
Menampilkan 0 jika penghapusan berhasil atau -1 jika penghapusan gagal.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| sql\$1hash | ID sql\$1hash pernyataan SQL terkelola milik rencana. |
| plan\$1hash | ID plan\$1hash rencana terkelola. |
## apg\$1plan\$1mgmt.evolve\$1plan\$1baselines
Memverifikasi apakah rencana yang sudah disetujui lebih cepat atau apakah rencana yang diidentifikasi oleh pengoptimal kueri sebagai rencana berbiaya minimum yang lebih cepat.
**Sintaksis**
```
apg_plan_mgmt.evolve_plan_baselines(
sql_hash,
plan_hash,
min_speedup_factor,
action
)
```
**Nilai yang ditampilkan**
Jumlah rencana yang tidak lebih cepat dari rencana terbaik yang disetujui.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| sql\$1hash | ID sql\$1hash pernyataan SQL terkelola milik rencana. |
| plan\$1hash | ID plan\$1hash rencana terkelola. Gunakan NULL untuk mengindikasikan semua rencana yang memiliki nilai ID sql\$1hash yang sama. |
| min\$1speedup\$1factor | *Faktor percepatan minimum* adalah seberapa kali lebih cepat suatu rencana daripada rencana lain yang sudah disetujui agar rencana tersebut dapat disetujui. Alternatifnya, faktor ini dapat berupa berapa kali lebih lambat agar rencana harus ditolak atau dinonaktifkan. Ini adalah nilai float positif. |
| action | Tindakan yang harus dilakukan oleh fungsi tersebut. Nilai yang valid mencakup hal berikut. Huruf besar/kecil tidak berpengaruh. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
**Catatan penggunaan**
Tetapkan rencana ke status disetujui, ditolak, atau dinonaktifkan berdasarkan apakah waktu perencanaan plus eksekusi lebih cepat daripada rencana yang disetujui berdasarkan faktor yang dapat Anda tetapkan. Parameter tindakan dapat diatur ke `'approve'` atau `'reject'` untuk secara otomatis menyetujui atau menolak rencana yang memenuhi kriteria performa. Alternatifnya, parameter dapat diatur ke '' (string kosong) untuk melakukan eksperimen performa dan membuat laporan, tetapi tidak mengambil tindakan.
Anda dapat mencegah fungsi `apg_plan_mgmt.evolve_plan_baselines` dijalankan kembali secara sia-sia untuk rencana tempat fungsi ini baru-baru ini dijalankan. Untuk melakukannya, batasi rencana hanya untuk rencana yang baru-baru ini dibuat yang belum disetujui. Alternatifnya, Anda dapat mencegah fungsi `apg_plan_mgmt.evolve_plan_baselines` dijalankan pada rencana yang disetujui yang memiliki stempel waktu `last_verified` baru-baru ini.
Lakukan eksperimen performa untuk membandingkan waktu perencanaan dan eksekusi untuk setiap rencana secara relatif terhadap rencana lain dalam acuan dasar (baseline). Dalam beberapa kasus, hanya ada satu rencana untuk satu pernyataan dan rencana ini disetujui. Dalam kasus seperti itu, bandingkan waktu perencanaan dan eksekusi rencana dengan waktu perencanaan dan eksekusi tanpa menggunakan rencana.
Keuntungan (atau kerugian) tambahan dari setiap rencana dicatat di tampilan `apg_plan_mgmt.dba_plans` dalam kolom `total_time_benefit_ms`. Jika nilainya positif, ada keuntungan performa yang dapat diukur untuk memasukkan rencana ini dalam acuan dasar.
Selain mengumpulkan waktu perencanaan dan eksekusi dari setiap rencana kandidat, kolom `last_verified` pada tampilan `apg_plan_mgmt.dba_plans` diperbarui dengan `current_timestamp`. Stempel waktu `last_verified` dapat digunakan agar fungsi ini tidak lagi dijalankan pada rencana yang performanya baru-baru ini diverifikasi.
## apg\$1plan\$1mgmt.get\$1explain\$1plan
Menghasilkan teks dari pernyataan `EXPLAIN` untuk pernyataan SQL yang ditentukan.
**Sintaksis**
```
apg_plan_mgmt.get_explain_plan(
sql_hash,
plan_hash,
[explainOptionList]
)
```
**Nilai yang ditampilkan**
Menampilkan statistik runtime untuk pernyataan SQL yang ditentukan. Gunakan tanpa `explainOptionList` untuk menampilkan rencana `EXPLAIN` sederhana.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| sql\$1hash | ID sql\$1hash pernyataan SQL terkelola milik rencana. |
| plan\$1hash | ID plan\$1hash rencana terkelola. |
| explainOptionList | Daftar opsi penjelasan yang dipisahkan dengan koma. Nilai yang valid termasuk `'analyze'`, `'verbose'`, `'buffers'`, `'hashes'`, dan `'format json'`. Jika `explainOptionList` adalah NULL atau string kosong (''), fungsi ini menghasilkan pernyataan `EXPLAIN`, tanpa statistik. |
**Catatan penggunaan**
Untuk `explainOptionList`, Anda dapat menggunakan salah satu dari opsi yang sama yang akan Anda gunakan dengan pernyataan `EXPLAIN`. Pengoptimal Aurora PostgreSQL menggabungkan daftar opsi yang Anda berikan ke pernyataan `EXPLAIN`.
## apg\$1plan\$1mgmt.plan\$1last\$1used
Menampilkan tanggal `last_used` untuk rencana yang ditetapkan dari memori bersama.
**catatan**
Nilai dalam memori bersama selalu terbaru pada instans DB primer dalam klaster DB. Nilai hanya secara berkala di-flush ke kolom `last_used` dalam tampilan `apg_plan_mgmt.dba_plans`.
**Sintaksis**
```
apg_plan_mgmt.plan_last_used(
sql_hash,
plan_hash
)
```
**Nilai yang ditampilkan**
Menampilkan tanggal `last_used`.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| sql\$1hash | ID sql\$1hash pernyataan SQL terkelola milik rencana. |
| plan\$1hash | ID plan\$1hash rencana terkelola. |
## apg\$1plan\$1mgmt.reload
Memuat ulang rencana ke dalam memori bersama dari tampilan `apg_plan_mgmt.dba_plans`.
**Sintaksis**
```
apg_plan_mgmt.reload()
```
**Nilai yang ditampilkan**
Tidak ada.
**Parameter**
Tidak ada.
**Catatan penggunaan**
Memanggil `reload` untuk situasi-situasi berikut:
+ Gunakan untuk me-refresh memori bersama replika hanya baca, dan bukan menunggu adanya rencana baru untuk disebarkan ke replika.
+ Gunakan setelah mengimpor rencana terkelola.
## apg\$1plan\$1mgmt.set\$1plan\$1enabled
Mengaktifkan atau menonaktifkan rencana terkelola.
**Sintaksis**
```
apg_plan_mgmt.set_plan_enabled(
sql_hash,
plan_hash,
[true | false]
)
```
**Nilai yang ditampilkan**
Menampilkan 0 jika pengaturan berhasil atau -1 jika pengaturan gagal.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| sql\$1hash | ID sql\$1hash pernyataan SQL terkelola milik rencana. |
| plan\$1hash | ID plan\$1hash rencana terkelola. |
| enabled | Nilai Boolean benar atau salah: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
## apg\$1plan\$1mgmt.set\$1plan\$1status
Mengatur status rencana terkelola ke `Approved`, `Unapproved`, `Rejected`, atau `Preferred`.
**Sintaksis**
```
apg_plan_mgmt.set_plan_status(
sql_hash,
plan_hash,
status
)
```
**Nilai yang ditampilkan**
Menampilkan 0 jika pengaturan berhasil atau -1 jika pengaturan gagal.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| sql\$1hash | ID sql\$1hash pernyataan SQL terkelola milik rencana. |
| plan\$1hash | ID plan\$1hash rencana terkelola. |
| status | String dengan salah satu nilai berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Huruf besar/kecil yang Anda gunakan tidak berpengaruh, tetapi nilai status menggunakan huruf besar di awal dalam tampilan `apg_plan_mgmt.dba_plans`. Untuk informasi selengkapnya tentang nilai-nilai tersebut, lihat `status` dalam [Referensi untuk tampilan apg\$1plan\$1mgmt.dba\$1plans untuk Aurora PostgreSQL Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md). |
## apg\$1plan\$1mgmt.update\$1plans\$1last\$1used
Segera memperbarui tabel rencana dengan tanggal `last_used` yang disimpan dalam memori bersama.
**Sintaksis**
```
apg_plan_mgmt.update_plans_last_used()
```
**Nilai yang ditampilkan**
Tidak ada.
**Parameter**
Tidak ada.
**Catatan penggunaan**
Panggil `update_plans_last_used` untuk memastikan kueri terhadap kolom `dba_plans.last_used` menggunakan informasi terbaru. Jika tanggal `last_used` tidak segera diperbarui, proses latar belakang akan memperbarui tabel rencana dengan tanggal `last_used` sekali setiap jam (secara default).
Misalnya, jika pernyataan dengan `sql_hash` tertentu mulai berjalan lambat, Anda dapat menentukan rencana mana yang dieksekusi untuk pernyataan tersebut sejak regresi performa dimulai. Untuk melakukannya, pertama-tama lakukan flushing data dalam memori bersama ke disk sehingga tanggal `last_used` menjadi terkini, lalu jalankan kueri untuk semua rencana `sql_hash` dari pernyataan yang memiliki regresi performa. Dalam kueri, pastikan tanggal `last_used` lebih besar dari atau sama dengan tanggal saat regresi performa dimulai. Kueri tersebut mengidentifikasi rencana atau kumpulan rencana yang mungkin bertanggung jawab atas regresi performa. Anda dapat menggunakan `apg_plan_mgmt.get_explain_plan` dengan `explainOptionList` yang diatur ke `verbose, hashes`. Anda juga dapat menggunakan `apg_plan_mgmt.evolve_plan_baselines` untuk menganalisis rencana dan rencana alternatif apa pun yang mungkin beperforma lebih baik.
Fungsi `update_plans_last_used` hanya berpengaruh pada instans DB primer klaster DB.
## apg\$1plan\$1mgmt.validate\$1plans
Memvalidasi bahwa pengoptimal masih dapat membuat ulang rencana. Pengoptimal memvalidasi rencana `Approved`, `Unapproved`, dan `Preferred`, baik ketika rencana tersebut diaktifkan maupun dinonaktifkan. Rencana `Rejected` tidak divalidasi. Secara opsional, Anda dapat menggunakan fungsi `apg_plan_mgmt.validate_plans` untuk menghapus atau menonaktifkan rencana yang tidak valid.
**Sintaksis**
```
apg_plan_mgmt.validate_plans(
sql_hash,
plan_hash,
action)
apg_plan_mgmt.validate_plans(
action)
```
**Nilai yang ditampilkan**
Jumlah rencana tidak valid.
**Parameter**
****
| Parameter | Deskripsi |
| --- | --- |
| sql\$1hash | ID sql\$1hash pernyataan SQL terkelola milik rencana. |
| plan\$1hash | ID plan\$1hash rencana terkelola. Gunakan NULL untuk merujuk pada semua rencana dengan nilai ID sql\$1hash yang sama. |
| action | Tindakan yang harus dilakukan fungsi untuk rencana yang tidak valid. Nilai string yang valid mencakup hal berikut. Huruf besar/kecil tidak berpengaruh. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Nilai lainnya diperlakukan seperti string kosong. |
**Catatan penggunaan**
Gunakan form `validate_plans(action)` untuk memvalidasi semua rencana terkelola untuk semua pernyataan terkelola dalam tampilan `apg_plan_mgmt.dba_plans` secara keseluruhan.
Gunakan form `validate_plans(sql_hash, plan_hash, action)` untuk memvalidasi rencana terkelola yang ditentukan dengan `plan_hash`, untuk pernyataan terkelola yang ditentukan dengan `sql_hash`.
Gunakan form `validate_plans(sql_hash, NULL, action)` untuk memvalidasi semua rencana terkelola untuk laporan terkelola yang ditentukan dengan `sql_hash`.
# Referensi untuk tampilan apg\$1plan\$1mgmt.dba\$1plans untuk Aurora PostgreSQL Compatible Edition
Kolom informasi rencana dalam tampilan `apg_plan_mgmt.dba_plans` mencakup hal-hal berikut ini.
| Kolom dba\$1plans | Deskripsi |
| --- | --- |
| cardinality\$1error | Pengukuran kesalahan antara kardinalitas yang diperkirakan dan kardinalitas yang sebenarnya. *Kardinalitas* adalah jumlah baris tabel yang akan diproses oleh rencana. Jika kesalahan pada kardinalitas berukuran besar, hal tersebut akan menambah kemungkinan bahwa rencana tersebut tidak optimal. Kolom ini diisi oleh fungsi [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| compatibility\$1level | Parameter ini menunjukkan kapan rencana kueri terakhir divalidasi. Dalam Aurora PostgreSQL versi 12.19, 13.15, 14.12, 15.7, 16.3, dan yang lebih baru, ini menampilkan nomor versi Aurora. Untuk versi sebelumnya, ini menampilkan fitur nomor versi tertentu. Pertahankan nilai parameter ini pada pengaturan defaultnya. Aurora PostgreSQL secara otomatis menetapkan dan memperbarui nilai ini. |
| created\$1by | Pengguna terautentikasi (session\$1user) yang membuat rencana. |
| enabled | Indikator apakah rencana diaktifkan atau dinonaktifkan. Semua rencana diaktifkan secara default. Anda dapat menonaktifkan rencana untuk mencegah pengoptimisasi menggunakannya. Untuk mengubah nilai ini, gunakan fungsi [apg\$1plan\$1mgmt.set\$1plan\$1enabled](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled). |
| environment\$1variables | Parameter dan nilai Grand Unified Configuration (GUC) PostgreSQL yang telah diganti oleh pengoptimisasi pada saat rencana diambil. |
| estimated\$1startup\$1cost | Perkiraan biaya penyiapan pengoptimisasi sebelum pengoptimisasi menghasilkan baris tabel. |
| estimated\$1total\$1cost | Perkiraan biaya pengoptimisasi untuk mengirimkan baris tabel akhir. |
| execution\$1time\$1benefit\$1ms | Keuntungan waktu eksekusi dalam milidetik untuk mengaktifkan rencana. Kolom ini diisi oleh fungsi [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| execution\$1time\$1ms | Perkiraan waktu dalam milidetik bahwa rencana akan berjalan. Kolom ini diisi oleh fungsi [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| has\$1side\$1effects | Nilai yang menunjukkan bahwa pernyataan SQL adalah pernyataan bahasa manipulasi data (DML) atau pernyataan SELECT yang berisi fungsi VOLATILE. |
| last\$1used | Nilai ini diperbarui ke tanggal saat ini setiap kali rencana dijalankan atau jika rencana adalah rencana berbiaya minimum dari pengoptimisasi kueri. Nilai ini disimpan di memori bersama dan dialirkan secara berkala ke disk. Untuk mendapatkan up-to-date nilai terbanyak, baca tanggal dari memori bersama dengan memanggil fungsi apg\$1plan\$1mgmt.plan\$1last\$1used(sql\$1hash, plan\$1hash) alih-alih membaca last\$1used nilainya. Untuk informasi tambahan, lihat parameter [apg\$1plan\$1mgmt.plan\$1retention\$1period](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period). |
| last\$1validated | Tanggal dan waktu terbaru saat terverifikasi bahwa rencana dapat dibuat ulang dengan fungsi [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) atau fungsi [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| last\$1verified | Tanggal dan waktu terbaru saat rencana terverifikasi sebagai rencana beperforma terbaik untuk parameter yang ditentukan oleh fungsi [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| origin | Cara pengambilan rencana dengan parameter [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines). Nilai yang valid mencakup hal berikut: `M` – Rencana diambil dengan pengambilan rencana manual. `A` – Rencana diambil dengan pengambilan rencana manual. |
| param\$1list | Nilai parameter yang diteruskan ke pernyataan jika pernyataan ini merupakan pernyataan yang disiapkan. |
| plan\$1created | Tanggal dan waktu rencana yang dibuat. |
| plan\$1hash | Pengidentifikasi rencana. Kombinasi dari plan\$1hash dan sql\$1hash mengidentifikasi rencana tertentu secara unik. |
| plan\$1outline | Representasi rencana yang digunakan untuk membuat ulang rencana eksekusi sebenarnya dan yang bersifat independen dari basis data. Operator di hierarki menunjukkan operator yang muncul di output EXPLAIN. |
| planning\$1time\$1ms | Waktu sebenarnya untuk menjalankan perencana, dalam milidetik. Kolom ini diisi oleh fungsi [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
| queryId | Hash pernyataan, sebagaimana dihitung oleh ekstensi pg\$1stat\$1statements. Ini bukan pengidentifikasi stabil atau database independen karena tergantung pada pengidentifikasi objek (). OIDs Nilainya adalah 0 jika compute\$1query\$1id adalah off saat mengambil rencana kueri. |
| sql\$1hash | Nilai hash teks pernyataan SQL, yang dinormalisasikan dengan menghapus literal. |
| sql\$1text | Teks lengkap pernyataan SQL. |
| status | Status rencana, yang menentukan cara pengoptimisasi menggunakan rencana. Nilai yang valid mencakup hal berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.dba_plans_view_Reference.html) |
| stmt\$1name | Nama pernyataan SQL di dalam pernyataan PREPARE. Nilai ini adalah string kosong untuk pernyataan yang disiapkan tanpa nama. Nilai ini adalah NULL untuk pernyataan yang tidak disiapkan. |
| total\$1time\$1benefit\$1ms | Keuntungan total waktu dalam milidetik untuk mengaktifkan rencana ini. Nilai ini mempertimbangkan waktu perencanaan dan waktu eksekusi. Jika nilai ini negatif, ada kerugian untuk mengaktifkan rencana ini. Kolom ini diisi oleh fungsi [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines). |
# Fitur lanjutan dalam Manajemen Rencana Kueri
Berikut ini Anda dapat menemukan informasi tentang Aurora Postgre SQL Query Plan Management () fitur canggih: QPM
**Topics**
+ [Mengambil rencana eksekusi Aurora PostgreSQL di Replika](AuroraPostgreSQL.QPM.Plancapturereplicas.md)
+ [Mendukung partisi tabel](AuroraPostgreSQL.QPM.Partitiontable.md)
# Mengambil rencana eksekusi Aurora PostgreSQL di Replika
QPM (Query Plan Management) memungkinkan Anda mengambil rencana kueri yang dihasilkan oleh Replika Aurora dan menyimpannya di instans DB primer dari klaster Aurora DB. Anda dapat mengumpulkan rencana kueri dari semua Replika Aurora, dan memelihara serangkaian rencana optimal dalam tabel persisten terpusat pada instans primer. Anda kemudian dapat menerapkan rencana ini pada Replika lain jika diperlukan. Ini membantu Anda menjaga stabilitas rencana eksekusi dan meningkatkan performa kueri di seluruh klaster DB dan versi mesin.
**Topics**
+ [Prasyarat](#AuroraPostgreSQL.QPM.Plancapturereplicas.Prereq)
+ [Mengelola pengambilan rencana untuk Replika Aurora](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing)
+ [Pemecahan Masalah](#AuroraPostgreSQL.QPM.Plancapturereplicas.Troubleshooting)
## Prasyarat
**Aktifkan `capture_plan_baselines parameter` di Replika Aurora** - Atur parameter `capture_plan_baselines` ke otomatis atau manual untuk mengambil rencana di Replika Aurora. Untuk informasi selengkapnya, lihat [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines).
**Instal ekstensi postgres\$1fdw** - Anda harus menginstal ekstensi wrapper data asing `postgres_fdw` untuk mengambil rencana di Replika Aurora. Jalankan perintah berikut di setiap basis data untuk menginstal ekstensi ini.
```
postgres=> CREATE EXTENSION IF NOT EXISTS postgres_fdw;
```
## Mengelola pengambilan rencana untuk Replika Aurora
**Aktifkan pengambilan rencana untuk Replika Aurora**
Anda harus memiliki hak akses `rds_superuser` untuk membuat atau menghapus Pengambilan Rencana di Replika Aurora. Untuk informasi selengkapnya tentang peran dan izin pengguna, lihat [Memahami peran dan izin PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Roles.html).
Untuk mengambil rencana, panggil fungsi apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture dalam instans DB penulis, seperti yang ditunjukkan berikut ini:
```
postgres=> CALL apg_plan_mgmt.create_replica_plan_capture('endpoint', 'password');
```
+ endpoint - Titik akhir penulis Aurora Global Database atau cluster\$1endpoint menyediakan dukungan failover untuk Plan Capture di Aurora Replicas.
Untuk informasi lebih lanjut tentang titik akhir penulis Aurora Global Database, lihat. [Melihat titik akhir database global Amazon Aurora](aurora-global-database-connecting.md#viewing-endpoints)
Untuk informasi selengkapnya tentang titik akhir klaster, lihat[Titik akhir cluster untuk Amazon Aurora](Aurora.Endpoints.Cluster.md).
+ password - Kami menyarankan Anda untuk mengikuti panduan di bawah ini saat membuat kata sandi untuk meningkatkan keamanan:
+ Kata sandi harus berisi setidaknya 8 karakter.
+ Kata sandi harus berisi setidaknya satu huruf besar, satu huruf kecil, dan satu angka.
+ Kata sandi harus memiliki setidaknya satu karakter khusus (`?`, `!`, `#`, `<`, `>`, `*`, dan sebagainya).
**catatan**
Jika Anda mengubah titik akhir, kata sandi, atau nomor port, Anda harus menjalankan `apg_plan_mgmt.create_replica_plan_capture()` lagi dengan titik akhir dan kata sandi untuk menginisialisasi ulang pengambilan paket. Jika tidak, pengambilan rencana dari Replika Aurora akan gagal.
**Nonaktifkan pengambilan rencana untuk Replika Aurora**
Anda dapat menonaktifkan parameter `capture_plan_baselines` di Replika Aurora dengan menetapkan nilainya ke `off` dalam grup Parameter.
**Hapus pengambilan rencana untuk Replika Aurora**
Anda dapat sepenuhnya menghapus Pengambilan Rencana di Replika Aurora tetapi pastikan untuk menonaktifkannya terlebih dahulu. Untuk menghapus pengambilan rencana, panggil `apg_plan_mgmt.remove_replica_plan_capture` seperti yang ditunjukkan berikut:
```
postgres=> CALL apg_plan_mgmt.remove_replica_plan_capture();
```
Anda harus memanggil apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture () lagi untuk mengaktifkan pengambilan rencana di Aurora Replicas dengan titik akhir dan kata sandi.
## Pemecahan Masalah
Di bagian berikut ini, Anda dapat menemukan ide dan solusi pemecahan masalah jika rencana tidak diambil di Replika Aurora seperti yang diharapkan.
+ **Pengaturan parameter** - Periksa apakah parameter `capture_plan_baselines` diatur ke nilai yang tepat untuk mengaktifkan pengambilan rencana.
+ **Ekstensi `postgres_fdw` diinstal** - Gunakan kueri berikut untuk memeriksa apakah `postgres_fdw` diinstal.
```
postgres=> SELECT * FROM pg_extension WHERE extname = 'postgres_fdw'
```
+ **create\$1replica\$1plan\$1capture() dipanggil** - Gunakan perintah berikut untuk memeriksa apakah pemetaan pengguna sudah ada. Jika tidak, panggil `create_replica_plan_capture()` untuk menginisialisasi fitur ini.
```
postgres=> SELECT * FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **Endpoint dan nomor port** - Periksa apakah titik akhir dan nomor port sesuai. Tidak akan ada pesan kesalahan yang ditampilkan jika nilai-nilai ini salah.
Gunakan perintah berikut untuk memverifikasi titik akhir yang digunakan dalam create() dan untuk memeriksa di basis data mana titik akhir tersebut berada:
```
postgres=> SELECT srvoptions FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **reload()** - Anda harus memanggil apg\$1plan\$1mgmt.reload() setelah memanggil apg\$1plan\$1mgmt.delete\$1plan() di Replika Aurora untuk membuat fungsi penghapusan efektif. Hal ini akan memastikan bahwa perubahan telah berhasil diterapkan.
+ **Kata sandi** - Anda harus memasukkan kata sandi di create\$1replica\$1plan\$1capture() sesuai pedoman yang disebutkan. Jika tidak, Anda akan menerima pesan kesalahan. Untuk informasi selengkapnya, lihat [Mengelola pengambilan rencana untuk Replika Aurora](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing). Gunakan kata sandi lain yang sesuai dengan persyaratan.
+ **Koneksi Lintas Wilayah** - Pengambilan rencana di Replika Aurora juga didukung di basis data global Aurora, yang memungkinkan instans penulis dan Replika Aurora berada di wilayah yang berbeda. Pastikan Anda menggunakan titik akhir penulis Aurora Global Database untuk mempertahankan konektivitas setelah peristiwa failover atau switchover. Untuk informasi selengkapnya tentang titik akhir Basis Data Global Aurora, lihat [Melihat titik akhir Database Global Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-connecting.html#viewing-endpoints). Instans penulis dan Replika lintas Wilayah harus dapat berkomunikasi menggunakan Peering VPC. Untuk informasi selengkapnya, lihat [Peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html). Jika failover lintas Wilayah terjadi, Anda harus mengonfigurasi ulang titik akhir ke titik akhir klaster DB primer yang baru.
**catatan**
Saat menggunakan titik akhir cluster alih-alih titik akhir penulis Aurora Global Database, Anda harus memperbarui titik akhir cluster setelah melakukan operasi failover atau switchover global.
# Mendukung partisi tabel
Aurora PostgreSQL Query Plan Management (QPM) mendukung partisi tabel deklaratif dalam versi berikut:
+ 15.3 dan versi 15 yang lebih tinggi
+ 14.8 dan versi 14 yang lebih tinggi
+ 13.11 dan versi 13 yang lebih tinggi
Untuk informasi selengkapnya, lihat [Pemartisian Tabel](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Topics**
+ [Mengatur partisi tabel](#AuroraPostgreSQL.QPM.Partitiontable.setup)
+ [Mengambil rencana untuk partisi tabel](#AuroraPostgreSQL.QPM.Partitiontable.capture)
+ [Memberlakukan rencana partisi tabel](#AuroraPostgreSQL.QPM.Partitiontable.enforcement)
+ [Konvensi Penamaan](#AuroraPostgreSQL.QPM.Partitiontable.naming.convention)
## Mengatur partisi tabel
Untuk mengatur partisi tabel di QPM Aurora PostgreSQL, lakukan hal berikut:
1. Atur `apg_plan_mgmt.plan_hash_version` ke 3 atau lebih di grup parameter klaster DB.
1. Temukan basis data yang menggunakan Manajemen Rencana Kueri dan memiliki entri dalam tampilan `apg_plan_mgmt.dba_plans`.
1. Panggil `apg_plan_mgmt.validate_plans('update_plan_hash')` untuk memperbarui nilai `plan_hash` dalam tabel rencana.
1. Ulangi langkah 2-3 untuk semua basis data dengan Manajemen Rencana Kueri diaktifkan yang memiliki entri dalam tampilan `apg_plan_mgmt.dba_plans`.
Untuk informasi selengkapnya tentang parameter ini, lihat [Referensi parameter untuk manajemen rencana kueri Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Parameters.md).
## Mengambil rencana untuk partisi tabel
Di QPM, berbagai rencana dibedakan berdasarkan nilai `plan_hash`-nya. Untuk memahami perubahan `plan_hash`, Anda harus terlebih dahulu memahami jenis rencana yang serupa.
Kombinasi metode akses, nama indeks tanpa digit, dan nama partisi tanpa digit, yang terakumulasi pada tingkat simpul Append harus konstan agar rencana dianggap sama. Partisi spesifik yang diakses dalam rencana tidaklah signifikan. Dalam contoh berikut, tabel `tbl_a` dibuat dengan 4 partisi.
```
postgres=>create table tbl_a(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table tbl_a1 partition of tbl_a for values from (0) to (1000);
CREATE TABLE
postgres=>create table tbl_a2 partition of tbl_a for values from (1001) to (2000);
CREATE TABLE
postgres=>create table tbl_a3 partition of tbl_a for values from (2001) to (3000);
CREATE TABLE
postgres=>create table tbl_a4 partition of tbl_a for values from (3001) to (4000);
CREATE TABLE
postgres=>create index t_i on tbl_a using btree (i);
CREATE INDEX
postgres=>create index t_j on tbl_a using btree (j);
CREATE INDEX
postgres=>create index t_k on tbl_a using btree (k);
CREATE INDEX
```
Rencana berikut dianggap sama karena metode pemindaian tunggal digunakan untuk memindai `tbl_a` terlepas dari jumlah partisi yang dicari kueri.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 999 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Seq Scan on tbl_a1 tbl_a
Filter: ((i >= 990) AND (i <= 999) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(3 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(8 rows)
```
Tiga rencana berikut juga dianggap sama karena pada tingkat induk, metode akses, nama indeks tanpa digit, dan nama partisi tanpa digit adalah `SeqScan tbl_a`, `IndexScan (i_idx) tbl_a`.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_i_idx on tbl_a2 tbl_a_2
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(7 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(11 rows)
```
Terlepas dari urutan dan jumlah kemunculan yang berbeda dalam partisi turunan, metode akses, nama indeks tanpa digit, dan nama partisi tanpa digit akan tetap konstan pada tingkat induk untuk masing-masing rencana di atas.
Namun, rencana akan dianggap berbeda jika salah satu dari persyaratan berikut terpenuhi:
+ Setiap metode akses tambahan digunakan dalam rencana.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 1134525070
(11 rows)
```
+ Salah satu metode akses dalam rencana tidak digunakan lagi.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
+ Indeks yang terkait dengan metode indeks diubah.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_j_idx on tbl_a2 tbl_a_2
Index Cond: (j < 9910)
Filter: ((i >= 990) AND (i <= 1100) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993343726
(7 rows)
```
## Memberlakukan rencana partisi tabel
Rencana yang disetujui untuk tabel yang dipartisi diberlakukan dengan kesesuaian posisi. Rencana tidak bersifat spesifik untuk partisi, dan dapat diberlakukan pada partisi selain rencana yang direferensikan dalam kueri asli. Rencana juga memiliki kemampuan untuk diberlakukan untuk kueri yang mengakses jumlah partisi yang berbeda dari garis besar asli yang disetujui.
Misalnya, jika garis besar yang disetujui adalah untuk rencana berikut:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
Dengan demikian, rencana ini juga dapat diterapkan pada kueri SQL yang mereferensikan 2, 4, atau lebih partisi. Rencana yang mungkin muncul dari skenario ini untuk akses partisi 2 dan 4 adalah:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(8 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a4 tbl_a_4
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(12 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(14 rows)
```
Pertimbangkan rencana lain yang disetujui dengan metode akses berbeda untuk setiap partisi:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 2032136998
(12 rows)
```
Dalam hal ini, rencana apa pun yang dibaca dari dua partisi akan gagal diberlakukan. Kecuali jika semua kombinasi (metode akses, nama indeks) dari rencana yang disetujui dapat digunakan, rencana tidak dapat diberlakukan. Misalnya, rencana berikut memiliki hash rencana yang berbeda dan rencana yang disetujui tidak dapat diberlakukan dalam kasus ini:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------------
Append
-> Bitmap Heap Scan on tbl_a1 tbl_a_1
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a1_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
-> Bitmap Heap Scan on tbl_a2 tbl_a_2
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a2_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -568647260
(13 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1900) AND (j < 9910) AND (k > 50))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -496793743
(8 rows)
```
## Konvensi Penamaan
Agar QPM dapat menerapkan rencana dengan tabel partisi deklaratif, Anda harus mengikuti aturan penamaan khusus untuk tabel induk, partisi tabel, dan indeks:
+ **Nama tabel induk** — Nama-nama ini harus berbeda menurut huruf atau karakter khusus, dan bukan hanya dengan angka. Misalnya, tA, tB, dan tC adalah nama yang dapat diterima untuk tabel induk terpisah, sedangkan t1, t2, dan t3 tidak.
+ **Nama tabel partisi individu** — Partisi dari induk yang sama harus berbeda satu sama lain dengan digit saja. Misalnya, nama partisi tA yang dapat diterima bisa berupa tA1, tA2, atau t1A, t2A, atau bahkan dengan beberapa angka.
Perbedaan lain (huruf, karakter khusus) tidak akan menjamin pemberlakuan rencana.
+ **Nama indeks** — Dalam hierarki tabel partisi, pastikan bahwa semua indeks memiliki nama yang unik. Ini berarti bahwa bagian non-numerik dari nama harus berbeda. Misalnya, jika Anda memiliki tabel dipartisi bernama `tA` dengan indeks bernama`tA_col1_idx1`, Anda tidak dapat memiliki indeks lain bernama. `tA_col1_idx2` Namun, Anda dapat memiliki indeks yang dipanggil `tA_a_col1_idx2` karena bagian non-numerik dari nama itu unik. Aturan ini berlaku untuk indeks yang dibuat pada tabel induk dan tabel partisi individu.
Jika konvensi penamaan di atas tidak dipatuhi, pemberlakuan rencana yang disetujui dapat gagal. Contoh berikut mengilustrasikan pemberlakuan yang gagal:
```
postgres=>create table t1(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table t1a partition of t1 for values from (0) to (1000);
CREATE TABLE
postgres=>create table t1b partition of t1 for values from (1001) to (2000);
CREATE TABLE
postgres=>SET apg_plan_mgmt.capture_plan_baselines TO 'manual';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 0;
QUERY PLAN
--------------------------------------------------------------------------
Aggregate
-> Append
-> Seq Scan on t1a t1_1
Filter: (i > 0)
-> Seq Scan on t1b t1_2
Filter: (i > 0)
SQL Hash: -1720232281, Plan Hash: -1010664377
(7 rows)
```
```
postgres=>SET apg_plan_mgmt.use_plan_baselines TO 'on';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 1000;
QUERY PLAN
-------------------------------------------------------------------------
Aggregate
-> Seq Scan on t1b t1
Filter: (i > 1000)
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: -1720232281, Plan Hash: 335531806
(5 rows)
```
Meskipun kedua rencana mungkin tampak identik, `Plan Hash` nilainya berbeda karena nama tabel anak. Nama tabel bervariasi menurut karakter alfa, bukan hanya digit yang mengarah ke kegagalan penegakan hukum.