Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memantau Database Tanpa Batas Aurora PostgreSQL
Anda dapat menggunakan Amazon CloudWatch, Enhanced Monitoring, dan Performance Insights untuk memantau Database Aurora PostgreSQL Limitless. Ada juga fungsi dan tampilan statistik baru, dan acara tunggu, untuk Aurora PostgreSQL Limitless Database yang dapat Anda gunakan untuk pemantauan dan diagnostik.
**Topics**
+ [Memantau Database Tanpa Batas Aurora PostgreSQL dengan Amazon CloudWatch](limitless-monitoring.cw.md)
+ [Memantau Database Tanpa Batas Aurora PostgreSQL dengan Wawasan Database CloudWatch](limitless-monitoring.cwdbi.md)
+ [Memantau Basis Data SQL Tanpa Batas Aurora Postgre dengan Log Amazon CloudWatch](limitless-monitoring.cwl.md)
+ [Memantau Basis Data SQL Tanpa Batas Aurora Postgre dengan Pemantauan yang Ditingkatkan](limitless-monitoring.em.md)
+ [Memantau Database Limitless PostgreSQL Aurora dengan Performance Insights](limitless-monitoring.pi.md)
+ [Memantau Basis Data SQL Tanpa Batas Aurora Postgre dengan Perlindungan Amazon GuardDuty RDS](limitless-monitoring.gd.md)
+ [Fungsi dan tampilan untuk Aurora SQL Postgre Limitless Database](limitless-monitoring-fns-views.md)
+ [Tunggu acara untuk Aurora SQL Postgre Limitless Database](limitless-monitoring-waits.md)
+ [Membangun untuk efisiensi dengan fungsi](limitless-performance-functions.md)
# Memantau Database Tanpa Batas Aurora PostgreSQL dengan Amazon CloudWatch
CloudWatch metrik untuk Aurora PostgreSQL Limitless Database dilaporkan dalam dimensi berikut:
+ [DBShardKelompok](#limitless-monitoring.cw.DBShardGroup)
+ [DBShardGroupRouterAggregation](#limitless-monitoring.cw.DBShardGroupRouterAggregate)
+ [DBShardGroupInstance](#limitless-monitoring.cw.DBShardGroupInstance)
+ [DBClusterPengenal](#limitless-monitoring.cw.DBClusterIdentifier)
Untuk informasi selengkapnya tentang CloudWatch metrik, lihat[Memantau Amazon Aurora dengan Amazon CloudWatch](monitoring-cloudwatch.md).
## DBShardMetrik grup
****Untuk melihat `DBShardGroup` metrik Aurora PostgreSQL Limitless Database CloudWatch di konsol, pilih RDS, lalu pilih Grup. DBShard****
Anda dapat melacak CloudWatch metrik berikut:
+ `DBShardGroupACUUtilization`— Penggunaan unit kapasitas Aurora (ACU) sebagai persentase yang dihitung dari `DBShardGroupCapacity` dibagi dengan. `DBShardGroupMaxACU`
+ `DBShardGroupCapacity`— Jumlah yang ACUs dikonsumsi oleh contoh penulis dari kelompok pecahan DB.
+ `DBShardGroupComputeRedundancyCapacity`— Jumlah yang ACUs dikonsumsi oleh instance siaga grup shard DB.
+ `DBShardGroupMaxACU`— Jumlah maksimum yang ACUs dikonfigurasi untuk grup pecahan DB.
+ `DBShardGroupMinACU`— Jumlah minimum yang ACUs dibutuhkan oleh grup pecahan DB.
Kunci `DBShardGroupIdentifier` dimensi tersedia untuk menggabungkan metrik. `DBShardGroup`
## DBShardGroupRouterAggregation metrik
**Untuk melihat `DBShardGroupRouterAggregation` metrik Aurora PostgreSQL Limitless Database CloudWatch di konsol, pilih RDS, lalu pilih. **DBShardGroupRouterAggregation****
Anda dapat melacak CloudWatch metrik berikut:
+ `CommitThroughput`— Jumlah rata-rata operasi komit per detik di semua node router dalam grup shard DB.
+ `DatabaseConnections`— Jumlah semua koneksi di semua node router dalam grup shard DB.
## DBShardGroupInstance metrik
A DBShardGroupInstanceadalah instance DB individu dalam setiap shard atau subcluster router.
**Untuk melihat `DBShardGroupInstance` metrik Aurora PostgreSQL Limitless Database CloudWatch di konsol, pilih RDS, lalu pilih. **DBShardGroupInstance****
Anda dapat melacak CloudWatch metrik berikut:
+ `ACUUtilization`— Persentase dihitung sebagai `ServerlessDatabaseCapacity` metrik dibagi dengan nilai ACU maksimum yang ditetapkan dari subcluster.
+ `AuroraReplicaLag`- Untuk redundansi komputasi yang diaktifkan Limitless cluster, ini adalah jumlah lag saat mereplikasi pembaruan dari instance utama di subcluster.
+ `AuroraReplicaLagMaximum`— Untuk redundansi komputasi yang diaktifkan Limitless cluster, ini adalah jumlah maksimum lag saat mereplikasi pembaruan dari instance utama di subcluster. Ketika replika baca dihapus atau diganti namanya, mungkin ada lonjakan sementara dalam kelambatan replikasi saat sumber daya lama didaur ulang. Gunakan metrik ini untuk mengetahui apakah failover terjadi karena kelambatan replikasi yang tinggi pada salah satu pembacanya.
+ `AuroraReplicaLagMinimum`— Untuk redundansi komputasi yang diaktifkan Limitless cluster, ini adalah jumlah minimum lag saat mereplikasi pembaruan dari instance utama di subcluster.
+ `BufferCacheHitRatio`— Persentase data dan indeks yang disajikan dari cache memori instance (sebagai lawan dari volume penyimpanan).
+ `CommitLatency`— Durasi rata-rata untuk mesin dan penyimpanan untuk menyelesaikan operasi komit untuk node tertentu (router atau shard).
+ `CommitThroughput`— Jumlah rata-rata operasi komit per detik.
+ `CPUUtilization`— Penggunaan CPU sebagai persentase dari nilai ACU maksimum yang ditetapkan dari subcluster.
+ `FreeableMemory`— Jumlah memori yang tidak terpakai yang tersedia ketika kelompok shard diskalakan ke kapasitas maksimumnya. Ini ditentukan oleh yang ditugaskan ACUs dari kelompok pecahan. Untuk setiap ACU kapasitas saat ini di bawah kapasitas maksimum, nilai ini meningkat sekitar 2 GiB. Dengan demikian, metrik ini tidak mendekati nol sampai kelompok pecahan DB diskalakan hingga batas maksimum.
+ `MaximumUsedTransactionIDs`— Usia ID transaksi tertua yang tidak disedot, dalam transaksi. Jika nilai ini mencapai 2.146.483.648 (2^31 - 1.000.000), basis data akan dipaksa ke mode hanya baca untuk menghindari wraparound ID transaksi. Untuk informasi selengkapnya, lihat [Preventing transaction ID wraparound failures](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) dalam dokumentasi PostgreSQL.
+ `NetworkReceiveThroughput`— Jumlah throughput jaringan yang diterima dari klien oleh setiap instance dalam grup shard DB. Throughput ini tidak termasuk lalu lintas jaringan antara instance dalam grup shard DB dan volume cluster.
+ `NetworkThroughput`— Throughput jaringan agregat (baik ditransmisikan dan diterima) antara klien dan router, dan router dan pecahan dalam grup pecahan DB. Throughput ini tidak termasuk lalu lintas jaringan antara instance dalam grup shard DB dan volume cluster.
+ `NetworkTransmitThroughput`— Jumlah throughput jaringan yang dikirim ke klien oleh setiap instance dalam grup shard DB. Throughput ini tidak termasuk lalu lintas jaringan antara instance dalam grup shard DB dan volume cluster.
+ `ReadIOPS`— Jumlah rata-rata operasi input/output baca disk per detik (IOPS).
+ `ReadLatency`— Jumlah rata-rata waktu yang dibutuhkan per disk readinput/output (I/O) operasi.
+ `ReadThroughput`— Jumlah rata-rata byte yang dibaca dari disk per detik.
+ `ServerlessDatabaseCapacity`- Kapasitas saat ini dari pecahan DB atau subcluster router dalam grup pecahan DB.
+ `StorageNetworkReceiveThroughput`— Jumlah throughput jaringan yang diterima dari subsistem penyimpanan Aurora oleh setiap instance dalam grup pecahan DB.
+ `StorageNetworkThroughput`— Throughput jaringan agregat yang ditransmisikan ke dan diterima dari subsistem penyimpanan Aurora oleh setiap instance dalam grup pecahan DB.
+ `StorageNetworkTransmitThroughput`— Jumlah throughput jaringan yang dikirim ke subsistem penyimpanan Aurora oleh setiap instance dalam grup pecahan DB.
+ `SwapUsage`— Jumlah ruang swap yang digunakan oleh grup shard DB.
+ `TempStorageIOPS`— Jumlah rata-rata operasi I/O yang dilakukan pada penyimpanan lokal yang melekat pada instans DB. Ini mencakup operasi baca dan tulis I/O.
`TempStorageIOPS`dapat digunakan `TempStorageThroughput` untuk mendiagnosis kasus yang jarang terjadi di mana aktivitas jaringan untuk transfer antara instans DB Anda dan perangkat penyimpanan lokal bertanggung jawab atas peningkatan kapasitas yang tidak terduga.
+ `TempStorageThroughput`— Jumlah data yang ditransfer ke dan dari penyimpanan lokal yang terkait dengan router atau pecahan.
+ `WriteIOPS`— Jumlah rata-rata disk menulis IOPS.
+ `WriteLatency`— Jumlah rata-rata waktu yang dibutuhkan per disk menulis operasi I/O.
+ `WriteThroughput`— Jumlah rata-rata byte yang ditulis ke disk per detik.
Kunci dimensi berikut tersedia untuk menggabungkan metrik: `DBShardGroupInstance`
+ `DBClusterIdentifier`— Cluster DB PostgreSQL Aurora.
+ `DBShardGroupIdentifier`— Grup pecahan DB tempat instance tersebut berada.
+ `DBShardGroupSubClusterType`— Tipe node, baik `Distributed Transaction Router` (router) atau `Data Access Shard` (shard).
+ `DBShardGroupSubClusterIdentifier`— Nama router atau pecahan tempat instance tersebut berada.
Berikut ini adalah contoh metrik agregasi CloudWatch :
+ Total `CPUUtilization` semua instance yang termasuk dalam shard atau router tertentu dalam grup shard DB.
+ Total `CPUUtilization` semua instance dalam grup pecahan DB.
## DBClusterMetrik pengenal
****Untuk melihat `DBClusterIdentifier` metrik Aurora PostgreSQL Limitless Database CloudWatch di konsol, pilih RDS, lalu pilih Identifier. DBCluster****
Bila Anda menggunakan Aurora PostgreSQL Limitless Database, Anda mungkin memiliki lebih banyak) input/output (I/O operasi daripada yang Anda lakukan untuk cluster Aurora DB. Anda dapat melacak CloudWatch metrik berikut untuk klaster Limitless Database Anda:
+ `VolumeReadIops`— Jumlah operasi I/O baca yang ditagih dari volume cluster, dilaporkan pada interval 5 menit.
+ `VolumeWriteIops`— Jumlah operasi I/O disk tulis ke volume cluster, dilaporkan pada interval 5 menit.
Aurora PostgreSQL Limitless Database menggunakan konfigurasi penyimpanan cluster. Aurora I/O-Optimized DenganAurora I/O-Optimized, Anda membayar satu harga bulanan untuk semua operasi I/O, daripada membayar untuk setiap satu juta permintaan I/O. Untuk informasi selengkapnya, lihat [Konfigurasi penyimpanan untuk klaster DB Amazon Aurora](Aurora.Overview.StorageReliability.md#aurora-storage-type).
Anda mungkin juga menggunakan lebih banyak penyimpanan daripada yang Anda lakukan untuk cluster Aurora DB. Anda dapat melacak CloudWatch metrik berikut untuk penyimpanan:
+ `BackupRetentionPeriodStorageUsed`— Total penggunaan penyimpanan cadangan berkelanjutan yang ditagih dari cluster Database Aurora PostgreSQL Limitless Anda.
+ `SnapshotStorageUsed`— Total penggunaan penyimpanan snapshot yang ditagih dari cluster Database Aurora PostgreSQL Limitless Anda.
+ `TotalBackupStorageBilled`— Jumlah biaya Anda untuk retensi cadangan otomatis dan snapshot cluster DB.
Untuk informasi selengkapnya tentang biaya penyimpanan cadangan, lihat[Memahami penggunaan penyimpanan cadangan Amazon Aurora](aurora-storage-backup.md).
+ `VolumeBytesUsed`— Jumlah penyimpanan yang digunakan oleh cluster Database Aurora PostgreSQL Limitless Anda, dilaporkan pada interval 5 menit.
# Memantau Database Tanpa Batas Aurora PostgreSQL dengan Wawasan Database CloudWatch
Mode Standar Database Insights diperlukan sebagai bagian dari mengaktifkan Aurora PostgreSQL Limitless Database. Anda dapat menggunakannya untuk memantau beban database (DB Load) dari instans DB Limitless Database Anda secara real time. DB Load mengukur tingkat aktivitas sesi dalam database. Anda dapat menggunakan Database Insights untuk menganalisis dan memecahkan masalah kinerja instans DB Database PostgreSQL Limitless Aurora Anda dalam skala besar.
Untuk informasi selengkapnya tentang CloudWatch Database Insights, lihat berikut ini.
+ [Memantau database Amazon Aurora dengan Database CloudWatch Insights](USER_DatabaseInsights.md)
+ [CloudWatch Wawasan Database](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html) di * CloudWatch Panduan Pengguna Amazon*
+ [Memulai Wawasan CloudWatch Database](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Get-Started.html) di * CloudWatch Panduan Pengguna Amazon*
+ [](USER_DatabaseInsights.SlowSQL.md)
Untuk informasi tentang mengaktifkan mode Lanjutan atau Mode Standar Wawasan Database, lihat topik berikut.
**Topics**
+ [Mengaktifkan mode Advanced Database Insights untuk Aurora PostgreSQL Limitless Database](limitless-monitoring.cwdbi.advanced.md)
+ [Mengaktifkan mode Standar Wawasan Database untuk Aurora PostgreSQL Limitless Database](limitless-monitoring.cwdbi.standard.md)
# Mengaktifkan mode Advanced Database Insights untuk Aurora PostgreSQL Limitless Database
Untuk mengaktifkan mode Advanced Database Insights untuk Aurora PostgreSQL Limitless Database Anda, gunakan prosedur berikut.
## Mengaktifkan mode Advanced Database Insights saat membuat cluster DB untuk Aurora PostgreSQL Limitless Database
Aktifkan mode Advanced Database Insights saat membuat database untuk Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
Di konsol, Anda dapat mengaktifkan mode Advanced Database Insights saat membuat cluster DB. Pengaturan untuk Database Insights berlaku untuk semua instans DB di cluster DB Anda.
**Untuk mengaktifkan mode Advanced Database Insights saat membuat cluster DB menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Basis data**.
1. Pilih **Buat basis data**.
1. Di bagian **Database Insights**, pilih **Mode lanjutan**. Kemudian, pilih opsi berikut:
+ **Retensi** – Jumlah waktu untuk mempertahankan data Wawasan Performa. Periode retensi harus 15-24 bulan untuk mode Advanced Database Insights.
+ **AWS KMS key** – Tentukan kunci KMS Anda. Wawasan Performa mengenkripsi semua data yang berpotensi sensitif menggunakan kunci KMS Anda. Data dienkripsi saat dipindahkan dan saat tidak aktif. Untuk informasi selengkapnya, lihat [Mengenkripsi sumber daya Amazon Aurora](Overview.Encryption.md).
1. Pilih **Buat basis data**.
------
#### [ AWS CLI ]
Untuk mengaktifkan mode Advanced Database Insights saat membuat cluster DB, panggil [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI perintah dan berikan nilai berikut:
+ `--db-cluster-identifier`— Pengidentifikasi untuk cluster DB.
+ `--database-insights-mode advanced`untuk mengaktifkan mode Advanced Database Insights.
+ `--engine`- Cluster DB harus menggunakan mesin `aurora-postgresql` DB.
+ `--engine-version`- Cluster DB harus menggunakan salah satu versi mesin DB:
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type`- Cluster DB harus menggunakan konfigurasi penyimpanan cluster `aurora-iopt1` DB.
+ `--cluster-scalability-type`— Menentukan mode skalabilitas cluster Aurora DB. Ketika diatur ke`limitless`, cluster beroperasi sebagai Database Aurora PostgreSQL Limitless. Ketika diatur ke `standard` (default), cluster menggunakan pembuatan instans DB normal.
**catatan**
Anda tidak dapat mengubah pengaturan ini setelah Anda membuat cluster DB.
+ `--master-username`— Nama pengguna master untuk cluster DB.
+ `--master-user-password`— Kata sandi untuk pengguna utama.
+ `--enable-performance-insights`untuk mengaktifkan Performance Insights untuk Database Insights.
+ `--performance-insights-retention-period`— Periode retensi untuk data untuk cluster DB Anda. Untuk mengaktifkan Database Insights, periode retensi harus minimal 465 hari.
+ `--monitoring-interval`— Interval, dalam hitungan detik, antara titik-titik saat metrik Pemantauan yang Ditingkatkan dikumpulkan untuk cluster DB. Nilai ini tidak bisa`0`.
+ `--monitoring-role-arn`— Nama Sumber Daya Amazon (ARN) untuk peran IAM yang memungkinkan RDS mengirim metrik Pemantauan yang Ditingkatkan ke Log Amazon. CloudWatch
+ `--enable-cloudwatch-logs-exports`— Anda harus mengekspor `postgresql` log ke CloudWatch Log.
Contoh berikut memungkinkan mode Advanced Database Insights saat membuat cluster DB.
Untuk Linux, macOS, atau Unix:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode advanced \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 465 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Untuk Windows:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode advanced ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 465 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
Untuk mengaktifkan mode Advanced Database Insights saat Anda membuat , tentukan parameter berikut untuk operasi [Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) RDS API.
+ `DatabaseInsightsMode` untuk `advanced`
+ `Engine` untuk `aurora-postgresql`
+ `EngineVersion`ke versi mesin yang tersedia untuk Limitless Database
+ `StorageType` untuk `aurora-iopt1`
+ `ClusterScalabilityType` untuk `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` untuk `True`
+ `PerformanceInsightsRetentionPeriod`setidaknya `465` berhari-hari
+ `MonitoringInterval`Untuk nilai yang tidak `0`
+ `MonitoringRoleArn`ke Nama Sumber Daya Amazon (ARN) untuk peran IAM yang memungkinkan RDS mengirim metrik Pemantauan yang Ditingkatkan ke Log Amazon CloudWatch
------
## Mengaktifkan mode Advanced Database Insights saat memodifikasi cluster DB untuk Aurora PostgreSQL Limitless Database
Aktifkan Database Insights saat memodifikasi database untuk Aurora PostgreSQL Limitless Database.
**catatan**
Untuk mengaktifkan Database Insights, setiap instans DB di klaster AdB harus memiliki pengaturan Performance Insights dan Enhanced Monitoring yang sama.
------
#### [ Console ]
Di konsol, Anda dapat mengaktifkan mode Advanced Database Insights saat Anda memodifikasi cluster DB. Pengaturan untuk Database Insights berlaku untuk semua instans DB di cluster DB Anda.
**Untuk mengaktifkan mode Advanced Database Insights saat memodifikasi cluster DB menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Basis data**.
1. Pilih cluster DB, dan pilih **Modify**.
1. Di bagian **Database Insights**, pilih **Mode lanjutan**. Kemudian, pilih opsi berikut:
+ **Retensi** – Jumlah waktu untuk mempertahankan data Wawasan Performa. Periode retensi harus 15-24 bulan untuk mode Advanced Database Insights.
+ **AWS KMS key** – Tentukan kunci KMS Anda. Wawasan Performa mengenkripsi semua data yang berpotensi sensitif menggunakan kunci KMS Anda. Data dienkripsi saat dipindahkan dan saat tidak aktif. Untuk informasi selengkapnya, lihat [Mengenkripsi sumber daya Amazon Aurora](Overview.Encryption.md).
1. Pilih **Lanjutkan**.
1. Untuk **Penjadwalan Modifikasi**, pilih **Langsung terapkan**. Jika Anda memilih **Terapkan selama jendela pemeliharaan terjadwal berikutnya**, database Anda akan mengabaikan pengaturan ini dan segera mengaktifkan mode Advanced Database Insights.
1. Pilih **Ubah klaster**.
------
#### [ AWS CLI ]
Untuk mengaktifkan mode Advanced Database Insights saat memodifikasi cluster DB, panggil [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI perintah dan berikan nilai berikut:
+ `--database-insights-mode advanced`untuk mengaktifkan mode Advanced Database Insights.
+ `--db-cluster-identifier`— Pengidentifikasi untuk cluster DB.
+ `--enable-performance-insights`untuk mengaktifkan Performance Insights untuk Database Insights.
+ `--performance-insights-retention-period`— Periode retensi untuk data untuk Anda. Untuk mengaktifkan mode Advanced Database Insights, periode retensi harus minimal 465 hari.
Contoh berikut memungkinkan mode Advanced Database Insights saat memodifikasi cluster DB.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster \
--database-insights-mode advanced \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 465
```
Untuk Windows:
```
aws rds modify-db-cluster ^
--database-insights-mode advanced ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 465
```
------
#### [ RDS API ]
Untuk mengaktifkan mode Advanced Database Insights saat Anda memodifikasi kluster DB, tentukan parameter berikut untuk operasi [Modify DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API.
+ `DatabaseInsightsMode` untuk `advanced`
+ `EnablePerformanceInsights` untuk `True`
+ `PerformanceInsightsRetentionPeriod`setidaknya `465` berhari-hari
------
# Mengaktifkan mode Standar Wawasan Database untuk Aurora PostgreSQL Limitless Database
Untuk mengaktifkan mode Standar Wawasan Database untuk Database Aurora PostgreSQL Limitless Anda, gunakan prosedur berikut.
## Mengaktifkan mode Standar Database Insights saat membuat cluster DB untuk Aurora PostgreSQL Limitless Database
Aktifkan mode Standar Database Insights saat membuat database untuk Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
Di konsol, Anda dapat mengaktifkan mode Standar Database Insights saat membuat cluster DB. Pengaturan untuk Database Insights berlaku untuk semua instans DB di cluster DB Anda.
**Untuk mengaktifkan mode Standar Database Insights saat membuat cluster DB menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Basis data**.
1. Pilih **Buat basis data**.
1. Di bagian **Database Insights**, pilih **Mode standar**. Kemudian, pilih opsi berikut:
+ **Retensi** – Jumlah waktu untuk mempertahankan data Wawasan Performa. Untuk membuat cluster DB untuk Aurora PostgreSQL Limitless Database, periode retensi harus minimal 31 hari.
+ **AWS KMS key** – Tentukan kunci KMS Anda. Wawasan Performa mengenkripsi semua data yang berpotensi sensitif menggunakan kunci KMS Anda. Data dienkripsi saat dipindahkan dan saat tidak aktif. Untuk informasi selengkapnya, lihat [Mengenkripsi sumber daya Amazon Aurora](Overview.Encryption.md).
1. Pilih **Buat basis data**.
------
#### [ AWS CLI ]
Untuk mengaktifkan mode Standar Database Insights saat membuat cluster DB, panggil [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI perintah dan berikan nilai berikut:
+ `--db-cluster-identifier`— Pengidentifikasi untuk cluster DB.
+ `--database-insights-mode standard`untuk mengaktifkan mode Standar Wawasan Database.
+ `--engine`- Cluster DB harus menggunakan mesin `aurora-postgresql` DB.
+ `--engine-version`- Cluster DB harus menggunakan salah satu versi mesin DB:
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type`- Cluster DB harus menggunakan konfigurasi penyimpanan cluster `aurora-iopt1` DB.
+ `--cluster-scalability-type`— Menentukan mode skalabilitas cluster Aurora DB. Ketika diatur ke`limitless`, cluster beroperasi sebagai Database Aurora PostgreSQL Limitless. Ketika diatur ke `standard` (default), cluster menggunakan pembuatan instans DB normal.
**catatan**
Anda tidak dapat mengubah pengaturan ini setelah Anda membuat cluster DB.
+ `--master-username`— Nama pengguna master untuk cluster DB.
+ `--master-user-password`— Kata sandi untuk pengguna utama.
+ `--enable-performance-insights`untuk mengaktifkan Performance Insights untuk Database Insights.
+ `--performance-insights-retention-period`— Periode retensi untuk data untuk cluster DB Anda. Untuk membuat cluster DB untuk Aurora PostgreSQL Limitless Database, periode retensi harus minimal 31 hari.
+ `--monitoring-interval`— Interval, dalam hitungan detik, antara titik-titik saat metrik Pemantauan yang Ditingkatkan dikumpulkan untuk cluster DB. Nilai ini tidak bisa`0`.
+ `--monitoring-role-arn`— Nama Sumber Daya Amazon (ARN) untuk peran IAM yang memungkinkan RDS mengirim metrik Pemantauan yang Ditingkatkan ke Log Amazon. CloudWatch
+ `--enable-cloudwatch-logs-exports`— Anda harus mengekspor `postgresql` log ke CloudWatch Log.
Contoh berikut memungkinkan mode Standar Database Insights saat membuat cluster DB.
Untuk Linux, macOS, atau Unix:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode standard \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 31 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Untuk Windows:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode standard ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 31 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
Untuk mengaktifkan mode Standar Database Insights saat Anda membuat , tentukan parameter berikut untuk operasi [Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) RDS API Anda.
+ `DatabaseInsightsMode` untuk `standard`
+ `Engine` untuk `aurora-postgresql`
+ `EngineVersion`ke versi mesin yang tersedia untuk Limitless Database
+ `StorageType` untuk `aurora-iopt1`
+ `ClusterScalabilityType` untuk `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` untuk `True`
+ `PerformanceInsightsRetentionPeriod`setidaknya `31` berhari-hari
+ `MonitoringInterval`Untuk nilai yang tidak `0`
+ `MonitoringRoleArn`ke Nama Sumber Daya Amazon (ARN) untuk peran IAM yang memungkinkan RDS mengirim metrik Pemantauan yang Ditingkatkan ke Log Amazon CloudWatch
------
## Mengaktifkan mode Standar Database Insights saat memodifikasi cluster DB untuk Aurora PostgreSQL Limitless Database
Aktifkan Database Insights saat memodifikasi database untuk Aurora PostgreSQL Limitless Database.
**catatan**
Untuk mengaktifkan Database Insights, setiap instans DB di cluster DB harus memiliki pengaturan Performance Insights dan Enhanced Monitoring yang sama.
------
#### [ Console ]
Di konsol, Anda dapat mengaktifkan mode Standar Database Insights saat membuat cluster DB. Pengaturan untuk Database Insights berlaku untuk semua instans DB di cluster DB Anda.
**Untuk mengaktifkan mode Standar Database Insights saat memodifikasi cluster DB menggunakan konsol**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Pilih **Basis data**.
1. Pilih cluster DB, dan pilih **Modify**.
1. Di bagian **Database Insights**, pilih **Mode standar**. Kemudian, pilih opsi berikut:
+ **Retensi** – Jumlah waktu untuk mempertahankan data Wawasan Performa. Untuk membuat cluster DB untuk Aurora PostgreSQL Limitless Database, periode retensi harus minimal 31 hari.
+ **AWS KMS key** – Tentukan kunci KMS Anda. Wawasan Performa mengenkripsi semua data yang berpotensi sensitif menggunakan kunci KMS Anda. Data dienkripsi saat dipindahkan dan saat tidak aktif. Untuk informasi selengkapnya, lihat [Mengenkripsi sumber daya Amazon Aurora](Overview.Encryption.md).
1. Pilih **Lanjutkan**.
1. Untuk **Penjadwalan Modifikasi**, pilih **Langsung terapkan**. Jika Anda memilih **Terapkan selama jendela pemeliharaan terjadwal berikutnya**, database Anda akan mengabaikan pengaturan ini dan segera mengaktifkan mode Standar Database Insights.
1. Pilih **Ubah klaster**.
------
#### [ AWS CLI ]
Untuk mengaktifkan mode Standar Database Insights saat memodifikasi cluster DB, panggil [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI perintah dan berikan nilai berikut:
+ `--db-cluster-identifier`— Pengidentifikasi untuk cluster DB.
+ `--database-insights-mode standard`untuk mengaktifkan mode Standar Wawasan Database.
+ `--enable-performance-insights`untuk mengaktifkan Performance Insights untuk Database Insights.
+ `--performance-insights-retention-period`— Periode retensi untuk data untuk cluster DB Anda. Untuk mengaktifkan mode Standar Wawasan Database, periode retensi harus minimal 31 hari.
Contoh berikut memungkinkan mode Standar Database Insights saat memodifikasi cluster DB.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster \
--database-insights-mode standard \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 31
```
Untuk Windows:
```
aws rds modify-db-cluster ^
--database-insights-mode standard ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 31
```
------
#### [ RDS API ]
Untuk mengaktifkan mode Standar Database Insights saat Anda memodifikasi kluster DB, tentukan parameter berikut untuk operasi [Modify DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API.
+ `DatabaseInsightsMode` untuk `standard`
+ `EnablePerformanceInsights` untuk `True`
+ `PerformanceInsightsRetentionPeriod`setidaknya `31` berhari-hari
------
# Memantau Basis Data SQL Tanpa Batas Aurora Postgre dengan Log Amazon CloudWatch
Mengekspor log Postgre ke SQL CloudWatch Log diperlukan sebagai bagian dari mengaktifkan Basis Data Tanpa Batas Aurora Postgre. SQL Anda dapat mengakses dan menganalisis log ini di Wawasan Log, mirip dengan mengakses CloudWatch log Postgre untuk klaster DB Aurora Postgre SQL standar. SQL Untuk informasi selengkapnya, lihat [Menganalisis log PostgreSQL menggunakan Wawasan Log CloudWatch](AuroraPostgreSQL.CloudWatch.Analyzing.md).
Nama grup log untuk cluster DB sama seperti di Aurora Postgre: SQL
```
/aws/rds/cluster/DB_cluster_ID/postgresql
```
Nama grup log untuk grup pecahan DB mengambil bentuk berikut:
```
/aws/rds/cluster/DB_cluster_ID/DB_shard_group_ID/postgresql
```
Ada aliran log untuk setiap node (router atau shard). Nama mereka memiliki bentuk berikut:
```
[DistributedTransactionRouter|DataAccessShard]/node_cluster_serial_ID-node_instance_serial_ID/n
```
Sebagai contoh:
+ Router — `DistributedTransactionRouter/6-6.2`
+ Pecahan — `DataAccessShard/22-22.0`
**catatan**
Anda tidak dapat melihat file SQL log Postgre untuk grup pecahan DB langsung di RDS konsol AWS CLI, atau RDS API seperti yang Anda bisa untuk cluster DB. Anda harus menggunakan Wawasan CloudWatch Log untuk melihatnya.
# Memantau Basis Data SQL Tanpa Batas Aurora Postgre dengan Pemantauan yang Ditingkatkan
Pemantauan yang Disempurnakan diperlukan sebagai bagian dari mengaktifkan Basis Data Tanpa Batas Aurora SQL Postgre. Anda dapat menggunakannya untuk memantau sistem operasi instans DB Limitless Database Anda secara real time.
Aurora menerbitkan metrik Pemantauan yang Ditingkatkan di Log. CloudWatch Beberapa metrik utama yang tersedia termasuk koneksi database, penggunaan penyimpanan, dan latensi kueri. Ini dapat membantu mengidentifikasi kemacetan kinerja.
Untuk informasi selengkapnya tentang metrik Pemantauan yang Ditingkatkan, lihat[Metrik OS untuk Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
# Memantau Database Limitless PostgreSQL Aurora dengan Performance Insights
Gunakan Performance Insights untuk memantau klaster Database Aurora PostgreSQL Limitless Anda. Performance Insights bekerja sama untuk Aurora PostgreSQL Limitless Database seperti halnya untuk cluster DB Aurora standar. Namun, Anda melacak metrik di tingkat grup shard untuk Aurora PostgreSQL Limitless Database.
Dua metrik Performance Insights utama yang harus dilacak adalah sebagai berikut:
+ Beban basis data - Mengukur tingkat aktivitas dalam database Anda. Metrik utama dalam Wawasan Performa adalah `DBLoad`, yang dikumpulkan setiap detik.
Unit untuk `DBLoad` metrik dalam Performance Insights adalah sesi aktif rata-rata (AAS). Untuk mendapatkan rata-rata sesi aktif, Performance Insights mengambil sampel jumlah sesi yang menjalankan kueri secara bersamaan. AAS adalah jumlah total sesi dibagi dengan jumlah total sampel untuk periode waktu tertentu. Untuk informasi lebih lanjut tentang `DBLoad` dan AAS, lihat[Muatan basis data](USER_PerfInsights.Overview.ActiveSessions.md).
+ CPU Maksimum — Daya komputasi maksimum yang tersedia untuk database Anda. Untuk melihat apakah sesi aktif melebihi CPU maksimum, lihat hubungannya dengan `Max vCPU` garis. `Max vCPU`Nilai ditentukan oleh jumlah inti vCPU (CPU virtual) untuk instans DB Anda. Untuk informasi selengkapnya tentang `Max vCPU`, lihat [Maksimum CPU](USER_PerfInsights.Overview.MaxCPU.md).
Selain itu, Anda dapat “mengiris” `DBLoad` metrik ke dalam *dimensi*, yang merupakan subkategori dari metrik. Dimensi yang paling berguna adalah sebagai berikut:
+ Instans teratas - Menunjukkan beban DB relatif untuk instans Anda (pecahan dan router) dalam urutan menurun.
+ Tunggu peristiwa - Menyebabkan pernyataan SQL menunggu peristiwa tertentu terjadi sebelum mereka dapat terus berjalan. Acara tunggu menunjukkan di mana pekerjaan terhambat.
+ SQL Teratas - Menunjukkan kueri mana yang paling berkontribusi pada pemuatan DB.
Untuk informasi selengkapnya tentang dimensi Performance Insights, lihat. [Dimensi](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions)
Gambar berikut menunjukkan dimensi **contoh Top** untuk grup pecahan DB.
![\[Dimensi instance teratas untuk grup pecahan DB.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
**Topics**
+ [Menganalisis beban DB untuk Aurora PostgreSQL Limitless Database menggunakan dasbor Performance Insights](USER_PerfInsights.AnalyzeLimitlessTables.md)
# Menganalisis beban DB untuk Aurora PostgreSQL Limitless Database menggunakan dasbor Performance Insights
Dengan Performance Insights, Anda dapat melacak metrik di tingkat grup shard dan di tingkat instans untuk Database Tanpa Batas PostgreSQL Aurora. Saat menganalisis beban DB untuk Database Aurora PostgreSQL Limitless, Anda mungkin ingin membandingkan beban DB untuk setiap pecahan dan router dengan vCPU maksimum.
**catatan**
Aurora PostgreSQL Limitless Database selalu mengaktifkan Performance Insights dan Enhanced Monitoring. Periode retensi minimum untuk data Performance Insights untuk Limitless Database adalah 31 hari (1 bulan).
Tampilan **Absolute** menunjukkan jumlah sesi aktif Rata-rata (AAS) dan perkiraan vCPU. Tampilan **Relatif** menunjukkan rasio AAS terhadap perkiraan vCPU.
**Topics**
+ [Menganalisis beban DB relatif untuk Aurora PostgreSQL Limitless Database menggunakan dasbor Performance Insights](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad)
+ [Menganalisis beban DB dengan menunggu Database Aurora SQL Postgre Limitless menggunakan dasbor Performance Insights](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md)
+ [Menganalisis distribusi beban untuk Aurora Postgre SQL Limitless Database menggunakan dasbor Performance Insights](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md)
## Menganalisis beban DB relatif untuk Aurora PostgreSQL Limitless Database menggunakan dasbor Performance Insights
Anda mungkin ingin meningkatkan kinerja Database Aurora PostgreSQL Limitless Anda dengan melacak beban DB relatif. Untuk menganalisis beban DB relatif dengan instance untuk Database Aurora PostgreSQL Limitless Anda, gunakan prosedur berikut.
**Untuk menganalisis beban DB relatif untuk Aurora PostgreSQL Limitless Database menggunakan konsol**
1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih Database Aurora PostgreSQL Limitless. Dasbor Performance Insights ditampilkan untuk Database Aurora PostgreSQL Limitless tersebut.
1. Di bagian **Pemuatan basis data (beban DB)**, pilih **Instans** untuk **Diiris** oleh. ****Untuk melihat rasio rata-rata sesi aktif (AAS) terhadap inti vCPU untuk semua instance di Database Aurora PostgreSQL Limitless Anda, pilih Relatif untuk Dilihat sebagai.****
Bagan sesi aktif rata-rata menunjukkan beban DB untuk instans di Database Aurora PostgreSQL Limitless Anda.
![\[Lihat dasbor Performance Insights untuk Database Aurora PostgreSQL Limitless Anda yang diiris berdasarkan instance.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png)
1. Untuk melihat instance teratas, pilih tab **Instance teratas**.
Dalam contoh berikut, contoh dengan beban DB tertinggi adalah`DTR-2-2`.
![\[Gunakan tab Top instance untuk Database Aurora PostgreSQL Limitless yang diiris oleh instance.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
1. **(Opsional) Untuk menganalisis beban DB untuk sebuah instance di Database Aurora PostgreSQL Limitless Anda, pilih nama instance di kolom Instances.** Untuk melihat beban DB`DTR-2-2`, pilih `DTR-2-2` di kolom **Instances**.
**catatan**
Anda dapat melihat metrik Performance Insights hanya untuk instance di Database Tanpa Batas PostgreSQL Aurora.
# Menganalisis beban DB dengan menunggu Database Aurora SQL Postgre Limitless menggunakan dasbor Performance Insights
Anda mungkin ingin meningkatkan kinerja untuk Basis Data SQL Tanpa Batas Aurora Postgre Anda dengan melacak peristiwa tunggu. Untuk menganalisis beban DB dengan menunggu peristiwa untuk Database Aurora Postgre SQL Limitless Anda, gunakan prosedur berikut.
**Untuk menganalisis beban DB dengan menunggu Aurora SQL Postgre Limitless Database menggunakan konsol**
1. Buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih Database Tanpa Batas Aurora PostgreSQL. Dasbor Performance Insights ditampilkan untuk Database Aurora Postgre Limitless tersebut. SQL
1. Di bagian **beban basis data (beban DB)**, pilih **Waits** for **Sliced by.** Untuk melihat jumlah AAS dan estimasi vCPU, pilih **Absolute** untuk **Dilihat sebagai**.
Bagan sesi aktif rata-rata menunjukkan beban DB untuk instans di Database Tanpa Batas Aurora SQL Postgre Anda.
![\[Diiris dengan menunggu.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png)
1. Gulir ke bawah ke SQL tab **Atas**.
Dalam contoh berikut, SQL pernyataan dengan beban tertinggi dengan menunggu adalah `DELETE` pernyataan.
![\[SQLTab atas saat diiris dengan menunggu.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png)
1. Pilih SQL pernyataan untuk mengembangkannya ke dalam pernyataan komponennya.
Dalam contoh berikut, `SELECT` pernyataan tersebut memiliki 3 pernyataan komponen.
![\[Pilih SQL pernyataan untuk mengembangkannya.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png)
# Menganalisis distribusi beban untuk Aurora Postgre SQL Limitless Database menggunakan dasbor Performance Insights
Anda mungkin ingin menyeimbangkan distribusi beban untuk instance di Database Aurora SQL Postgre Limitless Anda. Untuk menganalisis distribusi beban instans pada Database Aurora SQL Postgre Limitless, gunakan prosedur berikut.
**Untuk menganalisis distribusi beban instance pada Database Aurora SQL Postgre Limitless menggunakan konsol**
1. Buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih Database Tanpa Batas Aurora PostgreSQL. Dasbor Performance Insights ditampilkan untuk Database Aurora Postgre Limitless tersebut. SQL
1. Di bagian **Pemuatan basis data (beban DB)**, pilih **Instance** for **Sliced by.** ****Untuk melihat jumlah AAS dan estimasi v CPU untuk semua instans di Basis Data Tanpa Batas Aurora SQL Postgre Anda, pilih Absolute untuk Dilihat sebagai.****
Bagan sesi aktif rata-rata menunjukkan beban DB untuk instans di Database Tanpa Batas Aurora SQL Postgre Anda.
![\[Lihat dasbor Performance Insights absolut untuk Database Tanpa Batas Aurora Postgre SQL Anda yang diiris berdasarkan instans.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png)
1. **Untuk melihat bagan distribusi beban instans di Database Aurora SQL Postgre Limitless Anda, pilih tab distribusi Muat.**
Dalam contoh berikut, contoh dengan beban DB tertinggi adalah`DTR-2-2`.
![\[SQLTab teratas saat Anda mengiris dengan menunggu di tingkat instance.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png)
# Memantau Basis Data SQL Tanpa Batas Aurora Postgre dengan Perlindungan Amazon GuardDuty RDS
Amazon GuardDuty adalah layanan deteksi ancaman yang membantu melindungi akun, wadah, beban kerja, dan data di AWS lingkungan Anda. Menggunakan model machine learning (ML), serta kemampuan deteksi anomali dan ancaman, GuardDuty terus memantau berbagai sumber log dan aktivitas runtime untuk mengidentifikasi dan memprioritaskan potensi risiko keamanan dan aktivitas berbahaya di lingkungan Anda.
GuardDuty RDSProtection menganalisis dan memprofilkan peristiwa login untuk potensi ancaman akses ke database Amazon Aurora Anda. Saat Anda mengaktifkan RDS Perlindungan, akan GuardDuty menggunakan peristiwa RDS login dari basis data Aurora Anda. RDS Perlindungan memantau peristiwa ini dan memprofilkannya untuk potensi ancaman orang dalam atau aktor eksternal.
Untuk informasi lebih lanjut tentang GuardDuty RDS Perlindungan di Aurora, lihat. [Memantau ancaman dengan Perlindungan Amazon GuardDuty RDS untuk Amazon Aurora](guard-duty-rds-protection.md)
Untuk informasi selengkapnya tentang mengaktifkan GuardDuty RDS Perlindungan, lihat [GuardDuty RDSPerlindungan](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html) di *Panduan GuardDuty Pengguna Amazon*.
# Fungsi dan tampilan untuk Aurora SQL Postgre Limitless Database
Aurora Postgre SQL Limitless Database telah menambahkan fungsi dan tampilan. Mereka didasarkan pada fungsi dan tampilan Aurora Postgre SQL yang sesuai.
**catatan**
Beberapa statistik dapat mengembalikan hasil yang tidak konsisten jika ada transaksi yang sedang berlangsung.
**Topics**
+ [Fungsi Basis Data Tanpa Batas Aurora Postgre SQL](limitless-monitoring-functions.md)
+ [Tampilan Database Tanpa Batas Aurora PostgreSQL](limitless-monitoring-views.md)
# Fungsi Basis Data Tanpa Batas Aurora Postgre SQL
Tabel berikut menunjukkan fungsi baru untuk Aurora SQL Postgre Limitless Database.
**catatan**
Fungsi yang tercantum dalam tabel ini terletak di `rds_aurora` skema. Saat menggunakan fungsi Limitless Database, pastikan untuk menyertakan nama objek yang sepenuhnya memenuhi syarat:`rds_aurora`. `object_name`.
| Fungsi Basis Data Tanpa Batas Aurora Postgre SQL | Fungsi Aurora Postgre yang sesuai SQL |
| --- | --- |
| [limitless\$1backend\$1dsid](#limitless_backend_dsid) | pg\$1backend\$1pid |
| [limitless\$1cancel\$1session](#limitless_cancel_session) | pg\$1cancel\$1backend |
| [limitless\$1stat\$1clear\$1snapshot](#limitless_stat_clear_snapshot) | pg\$1stat\$1clear\$1snapshot |
| [limitless\$1stat\$1database\$1size](#limitless_stat_database_size) | pg\$1database\$1size |
| [limitless\$1stat\$1get\$1snapshot\$1timestamp](#limitless_stat_get_snapshot_timestamp) | pg\$1stat\$1get\$1snapshot\$1timestamp |
| [limitless\$1stat\$1prepared\$1xacts](#limitless_stat_prepared_xacts) | pg\$1prepared\$1xacts |
| [limitless\$1stat\$1relation\$1sizes](#limitless_stat_relation_sizes) | pg\$1indexes\$1size, pg\$1relation\$1size, pg\$1table\$1size, pg\$1total\$1relation\$1size |
| [limitless\$1stat\$1reset](#limitless_stat_reset) | pg\$1stat\$1reset |
| [limitless\$1stat\$1statements\$1reset](#limitless_stat_statements_reset) | pg\$1stat\$1statements\$1reset |
| [limitless\$1stat\$1system\$1waits](#limitless_stat_system_waits) | aurora\$1stat\$1system\$1waits |
| [limitless\$1terminate\$1session](#limitless_terminate_session) | pg\$1terminate\$1backend |
| [limitless\$1wait\$1report](#limitless_wait_report) | aurora\$1wait\$1report |
Contoh berikut memberikan rincian tentang fungsi Basis Data Tanpa Batas Aurora PostgreSQL. Untuk informasi selengkapnya tentang SQL fungsi Postgre, lihat [Fungsi dan operator dalam dokumentasi](https://www.postgresql.org/docs/15/functions.html) SQL Postgre.
**limitless\$1backend\$1dsid**
`limitless_backend_dsid`Fungsi mengembalikan ID sesi terdistribusi untuk sesi saat ini. Sesi terdistribusi berjalan pada router dalam grup pecahan DB dan melibatkan proses backend pada satu atau lebih pecahan dalam grup pecahan DB.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_backend_dsid` fungsi.
```
SELECT rds_aurora.limitless_backend_dsid();
limitless_backend_dsid
------------------------
8CACD7B04D0FC2A5
(1 row)
```
**limitless\$1cancel\$1session**
`limitless_cancel_session`Fungsi ini bekerja mirip dengan`pg_cancel_backend`, tetapi mencoba untuk membatalkan semua proses backend yang terkait dengan ID sesi terdistribusi yang disediakan dengan mengirimkan `SIGINT` (sinyal interupsi).
Parameter input adalah sebagai berikut:
+ `distributed_session_id`(teks) — ID sesi terdistribusi yang akan dibatalkan.
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `pid`(teks) — ID proses backend.
+ `success`(boolean) — Apakah pembatalan berhasil.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_cancel_session` fungsi.
```
SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1stat\$1clear\$1snapshot**
`limitless_stat_clear_snapshot`Fungsi membuang snapshot statistik saat ini atau informasi cache pada semua node.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_clear_snapshot` fungsi.
```
SELECT rds_aurora.limitless_stat_clear_snapshot();
```
**limitless\$1stat\$1database\$1size**
`limitless_stat_database_size`Fungsi mengembalikan ukuran database dalam kelompok shard DB.
Parameter input adalah sebagai berikut:
+ `dbname`(nama) — Database untuk mendapatkan ukuran.
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster yang menjadi milik proses ini: `router` atau`shard`.
+ `db_size`— Ukuran database dalam subcluster ini dalam byte.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_database_size` fungsi.
```
SELECT * FROM rds_aurora.limitless_stat_database_size('postgres_limitless');
subcluster_id | subcluster_type | db_size
---------------+-----------------+----------
1 | router | 8895919
2 | router | 8904111
3 | shard | 21929391
4 | shard | 21913007
5 | shard | 21831087
(5 rows)
```
**limitless\$1stat\$1get\$1snapshot\$1timestamp**
`limitless_stat_get_snapshot_timestamp`Fungsi mengembalikan stempel waktu snapshot statistik saat ini, atau `NULL` jika tidak ada snapshot statistik yang diambil. Sebuah snapshot diambil saat pertama kali statistik kumulatif diakses dalam transaksi jika `stats_fetch_consistency` diatur ke. `snapshot` Mengembalikan tampilan konsolidasi stempel waktu snapshot dari semua node. `subcluster_type`Kolom `subcluster_id` dan menunjukkan node mana datanya berasal.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_get_snapshot_timestamp` fungsi.
```
SELECT * FROM rds_aurora.limitless_stat_get_snapshot_timestamp();
subcluster_id | subcluster_type | snapshot_timestamp
---------------+-----------------+--------------------
1 | router |
2 | router |
3 | shard |
4 | shard |
5 | shard |
(5 rows)
```
**limitless\$1stat\$1prepared\$1xacts**
`limitless_stat_prepared_xacts`Fungsi mengembalikan informasi tentang transaksi pada semua node yang saat ini disiapkan untuk komit dua fase. Untuk informasi selengkapnya, lihat [pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html) di dokumentasi Postgre. SQL
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_prepared_xacts` fungsi.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_prepared_xacts;
subcluster_id | subcluster_type | transaction_id | gid | prepared | owner_id | database_id
---------------+-----------------+----------------+------------------------------+-------------------------------+------------+--------------------
8 | shard | 5815978 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659603+00 | auroraperf | postgres_limitless
12 | shard | 4599138 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659637+00 | auroraperf | postgres_limitless
(2 rows)
```
**limitless\$1stat\$1relation\$1sizes**
`limitless_stat_relation_sizes`Fungsi mengembalikan ukuran yang berbeda dari tabel dalam kelompok shard DB.
Parameter input adalah sebagai berikut:
+ `relnspname`(nama) — Nama skema yang berisi tabel.
+ `relname`(nama) — Nama tabel.
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster yang menjadi milik proses ini: `router` atau`shard`.
+ `main_size`— Ukuran dalam byte dari garpu data utama di node ini.
+ `fsm_size`— Ukuran dalam byte peta ruang kosong untuk tabel di simpul ini.
+ `vm_size`— Ukuran dalam byte peta visibilitas untuk tabel di node ini.
+ `init_size`— Ukuran dalam byte inisialisasi tabel di node ini.
+ `toast_size`— Ukuran dalam byte dari meja roti panggang yang terkait dengan tabel di garpu ini.
+ `index_size`— Ukuran dalam byte dari semua indeks untuk tabel di node ini.
+ `total_size`— Ukuran dalam byte dari semua segmen tabel di node ini.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_relation_sizes` fungsi (beberapa kolom dihilangkan).
```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customers');
subcluster_id | subcluster_type | main_size | fsm_size | vm_size | toast_size | table_size | total_size
---------------+-----------------+-----------+----------+---------+------------+------------+------------
1 | router | 0 | 0 | 0 | 0 | 0 | 0
2 | router | 0 | 0 | 0 | 0 | 0 | 0
3 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
4 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
5 | shard | 3981312 | 4227072 | 1409024 | 1409024 | 11026432 | 11026432
(5 rows)
```
**limitless\$1stat\$1reset**
`limitless_stat_reset`Fungsi me-reset semua penghitung statistik untuk database saat ini ke nol (0). Jika `track_functions` diaktifkan, `stats_reset` kolom di `limitless_stat_database` menunjukkan statistik terakhir kali disetel ulang untuk database. Secara default, hanya `limitless_stat_reset` dapat dijalankan oleh superuser. Pengguna lain dapat diberikan izin dengan menggunakan hak `EXECUTE` istimewa.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_reset` fungsi.
```
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
--------------+-------------
896 | 0
(1 row)
SELECT rds_aurora.limitless_stat_reset();
limitless_stat_reset
---------------------
(1 row)
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
-------------+-------------
0 | 0
(1 row)
```
**limitless\$1stat\$1statements\$1reset**
`limitless_stat_statements_reset`Fungsi membuang statistik yang dikumpulkan sejauh ini dengan `limitless_stat_statements` sesuai dengan yang ditentukan`username`,, `dbname``distributed_query_id`, dan `queryid` parameter. Jika salah satu parameter tidak ditentukan, nilai default `""` atau `0` (tidak valid) digunakan untuk masing-masing parameter tersebut, dan statistik yang cocok dengan parameter lain akan disetel ulang. Jika tidak ada parameter yang ditentukan, atau semua parameter yang ditentukan adalah `""` atau `0` (tidak valid), fungsi membuang semua statistik. Jika semua statistik dalam `limitless_stat_statements` tampilan dibuang, fungsi juga mengatur ulang statistik dalam tampilan. `limitless_stat_statements_info`
Parameter input adalah sebagai berikut:
+ `username`(nama) — Pengguna yang menanyakan pernyataan tersebut.
+ `dbname`(nama) — Database tempat kueri dijalankan.
+ `distributed_query_id`(bigint) — ID kueri dari kueri induk dari node koordinator. Kolom ini adalah `NULL` jika itu adalah kueri induk. Node koordinator menekan ID kueri terdistribusi ke node peserta. Jadi untuk node peserta, nilai untuk ID kueri terdistribusi dan ID kueri berbeda.
+ `queryid`(bigint) — ID kueri pernyataan.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_statements_reset` fungsi untuk mengatur ulang semua statistik yang dikumpulkan oleh`limitless_stat_statements`.
```
SELECT rds_aurora.limitless_stat_statements_reset();
```
**limitless\$1stat\$1system\$1waits**
`limitless_stat_system_waits`Fungsi mengembalikan tampilan konsolidasi dari data peristiwa tunggu dari`aurora_stat_system_waits`, yang melaporkan aktivitas menunggu luas sistem dalam sebuah instance, dari semua node. `subcluster_type`Kolom `subcluster_id` dan menunjukkan node mana datanya berasal.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_stat_system_waits` fungsi.
```
postgres_limitless=> SELECT *
FROM rds_aurora.limitless_stat_system_waits() lssw, pg_catalog.aurora_stat_wait_event() aswe
WHERE lssw.event_id=aswe.event_id and aswe.event_name='LimitlessTaskScheduler';
subcluster_id | subcluster_type | type_id | event_id | waits | wait_time | event_name
---------------+-----------------+---------+-----------+--------+--------------+------------------------
1 | router | 12 | 201326607 | 677068 | 616942216307 | LimitlessTaskScheduler
2 | router | 12 | 201326607 | 678586 | 616939897111 | LimitlessTaskScheduler
3 | shard | 12 | 201326607 | 756640 | 616965545172 | LimitlessTaskScheduler
4 | shard | 12 | 201326607 | 755184 | 616958057620 | LimitlessTaskScheduler
5 | shard | 12 | 201326607 | 757522 | 616963183539 | LimitlessTaskScheduler
(5 rows)
```
**limitless\$1terminate\$1session**
`limitless_terminate_session`Fungsi ini bekerja mirip dengan`pg_terminate_backend`, tetapi mencoba untuk mengakhiri semua proses backend yang terkait dengan ID sesi terdistribusi yang disediakan dengan mengirimkan `SIGTERM` (sinyal akhir).
Parameter input adalah sebagai berikut:
+ `distributed_session_id`(teks) — ID sesi terdistribusi yang akan diakhiri.
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `pid`(teks) — ID proses backend.
+ `success`(boolean) - Apakah proses berhasil berakhir.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_terminate_session` fungsi.
```
SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1wait\$1report**
`limitless_wait_report`Fungsi mengembalikan aktivitas acara tunggu selama periode waktu dari semua node. `subcluster_type`Kolom `subcluster_id` dan menunjukkan node mana datanya berasal.
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster yang menjadi milik proses ini: `router` atau`shard`.
Sisa kolom sama seperti di`aurora_wait_report`.
Contoh berikut menunjukkan bagaimana menggunakan `limitless_wait_report` fungsi.
```
postgres_limitless=> select * from rds_aurora.limitless_wait_report();
subcluster_id | subcluster_type | type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
---------------+-----------------+-----------+------------+-------+-----------+-------------+--------------- +-------------
1 | router | Client | ClientRead | 57 | 741550.14 | 13009.652 | 0.19 | 2505.237
5 | shard | Client | ClientRead | 54 | 738897.68 | 13683.290 | 0.18 | 2496.276
4 | shard | Client | ClientRead | 54 | 738859.53 | 13682.584 | 0.18 | 2496.147
2 | router | Client | ClientRead | 53 | 719223.64 | 13570.257 | 0.18 | 2429.810
3 | shard | Client | ClientRead | 54 | 461720.40 | 8550.378 | 0.18 | 1559.86
```
# Tampilan Database Tanpa Batas Aurora PostgreSQL
Tabel berikut menunjukkan tampilan baru untuk Aurora PostgreSQL Limitless Database.
**catatan**
Tampilan yang tercantum dalam tabel ini terletak di `rds_aurora` skema. Saat menggunakan tampilan Limitless Database, pastikan untuk menyertakan nama objek yang sepenuhnya memenuhi syarat:`rds_aurora`. `object_name`.
| Tampilan Database Tanpa Batas Aurora PostgreSQL | Tampilan PostgreSQL Aurora yang sesuai |
| --- | --- |
| [limitless\$1database](#limitless_database) | pg\$1database |
| [limitless\$1locks](#limitless_locks) | pg\$1locks |
| [limitless\$1stat\$1activity](#limitless_stat_activity) | pg\$1stat\$1activity |
| [limitless\$1stat\$1all\$1indexes](#limitless_stat_all_indexes) | pg\$1stat\$1all\$1indexes |
| [limitless\$1stat\$1all\$1tables](#limitless_stat_all_tables) | pg\$1stat\$1all\$1tables |
| [limitless\$1stat\$1database](#limitless_stat_database) | pg\$1stat\$1database |
| [limitless\$1stat\$1progress\$1vacuum](#limitless_stat_progress_vacuum) | pg\$1stat\$1progress\$1vacuum |
| [limitless\$1stat\$1statement](#limitless_stat_statements) | pg\$1stat\$1statements |
| [limitless\$1stat\$1subcluster](#limitless_stat_subclusters) | Tidak ada |
| [limitless\$1stat\$1statements\$1info](#limitless_stat_statements_info) | pg\$1stat\$1statements\$1info |
| [limitless\$1statio\$1all\$1indexes](#limitless_statio_all_indexes) | pg\$1statio\$1all\$1indexes |
| [limitless\$1statio\$1all\$1tables](#limitless_statio_all_tables) | pg\$1statio\$1all\$1tables |
| [limitless\$1tables](#limitless_tables) | pg\$1tables |
| [limitless\$1table\$1collocations](#limitless_table_collocations) | Tidak ada |
| [limitless\$1table\$1collocation\$1distributions](#limitless_table_collocation_distributions) | Tidak ada |
Contoh berikut memberikan rincian tentang tampilan Aurora PostgreSQL Limitless Database. Untuk informasi selengkapnya tentang tampilan PostgreSQL, [lihat Melihat statistik](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS) dalam dokumentasi PostgreSQL.
**catatan**
Beberapa tampilan statistik dapat mengembalikan hasil yang tidak konsisten jika Anda memiliki transaksi yang sedang berlangsung.
**limitless\$1database**
Tampilan ini berisi informasi tentang database yang tersedia di grup shard DB. Misalnya:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, oid, datname, datacl FROM rds_aurora.limitless_database;
subcluster_id | subcluster_type | oid | datname | datacl
---------------+-----------------+-------+--------------------+------------------------------------------------------------------------------------------------------------------------
2 | router | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
2 | router | 5 | postgres |
2 | router | 16384 | rdsadmin | {rdsadmin=CTc/rdsadmin,rds_aurora_limitless_metadata_admin=c/rdsadmin,rds_aurora_limitless_heat_mgmt_admin=c/rdsadmin}
2 | router | 16477 | postgres_limitless |
2 | router | 1 | template1 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
6 | shard | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
```
Parameter output adalah sebagai berikut:
+ `subcluster_id`(text) — ID dari subcluster (node)
+ `subcluster_type`(teks) — Jenis subcluster (node), router atau shard
Sisa kolom sama seperti di`pg_database`.
**limitless\$1locks**
Tampilan ini berisi satu baris per proses per node. Ini menyediakan akses ke informasi tentang kunci yang dipegang oleh proses aktif di server database.
**Example membuat kunci dengan dua transaksi**
Dalam contoh ini, kami menjalankan dua transaksi secara bersamaan pada dua router.
```
# Transaction 1 (run on router 1)
BEGIN;
SET search_path = public;
SELECT * FROM customers;
INSERT INTO customers VALUES (400,'foo','bar');
# Transaction 2 (run on router 2)
BEGIN;
SET search_path = public;
ALTER TABLE customers ADD COLUMN phone VARCHAR;
```
Transaksi pertama dijalankan. Transaksi selanjutnya harus menunggu hingga transaksi pertama selesai. Oleh karena itu transaksi kedua diblokir dengan kunci. Untuk memeriksa akar penyebabnya, kami menjalankan perintah dengan bergabung `limitless_locks` dengan`limitless_stat_activity`.
```
# Run on router 2
SELECT distributed_session_id, state, usename, query, query_start
FROM rds_aurora.limitless_stat_activity
WHERE distributed_session_id in (
SELECT distributed_session_id
FROM rds_aurora.limitless_locks
WHERE relname = 'customers'
);
distributed_session_id | state | usename | query | query_start
------------------------+---------------------+--------------------------+---------------------------------- -------------+-------------------------------
47BDE66E9A5E8477 | idle in transaction | limitless_metadata_admin | INSERT INTO customers VALUES (400,'foo','bar'); | 2023-04-13 17:44:45.152244+00
2AD7F370202D0FA9 | active | limitless_metadata_admin | ALTER TABLE customers ADD COLUMN phone VARCHAR; | 2023-04-13 17:44:55.113388+00
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
(6 rows)
```
**Example membuat kunci secara eksplisit**
Dalam contoh ini, kita membuat kunci secara eksplisit, kemudian menggunakan `limitless_locks` tampilan untuk melihat kunci (beberapa kolom dihilangkan).
```
BEGIN;
SET search_path = public;
LOCK TABLE customers IN ACCESS SHARE MODE;
SELECT * FROM rds_aurora.limitless_locks WHERE relname = 'customers';
subcluster_id | subcluster_type | distributed_session_id | locktype | datname | relnspname | relname | virtualtransaction | pid | mode
---------------+-----------------+------------------------+----------+--------------------+------------+ ----------+--------------------+-------+-----------------
1 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600787 | 59564 | AccessShareLock
2 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600405 | 67130 | AccessShareLock
3 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 15/473401 | 27735 | AccessShareLock
4 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473524 | 27734 | AccessShareLock
5 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/472935 | 27737 | AccessShareLock
6 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473015 | 48660 | AccessShareLock
(6 rows)
```
**limitless\$1stat\$1activity**
Tampilan ini berisi satu baris per proses per node. Ini dapat digunakan untuk melacak kesehatan sistem secara keseluruhan dan proses triase yang memakan waktu lama. Misalnya:
```
postgres=# SELECT
subcluster_id,
subcluster_type,
distributed_session_id,
distributed_session_state,
datname,
distributed_query_id,
is_sso_query
FROM
rds_aurora.limitless_stat_activity
WHERE
distributed_session_id in ('D2470C97E3D07E06', '5A3CD7B8E5FD13FF')
order by distributed_session_id;
subcluster_id | subcluster_type | distributed_session_id | distributed_session_state | datname | distributed_query_id | is_sso_query
---------------+-----------------+------------------------+---------------------------+--------------------+----------------------+--------------
2 | router | 5A3CD7B8E5FD13FF | coordinator | postgres_limitless | | f
3 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
4 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
2 | router | D2470C97E3D07E06 | coordinator | postgres_limitless | | t
3 | shard | D2470C97E3D07E06 | participant | postgres_limitless | 4058400544464210222 |
(5 rows)
```
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster tempat proses ini berada: `router` atau`shard`.
+ `distributed_session_id`(teks) — ID sesi terdistribusi tempat proses ini berada.
+ `distributed_session_state`(teks) — Apakah ini koordinator, peserta, atau standalone/nondistributed proses (ditampilkan sebagai`NULL`).
+ `datname`(teks) — Database yang terhubung dengan proses ini.
+ `distributed_query_id`(bigint) — ID kueri dari kueri induk dari node koordinator. Kolom ini adalah `NULL` jika itu adalah kueri induk. Node koordinator menekan ID kueri terdistribusi ke node peserta. Jadi untuk node peserta, nilai untuk ID kueri terdistribusi dan ID kueri berbeda.
+ `is_sso_query`(teks) - Ini memungkinkan kita tahu apakah kueri adalah pecahan tunggal yang dioptimalkan atau tidak.
Sisa kolom sama seperti di`pg_stat_activity`.
**limitless\$1stat\$1all\$1indexes**
Tampilan ini berisi statistik penggunaan pada indeks dalam grup pecahan DB. Misalnya:
```
postgres_limitless=> SELECT schemaname, relname, indexrelname, idx_scan
FROM rds_aurora.limitless_stat_all_indexes
WHERE relname LIKE 'orders_ts%' ORDER BY indexrelname LIMIT 10;
schemaname | relname | indexrelname | idx_scan
------------+----------------+---------------------+----------
ec_sample | orders_ts00001 | orders_ts00001_pkey | 196801
ec_sample | orders_ts00002 | orders_ts00002_pkey | 196703
ec_sample | orders_ts00003 | orders_ts00003_pkey | 196376
ec_sample | orders_ts00004 | orders_ts00004_pkey | 197966
ec_sample | orders_ts00005 | orders_ts00005_pkey | 195301
ec_sample | orders_ts00006 | orders_ts00006_pkey | 195673
ec_sample | orders_ts00007 | orders_ts00007_pkey | 194475
ec_sample | orders_ts00008 | orders_ts00008_pkey | 191694
ec_sample | orders_ts00009 | orders_ts00009_pkey | 193744
ec_sample | orders_ts00010 | orders_ts00010_pkey | 195421
(10 rows)
```
**limitless\$1stat\$1all\$1tables**
Tampilan ini berisi statistik tentang semua tabel dalam database saat ini di grup shard DB. Ini berguna saat melacak operasi vakum dan operasi bahasa Manipulasi Data (DML/Data Manipulation Language). Misalnya:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, relname, n_ins_since_vacuum, n_tup_ins, last_vacuum
FROM rds_aurora.limitless_stat_all_tables
WHERE relname LIKE 'orders_ts%' ORDER BY relname LIMIT 10;
subcluster_id | subcluster_type | relname | n_ins_since_vacuum | n_tup_ins | last_vacuum
---------------+-----------------+----------------+--------------------+-----------+-------------
5 | shard | orders_ts00001 | 34779 | 196083 |
5 | shard | orders_ts00002 | 34632 | 194721 |
5 | shard | orders_ts00003 | 34950 | 195965 |
5 | shard | orders_ts00004 | 34745 | 197283 |
5 | shard | orders_ts00005 | 34879 | 195754 |
5 | shard | orders_ts00006 | 34340 | 194605 |
5 | shard | orders_ts00007 | 33779 | 192203 |
5 | shard | orders_ts00008 | 33826 | 191293 |
5 | shard | orders_ts00009 | 34660 | 194117 |
5 | shard | orders_ts00010 | 34569 | 195560 |
(10 rows)
```
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster tempat proses ini berada: `router` atau`shard`.
+ `relname`(nama) — Nama tabel.
Sisa kolom sama seperti di`pg_stat_all_tables`.
**limitless\$1stat\$1database**
Tampilan ini berisi statistik tentang semua database dalam grup shard DB. Mengembalikan satu baris per database per node. Misalnya:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
datname,
blks_read,
blks_hit
FROM
rds_aurora.limitless_stat_database
WHERE
datname='postgres_limitless';
subcluster_id | subcluster_type | datname | blks_read | blks_hit
---------------+-----------------+--------------------+-----------+----------
1 | router | postgres_limitless | 484 | 34371314
2 | router | postgres_limitless | 673 | 33859317
3 | shard | postgres_limitless | 1299 | 17749550
4 | shard | postgres_limitless | 1094 | 17492849
5 | shard | postgres_limitless | 1036 | 17485098
6 | shard | postgres_limitless | 1040 | 17437257
(6 rows)
```
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster tempat proses ini berada: `router` atau`shard`.
+ `datname`(nama) — Nama database.
Sisa kolom sama seperti di`pg_stat_database`.
**limitless\$1stat\$1progress\$1vacuum**
Tampilan ini berisi informasi tentang operasi penyedot debu yang sedang berlangsung. Misalnya:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
-[ RECORD 1 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | A56D96E2A5C9F426
pid | 5270
datname | postgres
nspname | public
relname | customer_ts2
phase | vacuuming heap
heap_blks_total | 130500
heap_blks_scanned | 100036
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 11184810
num_dead_tuples | 0
-[ RECORD 2 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | 56DF26A89EC23AB5
pid | 6854
datname | postgres
nspname | public
relname | sales_ts1
phase | vacuuming heap
heap_blks_total | 43058
heap_blks_scanned | 24868
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 8569523
num_dead_tuples | 0
```
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster tempat proses ini berada: `router` atau`shard`.
+ `distributed_session_id`(teks) — Pengidentifikasi untuk sesi yang memulai operasi penyedot debu.
+ `datname`(nama) — Database tempat penyedot debu sedang dilakukan.
+ `nspname`(nama) — Nama skema tabel yang sedang disedot. Itu `null` jika tabel yang disedot tidak dalam database yang sama dengan yang terhubung dengan pengguna.
+ `relname`(nama) — Nama tabel yang sedang disedot. Itu `null` jika tabel yang disedot tidak dalam database yang sama dengan yang terhubung dengan pengguna.
Sisa kolom sama seperti di`pg_stat_progress_vacuum`.
**limitless\$1stat\$1statement**
Tampilan ini menyediakan sarana untuk melacak perencanaan dan menjalankan statistik dari semua pernyataan SQL yang dijalankan di semua node.
Anda harus menginstal ekstensi [pg\$1stat\$1statement](https://www.postgresql.org/docs/current/pgstatstatements.html) untuk menggunakan tampilan. `limitless_stat_statements`
```
-- CREATE EXTENSION must be run by a superuser
CREATE EXTENSION pg_stat_statements;
-- Verify that the extension is created on all nodes in the DB shard group
SELECT distinct node_id
FROM rds_aurora.limitless_stat_statements
LIMIT 10;
```
Contoh berikut menunjukkan penggunaan `limitless_stat_statements` tampilan.
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
distributedqueryid,
username,
dbname,
sso_calls
FROM
rds_aurora.limitless_stat_statements;
subcluster_id | subcluster_type | distributedqueryid | username | dbname | sso_calls
---------------+-----------------+----------------------+-------------------------------------+--------------------+-----------
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 1
3 | shard | -7975178695405682176 | postgres | postgres_limitless |
[...]
```
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
+ `subcluster_type`(teks) — Jenis subcluster yang menjadi milik proses ini: `router` untuk atau`shard`.
+ `distributedqueryid`(bigint) — ID kueri dari kueri induk dari node koordinator. Kolom ini adalah `NULL` jika itu adalah kueri induk. Node koordinator menekan ID kueri terdistribusi ke node peserta. Jadi untuk node peserta, nilai untuk ID kueri terdistribusi dan ID kueri berbeda.
+ `username`(nama) — Pengguna yang menanyakan pernyataan tersebut.
+ `dbname`(nama) — Database tempat kueri dijalankan.
+ `sso_calls`(nama) — Berapa kali pernyataan dioptimalkan dengan pecahan tunggal.
Sisa kolom sama seperti di [pg\$1stat\$1statement](https://www.postgresql.org/docs/current/pgstatstatements.html).
**limitless\$1stat\$1statements\$1info**
Tampilan ini berisi statistik untuk `limitless_stat_statements` tampilan. Setiap baris berisi data untuk tampilan [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) dari setiap node. `subcluster_id`Kolom mengidentifikasi setiap node.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_statements_info;
subcluster_id | subcluster_type | dealloc | stats_reset
---------------+-----------------+---------+-------------------------------
1 | router | 0 | 2023-06-30 21:22:09.524781+00
2 | router | 0 | 2023-06-30 21:21:40.834111+00
3 | shard | 0 | 2023-06-30 21:22:10.709942+00
4 | shard | 0 | 2023-06-30 21:22:10.740179+00
5 | shard | 0 | 2023-06-30 21:22:10.774282+00
6 | shard | 0 | 2023-06-30 21:22:10.808267+00
(6 rows)
```
Parameter output adalah sebagai berikut:
+ `subcluster_id`(teks) — ID subcluster tempat proses ini berada.
Sisa kolom sama seperti di [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7).
**limitless\$1stat\$1subcluster**
Tampilan ini berisi statistik jaringan antara router dan node lainnya. Ini berisi baris per pasang router dan node lainnya, misalnya:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_subclusters;
orig_subcluster | orig_instance_az | dest_subcluster | dest_instance_az | latency_us | latest_collection | failed_requests | received_bytes | sent_bytes | same_az_requests | cross_az_requests | stat_reset_timestamp
-----------------+------------------+-----------------+------------------+------------+-------------------------------+-----------------+----------------+------------+------------------+-------------------+-------------------------------
3 | us-west-2b | 2 | us-west-2a | 847 | 2024-10-07 17:25:39.518617+00 | 0 | 35668633 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.239675+00
3 | us-west-2b | 4 | us-west-2b | 419 | 2024-10-07 17:25:39.546376+00 | 0 | 101190464 | 248795719 | 883478 | 0 | 2024-10-05 12:39:55.231218+00
3 | us-west-2b | 5 | us-west-2c | 1396 | 2024-10-07 17:25:39.52122+00 | 0 | 72864849 | 172086292 | 0 | 557726 | 2024-10-05 12:39:55.196412+00
3 | us-west-2b | 6 | us-west-2c | 729 | 2024-10-07 17:25:39.54828+00 | 0 | 35668584 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.247334+00
3 | us-west-2b | 7 | us-west-2a | 1702 | 2024-10-07 17:25:39.545307+00 | 0 | 71699576 | 171634844 | 0 | 556278 | 2024-10-05 12:39:52.715168+00
2 | us-west-2a | 3 | us-west-2b | 868 | 2024-10-07 17:25:40.293927+00 | 0 | 35659611 | 92011872 | 0 | 302817 | 2024-10-05 12:39:54.420758+00
2 | us-west-2a | 4 | us-west-2b | 786 | 2024-10-07 17:25:40.296863+00 | 0 | 102437253 | 251838024 | 0 | 895060 | 2024-10-05 12:39:54.404081+00
2 | us-west-2a | 5 | us-west-2c | 1232 | 2024-10-07 17:25:40.292021+00 | 0 | 71990027 | 168828110 | 0 | 545453 | 2024-10-05 12:39:36.769549+00
```
Parameter output adalah sebagai berikut:
+ `orig_subcluster`(teks) — ID router tempat komunikasi berasal
+ `orig_subcluster_az`(teks) — Availability Zone (AZ) dari router pencetus
+ `dest_subcluster`(teks) — ID dari simpul tujuan
+ `dest_subcluster_az`(teks) — AZ terakhir yang dikumpulkan dari simpul tujuan
+ `latency_us`(bigint) — Latensi jaringan terakhir yang dikumpulkan antar node, dalam mikrodetik. Nilainya adalah `0` jika node tidak dapat dijangkau.
+ `latest_collection`(stempel waktu) - Stempel waktu koleksi terbaru AZ dan latensi untuk node tujuan
+ `failed_requests`(bigint) — Jumlah kumulatif permintaan internal yang gagal
+ `received_bytes`(bigint) — Perkiraan jumlah kumulatif byte yang diterima dari node ini
+ `sent_bytes`(bigint) — Perkiraan jumlah kumulatif byte yang dikirim ke node ini
+ `same_az_requests`(bigint) — Jumlah kumulatif permintaan DB internal ke node ini ketika berada di AZ yang sama dengan router pencetus
+ `cross_az_requests`(bigint) — Jumlah kumulatif permintaan DB internal ke node ini saat berada di AZ yang berbeda dari router pencetus
+ `stat_reset_timestamp`(stempel waktu) — Stempel waktu saat statistik kumulatif untuk tampilan ini terakhir disetel ulang
**limitless\$1statio\$1all\$1indexes**
Tampilan ini berisi statistik input/output (I/O) untuk semua indeks dalam grup pecahan DB. Misalnya:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_statio_all_indexes WHERE relname like'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit
---------------+-----------------+------------+-------------------+-------------------------------------+ --------------+--------------
3 | shard | public | customers_ts00002 | customers_ts00002_customer_name_idx | 1 | 0
3 | shard | public | customers_ts00001 | customers_ts00001_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00003 | customers_ts00003_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00004 | customers_ts00004_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00005 | customers_ts00005_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00006 | customers_ts00006_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00007 | customers_ts00007_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00008 | customers_ts00008_customer_name_idx | 1 | 0
(8 rows)
```
**limitless\$1statio\$1all\$1tables**
Tampilan ini berisi statistik input/output (I/O) untuk semua tabel dalam grup pecahan DB. Misalnya:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
schemaname,
relname,
heap_blks_read,
heap_blks_hit
FROM
rds_aurora.limitless_statio_all_tables
WHERE
relname LIKE 'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | heap_blks_read | heap_blks_hit
---------------+-----------------+------------+-------------------+----------------+---------------
3 | shard | public | customers_ts00002 | 305 | 57780
3 | shard | public | customers_ts00001 | 300 | 56972
4 | shard | public | customers_ts00004 | 302 | 57291
4 | shard | public | customers_ts00003 | 302 | 57178
5 | shard | public | customers_ts00006 | 300 | 56932
5 | shard | public | customers_ts00005 | 302 | 57386
6 | shard | public | customers_ts00008 | 300 | 56881
6 | shard | public | customers_ts00007 | 304 | 57635
(8 rows)
```
**limitless\$1tables**
Tampilan ini berisi informasi tentang tabel di Aurora PostgreSQL Limitless Database.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables;
table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key
-----------+-----------+-------------+-------------+--------------+-------------+------------------
5 | 18635 | public | placeholder | active | placeholder |
6 | 18641 | public | ref | active | reference |
7 | 18797 | public | orders | active | sharded | HASH (order_id)
2 | 18579 | public | customer | active | sharded | HASH (cust_id)
(4 rows)
```
**limitless\$1table\$1collocations**
Tampilan ini berisi informasi tentang tabel sharded collocated.
Dalam contoh berikut, `customers` tabel `orders` dan ditempatkan, dan `followers` tabel `users` dan ditempatkan. Tabel collocated memiliki hal yang sama`collocation_id`.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocations ORDER BY collocation_id;
collocation_id | schema_name | table_name
----------------+-------------+------------
2 | public | orders
2 | public | customers
5 | public | users
5 | public | followers
(4 rows)
```
**limitless\$1table\$1collocation\$1distributions**
Tampilan ini menunjukkan distribusi kunci untuk setiap kolokasi.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocation_distributions ORDER BY collocation_id, lower_bound;
collocation_id | subcluster_id | lower_bound | upper_bound
----------------+---------------+----------------------+----------------------
2 | 6 | -9223372036854775808 | -4611686018427387904
2 | 5 | -4611686018427387904 | 0
2 | 4 | 0 | 4611686018427387904
2 | 3 | 4611686018427387904 | 9223372036854775807
5 | 6 | -9223372036854775808 | -4611686018427387904
5 | 5 | -4611686018427387904 | 0
5 | 4 | 0 | 4611686018427387904
5 | 3 | 4611686018427387904 | 9223372036854775807
(8 rows)
```
# Tunggu acara untuk Aurora SQL Postgre Limitless Database
Acara tunggu di Aurora Postgre SQL menunjukkan sumber daya yang sedang menunggu sesi, sepertiinput/output (I/O) dan kunci. Acara tunggu sangat membantu dalam mencari tahu mengapa sesi menunggu sumber daya, dan mengidentifikasi kemacetan. Untuk informasi selengkapnya, lihat [Peristiwa tunggu Aurora PostgreSQL](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.waits).
Aurora Postgre SQL Limitless Database memiliki acara tunggu sendiri yang terkait dengan router dan pecahan. Banyak dari mereka adalah untuk router yang menunggu pecahan untuk menyelesaikan tugas. Acara tunggu pecahan berisi detail tentang tugas yang sedang dilakukan.
**Topics**
+ [Meminta acara tunggu](#limitless-monitoring-waits.query)
+ [Acara tunggu Database Tanpa Batas](limitless-waits-reference.md)
## Meminta acara tunggu
Anda dapat menggunakan tampilan [limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) untuk menanyakan peristiwa tunggu, seperti yang ditunjukkan pada contoh berikut.
```
SELECT wait_event FROM rds_aurora.limitless_stat_activity WHERE wait_event_type='AuroraLimitless';
wait_event
----------------------
RemoteStatementSetup
RemoteStatementSetup
(2 rows)
```
Anda juga dapat menggunakan `aurora_stat_system_waits` fungsi ini untuk mencantumkan jumlah menunggu dan total waktu yang dihabiskan untuk setiap acara tunggu, seperti yang ditunjukkan pada contoh berikut.
```
postgres_limitless=> SELECT type_name,event_name,waits,wait_time
FROM aurora_stat_system_waits()
NATURAL JOIN aurora_stat_wait_event()
NATURAL JOIN aurora_stat_wait_type()
WHERE type_name='AuroraLimitless'
ORDER BY wait_time DESC;
type_name | event_name | waits | wait_time
-----------------+---------------------------+---------+-------------
AuroraLimitless | RemoteStatementSetup | 7518 | 75236507897
AuroraLimitless | RemoteStatementExecution | 40 | 132986
AuroraLimitless | Connect | 5 | 1453
(3 rows)
```
# Acara tunggu Database Tanpa Batas
Acara tunggu berikut berlaku untuk Aurora PostgreSQL Limitless Database. Anda dapat memantau peristiwa tunggu ini untuk mengidentifikasi kemacetan dalam pemrosesan Basis Data Aurora PostgreSQL Limitless.
**Topics**
+ [IO: TwophaseFilePoolWrite tunggu acara](#limitless-waits-TwophaseFilePoolWrite)
+ [IO: TwophaseFilePoolRead tunggu acara](#limitless-waits-TwophaseFilePoolRead)
+ [AuroraLimitless:Hubungkan acara tunggu](#limitless-waits-Connect)
+ [AuroraLimitless: AsyncConnect tunggu acara](#limitless-waits-AsyncConnect)
+ [AuroraLimitless: RemoteStatementSetup tunggu acara](#limitless-waits-RemoteStatementSetup)
+ [AuroraLimitless:Acara DDLExecution tunggu jarak jauh](#limitless-waits-RemoteDDLExecution)
+ [AuroraLimitless: RemoteStatementExecution tunggu acara](#limitless-waits-RemoteStatementExecution)
+ [AuroraLimitless: FetchRemoteResults tunggu acara](#limitless-waits-FetchRemoteResults)
+ [AuroraLimitless: AsyncGetInitialResponse tunggu acara](#limitless-waits-AsyncGetInitialResponse)
+ [AuroraLimitless: AsyncGetNextResponse tunggu acara](#limitless-waits-AsyncGetNextResponse)
+ [AuroraLimitless: AbortedCommandCleanup tunggu acara](#limitless-waits-AbortedCommandCleanup)
+ [AuroraLimitless: DistributedCommitPrepare tunggu acara](#limitless-waits-DistributedCommitPrepare)
+ [AuroraLimitless: DistributedCommit tunggu acara](#limitless-waits-DistributedCommit)
+ [AuroraLimitless: DistributedCommitPrepareThrottle tunggu acara](#limitless-waits-DistributedCommitPrepareThrottle)
+ [AuroraLimitless: PreparedTransactionResolution tunggu acara](#limitless-waits-PreparedTransactionResolution)
+ [AuroraLimitless: SendPreparedTransactionOutcome tunggu acara](#limitless-waits-SendPreparedTransactionOutcome)
+ [AuroraLimitless: CommitClockBarrier tunggu acara](#limitless-waits-CommitClockBarrier)
+ [AuroraLimitless: SnapshotClockBarrier tunggu acara](#limitless-waits-SnapshotClockBarrier)
+ [AuroraLimitless: ReaderSnapshotClockBarrier tunggu acara](#limitless-waits-ReaderSnapshotClockBarrier)
+ [AuroraLimitless: GatherDistributedDeadlockGraph tunggu acara](#limitless-waits-GatherDistributedDeadlockGraph)
+ [AuroraLimitless: DistributedDeadlockDetection tunggu acara](#limitless-waits-DistributedDeadlockDetection)
+ [AuroraLimitless: DistributedDeadlockAbort tunggu acara](#limitless-waits-DistributedDeadlockAbort)
+ [AuroraLimitless: GatherRemoteStats tunggu acara](#limitless-waits-GatherRemoteStats)
+ [AuroraLimitless: GlobalSequenceRefresh tunggu acara](#limitless-waits-GlobalSequenceRefresh)
+ [AuroraLimitless: GlobalVacuumTimeExchange tunggu acara](#limitless-waits-GlobalVacuumTimeExchange)
+ [AuroraLimitless: DistributedTransactionMonitorGather tunggu acara](#limitless-waits-DistributedTransactionMonitorGather)
+ [AuroraLimitlessActivity: AdminTaskSchedulerMain tunggu acara](#limitless-waits-AdminTaskSchedulerMain)
+ [AuroraLimitlessActivity: AdminTaskExecutorMain tunggu acara](#limitless-waits-AdminTaskExecutorMain)
+ [AuroraLimitlessActivity: AdminTaskMonitorMain tunggu acara](#limitless-waits-AdminTaskMonitorMain)
+ [AuroraLimitlessActivity: DatabaseCleanupMonitorMain tunggu acara](#limitless-waits-DatabaseCleanupMonitorMain)
+ [AuroraLimitlessActivity: TopologyCleanupMonitorMain tunggu acara](#limitless-waits-TopologyCleanupMonitorMain)
+ [AuroraLimitlessActivity: ToplogyChangeMonitorMain tunggu acara](#limitless-waits-ToplogyChangeMonitorMain)
+ [AuroraLimitlessActivity: DistributedTransactionMonitorMain tunggu acara](#limitless-waits-DistributedTransactionMonitorMain)
+ [AuroraLimitlessActivity: GlobalVacuumMonitorMain tunggu acara](#limitless-waits-GlobalVacuumMonitorMain)
## IO: TwophaseFilePoolWrite tunggu acara
Menunggu penulisan file status dua fase dalam kumpulan file status dua fase. Ini adalah acara khusus Aurora.
### Penyebab
Proses mengeksekusi `PREPARED TRANSACTION` perintah, termasuk peserta dalam transaksi terdistribusi Limitless Database, harus mempertahankan status transaksi dalam file dua fase. Aurora menggunakan kumpulan file untuk meningkatkan kinerja operasi ini.
### Tindakan
Ini adalah operasi I/O tulis sinkron dan oleh karena itu latensi tinggi dalam acara ini memiliki penyebab yang sama `IO:XactSync` dan dapat diselidiki dengan cara yang sama. Jika menggunakan Limitless Database, Anda mungkin perlu mengurangi jumlah transaksi terdistribusi yang dieksekusi.
## IO: TwophaseFilePoolRead tunggu acara
Menunggu pembacaan file status dua fase dalam kumpulan file status dua fase.
### Penyebab
Proses mengeksekusi `COMMIT PREPARED` perintah terhadap transaksi yang disiapkan sebelumnya, termasuk peserta dalam transaksi terdistribusi Limitless Database, mungkin perlu membaca status transaksi yang bertahan sebelumnya dari file dua fase. Aurora menggunakan kumpulan file untuk meningkatkan kinerja operasi ini.
### Tindakan
Ini adalah operasi baca I/O. Oleh karena itu, latensi tinggi dalam peristiwa ini memiliki penyebab yang sama `IO:DataFileRead` dan dapat diselidiki sama. Jika menggunakan Limitless Database, Anda mungkin perlu mengurangi jumlah transaksi terdistribusi yang dieksekusi.
## AuroraLimitless:Hubungkan acara tunggu
Proses ini menunggu koneksi ke node lain di cluster yang akan dibuat.
### Penyebab
Koneksi dibuat antara proses dan node jarak jauh untuk mengeksekusi kueri, transaksi terdistribusi, dan melakukan DDLs.
### Tindakan
Kurangi jumlah koneksi simultan ke cluster atau sesuaikan penggunaan kueri cross-shard.
## AuroraLimitless: AsyncConnect tunggu acara
Peristiwa ini mirip dengan`Connect`, tetapi merupakan proses menunggu koneksi paralel ke satu set node yang akan dibuat.
### Penyebab
Pembentukan koneksi paralel paling sering dilakukan ketika mengeksekusi pernyataan DDL.
### Tindakan
Kurangi jumlah pernyataan DDL atau gabungkan beberapa DDLs di sesi yang sama untuk meningkatkan penggunaan kembali koneksi.
## AuroraLimitless: RemoteStatementSetup tunggu acara
Proses ini menunggu penyiapan eksekusi kueri jarak jauh, seperti kursor buka, tutup, atau pembuatan pernyataan yang disiapkan.
### Penyebab
Peristiwa tunggu ini meningkat dengan jumlah pemindaian pada tabel sharded di mana pernyataan tidak dapat dioptimalkan dengan pecahan tunggal.
### Tindakan
Optimalkan kueri untuk mengurangi jumlah operasi pemindaian atau meningkatkan kelayakan untuk pengoptimalan pecahan tunggal.
## AuroraLimitless:Acara DDLExecution tunggu jarak jauh
Prosesnya sedang menunggu perintah DDL jarak jauh selesai.
### Penyebab
Ketika Anda mengeluarkan perintah DDL pada grup shard DB, itu harus didistribusikan ke router lain dan node shard sebelum mengonfirmasi operasi. Beberapa operasi DDL dapat berjalan untuk waktu yang lama, karena data harus disesuaikan dengan perubahan skema.
### Tindakan
Identifikasi perintah DDL yang berjalan lama sehingga Anda dapat mengoptimalkannya.
## AuroraLimitless: RemoteStatementExecution tunggu acara
Sebuah proses sedang menunggu perintah jarak jauh selesai.
### Penyebab
Perintah SQL berjalan pada node jarak jauh. Acara ini akan sering muncul untuk komunikasi internal, seperti `auto_analyze` dan pemeriksaan detak jantung.
### Tindakan
Identifikasi perintah yang berjalan lama menggunakan tampilan limitless\$1stat\$1statement. Dalam banyak kasus ini adalah peristiwa yang diharapkan, terutama untuk pekerja latar belakang atau proses internal dan tidak diperlukan tindakan.
## AuroraLimitless: FetchRemoteResults tunggu acara
Sebuah proses sedang menunggu untuk mengambil baris dari node jarak jauh.
### Penyebab
Peristiwa tunggu ini dapat meningkat saat mengambil sejumlah besar baris dari tabel jarak jauh, seperti tabel sharded atau referensi.
### Tindakan
Identifikasi `SELECT` kueri yang tidak dioptimalkan menggunakan tampilan. `limitless_stat_statements` Optimalkan kueri untuk mengambil hanya data yang diperlukan. Anda juga dapat menyetel `rds_aurora.limitless_maximum_adaptive_fetch_size` parameternya.
## AuroraLimitless: AsyncGetInitialResponse tunggu acara
Proses ini menunggu respons awal ketika mode pipeline digunakan dalam eksekusi kueri.
### Penyebab
Ini biasanya akan terlihat selama eksekusi router to shard untuk kueri dengan penempatan data shard tunggal dan merupakan bagian yang diharapkan dari eksekusi normal.
### Tindakan
Tidak diperlukan tindakan lebih lanjut.
## AuroraLimitless: AsyncGetNextResponse tunggu acara
Proses ini menunggu tanggapan tambahan ketika mode pipeline digunakan dalam eksekusi kueri.
### Penyebab
Ini biasanya akan terlihat selama eksekusi router to shard untuk kueri dengan penempatan data shard tunggal dan merupakan bagian yang diharapkan dari eksekusi normal.
### Tindakan
Tidak diperlukan tindakan lebih lanjut.
## AuroraLimitless: AbortedCommandCleanup tunggu acara
Prosesnya menunggu hasil kueri pembersihan jarak jauh. Kueri pembersihan dikeluarkan ke node shard untuk mengembalikannya ke keadaan yang sesuai ketika transaksi terdistribusi berakhir.
### Penyebab
Pembersihan transaksi dilakukan ketika transaksi dibatalkan baik karena kesalahan ditemukan atau karena pengguna mengeluarkan perintah ABORT eksplisit atau membatalkan kueri yang sedang berjalan.
### Tindakan
Selidiki penyebab transaksi dibatalkan.
## AuroraLimitless: DistributedCommitPrepare tunggu acara
Proses ini melakukan transaksi terdistribusi dan menunggu semua peserta untuk mengakui perintah persiapan.
### Penyebab
Transaksi yang memodifikasi beberapa node harus melakukan komit terdistribusi. Penantian yang lama `DistributedCommitPrepare` dapat disebabkan oleh menunggu lama di `IO:TwophaseFilePoolWrite` acara pada node yang berpartisipasi.
### Tindakan
Kurangi jumlah transaksi yang memodifikasi data pada beberapa node. Selidiki `IO:TwophaseFilePoolWrite` peristiwa di node lain dari cluster.
## AuroraLimitless: DistributedCommit tunggu acara
Proses ini melakukan transaksi terdistribusi dan sedang menunggu peserta utama untuk mengakui perintah komit.
### Penyebab
Transaksi yang memodifikasi beberapa node harus melakukan komit terdistribusi. Penantian yang lama `DistributedCommit` bisa disebabkan oleh menunggu lama dalam `IO:XactSync` acara pada peserta utama.
### Tindakan
Kurangi jumlah transaksi yang memodifikasi data pada beberapa node. Selidiki `IO:XactSync` peristiwa di node lain dari cluster.
## AuroraLimitless: DistributedCommitPrepareThrottle tunggu acara
Proses ini mencoba untuk mempersiapkan transaksi terdistribusi dan sedang dibatasi karena transaksi yang sudah disiapkan.
### Penyebab
Transaksi yang memodifikasi beberapa node harus melakukan komit terdistribusi. Peserta dalam transaksi ini harus melakukan operasi persiapan sebagai bagian dari protokol komit. Aurora membatasi jumlah persiapan bersamaan, dan jika batas ini terlampaui proses akan menunggu dalam acara tersebut. `DistributedCommitPrepareThrottle`
### Tindakan
Kurangi jumlah transaksi yang memodifikasi data pada beberapa node. Selidiki `IO:TwophaseFilePoolWrite` peristiwa karena peningkatan waktu dalam peristiwa tersebut dapat menyebabkan transaksi siap pakai yang ada menumpuk, yang mengakibatkan pelambatan untuk upaya persiapan baru.
## AuroraLimitless: PreparedTransactionResolution tunggu acara
Proses ini telah mengalami tuple yang dimodifikasi oleh transaksi terdistribusi yang berada dalam keadaan siap. Proses harus menentukan apakah transaksi yang didistribusikan akan terlihat dalam snapshot-nya.
### Penyebab
Transaksi yang memodifikasi beberapa node harus melakukan komit terdistribusi yang mencakup fase persiapan. Tingginya jumlah transaksi terdistribusi atau peningkatan latensi pada komit terdistribusi dapat menyebabkan proses lain menghadapi peristiwa `PreparedTransactionResolution` tunggu.
### Tindakan
Kurangi jumlah transaksi yang memodifikasi data pada beberapa node. Selidiki peristiwa terkait komit terdistribusi karena peningkatan waktu dalam peristiwa tersebut dapat meningkatkan latensi di jalur komit transaksi terdistribusi. Anda mungkin juga ingin menyelidiki beban jaringan dan CPU.
## AuroraLimitless: SendPreparedTransactionOutcome tunggu acara
Proses ini mengeksekusi pada node yang mengoordinasikan transaksi terdistribusi dan proses lain telah menanyakan keadaan transaksi itu, atau proses telah melakukan transaksi terdistribusi dan mengirimkan hasilnya kepada peserta.
### Penyebab
Proses yang menghadapi peristiwa `PreparedTransactionResolution` tunggu akan menanyakan koordinator transaksi. Respons pada koordinator transaksi akan SendPreparedTransactionOutcome ecounter.
### Tindakan
Kurangi jumlah transaksi yang memodifikasi data pada beberapa node. Selidiki peristiwa `IO:TwophaseFilePoolWrite` dan `IO:TwophaseFilePoolRead` peristiwa terkait komit terdistribusi karena peristiwa tersebut dapat meningkatkan latensi di jalur komit transaksi terdistribusi. Anda mungkin juga ingin menyelidiki beban jaringan dan CPU.
## AuroraLimitless: CommitClockBarrier tunggu acara
Proses ini melakukan transaksi dan harus menunggu untuk memastikan bahwa waktu komit yang ditetapkan dijamin berada di masa lalu untuk semua node di cluster.
### Penyebab
Staturasi CPU atau jaringan dapat menyebabkan peningkatan penyimpangan jam, yang mengakibatkan waktu yang dihabiskan dalam acara tunggu ini.
### Tindakan
Selidiki CPU atau saturasi jaringan di cluster Anda.
## AuroraLimitless: SnapshotClockBarrier tunggu acara
Proses ini telah menerima waktu snapshot dari node lain dengan jam di masa depan dan sedang menunggu jamnya sendiri untuk mencapai waktu itu.
### Penyebab
Ini biasanya terjadi setelah proses menerima hasil dari fungsi yang didorong ke pecahan dan ada penyimpangan jam di antara node. Staturasi CPU atau jaringan dapat menyebabkan peningkatan penyimpangan jam, yang mengakibatkan waktu yang dihabiskan dalam acara tunggu ini.
### Tindakan
Selidiki staturasi CPU atau jaringan di cluster Anda.
## AuroraLimitless: ReaderSnapshotClockBarrier tunggu acara
Peristiwa ini terjadi pada node baca. Proses ini menunggu node baca untuk memutar ulang aliran tulis sehingga semua penulisan yang terjadi sebelum waktu snapshot proses telah diterapkan.
### Penyebab
Peningkatan lag replika Aurora dapat menyebabkan peningkatan waktu tunggu dalam acara ini.
### Tindakan
Selidiki lag replika Aurora.
## AuroraLimitless: GatherDistributedDeadlockGraph tunggu acara
Prosesnya berkomunikasi dengan node lain untuk mengumpulkan grafik kunci sebagai bagian dari deteksi kebuntuan terdistribusi.
### Penyebab
Ketika suatu proses menunggu di kunci, ia akan melakukan pemeriksaan kebuntuan terdistribusi setelah menunggu lebih lama dari`rds_aurora.limitless_distributed_deadlock_timeout`.
### Tindakan
Selidiki penyebab pertengkaran kunci dalam aplikasi Anda dan pertimbangkan penyetelan`rds_aurora.limitless_distributed_deadlock_timeout`.
## AuroraLimitless: DistributedDeadlockDetection tunggu acara
Prosesnya berkomunikasi dengan node lain untuk mendeteksi kebuntuan terdistribusi.
### Penyebab
Ketika suatu proses menunggu di kunci, ia akan melakukan pemeriksaan kebuntuan terdistribusi setelah menunggu lebih lama dari`rds_aurora.limitless_distributed_deadlock_timeout`.
### Tindakan
Selidiki penyebab pertengkaran kunci dalam aplikasi Anda dan pertimbangkan penyetelan`rds_aurora.limitless_distributed_deadlock_timeout`.
## AuroraLimitless: DistributedDeadlockAbort tunggu acara
Prosesnya berkomunikasi dengan node lain untuk membatalkan sesi yang dipilih sebagai korban dalam kebuntuan terdistribusi.
### Penyebab
Pola aplikasi menghasilkan kebuntuan terdistribusi.
### Tindakan
Selidiki pola aplikasi yang mengakibatkan kebuntuan terdistribusi.
## AuroraLimitless: GatherRemoteStats tunggu acara
Prosesnya adalah mengumpulkan statistik dari node lain di cluster.
### Penyebab
Monitoring atau activty query dan views, seperti`limitless_stat_activity`, akan mengambil statistik dari node lain.
### Tindakan
Tidak diperlukan tindakan lebih lanjut.
## AuroraLimitless: GlobalSequenceRefresh tunggu acara
Proses ini menghasilkan nilai urutan baru dan harus meminta potongan baru dari urutan global.
### Penyebab
Tingkat pembuatan nilai urutan yang tinggi dapat mengakibatkan penghentian dalam acara ini jika tidak `rds_aurora.limitless_sequence_chunk_size` mencukupi.
### Tindakan
Ini adalah kejadian normal. Jika Anda melihat waktu yang berlebihan dalam acara ini pertimbangkan penyetelan. `rds_aurora.limitless_sequence_chunk_size` Lihat dokumentasi tentang urutan di Limitless Database.
## AuroraLimitless: GlobalVacuumTimeExchange tunggu acara
Prosesnya bertukar data snapshot untuk mendukung kekosongan.
### Penyebab
Node di Limitless Database menukar data waktu snapshot aktif tertua dengan node lain untuk menghitung waktu cutoff yang benar untuk eksekusi vakum.
### Tindakan
Tidak diperlukan tindakan lebih lanjut.
## AuroraLimitless: DistributedTransactionMonitorGather tunggu acara
Prosesnya adalah mengumpulkan metadata transaksi dari node lain untuk mendukung pembersihan transaksi terdistribusi.
### Penyebab
Node dalam metadata transaksi pertukaran Database Limitless dengan node lain untuk menentukan kapan status transaksi terdistribusi dapat dibersihkan.
### Tindakan
Tidak diperlukan tindakan lebih lanjut.
## AuroraLimitlessActivity: AdminTaskSchedulerMain tunggu acara
Menunggu di loop utama proses penjadwal tugas.
## AuroraLimitlessActivity: AdminTaskExecutorMain tunggu acara
Menunggu di loop utama proses pelaksana tugas.
## AuroraLimitlessActivity: AdminTaskMonitorMain tunggu acara
Menunggu di loop utama proses monitor tugas.
## AuroraLimitlessActivity: DatabaseCleanupMonitorMain tunggu acara
Menunggu di loop utama proses monitor pembersihan basis data.
## AuroraLimitlessActivity: TopologyCleanupMonitorMain tunggu acara
Menunggu di loop utama proses monitor pembersihan topologi.
## AuroraLimitlessActivity: ToplogyChangeMonitorMain tunggu acara
Menunggu di loop utama proses monitor perubahan topologi.
## AuroraLimitlessActivity: DistributedTransactionMonitorMain tunggu acara
Menunggu di loop utama proses monitor transaksi terdistribusi.
## AuroraLimitlessActivity: GlobalVacuumMonitorMain tunggu acara
Menunggu di loop utama proses monitor vakum global.
# Membangun untuk efisiensi dengan fungsi
Fungsi yang ditentukan pengguna bukan shard tunggal yang dioptimalkan secara default, tetapi mereka dapat dikonfigurasi untuk dijalankan sebagai operasi pecahan tunggal. Fungsi dapat merangkum logika dan memastikannya dijalankan dengan cara yang dioptimalkan dengan shard tunggal.
## Mengapa operasi pecahan tunggal itu penting
Pemanfaatan sumber daya penting untuk kinerja dan efisiensi biaya. Operasi single-shard menggunakan sumber daya yang jauh lebih sedikit dibandingkan dengan operasi cross-shard. Misalnya, ketika menjalankan fungsi untuk menyisipkan satu juta baris, eksekusi shard tunggal menggunakan sekitar 90,5 ACUs dibandingkan dengan 126,5 ACUs untuk eksekusi cross-shard — peningkatan 35% dalam efisiensi sumber daya.
Eksekusi single-shard juga menyediakan:
+ Throughput 35% lebih tinggi dari operasi cross-shard
+ Waktu respons yang lebih dapat diprediksi
+ Skalabilitas yang lebih baik seiring pertumbuhan data
## Operasi dan fungsi shard tunggal
Fungsi dijalankan pada pecahan ketika salah satu dari prasyarat ini terpenuhi:
+ Fungsi ini dibuat sebagai tidak dapat diubah dan disertakan dalam kueri yang dioptimalkan dengan pecahan tunggal
+ Fungsi didistribusikan oleh pengguna
Fungsi yang dijalankan pada pecahan bekerja dan menskalakan lebih baik karena mereka mengeksekusi di mana data berada.
## Fungsi dan volatilitas
Untuk memeriksa volatilitas fungsi, gunakan kueri ini pada tabel sistem PostgreSQL:
```
SELECT DISTINCT nspname, proname, provolatile
FROM pg_proc PRO
JOIN pg_namespace NSP ON PRO.pronamespace = NSP.oid
WHERE proname IN ('random', 'md5');
```
Contoh output:
```
nspname | proname | provolatile
------------+---------+-------------
pg_catalog | md5 | i
pg_catalog | random | v
(2 rows)
```
Dalam contoh ini, `md5()` tidak dapat diubah dan tidak `random()` stabil. Ini berarti bahwa pernyataan yang dioptimalkan dengan pecahan tunggal yang menyertakan `md5()` tetap dioptimalkan pecahan tunggal, sedangkan pernyataan yang menyertakan tidak. `random()`
Contoh dengan fungsi yang tidak dapat diubah:
```
EXPLAIN ANALYZE
SELECT pg_catalog.md5('123')
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
----------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=3.409..3.409 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.313 ms
Execution Time: 4.253 ms
(4 rows)
```
Contoh dengan fungsi volatile:
```
EXPLAIN ANALYZE
SELECT pg_catalog.random()
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
------------------------------------------------------
Foreign Scan on t1_fs00001 t1
(cost=100.00..15905.15 rows=1 width=8)
(actual time=0.658..0.658 rows=1 loops=1)
Planning Time: 0.263 ms
Execution Time: 2.892 ms
(3 rows)
```
Output menunjukkan bahwa `md5()` didorong ke bawah dan dieksekusi sebagai shard tunggal yang dioptimalkan, sementara `random()` tidak.
## Mendistribusikan fungsi
Fungsi yang mengakses data hanya pada satu pecahan harus dijalankan pada pecahan itu untuk mendapatkan manfaat kinerja. Fungsi harus didistribusikan, dan tanda tangan fungsi harus menyertakan tombol shard lengkap—semua kolom dalam kunci shard harus diteruskan sebagai parameter ke fungsi.
Contoh fungsi:
```
CREATE OR REPLACE FUNCTION s1.func1(
param_a bigint,
param_b bigint,
param_c char(100)
)
RETURNS int AS $$
DECLARE
res int;
BEGIN
SELECT COUNT(*) INTO res
FROM s1.t1
WHERE s1.t1.col_a = param_a
AND s1.t1.col_b = param_b
AND s1.t1.col_c = param_c;
RETURN res;
END
$$ LANGUAGE plpgsql;
```
Sebelum distribusi, fungsinya tidak dioptimalkan dengan pecahan tunggal:
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=37.503..37.503 rows=1 loops=1)
Planning Time: 0.901 ms
Execution Time: 51.647 ms
(3 rows)
```
Untuk mendistribusikan fungsi:
```
SELECT rds_aurora.limitless_distribute_function(
's1.func1(bigint,bigint,character)',
ARRAY['param_a','param_b','param_c'],
's1.t1'
);
```
Setelah distribusi, fungsinya dioptimalkan dengan pecahan tunggal:
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.332..4.333 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.857 ms
Execution Time: 5.116 ms
(4 rows)
```
Anda dapat mengonfirmasi optimasi shard tunggal dengan memeriksa `sso_calls` kolom di: `rds_aurora.limitless_stat_statements`
```
subcluster_id | subcluster_type | calls | sso_calls | query
--------------+-----------------+-------+-----------+--------------------------------------
2 | router | 2 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
3 | router | 1 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
(2 rows)
```
## Fungsi dan pola efisiensi
Mengeksekusi logika dekat dengan data lebih efisien, dan fungsi memainkan peran kunci dalam mencapai hal ini. Ada dua kasus penggunaan utama untuk meningkatkan efisiensi dengan fungsi:
1. Mengekstrak kunci pecahan dari data kompleks untuk menjalankan fungsi terpisah yang dioptimalkan dengan pecahan tunggal
1. Mengubah beban kerja cross-shard menjadi shard tunggal yang dioptimalkan dengan memisahkan logika cross-shard dari pernyataan yang dioptimalkan dengan pecahan tunggal
### Mengekstrak kunci pecahan dari data kompleks
Pertimbangkan fungsi dengan tanda tangan `s3.func3(p_json_doc json)` yang melakukan beberapa operasi database. Operasi ini akan dijalankan di semua pecahan dalam transaksi yang mencakup semua pecahan. Jika dokumen JSON berisi kunci shard, Anda dapat membangun fungsi single-shard yang dioptimalkan untuk melakukan operasi database.
Pola asli:
```
s3.func3(p_json_doc json)
database operation 1;
database operation 2;
database operation 3;
```
Pola yang dioptimalkan:
```
s3.func3(p_json_doc json)
DECLARE
v_a bigint;
BEGIN
v_a := (p_json_doc->>'field_a')::bigint;
SELECT s3.func3_INNER(v_a, p_json_doc);
END;
```
Dimana fungsi batin melakukan:
```
s3.func3_INNER(p_a, p_json_doc)
database operation 1 WHERE shard_key = p_a;
database operation 2 WHERE shard_key = p_a;
database operation 3 WHERE shard_key = p_a;
```
Dalam pola ini, kunci pecahan dienkapsulasi dalam tipe data yang kompleks atau dapat dideduksi dari parameter lain. Logika, akses data, dan fungsi dapat menentukan, mengekstrak, atau membangun kunci shard, kemudian memanggil fungsi yang dioptimalkan shard tunggal yang melakukan operasi hanya dengan satu pecahan. Karena antarmuka aplikasi tidak berubah, pengoptimalan relatif mudah untuk diuji.
### Menunda kunci shard dari fungsi atau data lain
Pola desain lain berlaku ketika logika atau akses data menghitung atau menentukan kunci shard. Ini berguna ketika sebuah fungsi dapat dieksekusi pada satu pecahan untuk sebagian besar pemanggilan, tetapi kadang-kadang membutuhkan eksekusi cross-shard.
Pola asli:
```
NEWORD(INTEGER, …) RETURNS NUMERIC
DECLARE
all_whid_local := true;
LOOP through the order lines
Generate warehouse ID;
IF generated warehouse ID == input warehouse ID
THEN
ol_supply_whid := input warehouse ID;
ELSE
all_whid_local := false;
ol_supply_whid := generated warehouse ID;
END IF;
…
END LOOP;
…
RETURN no_s_quantity;
```
Pola yang dioptimalkan dengan fungsi terpisah:
```
CREATE OR REPLACE FUNCTION NEWORD_sso(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
SELECT rds_aurora.limitless_distribute_function(
'NEWORD_sso(int,…)',
ARRAY['no_w_id'],
'warehouse'
);
CREATE OR REPLACE FUNCTION NEWORD_crosshard(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
```
Kemudian minta fungsi utama memanggil versi single-shard yang dioptimalkan atau cross-shard:
```
IF all_whid_local THEN
SELECT NEWORD_sso(…) INTO no_s_quantity;
ELSE
SELECT NEWORD_crosshard(…) INTO no_s_quantity;
END IF;
```
Pendekatan ini memungkinkan sebagian besar pemanggilan untuk mendapatkan keuntungan dari optimasi pecahan tunggal sambil mempertahankan perilaku yang benar untuk kasus yang memerlukan eksekusi cross-shard.
## Memeriksa operasi pecahan tunggal
Gunakan `EXPLAIN` untuk memverifikasi apakah pernyataan dioptimalkan dengan pecahan tunggal. Output secara eksplisit melaporkan “Single Shard Optimized” untuk operasi yang dioptimalkan.
Pemanggilan cross-shard sebelum distribusi:
```
QUERY PLAN
---------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=59.622..59.623 rows=1 loops=1)
Planning Time: 0.925 ms
Execution Time: 60.211 ms
```
Pemanggilan pecahan tunggal setelah distribusi:
```
QUERY PLAN
----------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.576..4.577 rows=1 loops=1)
Single Shard Optimized
Planning Time: 1.483 ms
Execution Time: 5.404 ms
```
Perbedaan waktu eksekusi menunjukkan manfaat kinerja dari optimasi shard tunggal.