Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Monitoraggio di Aurora PostgreSQL Limitless Database
Puoi utilizzare Amazon CloudWatch, Enhanced Monitoring e Performance Insights per monitorare Aurora PostgreSQL Limitless Database. Sono inoltre disponibili nuove visualizzazioni e funzioni di statistiche, oltre a eventi di attesa, per Aurora PostgreSQL Limitless Database, che puoi utilizzare per attività di monitoraggio e diagnostica.
**Topics**
+ [
# Monitoraggio di Aurora PostgreSQL Limitless Database con Amazon CloudWatch
](limitless-monitoring.cw.md)
+ [
# Monitoraggio di Aurora PostgreSQL Limitless Database con CloudWatch Database Insights
](limitless-monitoring.cwdbi.md)
+ [
# Monitoraggio di Aurora PostgreSQL Limitless Database con Amazon CloudWatch Logs
](limitless-monitoring.cwl.md)
+ [
# Monitoraggio di Aurora PostgreSQL Limitless Database con Monitoraggio avanzato
](limitless-monitoring.em.md)
+ [
# Monitoraggio di Aurora PostgreSQL Limitless Database con Approfondimenti sulle prestazioni
](limitless-monitoring.pi.md)
+ [
# Monitoraggio di Aurora PostgreSQL Limitless Database con la protezione RDS Amazon GuardDuty
](limitless-monitoring.gd.md)
+ [
# Funzioni e visualizzazioni per Aurora PostgreSQL Limitless Database
](limitless-monitoring-fns-views.md)
+ [
# Eventi di attesa per Aurora PostgreSQL Limitless Database
](limitless-monitoring-waits.md)
+ [
# Costruire per l'efficienza con le funzioni
](limitless-performance-functions.md)
# Monitoraggio di Aurora PostgreSQL Limitless Database con Amazon CloudWatch
Le metriche CloudWatch per Aurora PostgreSQL Limitless Database vengono riportate nelle seguenti dimensioni:
+ [DBShardGroup](#limitless-monitoring.cw.DBShardGroup)
+ [DBShardGroupRouterAggregation](#limitless-monitoring.cw.DBShardGroupRouterAggregate)
+ [DBShardGroupInstance](#limitless-monitoring.cw.DBShardGroupInstance)
+ [DBClusterIdentifier](#limitless-monitoring.cw.DBClusterIdentifier)
Per ulteriori informazioni sui parametri di CloudWatch, consulta [Monitoraggio dei parametri di Amazon Aurora con Amazon CloudWatch](monitoring-cloudwatch.md).
## Metriche DBShardGroup
Per visualizzare le metriche `DBShardGroup` per Aurora PostgreSQL Limitless Database nella console CloudWatch, scegli **RDS** e poi **DBShardGroup**.
Puoi tenere traccia delle seguenti metriche di CloudWatch:
+ `DBShardGroupACUUtilization`: l’utilizzo dell’unità di capacità Aurora (ACU) come percentuale calcolata dividendo `DBShardGroupCapacity` per `DBShardGroupMaxACU`.
+ `DBShardGroupCapacity`: il numero di ACU utilizzate dalle istanze di scrittura del gruppo di shard del database.
+ `DBShardGroupComputeRedundancyCapacity`: il numero di ACU utilizzate dalle istanze di standby del gruppo di shard del database.
+ `DBShardGroupMaxACU`: il numero massimo di ACU configurate per il gruppo di shard del database.
+ `DBShardGroupMinACU`: il numero minimo di ACU richiesto dal gruppo di shard del database.
La chiave di dimensione `DBShardGroupIdentifier` è disponibile per l’aggregazione delle metriche `DBShardGroup`.
## Metriche di DBShardGroupRouterAggregation
Per visualizzare le metriche `DBShardGroupRouterAggregation` per Aurora PostgreSQL Limitless Database nella console CloudWatch, scegli **RDS** e poi **DBShardGroupRouterAggregation**.
Puoi tenere traccia delle seguenti metriche di CloudWatch:
+ `CommitThroughput`: il numero medio di operazioni di commit al secondo su tutti i nodi del router del gruppo di shard del database.
+ `DatabaseConnections`: la somma di tutte le connessioni su tutti i nodi del router nel gruppo di shard del database.
## Metriche di DBShardGroupInstance
Un’istanza DBShardGroupInstance rappresenta una singola istanza database all’interno di ogni shard o cluster secondario del router.
Per visualizzare le metriche `DBShardGroupInstance` per Aurora PostgreSQL Limitless Database nella console CloudWatch, scegli **RDS** e poi **DBShardGroupInstance**.
Puoi tenere traccia delle seguenti metriche di CloudWatch:
+ `ACUUtilization`: la percentuale calcolata dividendo la metrica `ServerlessDatabaseCapacity` per il valore massimo di ACU assegnato al cluster secondario.
+ `AuroraReplicaLag`: per i cluster Limitless con ridondanza di calcolo abilitata, il ritardo durante la replica degli aggiornamenti dall’istanza primaria del cluster secondario.
+ `AuroraReplicaLagMaximum`: per i cluster Limitless con ridondanza di calcolo abilitata, il ritardo massimo durante la replica degli aggiornamenti dall’istanza primaria del cluster secondario. Quando le repliche di lettura vengono eliminate o rinominate, potrebbe verificarsi un picco temporaneo del ritardo di replica dovuto al processo di riciclaggio a cui è sottoposta la vecchia risorsa. Utilizza questa metrica per determinare se si è verificato un failover dovuto all’elevato ritardo della replica su un’istanza di lettura.
+ `AuroraReplicaLagMinimum`: per i cluster Limitless con ridondanza di calcolo abilitata, il ritardo minimo durante la replica degli aggiornamenti dall’istanza primaria del cluster secondario.
+ `BufferCacheHitRatio`: la percentuale di dati e indici serviti dalla cache di memoria dell’istanza, invece che dal volume di archiviazione.
+ `CommitLatency`: la durata media necessaria al motore e all’archiviazione per completare le operazioni di commit in uno specifico nodo (router o shard).
+ `CommitThroughput`: il numero medio di operazioni di commit al secondo.
+ `CPUUtilization`: l’utilizzo della CPU come percentuale del valore ACU massimo assegnato al cluster secondario.
+ `FreeableMemory`: la quantità di memoria inutilizzata disponibile quando il gruppo di shard viene scalato alla sua capacità massima. Questo valore è determinato in base alle ACU assegnate al gruppo di shard. Per ogni ACU la cui capacità corrente è inferiore alla capacità massima, questo valore aumenta di circa 2 GiB. Di conseguenza, questa metrica non si avvicina a zero finché il gruppo di shard del database non viene aumentato verticalmente fino al limite massimo.
+ `MaximumUsedTransactionIDs`: l’età dell’ID transazione non sottoposto al comando VACUUM meno recente, nelle transazioni. Se questo valore raggiunge 2.146.483.648 (2^31 - 1.000.000), il database viene forzato in modalità di sola lettura, per evitare il wraparound dell’ID transazione. Per ulteriori informazioni, consulta [Impedire gli errori wraparound dell'ID transazione](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) nella documentazione di PostgreSQL.
+ `NetworkReceiveThroughput`: la quantità di throughput della rete ricevuto dai client da ogni istanza del gruppo di shard del database. Questo throughput non include il traffico di rete tra le istanze nel gruppo di shard del database e il volume del cluster.
+ `NetworkThroughput`: il throughput della rete aggregato (sia trasmesso che ricevuto) tra client e router, e tra router e shard all’interno del gruppo di shard del database. Questo throughput non include il traffico di rete tra le istanze nel gruppo di shard del database e il volume del cluster.
+ `NetworkTransmitThroughput`: la quantità di throughput della rete inviato ai client da ogni istanza del gruppo di shard del database. Questo throughput non include il traffico di rete tra le istanze nel gruppo di shard del database e il volume del cluster.
+ `ReadIOPS`: il numero medio di operazioni di input/output al secondo (IOPS) di lettura su disco.
+ `ReadLatency`: la quantità di tempo medio impiegato per ogni operazione di input/output (I/O) di lettura su disco.
+ `ReadThroughput`: il numero medio di byte letti dal disco al secondo.
+ `ServerlessDatabaseCapacity`: la capacità attuale dello shard del database o del cluster secondario del router all’interno del gruppo di shard.
+ `StorageNetworkReceiveThroughput`: la quantità di throughput della rete ricevuto dal sottosistema di archiviazione Aurora da ogni istanza nel gruppo di shard del database.
+ `StorageNetworkThroughput`: il throughput della rete aggregato, sia trasmesso che ricevuto, tra ogni istanza del gruppo di shard del database e il sottosistema di archiviazione Aurora.
+ `StorageNetworkTransmitThroughput`: la quantità di throughput della rete inviato al sottosistema di archiviazione Aurora da ogni istanza del gruppo di shard del database.
+ `SwapUsage`: la quantità di spazio di swap utilizzato dal gruppo di shard del database.
+ `TempStorageIOPS`: il numero medio di operazioni di I/O eseguite sull’archiviazione locale collegata all’istanza database. Include operazioni di I/O di lettura e scrittura.
È possibile utilizzare `TempStorageIOPS` e `TempStorageThroughput` per diagnosticare i rari casi in cui l’attività di rete relativa ai trasferimenti tra le istanze database e i dispositivi di archiviazione locale è responsabile di aumenti imprevisti della capacità.
+ `TempStorageThroughput`: la quantità di dati trasferiti da e verso l’archiviazione locale associata a un router o a uno shard.
+ `WriteIOPS`: il numero medio di IOPS di scrittura su disco.
+ `WriteLatency`: la quantità di tempo media impiegato per ogni operazione di I/O di scrittura su disco.
+ `WriteThroughput`: il numero medio di byte scritti su disco al secondo.
Le seguenti chiavi di dimensione sono disponibili per l’aggregazione delle metriche `DBShardGroupInstance`.
+ `DBClusterIdentifier`: il cluster di database Aurora PostgreSQL.
+ `DBShardGroupIdentifier`: il gruppo di shard del database a cui appartiene l’istanza.
+ `DBShardGroupSubClusterType`: il tipo di nodo, `Distributed Transaction Router` (router) o `Data Access Shard` (shard).
+ `DBShardGroupSubClusterIdentifier`: il nome del router o dello shard a cui appartiene l’istanza.
Di seguito sono riportati alcuni esempi di aggregazione delle metriche di CloudWatch:
+ Totale `CPUUtilization` di tutte le istanze che appartengono a un particolare shard o router in un gruppo di shard del database.
+ Totale `CPUUtilization` di tutte le istanze in un gruppo di shard del database.
## Metriche di DBClusterIdentifier
Per visualizzare le metriche `DBClusterIdentifier` per Aurora PostgreSQL Limitless Database nella console CloudWatch, scegli **RDS** e poi **DBClusterIdentifier**.
Quando utilizzi Aurora PostgreSQL Limitless Database, potresti riscontrare un numero maggiore di operazioni di input/output (I/O) rispetto a un cluster di database Aurora. Puoi tenere traccia delle seguenti metriche di CloudWatch per il cluster Limitless Database:
+ `VolumeReadIops`: il numero di operazioni I/O di lettura fatturate da un volume del cluster, indicato a intervalli di 5 minuti.
+ `VolumeWriteIops`: il numero di operazioni I/O di scrittura su disco verso il volume del cluster, indicato a intervalli di 5 minuti.
Aurora PostgreSQL Limitless Database utilizza la configurazione di archiviazione del cluster Aurora I/O-Optimized. Con Aurora I/O-Optimized, paghi un unico prezzo mensile per tutte le operazioni di I/O, invece di un costo per ogni milione di richieste I/O. Per ulteriori informazioni, consulta [Configurazioni dell'archiviazione per i cluster database Amazon Aurora](Aurora.Overview.StorageReliability.md#aurora-storage-type).
Potresti anche utilizzare una quantità di archiviazione maggiore rispetto a un cluster di database Aurora. Puoi tenere traccia delle seguenti metriche di CloudWatch relative all’archiviazione:
+ `BackupRetentionPeriodStorageUsed`: il totale dell’utilizzo fatturato dell’archiviazione di backup continuo del cluster Aurora PostgreSQL Limitless Database.
+ `SnapshotStorageUsed`: il totale dell’utilizzo fatturato dell’archiviazione degli snapshot del cluster Aurora PostgreSQL Limitless Database.
+ `TotalBackupStorageBilled`: la somma dei costi per la conservazione dei backup automatici e per gli snapshot del cluster di database.
Per ulteriori informazioni sui costi dell’archiviazione di backup, consulta [Informazioni sull'utilizzo dello storage di backup Amazon Aurora](aurora-storage-backup.md).
+ `VolumeBytesUsed`: la quantità di archiviazione utilizzata dal cluster Aurora PostgreSQL Limitless Database, indicata a intervalli di 5 minuti.
# Monitoraggio di Aurora PostgreSQL Limitless Database con CloudWatch Database Insights
La modalità standard di Database Insights è richiesta come parte dell’abilitazione di Aurora PostgreSQL Limitless Database. Puoi utilizzarla per monitorare il carico del database (carico del DB) dell’istanza database Limitless Database in tempo reale. L’opzione Carico del DB misura il livello di attività della sessione in un database. Puoi utilizzare Database Insights per analizzare e risolvere i problemi di prestazioni delle istanze database Aurora PostgreSQL Limitless Database su larga scala.
Per ulteriori informazioni su CloudWatch Database Insights, consulta quanto segue.
+ [Monitoraggio dei database Amazon Aurora con CloudWatch Database Insights](USER_DatabaseInsights.md)
+ [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html) nella *Guida per l’utente di Amazon CloudWatch*
+ [Nozioni di base di CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Get-Started.html) nella *Guida per l’utente di Amazon CloudWatch*
+ [Configurazione del database per monitorare le query SQL lente con Database Insights per Amazon Aurora](USER_DatabaseInsights.SlowSQL.md)
Per informazioni sull’attivazione della modalità avanzata o della modalità standard di Database Insights, consulta i seguenti argomenti.
**Topics**
+ [
# Attivazione della modalità avanzata di Database Insights per Aurora PostgreSQL Limitless Database
](limitless-monitoring.cwdbi.advanced.md)
+ [
# Attivazione della modalità standard di Database Insights per Aurora PostgreSQL Limitless Database
](limitless-monitoring.cwdbi.standard.md)
# Attivazione della modalità avanzata di Database Insights per Aurora PostgreSQL Limitless Database
Per attivare la modalità avanzata di Database Insights per il database Aurora PostgreSQL Limitless, utilizzare le seguenti procedure.
## Attivazione della modalità avanzata di Database Insights durante la creazione di un cluster di database per Aurora PostgreSQL Limitless Database
Attiva la modalità avanzata di Database Insights durante la creazione di un database per Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
Nella console è possibile attivare la modalità avanzata di Database Insights quando si crea un cluster di database. Le impostazioni per Database Insights si applicano a tutte le istanze database nel cluster di database.
**Per attivare la modalità avanzata di Database Insights durante la creazione di un cluster di database utilizzando la console**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database**.
1. Scegliere **Crea database**.
1. Nella sezione **Database Insights**, seleziona **Modalità avanzata**. Quindi, scegli le seguenti opzioni:
+ **Retention (Conservazione)** – Quantità di tempo per cui conservare i dati di Performance Insights. Il periodo di conservazione deve essere di 15-24 mesi per la modalità avanzata di Database Insights.
+ **AWS KMS key**: specificare la chiave KMS. Performance Insights crittografa tutti i dati potenzialmente sensibili con la chiave KMS. I dati vengono crittografati mentre sono in transito o inattivi. Per ulteriori informazioni, consulta [Crittografia delle risorse Amazon Aurora](Overview.Encryption.md).
1. Scegliere **Crea database**.
------
#### [ AWS CLI ]
Per attivare la modalità avanzata di Database Insights durante la creazione di un cluster di database, chiama il comando AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) e fornisci i seguenti valori:
+ `--db-cluster-identifier`: l’identificatore del cluster di database.
+ `--database-insights-mode advanced` per attivare la modalità avanzata di Database Insights.
+ `--engine`: il cluster di database deve utilizzare il motore di database `aurora-postgresql`.
+ `--engine-version`: il cluster di database deve utilizzare una delle versioni supportate del motore di database.
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type`: il cluster di database deve utilizzare la configurazione di archiviazione del cluster di database `aurora-iopt1`.
+ `--cluster-scalability-type`: specifica la modalità di scalabilità del cluster di database Aurora. Se impostato su `limitless`, il cluster funziona come Aurora PostgreSQL Limitless Database. Se impostato su `standard` (impostazione predefinita), il cluster utilizza la normale creazione di istanze database.
**Nota**
Non è possibile modificare questa impostazione dopo la creazione del cluster di database.
+ `--master-username`: il nome dell’utente master del cluster di database.
+ `--master-user-password`: la password dell’utente master.
+ `--enable-performance-insights` per attivare Approfondimenti sulle prestazioni per Database Insights.
+ `--performance-insights-retention-period`: il periodo di conservazione dei dati per il cluster di database. Per attivare Database Insights, il periodo di conservazione deve essere di almeno 465 giorni.
+ `--monitoring-interval`: l’intervallo, in secondi, tra i punti di raccolta delle metriche di monitoraggio avanzato per il cluster di database. Questo valore può essere `0`.
+ `--monitoring-role-arn`: il nome della risorsa Amazon (ARN) del ruolo IAM che consente a RDS di inviare le metriche di monitoraggio avanzato ad Amazon CloudWatch Logs.
+ `--enable-cloudwatch-logs-exports`: è necessario esportare i log `postgresql` in CloudWatch Logs.
L’esempio seguente abilita la modalità avanzata di Database Insights durante la creazione di un cluster di database.
Per Linux, macOS o 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
```
Per 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 ]
Per attivare la modalità avanzata di Database Insights quando crei , specifica i seguenti parametri per l’operazione API [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) di Amazon RDS.
+ `DatabaseInsightsMode` Da a `advanced`
+ `Engine` Da a `aurora-postgresql`
+ Da `EngineVersion` a una versione del motore disponibile per Limitless Database
+ `StorageType` Da a `aurora-iopt1`
+ `ClusterScalabilityType` Da a `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` Da a `True`
+ Da `PerformanceInsightsRetentionPeriod` ad almeno `465` giorni
+ Da `MonitoringInterval` a un valore diverso da `0`
+ Da `MonitoringRoleArn` al nome della risorsa Amazon (ARN) del ruolo IAM che consente a RDS di inviare le metriche di monitoraggio avanzato ad Amazon CloudWatch Logs.
------
## Attivazione della modalità avanzata di Database Insights durante la modifica di un cluster di database per Aurora PostgreSQL Limitless Database
Attiva Database Insights durante la modifica di un database per Aurora PostgreSQL Limitless Database.
**Nota**
Per abilitare Database Insights, ogni istanza database in un cluster di database deve avere le stesse impostazioni di Approfondimenti sulle prestazioni e monitoraggio avanzato.
------
#### [ Console ]
Nella console è possibile attivare la modalità avanzata di Database Insights durante la modifica di un cluster di database. Le impostazioni per Database Insights si applicano a tutte le istanze database nel cluster di database.
**Per attivare la modalità avanzata di Database Insights durante la modifica di un cluster di database utilizzando la console**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database**.
1. Scegli un cluster di database e scegli **Modifica**.
1. Nella sezione **Database Insights**, seleziona **Modalità avanzata**. Quindi, scegli le seguenti opzioni:
+ **Retention (Conservazione)** – Quantità di tempo per cui conservare i dati di Performance Insights. Il periodo di conservazione deve essere di 15-24 mesi per la modalità avanzata di Database Insights.
+ **AWS KMS key**: specificare la chiave KMS. Performance Insights crittografa tutti i dati potenzialmente sensibili con la chiave KMS. I dati vengono crittografati mentre sono in transito o inattivi. Per ulteriori informazioni, consulta [Crittografia delle risorse Amazon Aurora](Overview.Encryption.md).
1. Scegli **Continue (Continua)**.
1. In **Scheduling of Modifications (Pianificazione delle modifiche)**, scegliere **Apply immediately (Applica immediatamente)**. Se scegli **Applica durante la prossima finestra di manutenzione pianificata**, il database ignora questa impostazione e attiva immediatamente la modalità avanzata di Database Insights.
1. Scegli **Modifica cluster**.
------
#### [ AWS CLI ]
Per attivare la modalità avanzata di Database Insights durante la modifica di un cluster di database, chiama il comando AWS CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) e fornisci i seguenti valori:
+ `--database-insights-mode advanced` per attivare la modalità avanzata di Database Insights.
+ `--db-cluster-identifier`: l’identificatore del cluster di database.
+ `--enable-performance-insights` per attivare Approfondimenti sulle prestazioni per Database Insights.
+ `--performance-insights-retention-period`: il periodo di conservazione dei dati per il cluster di database. Per attivare la modalità avanzata di Database Insights, il periodo di conservazione deve essere di almeno 465 giorni.
L’esempio seguente abilita la modalità avanzata di Database Insights quando si modifica un cluster di database.
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--database-insights-mode advanced \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 465
```
Per 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 ]
Per attivare la modalità avanzata di Database Insights durante la modifica di un cluster di database, specifica i seguenti parametri per l’operazione API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) di Amazon RDS.
+ `DatabaseInsightsMode` Da a `advanced`
+ `EnablePerformanceInsights` Da a `True`
+ Da `PerformanceInsightsRetentionPeriod` ad almeno `465` giorni
------
# Attivazione della modalità standard di Database Insights per Aurora PostgreSQL Limitless Database
Per attivare la modalità standard di Database Insights per Aurora PostgreSQL Limitless Database, utilizza le procedure seguenti.
## Attivazione della modalità standard di Database Insights durante la creazione di un cluster di database per Aurora PostgreSQL Limitless Database
Attiva la modalità standard di Database Insights durante la creazione di un database per Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
Nella console, puoi attivare la modalità standard di Database Insights quando crei un cluster di database. Le impostazioni per Database Insights si applicano a tutte le istanze database nel cluster di database.
**Per attivare la modalità standard di Database Insights durante la creazione di un cluster di database utilizzando la console**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database**.
1. Scegliere **Crea database**.
1. Nella sezione **Database Insights**, seleziona **Modalità standard**. Quindi, scegli le seguenti opzioni:
+ **Retention (Conservazione)** – Quantità di tempo per cui conservare i dati di Performance Insights. Per creare un cluster di database per Aurora PostgreSQL Limitless Database, il periodo di conservazione deve essere di almeno 31 giorni.
+ **AWS KMS key**: specificare la chiave KMS. Performance Insights crittografa tutti i dati potenzialmente sensibili con la chiave KMS. I dati vengono crittografati mentre sono in transito o inattivi. Per ulteriori informazioni, consulta [Crittografia delle risorse Amazon Aurora](Overview.Encryption.md).
1. Scegliere **Crea database**.
------
#### [ AWS CLI ]
Per attivare la modalità standard di Database Insights durante la creazione di un cluster di database, chiama il comando AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) e fornisci i seguenti valori:
+ `--db-cluster-identifier`: l’identificatore del cluster di database.
+ `--database-insights-mode standard` per attivare la modalità standard di Database Insights.
+ `--engine`: il cluster di database deve utilizzare il motore di database `aurora-postgresql`.
+ `--engine-version`: il cluster di database deve utilizzare una delle versioni supportate del motore di database.
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type`: il cluster di database deve utilizzare la configurazione di archiviazione del cluster di database `aurora-iopt1`.
+ `--cluster-scalability-type`: specifica la modalità di scalabilità del cluster di database Aurora. Se impostato su `limitless`, il cluster funziona come Aurora PostgreSQL Limitless Database. Se impostato su `standard` (impostazione predefinita), il cluster utilizza la normale creazione di istanze database.
**Nota**
Non è possibile modificare questa impostazione dopo la creazione del cluster di database.
+ `--master-username`: il nome dell’utente master del cluster di database.
+ `--master-user-password`: la password dell’utente master.
+ `--enable-performance-insights` per attivare Approfondimenti sulle prestazioni per Database Insights.
+ `--performance-insights-retention-period`: il periodo di conservazione dei dati per il cluster di database. Per creare un cluster di database per Aurora PostgreSQL Limitless Database, il periodo di conservazione deve essere di almeno 31 giorni.
+ `--monitoring-interval`: l’intervallo, in secondi, tra i punti di raccolta delle metriche di monitoraggio avanzato per il cluster di database. Questo valore può essere `0`.
+ `--monitoring-role-arn`: il nome della risorsa Amazon (ARN) del ruolo IAM che consente a RDS di inviare le metriche di monitoraggio avanzato ad Amazon CloudWatch Logs.
+ `--enable-cloudwatch-logs-exports`: è necessario esportare i log `postgresql` in CloudWatch Logs.
L’esempio seguente abilita la modalità standard di Database Insights durante la creazione di un cluster di database.
Per Linux, macOS o 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
```
Per 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 ]
Per attivare la modalità standard di Database Insights quando crei , specifica i seguenti parametri per l’operazione API [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) di Amazon RDS.
+ `DatabaseInsightsMode` Da a `standard`
+ `Engine` Da a `aurora-postgresql`
+ Da `EngineVersion` a una versione del motore disponibile per Limitless Database
+ `StorageType` Da a `aurora-iopt1`
+ `ClusterScalabilityType` Da a `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` Da a `True`
+ Da `PerformanceInsightsRetentionPeriod` ad almeno `31` giorni
+ Da `MonitoringInterval` a un valore diverso da `0`
+ Da `MonitoringRoleArn` al nome della risorsa Amazon (ARN) del ruolo IAM che consente a RDS di inviare le metriche di monitoraggio avanzato ad Amazon CloudWatch Logs.
------
## Attivazione della modalità standard di Database Insights durante la modifica di un cluster di database per Aurora PostgreSQL Limitless Database
Attiva Database Insights durante la modifica di un database per Aurora PostgreSQL Limitless Database.
**Nota**
Per abilitare Database Insights, ogni istanza database in un cluster di database deve avere le stesse impostazioni di Approfondimenti sulle prestazioni e Monitoraggio avanzato.
------
#### [ Console ]
Nella console, puoi attivare la modalità standard di Database Insights quando crei un cluster di database. Le impostazioni per Database Insights si applicano a tutte le istanze database nel cluster di database.
**Per attivare la modalità standard di Database Insights durante la modifica di un cluster di database utilizzando la console**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegli **Database**.
1. Scegli un cluster di database e scegli **Modifica**.
1. Nella sezione **Database Insights**, seleziona **Modalità standard**. Quindi, scegli le seguenti opzioni:
+ **Retention (Conservazione)** – Quantità di tempo per cui conservare i dati di Performance Insights. Per creare un cluster di database per Aurora PostgreSQL Limitless Database, il periodo di conservazione deve essere di almeno 31 giorni.
+ **AWS KMS key**: specificare la chiave KMS. Performance Insights crittografa tutti i dati potenzialmente sensibili con la chiave KMS. I dati vengono crittografati mentre sono in transito o inattivi. Per ulteriori informazioni, consulta [Crittografia delle risorse Amazon Aurora](Overview.Encryption.md).
1. Scegli **Continue (Continua)**.
1. In **Scheduling of Modifications (Pianificazione delle modifiche)**, scegliere **Apply immediately (Applica immediatamente)**. Se scegli **Applica durante la prossima finestra di manutenzione pianificata**, il database ignora questa impostazione e attiva immediatamente la modalità standard di Database Insights.
1. Scegli **Modifica cluster**.
------
#### [ AWS CLI ]
Per attivare la modalità standard di Database Insights durante la modifica di un cluster di database, chiama il comando AWS CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) e fornisci i seguenti valori:
+ `--db-cluster-identifier`: l’identificatore del cluster di database.
+ `--database-insights-mode standard` per attivare la modalità standard di Database Insights.
+ `--enable-performance-insights` per attivare Approfondimenti sulle prestazioni per Database Insights.
+ `--performance-insights-retention-period`: il periodo di conservazione dei dati per il cluster di database. Per attivare la modalità standard di Database Insights, il periodo di conservazione deve essere di almeno 31 giorni.
L’esempio seguente abilita la modalità standard di Database Insights durante la modifica di un cluster di database.
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--database-insights-mode standard \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 31
```
Per 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 ]
Per attivare la modalità standard di Database Insights durante la modifica di un cluster di database, specifica i seguenti parametri per l’operazione API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) di Amazon RDS.
+ `DatabaseInsightsMode` Da a `standard`
+ `EnablePerformanceInsights` Da a `True`
+ Da `PerformanceInsightsRetentionPeriod` ad almeno `31` giorni
------
# Monitoraggio di Aurora PostgreSQL Limitless Database con Amazon CloudWatch Logs
L’esportazione dei log di PostgreSQL in CloudWatch Logs è obbligatoria come parte del processo di abilitazione di Aurora PostgreSQL Limitless Database. Puoi accedere e analizzare questi log in CloudWatch Logs Insights, in modo analogo a come accedi ai log di PostgreSQL per un cluster di database Aurora PostgreSQL standard. Per ulteriori informazioni, consulta [Analisi dei registri Aurora PostgreSQL utilizzando approfondimenti sui file di log Amazon CloudWatch](AuroraPostgreSQL.CloudWatch.Analyzing.md).
Il nome del gruppo di log per il cluster di database è lo stesso di Aurora PostgreSQL:
```
/aws/rds/cluster/DB_cluster_ID/postgresql
```
Il nome del gruppo di log per il gruppo di shard del database assume il seguente formato:
```
/aws/rds/cluster/DB_cluster_ID/DB_shard_group_ID/postgresql
```
Esistono flussi di log per ogni nodo (router o shard). Queste espressioni hanno il seguente formato:
```
[DistributedTransactionRouter|DataAccessShard]/node_cluster_serial_ID-node_instance_serial_ID/n
```
Per esempio:
+ Router: `DistributedTransactionRouter/6-6.2`
+ Shard: `DataAccessShard/22-22.0`
**Nota**
Non puoi visualizzare direttamente i file di log di PostgreSQL per il gruppo di shard del database nella console RDS, nella AWS CLI o tramite nell’API RDS, come invece avviene per un cluster di database. Devi utilizzare CloudWatch Logs Insights per visualizzarli.
# Monitoraggio di Aurora PostgreSQL Limitless Database con Monitoraggio avanzato
Monitoraggio avanzato è necessario come parte dell’abilitazione di Aurora PostgreSQL Limitless Database. Puoi usarlo per monitorare il sistema operativo dell’istanza database Limitless Database in tempo reale.
Aurora pubblica le metriche di Monitoraggio avanzato in CloudWatch Logs. Alcune delle metriche principali disponibili includono le connessioni al database, l’utilizzo dell’archiviazione e la latenza delle query. Queste possono aiutare a identificare i colli di bottiglia delle prestazioni.
Per ulteriori informazioni sulle metriche di Monitoraggio avanzato, consulta [Parametri del sistema operativo per Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
# Monitoraggio di Aurora PostgreSQL Limitless Database con Approfondimenti sulle prestazioni
Utilizza Approfondimenti sulle prestazioni per monitorare il cluster Aurora PostgreSQL Limitless Database. Approfondimenti sulle prestazioni funziona in modo simile per Aurora PostgreSQL Limitless Database e per i cluster di database Aurora standard. Tuttavia, monitora le metriche a livello di gruppo di shard per Aurora PostgreSQL Limitless Database.
Le due metriche principali di Approfondimenti sulle prestazioni da monitorare sono le seguenti:
+ Il carico del database: misura il livello di attività nel database. Il parametro chiave in Performance Insights è `DBLoad`, che viene raccolto ogni secondo.
L’unità della metrica `DBLoad` in Approfondimenti sulle prestazioni sono le sessioni attive medie (AAS). Per ottenere le sessioni attive medie (AAS), Performance Insights esegue il campionamento del numero di sessioni che eseguono contemporaneamente una query. L'AAS è il numero totale di sessioni diviso per il numero totale di campioni per un periodo di tempo specifico. Per ulteriori informazioni su `DBLoad` e AAS, consulta [Carico del database](USER_PerfInsights.Overview.ActiveSessions.md).
+ CPU massima: la massima potenza di calcolo disponibile per il database. Per verificare se le sessioni attive superano la CPU massima, esamina la loro relazione con la linea `Max vCPU` massima. Il valore `Max vCPU` massima è determinato dal numero di core vCPU (CPU virtuale) per l’istanza database. Per ulteriori informazioni su `Max vCPU`, consulta [CPU massima](USER_PerfInsights.Overview.MaxCPU.md).
Inoltre, puoi “sezionare” la metrica `DBLoad` in *dimensioni*, che sono sottocategorie della metrica. Le dimensioni più utili sono le seguenti:
+ Istanze principali: mostra il carico del database relativo per le istanze (shard e router) in ordine decrescente.
+ Eventi di attesa: indicano eventi per cui le istruzioni SQL devono attendere prima di poter continuare l’esecuzione. Gli eventi di attesa indicano dove il processo è ostacolato.
+ SQL principale: mostra quali query contribuiscono maggiormente al carico del database.
Per ulteriori informazioni su Approfondimenti sulle prestazioni, consulta [Dimensioni](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions).
La figura seguente mostra la dimensione **Istanze principali** per un gruppo di shard del database.
![\[Dimensione Istanze principali per un gruppo di shard del database.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
**Topics**
+ [
# Analisi del carico del database per Aurora PostgreSQL Limitless Database tramite la dashboard Approfondimenti sulle prestazioni
](USER_PerfInsights.AnalyzeLimitlessTables.md)
# Analisi del carico del database per Aurora PostgreSQL Limitless Database tramite la dashboard Approfondimenti sulle prestazioni
Con Approfondimenti sulle prestazioni, puoi tenere traccia delle metriche a livello di gruppo di shard e a livello di istanza per un database Aurora PostgreSQL Limitless. Quando si analizza il carico di database per un database Aurora PostgreSQL Limitless, è possibile confrontare il carico del DB per ogni shard e router con la vCPU massima.
**Nota**
Aurora PostgreSQL Limitless Database ha sempre abilitato Approfondimenti sulle prestazioni e Monitoraggio avanzato. Il periodo minimo di conservazione dei dati di Approfondimenti sulle prestazioni per Limitless Database è di 31 giorni (1 mese).
La visualizzazione **Assoluto** mostra il numero di sessioni attive medie (AAS) e la vCPU stimata. La visualizzazione **Relativo** mostra il rapporto tra AAS e la vCPU stimata.
**Topics**
+ [
## Analisi del carico di database relativo per Aurora PostgreSQL Limitless Database tramite la dashboard di Approfondimenti sulle prestazioni
](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad)
+ [
# Analisi del carico del database in base alle attese per Aurora PostgreSQL Limitless Database tramite la dashboard Approfondimenti sulle prestazioni
](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md)
+ [
# Analisi della distribuzione del carico per Aurora PostgreSQL Limitless Database tramite la dashboard Approfondimenti sulle prestazioni
](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md)
## Analisi del carico di database relativo per Aurora PostgreSQL Limitless Database tramite la dashboard di Approfondimenti sulle prestazioni
Potresti voler migliorare le prestazioni del tuo database Aurora PostgreSQL Limitless monitorando il carico relativo del database. Per analizzare il carico di database relativo per istanza per il database Aurora PostgreSQL Limitless, utilizzare la procedura seguente.
**Per analizzare il carico relativo del database per Aurora PostgreSQL Limitless Database utilizzando la console**
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione scegli **Approfondimenti sulle prestazioni**.
1. Scegli un database Aurora PostgreSQL Limitless Viene visualizzata la dashboard di Approfondimenti sulle prestazioni per il database Aurora PostgreSQL Limitless.
1. Nella sezione **Carico del database (Carico DB)**, scegli **Istanze** per **Suddivisione per**. Per visualizzare il rapporto tra sessioni attive medie (AAS) e core vCPU per tutte le istanze database Aurora PostgreSQL Limitless, scegli **Relativo** per **Visualizzato come**.
Il grafico Average active sessions (Media delle sessioni attive) mostra il carico di database per le istanze nel database Aurora PostgreSQL Limitless.
![\[Visualizza la dashboard Approfondimenti sulle prestazioni per il tuo database Aurora PostgreSQL Limitless suddiviso per istanze.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png)
1. Per visualizzare le istanze principali, scegli la scheda **Istanze principali**.
Nell’esempio seguente, l’istanza con il carico di database più elevato è `DTR-2-2`.
![\[Utilizza la scheda Istanze principali per un database Aurora PostgreSQL Limitless suddiviso per istanze.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
1. (Facoltativo) Per analizzare il carico di database per un’istanza nel tuo database Aurora PostgreSQL Limitless, scegli il nome dell’istanza nella colonna **Istanze**. Per visualizzare il carico di database per`DTR-2-2`, scegli `DTR-2-2` nella colonna **Istanze**.
**Nota**
È possibile visualizzare le metriche di Approfondimenti sulle prestazioni solo per le istanze in un database Aurora PostgreSQL Limitless.
# Analisi del carico del database in base alle attese per Aurora PostgreSQL Limitless Database tramite la dashboard Approfondimenti sulle prestazioni
Potresti voler migliorare le prestazioni del tuo database Aurora PostgreSQL Limitless monitorando gli eventi di attesa. Per analizzare il carico di database in base agli eventi di attesa per il database Aurora PostgreSQL Limitless, utilizzare la procedura seguente.
**Per analizzare il carico di database in base alle attese di Aurora per il database PostgreSQL Limitless utilizzando la console**
1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione scegli **Performance Insights**.
1. Scegli un database Aurora PostgreSQL Limitless Viene visualizzata la dashboard di Approfondimenti sulle prestazioni per il database Aurora PostgreSQL Limitless.
1. Nella sezione **Carico del database (Carico DB)**, scegli **Attese** per **Suddivisione per**. Per visualizzare il numero di AAS e la vCPU stimata, scegli **Assoluto** per **Visualizzato come**.
Il grafico Average active sessions (Media delle sessioni attive) mostra il carico di database per le istanze nel database Aurora PostgreSQL Limitless.
![\[Suddiviso in base alle attese.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png)
1. Scorri verso il basso fino alla scheda **Top SQL** (Prime istruzioni SQL).
Nell’esempio seguente, l’istruzione SQL con il carico per attese più elevato è l’istruzione `DELETE`.
![\[La scheda Top SQL se suddivisa in base alle attese.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png)
1. Scegli l’istruzione SQL per espanderla nelle istruzioni componenti.
Nell’esempio seguente, l’istruzione `SELECT` ha 3 istruzioni componenti.
![\[Scegli un’istruzione SQL per espanderla.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png)
# Analisi della distribuzione del carico per Aurora PostgreSQL Limitless Database tramite la dashboard Approfondimenti sulle prestazioni
Potresti voler bilanciare la distribuzione del carico per le istanze sul tuo database Aurora PostgreSQL Limitless. Per analizzare la distribuzione del carico delle istanze su un database Aurora PostgreSQL Limitless, utilizzare la procedura seguente.
**Per analizzare la distribuzione del carico delle istanze su un database Aurora PostgreSQL Limitless utilizzando la console**
1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione scegli **Performance Insights**.
1. Scegli un database Aurora PostgreSQL Limitless Viene visualizzata la dashboard di Approfondimenti sulle prestazioni per il database Aurora PostgreSQL Limitless.
1. Nella sezione **Carico del database (Carico DB)**, scegli **Istanze** per **Suddivisione per**. Per visualizzare il numero di AAS e la vCPU stimata per tutte le istanze database Aurora PostgreSQL Limitless, scegli **Assoluto** per **Visualizzato come**.
Il grafico Average active sessions (Media delle sessioni attive) mostra il carico di database per le istanze nel database Aurora PostgreSQL Limitless.
![\[Visualizzare la dashboard di Approfondimenti sulle prestazioni in assoluto per il tuo database Aurora PostgreSQL Limitless suddiviso per istanze.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png)
1. Per visualizzare un grafico della distribuzione del carico delle istanze nel database Aurora PostgreSQL Limitless, scegli la scheda **Distribuzione del carico**.
Nell’esempio seguente, l’istanza con il carico di database più elevato è `DTR-2-2`.
![\[La scheda SQL principale quando si esegue lo slice by waits (suddivisione per attese) a livello di istanza.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png)
# Monitoraggio di Aurora PostgreSQL Limitless Database con la protezione RDS Amazon GuardDuty
Amazon GuardDuty è un servizio di rilevamento delle minacce che aiuta a proteggere gli account, i container, i carichi di lavoro e i dati nell’ambiente AWS. Grazie a modelli di machine learning (ML) e funzionalità di rilevamento di anomalie e minacce, GuardDuty monitora continuamente origini di log e attività di runtime diverse per identificare e dare priorità ai potenziali rischi per la sicurezza e alle attività dannose nell’ambiente.
La protezione RDS GuardDuty analizza e profila gli eventi di accesso per individuare potenziali minacce di accesso ai database Amazon Aurora. Quando attivi la protezione RDS, GuardDuty utilizza gli eventi di accesso RDS dei database Aurora. La protezione RDS monitora questi eventi e li profila per potenziali minacce interne o attori esterni.
Per ulteriori informazioni sulla protezione RDS GuardDuty, consulta [Monitoraggio delle minacce con Amazon GuardDuty RDS Protection per Amazon Aurora](guard-duty-rds-protection.md).
Per maggiori informazioni sull'abilitazione della protezione RDS GuardDuty, consulta [Protezione GuardDuty RDS](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html) nella *Guida per l'utente di Amazon GuardDuty*.
# Funzioni e visualizzazioni per Aurora PostgreSQL Limitless Database
In Aurora PostgreSQL Limitless Database sono state aggiunte funzioni e visualizzazioni. Si basano sulle funzioni e sulle visualizzazioni corrispondenti di Aurora PostgreSQL.
**Nota**
Alcune statistiche possono restituire risultati incoerenti se sono presenti transazioni in corso.
**Topics**
+ [
# Funzioni di Aurora PostgreSQL Limitless Database
](limitless-monitoring-functions.md)
+ [
# Visualizzazioni di Aurora PostgreSQL Limitless Database
](limitless-monitoring-views.md)
# Funzioni di Aurora PostgreSQL Limitless Database
La tabella seguente mostra le nuove funzioni per Aurora PostgreSQL Limitless Database.
**Nota**
Le funzioni elencate in questa tabella si trovano nello schema `rds_aurora`. Quando utilizzi una funzione di Limitless Database, assicurati di includere il nome completo dell’oggetto: `rds_aurora`.`object_name`.
| Funzione di Aurora PostgreSQL Limitless Database | Funzione di Aurora PostgreSQL corrispondente |
| --- | --- |
| [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 |
Gli esempi seguenti forniscono dettagli sulle funzioni di Aurora PostgreSQL Limitless Database. Per ulteriori informazioni sulle funzioni di PostgreSQL, consulta [Functions and operators](https://www.postgresql.org/docs/15/functions.html) nella documentazione di PostgreSQL.
**limitless\$1backend\$1dsid**
La funzione `limitless_backend_dsid` restituisce l’ID di sessione distribuita per la sessione corrente. Una sessione distribuita viene eseguita su un router in un gruppo di shard del database e coinvolge processi di backend su uno o più shard del gruppo di shard del database.
Il seguente esempio illustra come utilizzare la funzione `limitless_backend_dsid`.
```
SELECT rds_aurora.limitless_backend_dsid();
limitless_backend_dsid
------------------------
8CACD7B04D0FC2A5
(1 row)
```
**limitless\$1cancel\$1session**
La funzione `limitless_cancel_session` funziona in modo simile a `pg_cancel_backend`, ma tenta di annullare tutti i processi di backend associati all’ID di sessione distribuita fornito, inviando un `SIGINT` (segnale di interruzione).
Il parametro di input è il seguente:
+ `distributed_session_id` (testo): l’ID della sessione distribuita da annullare.
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `pid` (testo): l’ID del processo di backend.
+ `success` (booleano): indica se l’annullamento è riuscito.
Il seguente esempio illustra come utilizzare la funzione `limitless_cancel_session`.
```
SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1stat\$1clear\$1snapshot**
La funzione `limitless_stat_clear_snapshot` elimina lo snapshot delle statistiche corrente o le informazioni memorizzate nella cache su tutti i nodi.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_clear_snapshot`.
```
SELECT rds_aurora.limitless_stat_clear_snapshot();
```
**limitless\$1stat\$1database\$1size**
La funzione `limitless_stat_database_size` restituisce le dimensioni di un database nel gruppo di shard del database.
Il parametro di input è il seguente:
+ `dbname` (nome): il database per il quale ottenere le dimensioni.
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
+ `db_size`: la dimensione del database in questo cluster secondario in byte.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_database_size`.
```
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**
La funzione `limitless_stat_get_snapshot_timestamp` restituisce il timestamp dello snapshot delle statistiche corrente oppure `NULL` se non è stato acquisito alcuno snapshot. Uno snapshot viene acquisito al primo accesso alle statistiche cumulative in una transazione, se `stats_fetch_consistency` è impostato su `snapshot`. Restituisce una visualizzazione consolidata dei timestamp degli snapshot da tutti i nodi. Le colonne `subcluster_id` e `subcluster_type` mostrano da quale nodo provengono i dati.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_get_snapshot_timestamp`.
```
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**
La funzione `limitless_stat_prepared_xacts` restituisce informazioni sulle transazioni su tutti i nodi attualmente preparati per il commit in due fasi. Per ulteriori informazioni, consulta [pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html) nella documentazione di PostgreSQL.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_prepared_xacts`.
```
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**
La funzione `limitless_stat_relation_sizes` restituisce le diverse dimensioni di una tabella nel gruppo di shard del database.
I parametri di input sono i seguenti:
+ `relnspname` (nome): il nome dello schema contenente la tabella.
+ `relname` (nome): il nome della tabella.
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
+ `main_size`: la dimensione in byte della fork dei dati principale in questo nodo.
+ `fsm_size`: la dimensione in byte della mappa dello spazio libero per la tabella in questo nodo.
+ `vm_size`: la dimensione in byte della mappa di visibilità per la tabella in questo nodo.
+ `init_size`: la dimensione in byte dell’inizializzazione della tabella in questo nodo.
+ `toast_size`: la dimensione in byte della tabella TOAST associata alla tabella in questa forcella.
+ `index_size`: la dimensione in byte di tutti gli indici della tabella in questo nodo.
+ `total_size`: la dimensione in byte di tutti i segmenti della tabella in questo nodo.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_relation_sizes` (alcune colonne sono omesse).
```
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**
La funzione `limitless_stat_reset` azzera tutti i contatori delle statistiche per il database corrente impostandoli su zero (0). Se `track_functions` è abilitato, la colonna `stats_reset` in `limitless_stat_database` mostra l’ultima volta in cui le statistiche sono state reimpostate per il database. Per impostazione predefinita, `limitless_stat_reset` può essere eseguito solo da un utente con privilegi avanzati. È possibile concedere l’autorizzazione ad altri utenti utilizzando il privilegio `EXECUTE`.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_reset`.
```
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**
La funzione `limitless_stat_statements_reset` elimina le statistiche raccolte finora da `limitless_stat_statements` corrispondenti ai parametri `username`, `dbname`, `distributed_query_id` e `queryid` specificati. Se uno qualsiasi dei parametri non è specificato, viene utilizzato il valore predefinito `""` o `0` (non valido) per ciascuno di essi e vengono reimpostate le statistiche che corrispondono agli altri parametri. Se nessun parametro viene specificato o tutti i parametri specificati sono `""` o `0` (non valido), la funzione elimina tutte le statistiche. Se tutte le statistiche nella visualizzazione `limitless_stat_statements` vengono eliminate, la funzione reimposta anche le statistiche nella visualizzazione `limitless_stat_statements_info`.
I parametri di input sono i seguenti:
+ `username` (nome): l’utente che ha eseguito la query sull’istruzione.
+ `dbname` (nome): il database su cui è stata eseguita la query.
+ `distributed_query_id` (bigint): l’ID della query principale proveniente dal nodo coordinatore. Questa colonna è `NULL` se è la query principale. Il nodo coordinatore esegue il push down dell’ID della query distribuita ai nodi partecipanti. Pertanto, per i nodi partecipanti, i valori dell’ID della query distribuita e dell’ID della query principale sono diversi.
+ `queryid` (bigint): l’ID della query dell’istruzione.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_statements_reset` per reimpostare tutte le statistiche raccolte da `limitless_stat_statements`.
```
SELECT rds_aurora.limitless_stat_statements_reset();
```
**limitless\$1stat\$1system\$1waits**
La funzione `limitless_stat_system_waits` restituisce una visualizzazione consolidata dei dati degli eventi di attesa da `aurora_stat_system_waits`, che riporta l’attività di attesa a livello di sistema in un’istanza, da tutti i nodi. Le colonne `subcluster_id` e `subcluster_type` mostrano da quale nodo provengono i dati.
Il seguente esempio illustra come utilizzare la funzione `limitless_stat_system_waits`.
```
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**
La funzione `limitless_terminate_session` funziona in modo simile a `pg_terminate_backend`, ma tenta di terminare tutti i processi di backend associati all’ID di sessione distribuita fornito, inviando un `SIGTERM` (segnale di termine).
Il parametro di input è il seguente:
+ `distributed_session_id` (testo): l’ID della sessione distribuita da terminare.
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `pid` (testo): l’ID del processo di backend.
+ `success` (booleano): indica se il processo è stato terminato correttamente.
Il seguente esempio illustra come utilizzare la funzione `limitless_terminate_session`.
```
SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1wait\$1report**
La funzione `limitless_wait_report` restituisce l’attività degli eventi di attesa di tutti i nodi in un periodo di tempo. Le colonne `subcluster_id` e `subcluster_type` mostrano da quale nodo provengono i dati.
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
Le restanti colonne sono le stesse di `aurora_wait_report`.
Il seguente esempio illustra come utilizzare la funzione `limitless_wait_report`.
```
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
```
# Visualizzazioni di Aurora PostgreSQL Limitless Database
La tabella seguente mostra le nuove visualizzazioni per Aurora PostgreSQL Limitless Database.
**Nota**
Le visualizzazioni elencate in questa tabella si trovano nello schema `rds_aurora`. Quando utilizzi una visualizzazione di Limitless Database, assicurati di includere il nome completo dell’oggetto: `rds_aurora`.`object_name`.
| Visualizzazione di Aurora PostgreSQL Limitless Database | Visualizzazione di Aurora PostgreSQL corrispondente |
| --- | --- |
| [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\$1statements](#limitless_stat_statements) | pg\$1stat\$1statements |
| [limitless\$1stat\$1subclusters](#limitless_stat_subclusters) | Nessuno |
| [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) | Nessuno |
| [limitless\$1table\$1collocation\$1distributions](#limitless_table_collocation_distributions) | Nessuno |
Gli esempi seguenti forniscono dettagli sulle visualizzazioni di Aurora PostgreSQL Limitless Database. Per ulteriori informazioni sulle visualizzazioni di PostgreSQL, consulta [Viewing statistics](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS) nella documentazione di PostgreSQL.
**Nota**
Alcune visualizzazioni statistiche possono restituire risultati incoerenti se sono presenti transazioni in corso.
**limitless\$1database**
Questa visualizzazione contiene informazioni sui database disponibili nel gruppo di shard del database. Per esempio:
```
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}
```
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario (nodo)
+ `subcluster_type` (testo): il tipo di cluster secondario (nodo), router o shard
Le restanti colonne sono le stesse di `pg_database`.
**limitless\$1locks**
Questa visualizzazione contiene una riga per processo per nodo. Fornisce accesso alle informazioni sui blocchi dei processi attivi nel server del database.
**Example di creazione di un blocco con due transazioni**
In questo esempio, eseguiamo due transazioni contemporaneamente su due 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;
```
Viene eseguita la prima transazione. Le transazioni successive devono attendere il completamento della prima transazione. Pertanto la seconda transazione viene bloccata con un blocco. Per verificarne la causa principale, eseguiamo un comando unendo `limitless_locks` e `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 di creazione di un blocco in modo esplicito**
In questo esempio, creiamo un blocco in modo esplicito, quindi utilizziamo la visualizzazione `limitless_locks` per vedere i blocchi (alcune colonne vengono omesse).
```
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**
Questa visualizzazione contiene una riga per processo per nodo. Può essere utilizzata per tenere traccia dell’integrità generale del sistema e identificare processi che richiedono tempi di esecuzione elevati. Per esempio:
```
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)
```
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
+ `distributed_session_id` (testo): l’ID della sessione distribuita a cui appartiene questo processo.
+ `distributed_session_state` (testo): indica se si tratta di processo coordinatore, partecipante o autonomo/non distribuito (mostrato come `NULL`).
+ `datname` (testo): il database a cui è connesso questo processo.
+ `distributed_query_id` (bigint): l’ID della query principale proveniente dal nodo coordinatore. Questa colonna è `NULL` se è la query principale. Il nodo coordinatore esegue il push down dell’ID della query distribuita ai nodi partecipanti. Pertanto, per i nodi partecipanti, i valori dell’ID della query distribuita e dell’ID della query principale sono diversi.
+ `is_sso_query` (testo): indica se la query è ottimizzata per un singolo shard o meno.
Le restanti colonne sono le stesse di `pg_stat_activity`.
**limitless\$1stat\$1all\$1indexes**
Questa visualizzazione contiene statistiche di utilizzo sugli indici nel gruppo di shard del database. Per esempio:
```
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**
Questa visualizzazione contiene statistiche su tutte le tabelle nel database corrente del gruppo di shard del database. È utile per monitorare le operazioni di vacuum e le operazioni DML. Per esempio:
```
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)
```
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
+ `relname` (nome): il nome della tabella.
Le restanti colonne sono le stesse di `pg_stat_all_tables`.
**limitless\$1stat\$1database**
Questa visualizzazione contiene statistiche su tutti i database nel gruppo di shard del database. Restituisce una riga per database per nodo. Per esempio:
```
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)
```
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
+ `datname` (nome): il nome del database.
Le restanti colonne sono le stesse di `pg_stat_database`.
**limitless\$1stat\$1progress\$1vacuum**
Questa visualizzazione contiene informazioni sulle operazioni di vacuum in corso. Per esempio:
```
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
```
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
+ `distributed_session_id` (testo): l’identificatore della sessione che ha avviato l’operazione di vacuum.
+ `datname` (nome): il database in cui viene eseguita l’operazione di vacuum.
+ `nspname` (nome): il nome dello schema della tabella in cui viene eseguita l’operazione di vacuum. È `null` se la tabella non si trova nello stesso database a cui l’utente è connesso.
+ `relname` (nome): il nome della tabella in cui viene eseguita l’operazione di vacuum. È `null` se la tabella non si trova nello stesso database a cui l’utente è connesso.
Le restanti colonne sono le stesse di `pg_stat_progress_vacuum`.
**limitless\$1stat\$1statements**
Questa visualizzazione consente di monitorare le statistiche di pianificazione ed esecuzione di tutte le istruzioni SQL eseguite su tutti i nodi.
Devi installare l’estensione [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) per utilizzare la visualizzazione `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;
```
L’esempio seguente illustra l’utilizzo della visualizzazione `limitless_stat_statements`.
```
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 |
[...]
```
I parametri di output sono i seguenti:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
+ `subcluster_type` (testo): il tipo di cluster secondario a cui appartiene questo processo (`router` o `shard`).
+ `distributedqueryid` (bigint): l’ID della query principale proveniente dal nodo coordinatore. Questa colonna è `NULL` se è la query principale. Il nodo coordinatore esegue il push down dell’ID della query distribuita ai nodi partecipanti. Pertanto, per i nodi partecipanti, i valori dell’ID della query distribuita e dell’ID della query principale sono diversi.
+ `username` (nome): l’utente che ha eseguito la query sull’istruzione.
+ `dbname` (nome): il database su cui è stata eseguita la query.
+ `sso_calls` (nome): il numero di volte in cui la dichiarazione è stata ottimizzata per singolo shard.
Le restanti colonne sono le stesse di [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html).
**limitless\$1stat\$1statements\$1info**
Questa visualizzazione contiene le statistiche relative alla visualizzazione `limitless_stat_statements`. Ogni riga contiene i dati per la visualizzazione [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) di ciascun nodo. La colonna `subcluster_id` identifica ogni nodo.
```
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)
```
Il parametro di output è il seguente:
+ `subcluster_id` (testo): l’ID del cluster secondario a cui appartiene il processo.
Le restanti colonne sono le stesse di [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7).
**limitless\$1stat\$1subclusters**
Questa visualizzazione contiene statistiche di rete tra router e altri nodi. Contiene una riga per coppia di router e altro nodo, ad esempio:
```
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
```
I parametri di output sono i seguenti:
+ `orig_subcluster` (testo): l’ID del router da cui originano le comunicazioni.
+ `orig_subcluster_az` (testo): la zona di disponibilità (AZ) del router di origine.
+ `dest_subcluster` (testo): l’ID del nodo di destinazione.
+ `dest_subcluster_az` (testo): l’ultima AZ raccolta del nodo di destinazione.
+ `latency_us` (bigint): l’ultima latenza di rete raccolta tra i nodi, in microsecondi. Il valore è `0` se il nodo non è raggiungibile.
+ `latest_collection` (timestamp): il timestamp dell’ultima raccolta di AZ e latenza per il nodo di destinazione.
+ `failed_requests` (bigint): il conteggio cumulativo delle richieste interne non riuscite.
+ `received_bytes` (bigint): il numero cumulativo stimato di byte ricevuti da questo nodo.
+ `sent_bytes` (bigint): il numero cumulativo stimato di byte inviati a questo nodo.
+ `same_az_requests` (bigint): il numero cumulativo di richieste database interne verso questo nodo quando è nella stessa AZ del router di origine.
+ `cross_az_requests` (bigint): il numero cumulativo di richieste database interne verso questo nodo quando è in una AZ diversa dal router di origine.
+ `stat_reset_timestamp` (timestamp): il timestamp dell’ultimo ripristino delle statistiche cumulative per questa visualizzazione.
**limitless\$1statio\$1all\$1indexes**
Questa visualizzazione contiene statistiche di input/output (I/O) per tutti gli indici nel gruppo di shard del database. Per esempio:
```
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**
Questa visualizzazione contiene statistiche di input/output (I/O) per tutte le tabelle nel gruppo di shard del database. Per esempio:
```
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**
Questa visualizzazione contiene informazioni sulle tabelle in 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**
Questa visualizzazione contiene informazioni sulle tabelle sottoposte a sharding co-localizzate.
Nell’esempio seguente, le tabelle `orders` e `customers` sono collocate congiuntamente e le tabelle `users` e `followers` sono co-localizzate. Le tabelle co-localizzate hanno lo stesso `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**
Questa visualizzazione mostra la distribuzione delle chiavi per ogni co-localizzazione.
```
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)
```
# Eventi di attesa per Aurora PostgreSQL Limitless Database
In Aurora PostgreSQL, un evento di attesa indica una risorsa per la quale una sessione è in attesa, ad esempio input/output (I/O) e blocchi. Gli eventi di attesa sono utili per scoprire perché le sessioni restano in attesa di risorse e per individuare i colli di bottiglia. Per ulteriori informazioni, consulta [Eventi di attesa Aurora PostgreSQL](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.waits).
Aurora PostgreSQL Limitless Database include eventi di attesa specifici relativi a router e shard. Molti di questi riguardano router in attesa che gli shard completino determinate attività. Gli eventi di attesa degli shard contengono dettagli sulle attività in corso.
**Topics**
+ [
## Esecuzione di query sugli eventi di attesa
](#limitless-monitoring-waits.query)
+ [
# Eventi di attesa Limitless Database
](limitless-waits-reference.md)
## Esecuzione di query sugli eventi di attesa
Puoi utilizzare la visualizzazione [limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) per eseguire query sugli eventi di attesa, come mostrato nell’esempio seguente.
```
SELECT wait_event FROM rds_aurora.limitless_stat_activity WHERE wait_event_type='AuroraLimitless';
wait_event
----------------------
RemoteStatementSetup
RemoteStatementSetup
(2 rows)
```
Puoi inoltre utilizzare la funzione `aurora_stat_system_waits` per elencare il numero di attese e il tempo totale trascorso per ogni evento di attesa, come mostrato nell’esempio seguente.
```
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)
```
# Eventi di attesa Limitless Database
I seguenti eventi di attesa si applicano ad Aurora PostgreSQL Limitless Database. È possibile monitorare questi eventi di attesa per identificare i colli di bottiglia nell’elaborazione del database Aurora PostgreSQL Limitless.
**Topics**
+ [
## IO:TwophaseFilePoolWrite, evento di attesa
](#limitless-waits-TwophaseFilePoolWrite)
+ [
## IO:TwophaseFilePoolRead, evento di attesa
](#limitless-waits-TwophaseFilePoolRead)
+ [
## Evento di attesa AuroraLimitless:Connect
](#limitless-waits-Connect)
+ [
## Evento di attesa AuroraLimitless:AsyncConnect
](#limitless-waits-AsyncConnect)
+ [
## Evento di attesa AuroraLimitless:RemoteStatementSetup
](#limitless-waits-RemoteStatementSetup)
+ [
## Evento di attesa AuroraLimitless:RemoteDDLExecution
](#limitless-waits-RemoteDDLExecution)
+ [
## Evento di attesa AuroraLimitless:RemoteStatementExecution
](#limitless-waits-RemoteStatementExecution)
+ [
## AuroraLimitless:FetchRemoteResults, evento di attesa
](#limitless-waits-FetchRemoteResults)
+ [
## Evento di attesa AuroraLimitless:AsyncGetInitialResponse
](#limitless-waits-AsyncGetInitialResponse)
+ [
## Evento di attesa AuroraLimitless:AsyncGetNextResponse
](#limitless-waits-AsyncGetNextResponse)
+ [
## Evento di attesa AuroraLimitless:AbortedCommandCleanup
](#limitless-waits-AbortedCommandCleanup)
+ [
## Evento di attesa AuroraLimitless:DistributedCommitPrepare
](#limitless-waits-DistributedCommitPrepare)
+ [
## Evento di attesa AuroraLimitless:DistributedCommit
](#limitless-waits-DistributedCommit)
+ [
## Evento di attesa AuroraLimitless:DistributedCommitPrepareThrottle
](#limitless-waits-DistributedCommitPrepareThrottle)
+ [
## Evento di attesa AuroraLimitless:PreparedTransactionResolution
](#limitless-waits-PreparedTransactionResolution)
+ [
## Evento di attesa AuroraLimitless:SendPreparedTransactionOutcome
](#limitless-waits-SendPreparedTransactionOutcome)
+ [
## Evento di attesa AuroraLimitless:CommitClockBarrier
](#limitless-waits-CommitClockBarrier)
+ [
## Evento di attesa AuroraLimitless:SnapshotClockBarrier
](#limitless-waits-SnapshotClockBarrier)
+ [
## Evento di attesa AuroraLimitless:ReaderSnapshotClockBarrier
](#limitless-waits-ReaderSnapshotClockBarrier)
+ [
## Evento di attesa AuroraLimitless:GatherDistributedDeadlockGraph
](#limitless-waits-GatherDistributedDeadlockGraph)
+ [
## Evento di attesa AuroraLimitless:DistributedDeadlockDetection
](#limitless-waits-DistributedDeadlockDetection)
+ [
## Evento di attesa AuroraLimitless:DistributedDeadlockAbort
](#limitless-waits-DistributedDeadlockAbort)
+ [
## Evento di attesa AuroraLimitless:GatherRemoteStats
](#limitless-waits-GatherRemoteStats)
+ [
## Evento di attesa AuroraLimitless:GlobalSequenceRefresh
](#limitless-waits-GlobalSequenceRefresh)
+ [
## Evento di attesa AuroraLimitless:GlobalVacuumTimeExchange
](#limitless-waits-GlobalVacuumTimeExchange)
+ [
## Evento di attesa AuroraLimitless:DistributedTransactionMonitorGather
](#limitless-waits-DistributedTransactionMonitorGather)
+ [
## Evento di attesa AuroraLimitlessActivity:AdminTaskSchedulerMain
](#limitless-waits-AdminTaskSchedulerMain)
+ [
## Evento di attesa AuroraLimitlessActivity:AdminTaskExecutorMain
](#limitless-waits-AdminTaskExecutorMain)
+ [
## Evento di attesa AuroraLimitlessActivity:AdminTaskMonitorMain
](#limitless-waits-AdminTaskMonitorMain)
+ [
## Evento di attesa AuroraLimitlessActivity:DatabaseCleanupMonitorMain
](#limitless-waits-DatabaseCleanupMonitorMain)
+ [
## Evento di attesa AuroraLimitlessActivity:TopologyCleanupMonitorMain
](#limitless-waits-TopologyCleanupMonitorMain)
+ [
## Evento di attesa AuroraLimitlessActivity:ToplogyChangeMonitorMain
](#limitless-waits-ToplogyChangeMonitorMain)
+ [
## Evento di attesa AuroraLimitlessActivity:DistributedTransactionMonitorMain
](#limitless-waits-DistributedTransactionMonitorMain)
+ [
## Evento di attesa AuroraLimitlessActivity:GlobalVacuumMonitorMain
](#limitless-waits-GlobalVacuumMonitorMain)
## IO:TwophaseFilePoolWrite, evento di attesa
In attesa della scrittura di un file di stato in due fasi all’interno del pool di file di stato in due fasi. Questo è un evento specifico di Aurora.
### Cause
I processi che eseguono un `PREPARED TRANSACTION` comando, inclusi i partecipanti a una transazione distribuita con Limitless Database, devono mantenere lo stato della transazione in un file a due fasi. Aurora utilizza un pool di file per migliorare le prestazioni di questa operazione.
### Azione
Si tratta di un’operazione di I/O di scrittura sincrona e pertanto un’elevata latenza in questo evento ha cause simili `IO:XactSync` e può essere esaminata allo stesso modo. Se si utilizza Limitless Database, potrebbe essere necessario ridurre il numero di transazioni distribuite eseguite.
## IO:TwophaseFilePoolRead, evento di attesa
In attesa di una lettura di un file di stato in due fasi all’interno del pool di file di stato in due fasi.
### Cause
I processi che eseguono un `COMMIT PREPARED` comando su una transazione preparata in precedenza, inclusi i partecipanti a una transazione distribuita da Limitless Database, potrebbero dover leggere lo stato della transazione precedentemente persistente da un file a due fasi. Aurora utilizza un pool di file per migliorare le prestazioni di questa operazione.
### Azione
Questa è un’operazione di I/O di lettura. Pertanto, un’elevata latenza in questo evento ha cause simili `IO:DataFileRead` e può essere studiata allo stesso modo. Se si utilizza Limitless Database, potrebbe essere necessario ridurre il numero di transazioni distribuite eseguite.
## Evento di attesa AuroraLimitless:Connect
Il processo è in attesa che venga stabilita una connessione a un altro nodo del cluster.
### Cause
Vengono stabilite connessioni tra processi e nodi remoti per eseguire query, transazioni distribuite ed eseguire DDL.
### Azione
Riduci il numero di connessioni simultanee al cluster o ottimizza l’uso delle query cross-shard.
## Evento di attesa AuroraLimitless:AsyncConnect
Questo evento è simile a`Connect`, ma rappresenta un processo in attesa che vengano stabilite connessioni parallele a un insieme di nodi.
### Cause
La creazione di connessioni parallele viene eseguita più comunemente durante l’esecuzione di istruzioni DDL.
### Azione
Riduci il numero di istruzioni DDL o combina più DDL nella stessa sessione per migliorare il riutilizzo della connessione.
## Evento di attesa AuroraLimitless:RemoteStatementSetup
Il processo è in attesa della configurazione dell’esecuzione remota delle query, ad esempio l’apertura, la chiusura del cursore o la creazione di istruzioni preparate.
### Cause
Questo evento di attesa aumenta con il numero di scansioni su tabelle frammentate in cui l’istruzione non può essere ottimizzata per un singolo shard.
### Azione
Ottimizza le query per ridurre il numero di operazioni di scansione o aumentare l’idoneità all’ottimizzazione a shard singolo.
## Evento di attesa AuroraLimitless:RemoteDDLExecution
Il processo è in attesa del completamento di un comando DDL remoto.
### Cause
Quando si esegue un comando DDL su un gruppo di shard DB, è necessario distribuirlo ad altri router e nodi shard prima di confermare l’operazione. Alcune operazioni DDL possono essere eseguite a lungo, poiché i dati devono essere adattati alle modifiche dello schema.
### Azione
Identifica i comandi DDL a esecuzione prolungata in modo da poterli ottimizzare.
## Evento di attesa AuroraLimitless:RemoteStatementExecution
Un processo è in attesa del completamento di un comando remoto.
### Cause
Un comando SQL è in esecuzione su un nodo remoto. Questo evento verrà visualizzato frequentemente per le comunicazioni interne, ad esempio per i `auto_analyze` controlli del battito cardiaco.
### Azione
Identifica i comandi a esecuzione prolungata utilizzando la vista limitless\$1stat\$1statements. In molti casi si tratta di un evento previsto, specialmente per i lavoratori in background o i processi interni, e non è necessaria alcuna azione.
## AuroraLimitless:FetchRemoteResults, evento di attesa
Un processo è in attesa di recuperare le righe da un nodo remoto.
### Cause
Questo evento di attesa può aumentare quando si recupera un numero elevato di righe da una tabella remota, ad esempio una tabella frammentata o di riferimento.
### Azione
Identifica le `SELECT` query non ottimizzate utilizzando la vista. `limitless_stat_statements` Ottimizza le query per recuperare solo i dati necessari. Non è possibile specificare anche il parametro `rds_aurora.limitless_maximum_adaptive_fetch_size`.
## Evento di attesa AuroraLimitless:AsyncGetInitialResponse
Il processo è in attesa di una risposta iniziale quando viene utilizzata la modalità pipeline nell’esecuzione delle query.
### Cause
Ciò si verifica in genere durante l’esecuzione di router to shard per le query con posizionamento di dati a frammento singolo ed è una parte prevista della normale esecuzione.
### Azione
Non è richiesta alcuna operazione aggiuntiva.
## Evento di attesa AuroraLimitless:AsyncGetNextResponse
Il processo è in attesa di risposte aggiuntive quando si utilizza la modalità pipeline nell’esecuzione delle query.
### Cause
Ciò si verifica in genere durante l’esecuzione di router to shard per le query con posizionamento di dati a frammento singolo ed è una parte prevista della normale esecuzione.
### Azione
Non è richiesta alcuna operazione aggiuntiva.
## Evento di attesa AuroraLimitless:AbortedCommandCleanup
Il processo è in attesa del risultato di una query di pulizia remota. Le query di pulizia vengono inviate ai nodi shard per riportarli allo stato appropriato al termine di una transazione distribuita.
### Cause
La pulizia delle transazioni viene eseguita quando una transazione viene interrotta perché è stato rilevato un errore o perché un utente ha chiamato un comando ABORT esplicito o ha annullato la query in esecuzione.
### Azione
Indagate sulla causa dell’annullamento della transazione.
## Evento di attesa AuroraLimitless:DistributedCommitPrepare
Il processo sta eseguendo una transazione distribuita ed è in attesa che tutti i partecipanti confermino il comando prepare.
### Cause
Le transazioni che modificano più nodi devono eseguire un commit distribuito. Una lunga attesa `DistributedCommitPrepare` potrebbe essere causata da lunghe attese nell’`IO:TwophaseFilePoolWrite`evento sui nodi partecipanti.
### Azione
Riduci il numero di transazioni che modificano i dati su più nodi. Analizza `IO:TwophaseFilePoolWrite` gli eventi in altri nodi del cluster.
## Evento di attesa AuroraLimitless:DistributedCommit
Il processo sta commettendo una transazione distribuita ed è in attesa che il partecipante principale confermi il comando di commit.
### Cause
Le transazioni che modificano più nodi devono eseguire un commit distribuito. Una lunga attesa `DistributedCommit` potrebbe essere causata da lunghe attese nell’`IO:XactSync`evento da parte del partecipante principale.
### Azione
Riduci il numero di transazioni che modificano i dati su più nodi. Analizza `IO:XactSync` gli eventi in altri nodi del cluster.
## Evento di attesa AuroraLimitless:DistributedCommitPrepareThrottle
Il processo sta tentando di preparare una transazione distribuita e viene rallentato a causa delle transazioni preparate esistenti.
### Cause
Le transazioni che modificano più nodi devono eseguire un commit distribuito. I partecipanti a queste transazioni devono eseguire un’operazione di preparazione come parte del protocollo di commit. Aurora limita il numero di preparazioni simultanee e, se questo limite viene superato, il processo attenderà l’evento. `DistributedCommitPrepareThrottle`
### Azione
Riduci il numero di transazioni che modificano i dati su più nodi. Esamina `IO:TwophaseFilePoolWrite` gli eventi, poiché il prolungamento del tempo trascorso in tali eventi potrebbe causare l’accumulo di transazioni preparate esistenti, con conseguente limitazione (della larghezza di banda della rete) per i nuovi tentativi di preparazione.
## Evento di attesa AuroraLimitless:PreparedTransactionResolution
Il processo ha rilevato una tupla modificata da una transazione distribuita che si trova nello stato preparato. Il processo deve determinare se la transazione distribuita diventerà visibile nella relativa istantanea.
### Cause
Le transazioni che modificano più nodi devono eseguire un commit distribuito che include una fase di preparazione. Un numero elevato di transazioni distribuite o una maggiore latenza sui commit distribuiti possono causare l’evento di `PreparedTransactionResolution` attesa in altri processi.
### Azione
Riduci il numero di transazioni che modificano i dati su più nodi. Analizzate gli eventi relativi al commit distribuito, in quanto l’aumento del tempo trascorso in tali eventi potrebbe aumentare la latenza nel percorso di commit delle transazioni distribuite. Potresti anche voler esaminare i carichi di rete e della CPU.
## Evento di attesa AuroraLimitless:SendPreparedTransactionOutcome
Il processo viene eseguito su un nodo che coordina una transazione distribuita e un altro processo ha richiesto informazioni sullo stato di tale transazione oppure il processo ha eseguito una transazione distribuita e invia il risultato ai partecipanti.
### Cause
I processi che riscontrano l’evento di `PreparedTransactionResolution` attesa interrogheranno il coordinatore della transazione. La risposta sul coordinatore della transazione incontrerà SendPreparedTransactionOutcome.
### Azione
Riduci il numero di transazioni che modificano i dati su più nodi. Analizza gli eventi `IO:TwophaseFilePoolWrite` e `IO:TwophaseFilePoolRead` gli eventi relativi al commit distribuito, poiché tali eventi potrebbero aumentare la latenza nel percorso di commit delle transazioni distribuite. Potresti anche voler esaminare i carichi di rete e della CPU.
## Evento di attesa AuroraLimitless:CommitClockBarrier
Il processo sta eseguendo una transazione e deve attendere per garantire che il tempo di commit assegnato sia garantito come passato per tutti i nodi del cluster.
### Cause
La saturazione della CPU o della rete potrebbe causare un aumento della deriva del clock, con conseguente tempo impiegato in questo evento di attesa.
### Azione
Analizza la saturazione della CPU o della rete nel cluster.
## Evento di attesa AuroraLimitless:SnapshotClockBarrier
Il processo ha ricevuto un’istantanea dell’ora da un altro nodo con un orologio del futuro ed è in attesa che il proprio orologio raggiunga quell’ora.
### Cause
Ciò si verifica in genere dopo che il processo ha ricevuto i risultati da una funzione che è stata trasferita su uno shard e si è verificata una variazione dell’orologio tra i nodi. La saturazione della CPU o della rete potrebbe causare un aumento della deriva del clock, con conseguente tempo impiegato in questo evento di attesa.
### Azione
Analizza la saturazione della CPU o della rete nel cluster.
## Evento di attesa AuroraLimitless:ReaderSnapshotClockBarrier
Questo evento si verifica sui nodi di lettura. Il processo è in attesa che il nodo di lettura riproduca il flusso di scrittura in modo che tutte le scritture avvenute prima dell’ora dell’istantanea del processo siano state applicate.
### Cause
Un aumento del ritardo della replica di Aurora può causare un aumento del tempo di attesa in questo evento.
### Azione
Indaga sul ritardo della replica di Aurora.
## Evento di attesa AuroraLimitless:GatherDistributedDeadlockGraph
Il processo sta comunicando con altri nodi per raccogliere grafici di blocco come parte del rilevamento distribuito dei deadlock.
### Cause
Quando un processo è in attesa di un blocco, eseguirà un controllo di deadlock distribuito dopo aver atteso più di. `rds_aurora.limitless_distributed_deadlock_timeout`
### Azione
Analizzate le cause della contrapposizione dei blocchi nella vostra applicazione e valutate la possibilità di ottimizzarla. `rds_aurora.limitless_distributed_deadlock_timeout`
## Evento di attesa AuroraLimitless:DistributedDeadlockDetection
Il processo sta comunicando con altri nodi per rilevare un deadlock distribuito.
### Cause
Quando un processo è in attesa di un blocco, eseguirà un controllo di deadlock distribuito dopo aver atteso più di. `rds_aurora.limitless_distributed_deadlock_timeout`
### Azione
Analizzate le cause della contrapposizione dei blocchi nella vostra applicazione e valutate la possibilità di ottimizzarla. `rds_aurora.limitless_distributed_deadlock_timeout`
## Evento di attesa AuroraLimitless:DistributedDeadlockAbort
Il processo sta comunicando con un altro nodo per interrompere una sessione scelta come vittima in un deadlock distribuito.
### Cause
I modelli di applicazione danno luogo a situazioni di stallo distribuite.
### Azione
Analizzate i modelli di applicazione che determinano situazioni di stallo distribuite.
## Evento di attesa AuroraLimitless:GatherRemoteStats
Il processo sta raccogliendo statistiche da altri nodi del cluster.
### Cause
Il monitoraggio delle nostre attività, le query e le visualizzazioni, ad esempio`limitless_stat_activity`, recupereranno le statistiche da altri nodi.
### Azione
Non è richiesta alcuna operazione aggiuntiva.
## Evento di attesa AuroraLimitless:GlobalSequenceRefresh
Il processo sta generando un nuovo valore di sequenza e deve richiedere un nuovo blocco dalla sequenza globale.
### Cause
In questo caso, un’elevata velocità di generazione del valore di sequenza può causare uno stallo se `rds_aurora.limitless_sequence_chunk_size` è insufficiente.
### Azione
Si tratta di un evento normale. Se in questo caso il tempo a disposizione è eccessivo, valuta la possibilità di effettuare la sintonizzazione. `rds_aurora.limitless_sequence_chunk_size` Consulta la documentazione sulle sequenze in Limitless Database.
## Evento di attesa AuroraLimitless:GlobalVacuumTimeExchange
Il processo consiste nello scambio di dati istantanei per supportare il vuoto.
### Cause
I nodi di Limitless Database scambiano i dati temporali più vecchi relativi alle istantanee attive con altri nodi per calcolare l’ora limite corretta per l’esecuzione sotto vuoto.
### Azione
Non è richiesta alcuna operazione aggiuntiva.
## Evento di attesa AuroraLimitless:DistributedTransactionMonitorGather
Il processo sta raccogliendo i metadati delle transazioni da altri nodi per supportare la pulizia distribuita delle transazioni.
### Cause
I nodi di Limitless Database scambiano i metadati delle transazioni con altri nodi per determinare quando è possibile eliminare lo stato della transazione distribuita.
### Azione
Non è richiesta alcuna operazione aggiuntiva.
## Evento di attesa AuroraLimitlessActivity:AdminTaskSchedulerMain
Attesa nel ciclo principale del processo di pianificazione delle attività.
## Evento di attesa AuroraLimitlessActivity:AdminTaskExecutorMain
Attesa nel ciclo principale del processo di esecuzione delle attività.
## Evento di attesa AuroraLimitlessActivity:AdminTaskMonitorMain
Attesa nel ciclo principale del processo di monitoraggio delle attività.
## Evento di attesa AuroraLimitlessActivity:DatabaseCleanupMonitorMain
Attesa nel ciclo principale del processo di monitoraggio della pulizia del database.
## Evento di attesa AuroraLimitlessActivity:TopologyCleanupMonitorMain
Attesa nel ciclo principale del processo di monitoraggio della pulizia della topologia.
## Evento di attesa AuroraLimitlessActivity:ToplogyChangeMonitorMain
Attesa nel ciclo principale del processo di monitoraggio delle modifiche alla topologia.
## Evento di attesa AuroraLimitlessActivity:DistributedTransactionMonitorMain
Attesa nel ciclo principale del processo di monitoraggio distribuito delle transazioni.
## Evento di attesa AuroraLimitlessActivity:GlobalVacuumMonitorMain
Attesa nel ciclo principale del processo globale di monitoraggio del vuoto.
# Costruire per l'efficienza con le funzioni
Le funzioni definite dall'utente non sono ottimizzate a shard singolo per impostazione predefinita, ma possono essere configurate per essere eseguite come operazioni a shard singolo. Le funzioni possono incapsulare la logica e garantire che venga eseguita in modo ottimizzato per un singolo shard.
## Perché le operazioni a shard singolo sono importanti
L'utilizzo delle risorse è importante per le prestazioni e l'efficienza dei costi. Le operazioni a shard singolo utilizzano un numero significativamente inferiore di risorse rispetto alle operazioni con shard incrociati. Ad esempio, quando si esegue una funzione per inserire un milione di righe, l'esecuzione single-shard utilizza circa 90,5 ACUs rispetto ai 126,5 ACUs per l'esecuzione cross-shard, con un miglioramento del 35% dell'efficienza delle risorse.
L'esecuzione a shard singolo fornisce inoltre:
+ Throughput superiore del 35% rispetto alle operazioni cross-shard
+ Tempi di risposta più prevedibili
+ Migliore scalabilità man mano che i dati crescono
## Operazioni e funzioni a shard singolo
Le funzioni vengono eseguite sugli shard quando viene soddisfatto uno di questi prerequisiti:
+ La funzione viene creata come immutabile e inclusa in una query ottimizzata a shard singolo
+ La funzione è distribuita da un utente
Le funzioni eseguite sugli shard offrono prestazioni e scalabilità migliori perché vengono eseguite dove si trovano i dati.
## Funzioni e volatilità
Per verificare la volatilità di una funzione, usa questa query sulle tabelle di sistema di PostgreSQL:
```
SELECT DISTINCT nspname, proname, provolatile
FROM pg_proc PRO
JOIN pg_namespace NSP ON PRO.pronamespace = NSP.oid
WHERE proname IN ('random', 'md5');
```
Output di esempio:
```
nspname | proname | provolatile
------------+---------+-------------
pg_catalog | md5 | i
pg_catalog | random | v
(2 rows)
```
In questo esempio, `md5()` è immutabile ed è volatile. `random()` Ciò significa che un'istruzione ottimizzata per shard singolo che include `md5()` rimane ottimizzata per shard singolo, mentre un'istruzione che include no. `random()`
Esempio con funzione immutabile:
```
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)
```
Esempio con funzione 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)
```
L'output mostra che `md5()` viene premuto ed eseguito come ottimizzato per shard singolo, mentre non lo è. `random()`
## Funzioni di distribuzione
Una funzione che accede ai dati su un solo shard deve essere eseguita su quello shard per ottenere vantaggi in termini di prestazioni. La funzione deve essere distribuita e la firma della funzione deve includere la chiave shard completa: tutte le colonne della chiave shard devono essere passate come parametri alla funzione.
Funzione di esempio:
```
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;
```
Prima della distribuzione, la funzione non è ottimizzata per un singolo shard:
```
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)
```
Per distribuire la funzione:
```
SELECT rds_aurora.limitless_distribute_function(
's1.func1(bigint,bigint,character)',
ARRAY['param_a','param_b','param_c'],
's1.t1'
);
```
Dopo la distribuzione, la funzione è ottimizzata per shard singolo:
```
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)
```
Puoi confermare l'ottimizzazione a shard singolo controllando la colonna in: `sso_calls` `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)
```
## Funzioni e modelli di efficienza
L'esecuzione della logica in prossimità dei dati è più efficiente e le funzioni svolgono un ruolo chiave a tal fine. Esistono due casi d'uso principali per migliorare l'efficienza delle funzioni:
1. Estrazione della chiave shard da dati complessi per richiamare una funzione ottimizzata a shard singolo separata
1. Trasformazione dei carichi di lavoro cross-shard in single-shard ottimizzati separando la logica cross-shard dalle istruzioni ottimizzate a shard singolo
### Estrazione della chiave shard da dati complessi
Consideriamo una funzione con firma `s3.func3(p_json_doc json)` che esegue diverse operazioni sul database. Queste operazioni verranno eseguite su tutti gli shard all'interno di una transazione che si estende su tutti gli shard. Se il documento JSON contiene la chiave shard, puoi creare una funzione ottimizzata per shard singolo per eseguire le operazioni del database.
Modello originale:
```
s3.func3(p_json_doc json)
database operation 1;
database operation 2;
database operation 3;
```
Pattern ottimizzato:
```
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;
```
Dove funziona la funzione interna:
```
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;
```
In questo modello, la chiave shard è incapsulata in un tipo di dati complesso o deducibile da altri parametri. La logica, l'accesso ai dati e le funzioni possono determinare, estrarre o costruire la chiave shard, quindi richiamare una funzione ottimizzata per shard singolo che esegue operazioni su un solo shard. Poiché l'interfaccia dell'applicazione non cambia, l'ottimizzazione è relativamente facile da testare.
### Rimandare la chiave shard da altre funzioni o dati
Un altro modello di progettazione si applica quando la logica o l'accesso ai dati calcola o determina la chiave shard. Ciò è utile quando una funzione può essere eseguita su un singolo shard per la maggior parte delle chiamate, ma occasionalmente richiede l'esecuzione tra shard.
Modello originale:
```
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;
```
Modello ottimizzato con funzioni separate:
```
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';
```
Quindi fai in modo che la funzione principale chiami la versione ottimizzata per shard singolo o per shard incrociato:
```
IF all_whid_local THEN
SELECT NEWORD_sso(…) INTO no_s_quantity;
ELSE
SELECT NEWORD_crosshard(…) INTO no_s_quantity;
END IF;
```
Questo approccio consente alla maggior parte delle chiamate di trarre vantaggio dall'ottimizzazione a shard singolo mantenendo al contempo il comportamento corretto nei casi che richiedono l'esecuzione su shard incrociati.
## Verifica delle operazioni a shard singolo
Utilizzato `EXPLAIN` per verificare se un'istruzione è ottimizzata per shard singolo. L'output riporta esplicitamente «Single Shard Optimized» per operazioni ottimizzate.
Invocazione Cross-shard prima della distribuzione:
```
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
```
Invocazione a shard singolo dopo la distribuzione:
```
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
```
La differenza nei tempi di esecuzione dimostra i vantaggi in termini di prestazioni dell'ottimizzazione a shard singolo.