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à.
# Riferimenti relativi alle funzioni Aurora PostgreSQL
Di seguito, è possibile trovare un elenco delle funzioni Aurora PostgreSQL disponibili per i cluster Aurora DB che eseguono il motore di database dell’edizione compatibile con Aurora PostgreSQL. Queste funzioni Aurora PostgreSQL sono in aggiunta alle funzioni standard PostgreSQL. Per ulteriori informazioni sulle funzioni PostgreSQL standard, consulta [PostgreSQL: funzioni e operatori](https://www.postgresql.org/docs/current/functions.html).
## Panoramica di
È possibile utilizzare le seguenti funzioni per le istanze database Amazon RDS che eseguono Aurora PostgreSQL:
+ [aurora\$1db\$1instance\$1identifier](aurora_db_instance_identifier.md)
+ [aurora\$1ccm\$1status](aurora_ccm_status.md)
+ [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md)
+ [aurora\$1global\$1db\$1status](aurora_global_db_status.md)
+ [aurora\$1list\$1builtins](aurora_list_builtins.md)
+ [aurora\$1replica\$1status](aurora_replica_status.md)
+ [aurora\$1stat\$1activity](aurora_stat_activity.md)
+ [aurora\$1stat\$1backend\$1waits](aurora_stat_backend_waits.md)
+ [aurora\$1stat\$1bgwriter](aurora_stat_bgwriter.md)
+ [aurora\$1stat\$1database](aurora_stat_database.md)
+ [aurora\$1stat\$1dml\$1activity](aurora_stat_dml_activity.md)
+ [aurora\$1stat\$1get\$1db\$1commit\$1latency](aurora_stat_get_db_commit_latency.md)
+ [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)
+ [aurora\$1stat\$1memctx\$1usage](aurora_stat_memctx_usage.md)
+ [aurora\$1stat\$1optimized\$1reads\$1cache](aurora_stat_optimized_reads_cache.md)
+ [aurora\$1stat\$1plans](aurora_stat_plans.md)
+ [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md)
+ [aurora\$1stat\$1statements](aurora_stat_statements.md)
+ [aurora\$1stat\$1system\$1waits](aurora_stat_system_waits.md)
+ [aurora\$1stat\$1wait\$1event](aurora_stat_wait_event.md)
+ [aurora\$1stat\$1wait\$1type](aurora_stat_wait_type.md)
+ [aurora\$1version](aurora_version.md)
+ [aurora\$1volume\$1logical\$1start\$1lsn](aurora_volume_logical_start_lsn.md)
+ [aurora\$1wait\$1report](aurora_wait_report.md)
# aurora\$1db\$1instance\$1identifier
Comunica il nome dell'istanza database cui si è connessi.
## Sintassi
```
aurora_db_instance_identifier()
```
## Argomenti
Nessuno
## Tipo restituito
Stringa VARCHA
## Note per l'utilizzo
Questa funzione visualizza il nome dell'istanza database del cluster Aurora edizione compatibile con PostgreSQL per la connessione al client di database o all'applicazione.
Questa funzione è disponibile a partire dal rilascio di PostgreSQL versioni 13.7, 12.11, 11.16, 10.21 e per tutte le altre versioni successive.
## Esempi
Nell'esempio seguente vengono mostrati i risultati della chiamata della funzione `aurora_db_instance_identifier`.
```
=> SELECT aurora_db_instance_identifier();
aurora_db_instance_identifier
-------------------------------
test-my-instance-name
```
È possibile unire i risultati di questa funzione con la funzione `aurora_replica_status` per ottenere i dettagli relativi all'istanza database per la connessione. Il parametro [aurora\$1replica\$1status](aurora_replica_status.md) da solo non mostra l’istanza database in uso. Nell'esempio seguente viene illustrato come fare.
```
=> SELECT *
FROM aurora_replica_status() rt,
aurora_db_instance_identifier() di
WHERE rt.server_id = di;
-[ RECORD 1 ]----------------------+-----------------------
server_id | test-my-instance-name
session_id | MASTER_SESSION_ID
durable_lsn | 88492069
highest_lsn_rcvd |
current_read_lsn |
cur_replay_latency_in_usec |
active_txns |
is_current | t
last_transport_error | 0
last_error_timestamp |
last_update_timestamp | 2022-06-03 11:18:25+00
feedback_xmin |
feedback_epoch |
replica_lag_in_msec |
log_stream_speed_in_kib_per_second | 0
log_buffer_sequence_number | 0
oldest_read_view_trx_id |
oldest_read_view_lsn |
pending_read_ios | 819
```
# aurora\$1ccm\$1status
Visualizza lo stato del gestore della cache del cluster.
## Sintassi
```
aurora_ccm_status()
```
## Argomenti
Nessuna.
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `buffers_sent_last_minute`: il numero di buffer inviati all'istanza database di lettura designata nell'ultimo minuto.
+ `buffers_found_last_minute`: il numero di buffer con accesso frequente identificati durante l'ultimo minuto.
+ `buffers_sent_last_scan`: il numero di buffer inviati all'istanza di lettura designata durante l'ultima scansione completa della cache.
+ `buffers_found_last_scan`: il numero di buffer ad accesso frequente inviati durante l'ultima scansione completa della cache. I buffer già memorizzati sull'istanza database di lettura designata non vengono inviati.
+ `buffers_sent_current_scan`: il numero di buffer inviati durante la scansione corrente.
+ `buffers_found_current_scan`: il numero di buffer ad accesso frequente identificati nella scansione corrente.
+ `current_scan_progress`: il numero di buffer analizzati finora durante la scansione corrente.
## Note per l'utilizzo
È possibile utilizzare questa funzione per controllare e monitorare la funzionalità di gestione della cache del cluster (CCM). Ciò può avvenire solo se la funzionalità di gestione della cache del cluster è attiva sul cluster di database Aurora PostgreSQL. Per utilizzare questa funzione, connettersi all'istanza DB di scrittura sul cluster di database Aurora PostgreSQL.
Per attivare la funzionalità di gestione della cache del cluster per un cluster di database Aurora PostgreSQL, impostare `apg_ccm_enabled` su 1 nel gruppo di parametri del cluster di database personalizzato. Per scoprire come, consulta [Configurazione della gestione della cache del cluster](AuroraPostgreSQL.cluster-cache-mgmt.md#AuroraPostgreSQL.cluster-cache-mgmt.Configure).
La gestione della cache del cluster è attiva su un cluster di database Aurora PostgreSQL quando il cluster dispone di un'istanza di lettura Aurora configurata come segue:
+ L'istanza di lettura Aurora utilizza lo stesso tipo di classe di istanza database e la stessa dimensione dell'istanza di scrittura del cluster.
+ L'istanza di lettura Aurora è configurata come Tier-0 per il cluster. Se il cluster include più di un'istanza di lettura, questa istanza sarà l'unica istanza di lettura di tipo Tier-0.
L'impostazione di più di un'istanza di lettura su Tier-0 disabilita la funzionalità di gestione della cache del cluster. Quando la funzionalità di gestione della cache del cluster è disabilitata, una chiamata a questa funzione restituirà il seguente messaggio di errore:
```
ERROR: Cluster Cache Manager is disabled
```
È inoltre possibile impostare l'estensione PostgreSQL pg\$1buffercache affinché analizzi la cache del buffer. Per ulteriori informazioni, consulta [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html) nella documentazione di PostgreSQL.
Per ulteriori informazioni, consulta [Introduzione alla gestione della cache del cluster Aurora PostgreSQL](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/).
## Esempi
Nell'esempio seguente vengono mostrati i risultati della chiamata della funzione `aurora_ccm_status`. Questo primo esempio mostra le statistiche restituite dalla funzionalità di gestione della cache del cluster.
```
=> SELECT * FROM aurora_ccm_status();
buffers_sent_last_minute | buffers_found_last_minute | buffers_sent_last_scan | buffers_found_last_scan | buffers_sent_current_scan | buffers_found_current_scan | current_scan_progress
--------------------------+---------------------------+------------------------+-------------------------+---------------------------+----------------------------+-----------------------
2242000 | 2242003 | 17920442 | 17923410 | 14098000 | 14100964 | 15877443
```
Per dettagli più completi, è possibile utilizzare la visualizzazione espansa, come illustrato di seguito:
```
\x
Expanded display is on.
SELECT * FROM aurora_ccm_status();
[ RECORD 1 ]-----------------------+---------
buffers_sent_last_minute | 2242000
buffers_found_last_minute | 2242003
buffers_sent_last_scan | 17920442
buffers_found_last_scan | 17923410
buffers_sent_current_scan | 14098000
buffers_found_current_scan | 14100964
current_scan_progress | 15877443
```
Questo esempio mostra come controllare la frequenza e la percentuale degli avvii a caldo.
```
=> SELECT buffers_sent_last_minute * 8/60 AS warm_rate_kbps,
100 * (1.0-buffers_sent_last_scan/buffers_found_last_scan) AS warm_percent
FROM aurora_ccm_status ();
warm_rate_kbps | warm_percent
----------------+--------------
16523 | 100.0
```
# aurora\$1global\$1db\$1instance\$1status
Visualizza lo stato di tutte le istanze Aurora, incluse le repliche in un cluster di database globale Aurora.
## Sintassi
```
aurora_global_db_instance_status()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `server_id`: l'identificatore dell'istanza database.
+ `session_id`: un identificatore univoco per la sessione. Il valore di `MASTER_SESSION_ID` identifica l'istanza database di lettura (primaria).
+ `aws_region`: l'Regione AWS in cui viene eseguita l'istanza database globale corrente. Per l'elenco delle regioni , consulta [Disponibilità nelle regioni](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ `durable_lsn`: il numero di sequenza di log (LSN) reso durevole nell'archiviazione. Numero di sequenza di log (LSN) è un numero sequenziale univoco che identifica un record nel log delle transazioni del database. Gli LSN sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva.
+ `highest_lsn_rcvd`: l'LSN più alto che l'istanza database ha ricevuto dall'istanza database di scrittura.
+ `feedback_epoch`: l'epoca utilizzata dall'istanza database quando genera informazioni standby a caldo. Uno *standby a caldo* è un'istanza database che supporta connessioni e query mentre il database primario è in modalità di ripristino o standby. Le informazioni relative allo standby a caldo includono l'epoca (point-in-time) e altri dettagli sull'istanza database utilizzata come standby a caldo. Per ulteriori informazioni, consulta [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html) nella documentazione di PostgreSQL.
+ `feedback_xmin`: l'ID della transazione attiva più basso utilizzato dall'istanza database.
+ `oldest_read_view_lsn`: l'LSN più vecchio utilizzato dall'istanza database per le operazioni di lettura dallo storage.
+ `visibility_lag_in_msec`: il ritardo dell'istanza database corrente rispetto all'istanza database di scrittura in millisecondi.
## Note per l'utilizzo
Questa funzione mostra le statistiche di replica per un cluster di database Aurora. Per ogni istanza database Aurora PostgreSQL nel cluster, la funzione mostra una riga di dati che include eventuali repliche tra regioni in una configurazione di database globale.
È possibile eseguire questa funzione da qualsiasi istanza in un cluster di database Aurora PostgreSQL o Aurora PostgreSQL. La funzione restituisce dettagli sul ritardo per tutte le istanze di replica.
Per ulteriori informazioni sul monitoraggio del ritardo utilizzando questa funzione (`aurora_global_db_instance_status`) o `aurora_global_db_status`, consulta [Monitoraggio dei database globali Aurora basati su PostgreSQL](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres).
Per informazioni sui database globali Aurora, consulta [Panoramica di Database globale Amazon Aurora](aurora-global-database.md#aurora-global-database-overview).
Per iniziare a utilizzare i database globali Aurora, consulta [Nozioni di base sul Database globale Amazon Aurora](aurora-global-database-getting-started.md) o [Domande frequenti su Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/).
## Esempi
Questo esempio mostra le statistiche delle istanze tra regioni.
```
=> SELECT *
FROM aurora_global_db_instance_status();
server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
------------------------------------------+--------------------------------------+--------------+-------------+------------------+----------------+---------------+----------------------+------------------------
db-119-001-instance-01 | MASTER_SESSION_ID | eu-west-1 | 2534560273 | [NULL] | [NULL] | [NULL] | [NULL] | [NULL]
db-119-001-instance-02 | 4ecff34d-d57c-409c-ba28-278b31d6fc40 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-03 | 3e8a20fc-be86-43d5-95e5-bdf19d27ad6b | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-04 | fc1b0023-e8b4-4361-bede-2a7e926cead6 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-instance-05 | 30319b74-3f08-4e13-9728-e02aa1aa8649 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-global-instance-1 | a331ffbb-d982-49ba-8973-527c96329c60 | eu-central-1 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 996
db-119-001-global-instance-1 | e0955367-7082-43c4-b4db-70674064a9da | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 14
db-119-001-global-instance-1-eu-west-2a | 1248dc12-d3a4-46f5-a9e2-85850491a897 | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 0
```
Questo esempio mostra come controllare il ritardo delle repliche globali in millisecondi.
```
=> SELECT CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
aws_region,
server_id,
visibility_lag_in_msec
FROM aurora_global_db_instance_status()
ORDER BY 1, 2, 3;
global_role | aws_region | server_id | visibility_lag_in_msec
-------------+--------------+-----------------------------------------+------------------------
Primary | eu-west-1 | db-119-001-instance-01 | [NULL]
Secondary | eu-central-1 | db-119-001-global-instance-1 | 13
Secondary | eu-west-1 | db-119-001-instance-02 | 10
Secondary | eu-west-1 | db-119-001-instance-03 | 9
Secondary | eu-west-1 | db-119-001-instance-04 | 2
Secondary | eu-west-1 | db-119-001-instance-05 | 18
Secondary | eu-west-2 | db-119-001-global-instance-1 | 14
Secondary | eu-west-2 | db-119-001-global-instance-1-eu-west-2a | 13
```
Questo esempio mostra come controllare il ritardo minimo, massimo e medio per Regione AWS rispetto alla configurazione del database globale.
```
=> SELECT 'Secondary' global_role,
aws_region,
min(visibility_lag_in_msec) min_lag_in_msec,
max(visibility_lag_in_msec) max_lag_in_msec,
round(avg(visibility_lag_in_msec),0) avg_lag_in_msec
FROM aurora_global_db_instance_status()
WHERE aws_region NOT IN (SELECT aws_region
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID')
GROUP BY aws_region
UNION ALL
SELECT 'Primary' global_role,
aws_region,
NULL,
NULL,
NULL
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID'
ORDER BY 1, 5;
global_role | aws_region | min_lag_in_msec | max_lag_in_msec | avg_lag_in_msec
------------+--------------+-----------------+-----------------+-----------------
Primary | eu-west-1 | [NULL] | [NULL] | [NULL]
Secondary | eu-central-1 | 133 | 133 | 133
Secondary | eu-west-2 | 0 | 495 | 248
```
# aurora\$1global\$1db\$1status
Visualizza informazioni su vari aspetti del ritardo del database globale Aurora, in particolare il ritardo dell'archiviazione Aurora sottostante (il cosiddetto ritardo di durabilità) e il ritardo rispetto all'obiettivo del punto di ripristino (RPO).
## Sintassi
```
aurora_global_db_status()
```
## Argomenti
Nessuna.
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `aws_region`: la Regione AWS in cui si trova il cluster di database corrente. Per un elenco completo di Regioni AWS per motore, consulta [ Regioni e zone di disponibilità](Concepts.RegionsAndAvailabilityZones.md).
+ `highest_lsn_written`: il numero di sequenza di log (LSN) più alto attualmente esistente in questo cluster di database. Numero di sequenza di log (LSN) è un numero sequenziale univoco che identifica un record nel log delle transazioni del database. Gli LSN sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva.
+ `durability_lag_in_msec`: la differenza tra i valori di timestamp tra `highest_lsn_written` su un cluster di database secondario e `highest_lsn_written` sul cluster di database primario. Un valore -1 identifica il cluster di database globale principale di un database globale Aurora.
+ `rpo_lag_in_msec`: il ritardo dell'obiettivo del punto di ripristino (RPO). Il ritardo dell'obiettivo del punto di ripristino (RPO) è il tempo necessario per memorizzare il COMMIT delle transazioni utente più recenti dopo la sua memorizzazione nel cluster di database primario del database globale Aurora. Un valore -1 indica il cluster di database primario e quindi il ritardo non è rilevante.
In sintesi, questo parametro calcola l'obiettivo del punto di ripristino per ciascun cluster di database Aurora PostgreSQL nel database globale Aurora, ovvero quanti dati potrebbero andare perduti in caso di interruzione. Come per il ritardo, l'obiettivo del punto di ripristino (RPO) viene misurato nel tempo.
+ `last_lag_calculation_time`: il timestamp che specifica quando sono stati calcolati i valori per `durability_lag_in_msec` e `rpo_lag_in_msec`. Il valore temporale `1970-01-01 00:00:00+00` indica che questo è il cluster di database primario.
+ `feedback_epoch`: l'epoca utilizzata dal cluster di database secondario quando genera informazioni sullo standby a caldo. Uno *standby a caldo* è un'istanza database che supporta connessioni e query mentre il database primario è in modalità di ripristino o standby. Le informazioni relative allo standby a caldo includono l'epoca (point-in-time) e altri dettagli sull'istanza database utilizzata come standby a caldo. Per ulteriori informazioni, consulta [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html) nella documentazione di PostgreSQL.
+ `feedback_xmin`: l'ID minimo della transazione attiva (meno recente) utilizzato da un cluster di database secondario.
## Note per l’utilizzo
Tutte le versioni di Aurora PostgreSQL attualmente disponibili supportano questa funzione. Questa funzione mostra le statistiche di replica per un database globale Aurora. Mostra una riga per ciascun cluster di database in un database globale Aurora PostgreSQL. È possibile eseguire questa funzione da qualsiasi istanza del database globale Aurora PostgreSQL.
Per valutare il ritardo di replica del database globale Aurora, ovvero il ritardo visibile dei dati, consulta [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md).
Per ulteriori informazioni sull'uso di `aurora_global_db_status` e `aurora_global_db_instance_status` per monitorare il ritardo del database globale Aurora, consulta [Monitoraggio dei database globali Aurora basati su PostgreSQL](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres). Per informazioni sui database globali Aurora, consulta [Panoramica di Database globale Amazon Aurora](aurora-global-database.md#aurora-global-database-overview).
## Esempi
Questo esempio mostra come visualizzare le statistiche di archiviazione tra regioni.
```
=> SELECT CASE
WHEN '-1' = durability_lag_in_msec THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
*
FROM aurora_global_db_status();
global_role | aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin
-------------+------------+---------------------+------------------------+-----------------+----------------------------+----------------+---------------
Primary | eu-west-1 | 131031557 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0
Secondary | eu-west-2 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
Secondary | eu-west-3 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
```
# aurora\$1list\$1builtins
Elenca tutte le funzioni integrate di Aurora PostgreSQL disponibili, insieme a brevi descrizioni e dettagli delle funzioni.
## Sintassi
```
aurora_list_builtins()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF
## Esempi
Nell'esempio seguente vengono mostrati i risultati della chiamata alla funzione `aurora_list_builtins`.
```
=> SELECT *
FROM aurora_list_builtins();
Name | Result data type | Argument data types | Type | Volatility | Parallel | Security | Description
-----------------------------------+------------------+----------------------------------------------------------+------+------------+------------+----------+---------------------------------------------------------------------
aurora_version | text | | func | stable | safe | invoker | Amazon Aurora PostgreSQL-Compatible Edition version string
aurora_stat_wait_type | SETOF record | OUT type_id smallint, OUT type_name text | func | volatile | restricted | invoker | Lists all supported wait types
aurora_stat_wait_event | SETOF record | OUT type_id smallint, OUT event_id integer, OUT event_na.| func | volatile | restricted | invoker | Lists all supported wait events
| |.me text | | | | |
aurora_list_builtins | SETOF record | OUT "Name" text, OUT "Result data type" text, OUT "Argum.| func | stable | safe | invoker | Lists all Aurora built-in functions
| |.ent data types" text, OUT "Type" text, OUT "Volatility" .| | | | |
| |.text, OUT "Parallel" text, OUT "Security" text, OUT "Des.| | | | |
| |.cription" text | | | | |
.
.
.
aurora_stat_file | SETOF record | OUT filename text, OUT allocated_bytes bigint, OUT used_.| func | stable | safe | invoker | Lists all files present in Aurora storage
| |.bytes bigint | | | | |
aurora_stat_get_db_commit_latency | bigint | oid | func | stable | restricted | invoker | Per DB commit latency in microsecs
```
# aurora\$1replica\$1status
Visualizza lo stato di tutti i nodi del lettore Aurora PostgreSQL.
## Sintassi
```
aurora_replica_status()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `server_id`: ID dell’istanza database (identificatore).
+ `session_id`: un identificatore univoco per la sessione corrente, restituito per l’istanza primaria e le istanze di lettura nel modo seguente:
+ Per l'istanza primaria, il `session_id` è sempre ``MASTER_SESSION_ID’`.
+ Per le istanze di lettura, il `session_id` è sempre l'`UUID` (universally unique identifier, identificatore univoco universale) dell'istanza di lettura.
+ `durable_lsn`: numero di sequenza di log (log sequence number, LSN) archiviato nello storage.
+ Per il volume primario, l'LSN (VDL) durevole del primario attualmente in uso.
+ Per tutti i volumi secondari, il VDL del primario a cui è stato applicato correttamente il secondario.
**Nota**
Numero di sequenza di log (LSN) è un numero sequenziale univoco che identifica un record nel log delle transazioni del database. Gli LSN sono ordinati in modo tale che quelli più grandi rappresentino una transizione successiva.
+ `highest_lsn_rcvd`: l'LSN più alto (più recente) che l'istanza database ha ricevuto dall'istanza database di scrittura.
+ `current_read_lsn`: l'LSN della snapshot più recente applicato a tutte le operazioni di lettura.
+ `cur_replay_latency_in_usec`: tempo previsto in millisecondi per riprodurre il log sul secondario.
+ `active_txns`: numero di transazioni attualmente attive.
+ `is_current`: non utilizzato.
+ `last_transport_error`: codice di errore dell'ultima replica.
+ `last_error_timestamp`: timestamp dell'ultimo errore di replica.
+ `last_update_timestamp`: timestamp dell'ultimo aggiornamento allo stato della replica. Da Aurora PostgreSQL versione 13.9, il valore `last_update_timestamp` per l'istanza database a cui si è connessi è impostato su `NULL`.
+ `feedback_xmin`: feedback\$1xmin della replica in standby a caldo. L'ID della transazione attiva più basso (meno recente) utilizzato dall'istanza database.
+ `feedback_epoch`: l'epoca utilizzata dall'istanza database quando genera informazioni standby a caldo.
+ `replica_lag_in_msec`: ritardo dell’istanza di lettura rispetto a quella di scrittura misurato in millisecondi.
+ `log_stream_speed_in_kib_per_second`: la velocità effettiva del flusso di log in kilobyte al secondo.
+ `log_buffer_sequence_number`: il numero di sequenza del buffer di registro.
+ `oldest_read_view_trx_id`: non utilizzato.
+ `oldest_read_view_lsn`: l'LSN più vecchio utilizzato dall'istanza database per le operazioni di lettura dallo storage.
+ `pending_read_ios`: le letture di pagina in sospeso sulla replica.
+ `read_ios`: il numero totale di letture di pagina sulla replica.
+ `iops`: non utilizzato.
+ `cpu`: utilizzo della CPU di Aurora Storage Daemon per ogni nodo del cluster. Per informazioni sull'utilizzo della CPU da parte dell'istanza, consulta [Parametri a livello di istanza per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
## Note per l’utilizzo
Tutte le versioni di Aurora PostgreSQL attualmente disponibili supportano questa funzione. La funzione `aurora_replica_status` restituisce i valori del gestore di stato della replica di un cluster database Aurora PostgreSQL. Utilizza questa funzione per ottenere informazioni sullo stato della replica sul cluster database Aurora PostgreSQL, inclusi i parametri per tutte le istanze database nel cluster database Aurora. Ad esempio, puoi eseguire le operazioni seguenti:
+ **Ottenere informazioni sul tipo di istanza (di scrittura, di lettura) nel cluster database Aurora PostgreSQL**. Per ottenere queste informazioni, controlla i valori contenuti nelle colonne seguenti:
+ `server_id`: contiene il nome dell'istanza specificato durante la sua creazione. In alcuni casi, ad esempio per l'istanza primaria (di scrittura), il nome viene generato automaticamente aggiungendo *-instance-1* al nome creato per il cluster database Aurora PostgreSQL.
+ `session_id`: il campo `session_id` indica se l'istanza è di lettura o di scrittura. Per un'istanza di scrittura, `session_id` è sempre impostato su `"MASTER_SESSION_ID"`. Per un'istanza di lettura, `session_id` è impostato sull'`UUID` del lettore specifico.
+ **Diagnostica dei problemi comuni correlati alle repliche, come il ritardo di replica**. Il ritardo di replica indica il ritardo in millisecondi della cache di pagina di un'istanza di lettura rispetto a quella dell'istanza di scrittura. Questo ritardo si verifica perché i cluster Aurora utilizzano la replica asincrona, come descritto in [Replica con Amazon Aurora](Aurora.Replication.md). Nella colonna `replica_lag_in_msec` sono mostrati i risultati restituiti da questa funzione. Il ritardo può verificarsi anche quando una query viene annullata a causa di conflitti con il ripristino su un server in standby. È possibile verificare se il ritardo di replica è causato o meno da questo conflitto controllando `pg_stat_database_conflicts()`. Per ulteriori informazioni, consulta [Raccolta di statistiche](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW) nella *Documentazione di PostgreSQL*. Per ulteriori informazioni sulla disponibilità elevata e la replica, consulta [Domande frequenti su Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication).
Amazon CloudWatch archivia i risultati di `replica_lag_in_msec` nel tempo, come parametro `AuroraReplicaLag`. Per ulteriori informazioni sull’utilizzo dei parametri CloudWatch per Aurora, consulta [Monitoraggio dei parametri di Amazon Aurora con Amazon CloudWatch](monitoring-cloudwatch.md)
Per ulteriori informazioni sulla risoluzione dei problemi relativi alla lettura e al riavvio di Aurora, consulta [Perché la mia replica Amazon Aurora è in ritardo e si è riavviata?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/) nel [Centro Supporto AWS](https://console.aws.amazon.com/support/home#/).
## Esempi
L'esempio seguente mostra come ottenere lo stato di replica di tutte le istanze in un cluster database Aurora PostgreSQL:
```
=> SELECT *
FROM aurora_replica_status();
```
L'esempio seguente mostra l'istanza di lettura nel cluster database `docs-lab-apg-main` Aurora PostgreSQL:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id = 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-01 | writer
```
Nell'esempio seguente sono elencate tutte le istanze di lettura in un cluster:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id <> 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-02 | reader
db-119-001-instance-03 | reader
db-119-001-instance-04 | reader
db-119-001-instance-05 | reader
(4 rows)
```
Nell'esempio seguente sono elencate tutte le istanze, il ritardo di ognuna di esse rispetto all'istanza di scrittura e quanto tempo è trascorso dall'ultimo aggiornamento:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role,
replica_lag_in_msec AS replica_lag_ms,
round(extract (epoch FROM (SELECT age(clock_timestamp(), last_update_timestamp))) * 1000) AS last_update_age_ms
FROM aurora_replica_status()
ORDER BY replica_lag_in_msec NULLS FIRST;
server_id | instance_role | replica_lag_ms | last_update_age_ms
------------------------+---------------+----------------+--------------------
db-124-001-instance-03 | writer | [NULL] | 1756
db-124-001-instance-01 | reader | 13 | 1756
db-124-001-instance-02 | reader | 13 | 1756
(3 rows)
```
# aurora\$1stat\$1activity
Restituisce una riga per processo del server, mostrando le informazioni relative all’attività corrente di quel processo.
## Sintassi
```
aurora_stat_activity();
```
## Argomenti
Nessuno
## Tipo restituito
Restituisce una riga per processo del server. Oltre alle colonne `pg_stat_activity`, viene aggiunto il seguente campo:
+ planid: identificatore del piano
## Note per l’utilizzo
Una vista supplementare di `pg_stat_activity` che restituisce le stesse colonne con una colonna `plan_id` aggiuntiva che mostra il piano di esecuzione della query corrente.
`aurora_compute_plan_id` deve essere abilitato affinché la vista restituisca un plan\$1id.
Questa funzione è disponibile dalle versioni 14.10, 15.5 di Aurora PostgreSQL e per tutte le altre versioni successive.
## Esempi
La query di esempio riportata di seguito aggrega il carico massimo per query\$1id e plan\$1id.
```
db1=# select count(*), query_id, plan_id
db1-# from aurora_stat_activity() where state = 'active'
db1-# and pid <> pg_backend_pid()
db1-# group by query_id, plan_id
db1-# order by 1 desc;
count | query_id | plan_id
-------+----------------------+-------------
11 | -5471422286312252535 | -2054628807
3 | -6907107586630739258 | -815866029
1 | 5213711845501580017 | 300482084
(3 rows)
```
Se il piano utilizzato per query\$1id cambia, aurora\$1stat\$1activity riporterà un nuovo plan\$1id.
```
count | query_id | plan_id
-------+----------------------+-------------
10 | -5471422286312252535 | 1602979607
1 | -6907107586630739258 | -1809935983
1 | -2446282393000597155 | -207532066
(3 rows)
```
# aurora\$1stat\$1backend\$1waits
Visualizza le statistiche per l'attività di attesa per un processo di back-end specifico.
## Sintassi
```
aurora_stat_backend_waits(pid)
```
## Argomenti
`pid`: l'ID per il processo di back-end. È possibile ottenere gli ID di processo utilizzando la vista `pg_stat_activity`.
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `type_id`: un numero che indica il tipo di evento di attesa, ad esempio `1` per un blocco leggero (`LWLock`), `3` per un blocco o `6` per una sessione client. Questi valori diventano significativi quando i risultati di questa funzione vengono abbinati alle colonne della funzione `aurora_stat_wait_type`, come descritto nella sezione [Esempi](#aurora_stat_backend_waits-examples).
+ `event_id`: un numero identificativo per l'evento di attesa. Abbina questo valore alle colonne di `aurora_stat_wait_event` per ottenere nomi significativi per gli eventi.
+ `waits`: conteggio del numero di attese accumulate per l'ID di processo specificato.
+ `wait_time`: tempo di attesa in millisecondi.
## Note per l'utilizzo
È possibile utilizzare questa funzione per analizzare eventi di attesa di back-end (sessione) specifici che si sono verificati dall'apertura di una connessione. Per ottenere informazioni più significative sui nomi e sui tipi di eventi di attesa, è possibile combinare `aurora_stat_wait_type` e `aurora_stat_wait_event`, utilizzando JOIN come mostrato negli esempi.
## Esempi
Questo esempio mostra tutte le attese, tutti i tipi e tutti i nomi di evento per l'ID processo back-end 3027.
```
=> SELECT type_name, event_name, waits, wait_time
FROM aurora_stat_backend_waits(3027)
NATURAL JOIN aurora_stat_wait_type()
NATURAL JOIN aurora_stat_wait_event();
type_name | event_name | waits | wait_time
-----------+------------------------+-------+------------
LWLock | ProcArrayLock | 3 | 27
LWLock | wal_insert | 423 | 16336
LWLock | buffer_content | 11840 | 1033634
LWLock | lock_manager | 23821 | 5664506
Lock | tuple | 10258 | 152280165
Lock | transactionid | 78340 | 1239808783
Client | ClientRead | 34072 | 17616684
IO | ControlFileSyncUpdate | 2 | 0
IO | ControlFileWriteUpdate | 4 | 32
IO | RelationMapRead | 2 | 795
IO | WALWrite | 36666 | 98623
IO | XactSync | 4867 | 7331963
```
Questo esempio mostra i tipi di attesa correnti e cumulativi e gli eventi di attesa per tutte le sessioni attive (`pg_stat_activity state <> 'idle'`) (ma senza la sessione corrente che richiama la funzione (`pid <> pg_backend_pid()`).
```
=> SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+----------+----------+-------------------+--------------------+---------------+-----------+------------------------+-------+-----------
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1937 | 29975
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22903 | 760498
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | lock_manager | 10012 | 223207
30099 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 20315 | 63081529
.
.
.
30099 | postgres | pgbench | Lock | transactionid | active | IO | WALWrite | 93293 | 237440
30099 | postgres | pgbench | Lock | transactionid | active | IO | XactSync | 13010 | 19525143
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | ProcArrayLock | 6 | 53
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1913 | 25450
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22874 | 778005
.
.
.
30109 | postgres | pgbench | IO | XactSync | active | LWLock | ProcArrayLock | 3 | 71
30109 | postgres | pgbench | IO | XactSync | active | LWLock | wal_insert | 1940 | 27741
30109 | postgres | pgbench | IO | XactSync | active | LWLock | buffer_content | 22962 | 776352
30109 | postgres | pgbench | IO | XactSync | active | LWLock | lock_manager | 9879 | 218826
30109 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 20401 | 63581306
30109 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 50769 | 211645008
30109 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 89901 | 44192439
```
Questo esempio mostra il tipo di attesa corrente e i primi tre (3) eventi di attesa cumultativi, nonché gli eventi di attesa per tutte le sessioni attive (`pg_stat_activity state <> 'idle'`) esclusa la sessione corrente (`pid <>pg_backend_pid()`).
```
=> SELECT top3.*
FROM (SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time,
RANK() OVER (PARTITION BY pid ORDER BY a.wait_time DESC)
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we) top3
WHERE RANK <=3;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time | rank
-------+----------+----------+-------------------+--------------------+---------------+-----------+-----------------+---------+------------+------
20567 | postgres | psql | CPU | CPU | active | LWLock | wal_insert | 25000 | 67512003 | 1
20567 | postgres | psql | CPU | CPU | active | IO | WALWrite | 3071758 | 1016961 | 2
20567 | postgres | psql | CPU | CPU | active | IO | BufFileWrite | 20750 | 184559 | 3
27743 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237350 | 1265580011 | 1
27743 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93641 | 341472318 | 2
27743 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417556 | 204796837 | 3
.
.
.
27745 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 238068 | 1265816822 | 1
27745 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 93210 | 338312247 | 2
27745 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 419157 | 207836533 | 3
27746 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237621 | 1264528811 | 1
27746 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93563 | 339799310 | 2
27746 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417304 | 208372727 | 3
```
# aurora\$1stat\$1bgwriter
`aurora_stat_bgwriter` è una vista delle statistiche che mostra informazioni sulle scritture nella cache di Letture ottimizzate.
## Sintassi
```
aurora_stat_bgwriter()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF con tutte le colonne `pg_stat_bgwriter` e le seguenti colonne aggiuntive. Per ulteriori informazioni sulle colonne `pg_stat_bgwriter`, consulta [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW).
È possibile ripristinare le statistiche per questa funzione utilizzando `pg_stat_reset_shared("bgwriter")`.
+ `orcache_blks_written`: numero totale di blocchi di dati della cache di Letture ottimizzate scritti.
+ `orcache_blk_write_time`: se `track_io_timing` è abilitato, tiene traccia del tempo totale in millisecondi impiegato per scrivere blocchi di dati di file della cache di Letture ottimizzate. Per ulteriori informazioni, consulta [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
## Note per l'utilizzo
Questa funzione è disponibile per le seguenti versioni di Aurora PostgreSQL:
+ 15.4 e versioni successive
+ 14.9 e versioni successive
## Esempi
```
=> select * from aurora_stat_bgwriter();
-[ RECORD 1 ]-----------------+-----------
orcache_blks_written | 246522
orcache_blk_write_time | 339276.404
```
# aurora\$1stat\$1database
Contiene tutte le colonne di pg\$1stat\$1database e aggiunge nuove colonne alla fine.
## Sintassi
```
aurora_stat_database()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF con tutte le colonne `pg_stat_database` e le seguenti colonne aggiuntive. Per ulteriori informazioni sulle colonne `pg_stat_database`, consulta [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW).
+ `storage_blks_read`: numero totale di blocchi condivisi letti dall'archiviazione Aurora in questo database.
+ `orcache_blks_hit`: numero totale di accessi alla cache di Letture ottimizzate in questo database.
+ `local_blks_read`: numero totale di blocchi locali letti in questo database.
+ `storage_blk_read_time`: se `track_io_timing` è abilitato, tiene traccia del tempo totale impiegato in millisecondi per leggere i blocchi di file di dati dall'archiviazione Aurora altrimenti il valore è zero. Per ulteriori informazioni, consulta [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time`: se `track_io_timing` è abilitato, tiene traccia del tempo totale impiegato in millisecondi per leggere i blocchi di file di dati locali, altrimenti il valore è zero. Per ulteriori informazioni, consulta [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time`: se `track_io_timing` è abilitato, tiene traccia del tempo totale impiegato in millisecondi per leggere i blocchi di file di dati dalla cache di Letture ottimizzate, altrimenti il valore è zero. Per ulteriori informazioni, consulta [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
**Nota**
Il valore di `blks_read` è la somma di `storage_blks_read`, `orcache_blks_hit` e `local_blks_read`.
Il valore di `blk_read_time` è la somma di `storage_blk_read_time`, `orcache_blk_read_time` e `local_blk_read_time`.
## Note per l'utilizzo
Questa funzione è disponibile per le seguenti versioni di Aurora PostgreSQL:
+ 15.4 e versioni successive
+ 14.9 e versioni successive
## Esempi
L'esempio seguente mostra come contiene tutte le colonne `pg_stat_database` e aggiunge 6 nuove colonne alla fine:
```
=> select * from aurora_stat_database() where datid=14717;
-[ RECORD 1 ]------------+------------------------------
datid | 14717
datname | postgres
numbackends | 1
xact_commit | 223
xact_rollback | 4
blks_read | 1059
blks_hit | 11456
tup_returned | 27746
tup_fetched | 5220
tup_inserted | 165
tup_updated | 42
tup_deleted | 91
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
checksum_failures |
checksum_last_failure |
blk_read_time | 3358.689
blk_write_time | 0
session_time | 1076007.997
active_time | 3684.371
idle_in_transaction_time | 0
sessions | 10
sessions_abandoned | 0
sessions_fatal | 0
sessions_killed | 0
stats_reset | 2023-01-12 20:15:17.370601+00
orcache_blks_hit | 425
orcache_blk_read_time | 89.934
storage_blks_read | 623
storage_blk_read_time | 3254.914
local_blks_read | 0
local_blk_read_time | 0
```
# aurora\$1stat\$1dml\$1activity
Riporta l'attività cumulativa per ogni tipo di operazione di linguaggio di manipolazione dei dati (DML) su un database in un cluster Aurora PostgreSQL.
## Sintassi
```
aurora_stat_dml_activity(database_oid)
```
## Argomenti
*database\$1oid*
L'ID oggetto (OID) del database nel cluster Aurora PostgreSQL.
## Tipo restituito
Record SETOF
## Note per l'utilizzo
La funzione `aurora_stat_dml_activity` è disponibile solo con Aurora PostgreSQL versione 3.1 compatibile con il motore PostgreSQL 11.6 e versioni successive.
Utilizzare questa funzione sui cluster Aurora PostgreSQL con un gran numero di database per identificare quali database hanno un'attività DML più veloce o più lenta, o entrambi.
La funzione `aurora_stat_dml_activity` restituisce il numero di volte in cui le operazioni sono state eseguite e la latenza cumulativa in microsecondi per le operazioni SELECT, INSERT, UPDATE e DELETE. Il report include solo le operazioni DML riuscite.
È possibile reimpostare questa statistica utilizzando la funzione di accesso alle statistiche PostgreSQL `pg_stat_reset`. È possibile controllare l'ultima volta che questa statistica è stata reimpostata utilizzando la funzione `pg_stat_get_db_stat_reset_time`. Per ulteriori informazioni sulle funzioni di accesso alle statistiche PostgreSQL, consulta [Raccolta di statistiche](https://www.postgresql.org/docs/9.1/monitoring-stats.html) nella documentazione di PostgreSQL.
## Esempi
L'esempio seguente mostra come eseguire il report delle statistiche di attività DML per il database connesso.
```
––Define the oid variable from connected database by using \gset
=> SELECT oid,
datname
FROM pg_database
WHERE datname=(select current_database()) \gset
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
178957 | 66684115 | 171065 | 28876649 | 519538 | 1454579206167 | 1 | 53027
–– Showing the same results with expanded display on
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
-[ RECORD 1 ]------------+--------------
select_count | 178957
select_latency_microsecs | 66684115
insert_count | 171065
insert_latency_microsecs | 28876649
update_count | 519538
update_latency_microsecs | 1454579206167
delete_count | 1
delete_latency_microsecs | 53027
```
L'esempio seguente mostra le statistiche di attività DML per tutti i database nel cluster Aurora PostgreSQL. Questo cluster dispone di due database, `postgres` e `mydb`. L'elenco separato da virgole corrisponde ai campi `select_count`, `select_latency_microsecs`, `insert_count`, `insert_latency_microsecs`, `update_count`, `update_latency_microsecs`, `delete_count` e `delete_latency_microsecs`.
Aurora PostgreSQL crea e utilizza un database di sistema denominato `rdsadmin` per supportare operazioni amministrative quali backup, ripristini, controlli di integrità, replica e così via. Queste operazioni DML non hanno alcun impatto sul cluster Aurora PostgreSQL.
```
=> SELECT oid,
datname,
aurora_stat_dml_activity(oid)
FROM pg_database;
oid | datname | aurora_stat_dml_activity
-------+----------------+-----------------------------------------------------------------
14006 | template0 | (,,,,,,,)
16384 | rdsadmin | (2346623,1211703821,4297518,817184554,0,0,0,0)
1 | template1 | (,,,,,,,)
14007 | postgres | (178961,66716329,171065,28876649,519538,1454579206167,1,53027)
16401 | mydb | (200246,64302436,200036,107101855,600000,83659417514,0,0)
```
Nell'esempio seguente vengono illustrate le statistiche di attività DML per tutti i database, organizzate in colonne per una migliore leggibilità.
```
SELECT db.datname,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 1), '()') AS select_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 2), '()') AS select_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 3), '()') AS insert_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 4), '()') AS insert_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 5), '()') AS update_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 6), '()') AS update_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 7), '()') AS delete_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 8), '()') AS delete_latency_microsecs
FROM (SELECT datname,
aurora_stat_dml_activity(oid) AS asdmla
FROM pg_database
) AS db;
datname | select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
----------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
template0 | | | | | | | |
rdsadmin | 4206523 | 2478812333 | 7009414 | 1338482258 | 0 | 0 | 0 | 0
template1 | | | | | | | |
fault_test | 66 | 452099 | 0 | 0 | 0 | 0 | 0 | 0
db_access_test | 1 | 5982 | 0 | 0 | 0 | 0 | 0 | 0
postgres | 42035 | 95179203 | 5752 | 2678832898 | 21157 | 441883182488 | 2 | 1520
mydb | 71 | 453514 | 0 | 0 | 1 | 190 | 1 | 152
```
Nell'esempio seguente viene illustrata la latenza cumulativa media (latenza cumulativa divisa per conteggio) per ogni operazione DML per il database con OID `16401`.
```
=> SELECT select_count,
select_latency_microsecs,
select_latency_microsecs/NULLIF(select_count,0) select_latency_per_exec,
insert_count,
insert_latency_microsecs,
insert_latency_microsecs/NULLIF(insert_count,0) insert_latency_per_exec,
update_count,
update_latency_microsecs,
update_latency_microsecs/NULLIF(update_count,0) update_latency_per_exec,
delete_count,
delete_latency_microsecs,
delete_latency_microsecs/NULLIF(delete_count,0) delete_latency_per_exec
FROM aurora_stat_dml_activity(16401);
-[ RECORD 1 ]------------+-------------
select_count | 451312
select_latency_microsecs | 80205857
select_latency_per_exec | 177
insert_count | 451001
insert_latency_microsecs | 123667646
insert_latency_per_exec | 274
update_count | 1353067
update_latency_microsecs | 200900695615
update_latency_per_exec | 148478
delete_count | 12
delete_latency_microsecs | 448
delete_latency_per_exec | 37
```
# aurora\$1stat\$1get\$1db\$1commit\$1latency
Ottiene la latenza di commit cumulativa in microsecondi per i database Aurora PostgreSQL. La *Latenza commit* viene misurata come il tempo che intercorre tra il momento in cui un client invia una richiesta di commit e il momento in cui riceve la conferma di commit.
## Sintassi
```
aurora_stat_get_db_commit_latency(database_oid)
```
## Argomenti
*database\$1oid*
L'ID oggetto (OID) del database Aurora PostgreSQL.
## Tipo restituito
Record SETOF
## Note per l'utilizzo
Amazon CloudWatch utilizza questa funzione per calcolare la latenza media di commit. Per ulteriori informazioni sui parametri di Amazon CloudWatch e sulla risoluzione dei problemi di elevata latenza di commit, consulta [Visualizzazione delle metriche nella console Amazon RDS](USER_Monitoring.md) e [Prendere decisioni migliori su Amazon RDS con i parametri di Amazon CloudWatch](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/).
È possibile reimpostare questa statistica utilizzando la funzione di accesso alle statistiche PostgreSQL `pg_stat_reset`. È possibile controllare l'ultima volta che questa statistica è stata reimpostata utilizzando la funzione `pg_stat_get_db_stat_reset_time`. Per ulteriori informazioni sulle funzioni di accesso alle statistiche PostgreSQL, consulta [Raccolta di statistiche](https://www.postgresql.org/docs/9.1/monitoring-stats.html) nella documentazione di PostgreSQL.
## Esempi
Nell'esempio seguente viene ottenuta la latenza di commit cumulativa per ogni database nel cluster `pg_database`.
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database;
oid | datname | aurora_stat_get_db_commit_latency
-------+----------------+-----------------------------------
14006 | template0 | 0
16384 | rdsadmin | 654387789
1 | template1 | 0
16401 | mydb | 229556
69768 | postgres | 22011
```
Nell'esempio seguente viene ottenuta la latenza di commit cumulativa per il database attualmente connesso. Prima di chiamare la funzione `aurora_stat_get_db_commit_latency`, l'esempio utilizza `\gset` per definire una variabile per `oid` e imposta il suo valore dal database connesso.
```
––Get the oid value from the connected database before calling aurora_stat_get_db_commit_latency
=> SELECT oid
FROM pg_database
WHERE datname=(SELECT current_database()) \gset
=> SELECT *
FROM aurora_stat_get_db_commit_latency(:oid);
aurora_stat_get_db_commit_latency
-----------------------------------
1424279160
```
Nell'esempio seguente viene ottenuta la latenza di commit cumulativa per il database `mydb` nel cluster `pg_database`. Quindi, reimposta questa statistica utilizzando la funzione `pg_stat_reset` e mostra i risultati. Infine, utilizza la funzione `pg_stat_get_db_stat_reset_time` per controllare l'ultima volta che questa statistica è stata reimpostata.
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 3320370
=> SELECT pg_stat_reset();
pg_stat_reset
---------------
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 6
=> SELECT *
FROM pg_stat_get_db_stat_reset_time(16427);
pg_stat_get_db_stat_reset_time
--------------------------------
2021-04-29 21:36:15.707399+00
```
# aurora\$1stat\$1logical\$1wal\$1cache
Mostra l'utilizzo della cache WAL (write-ahead log) logica per slot.
## Sintassi
```
SELECT * FROM aurora_stat_logical_wal_cache()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `name`: il nome dello slot di replica.
+ `active_pid`: ID del processo walsender.
+ `cache_hit`: il numero totale di riscontri della cache wal dall'ultimo ripristino.
+ `cache_miss`: il numero totale di riscontri mancati della cache wal dall'ultimo ripristino.
+ `blks_read`: il numero totale di richieste di lettura della cache wal.
+ `hit_rate`: la percentuale di riscontri nella cache WAL (cache\$1hit/blks\$1read).
+ `last_reset_timestamp`: data e ora dell'ultimo ripristino del contatore.
## Note per l’utilizzo
Questa funzione è disponibile per le seguenti versioni di Aurora PostgreSQL.
+ 15.2 e tutte le versioni successive
+ 14.7 e versioni successive
+ 13.8 e versioni successive
+ 12.12 e versioni successive
+ 11.17 e versioni successive
## Esempi
L'esempio seguente mostra due slot di replica con una sola funzione `aurora_stat_logical_wal_cache`attiva.
```
=> SELECT *
FROM aurora_stat_logical_wal_cache();
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
------------+------------+-----------+------------+-----------+----------+-------------------------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39:56.830635+00
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34:04.036795+00
(2 rows)
```
# aurora\$1stat\$1memctx\$1usage
Segnala l'utilizzo del contesto della memoria per ciascun processo PostgreSQL.
## Sintassi
```
aurora_stat_memctx_usage()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `pid`: l'ID del processo.
+ `name`: il nome del contesto della memoria.
+ `allocated`: il numero di byte ottenuti dal sottosistema della memoria sottostante mediante il contesto della memoria.
+ `used`: il numero di byte vincolati per i client del contesto della memoria.
+ `instances`: il numero di contesti di questo tipo attualmente esistenti.
## Note per l'utilizzo
Questa funzione visualizza l'utilizzo del contesto della memoria per ciascun processo PostgreSQL. Alcuni processi sono etichettati `anonymous`. I processi non sono esposti perché contengono parole chiave limitate.
Questa funzione è disponibile a partire dalle seguenti versioni di Aurora PostgreSQL:
+ 15.3 o versioni successive alla 15
+ 14.8 o versioni successive alla 14
+ 13.11 o versioni successive alla 13
+ 12.15 e versioni successive alla 12
+ 11.20 e versioni successive alla 11
## Esempi
Nell'esempio seguente vengono mostrati i risultati della chiamata della funzione `aurora_stat_memctx_usage`.
```
=> SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
123864 | Miscellaneous | 19520 | 15064 | 3
123864 | Aurora File Context | 8192 | 616 | 1
123864 | Aurora WAL Context | 8192 | 296 | 1
123864 | CacheMemoryContext | 524288 | 422600 | 1
123864 | Catalog tuple context | 16384 | 13736 | 1
123864 | ExecutorState | 32832 | 28304 | 1
123864 | ExprContext | 8192 | 1720 | 1
123864 | GWAL record construction | 1024 | 832 | 1
123864 | MdSmgr | 8192 | 296 | 1
123864 | MessageContext | 532480 | 353832 | 1
123864 | PortalHeapMemory | 1024 | 488 | 1
123864 | PortalMemory | 8192 | 576 | 1
123864 | printtup | 8192 | 296 | 1
123864 | RelCache hash table entries | 8192 | 8152 | 1
123864 | RowDescriptionContext | 8192 | 1344 | 1
123864 | smgr relation context | 8192 | 296 | 1
123864 | Table function arguments | 8192 | 352 | 1
123864 | TopTransactionContext | 8192 | 632 | 1
123864 | TransactionAbortContext | 32768 | 296 | 1
123864 | WAL record construction | 50216 | 43904 | 1
123864 | hash table | 65536 | 52744 | 6
123864 | Relation metadata | 191488 | 124240 | 87
104992 | Miscellaneous | 9280 | 7728 | 3
104992 | Aurora File Context | 8192 | 376 | 1
104992 | Aurora WAL Context | 8192 | 296 | 1
104992 ||Autovacuum Launcher | 8192 | 296 | 1
104992 | Autovacuum database list | 16384 | 744 | 2
104992 | CacheMemoryContext | 262144 | 140288 | 1
104992 | Catalog tuple context | 8192 | 296 | 1
104992 | GWAL record construction | 1024 | 832 | 1
104992 | MdSmgr | 8192 | 296 | 1
104992 | PortalMemory | 8192 | 296 | 1
104992 | RelCache hash table entries | 8192 | 296 | 1
104992 | smgr relation context | 8192 | 296 | 1
104992 | Autovacuum start worker (tmp) | 8192 | 296 | 1
104992 | TopTransactionContext | 16384 | 592 | 2
104992 | TransactionAbortContext | 32768 | 296 | 1
104992 | WAL record construction | 50216 | 43904 | 1
104992 | hash table | 49152 | 34024 | 4
(39 rows)
```
Alcune parole chiave limitate verranno nascoste e l'aspetto dell'output sarà il seguente:
```
postgres=>SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
5482 | anonymous | 8192 | 456 | 1
5482 | anonymous | 8192 | 296 | 1
```
# aurora\$1stat\$1optimized\$1reads\$1cache
Questa funzione mostra le statistiche relative alla cache a più livelli.
## Sintassi
```
aurora_stat_optimized_reads_cache()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ `total_size`: dimensione totale della cache di Letture ottimizzate.
+ `used_size`: dimensione della pagina utilizzata nella cache di Letture ottimizzate.
## Note per l'utilizzo
Questa funzione è disponibile per le seguenti versioni di Aurora PostgreSQL:
+ 15.4 e versioni successive
+ 14.9 e versioni successive
## Esempi
L'esempio seguente mostra l'output di un'istanza r6gd.8xlarge:
```
=> select pg_size_pretty(total_size) as total_size, pg_size_pretty(used_size)
as used_size from aurora_stat_optimized_reads_cache();
total_size | used_size
-----------+-----------
1054 GB | 975 GB
```
# aurora\$1stat\$1plans
Restituisce una riga per ogni piano di esecuzione monitorato.
## Sintassi
```
aurora_stat_plans(
showtext
)
```
## Argomenti
+ showtext: mostra il testo della query e del piano. I valori validi sono NULL, true o false. True mostrerà il testo della query e del piano.
## Tipo restituito
Restituisce una riga per ogni piano monitorato che contiene tutte le colonne di `aurora_stat_statements` e le seguenti colonne aggiuntive.
+ planid: identificatore del piano
+ explain\$1plan: spiega il testo del piano
+ plan\$1type:
+ `no plan`: nessun piano è stato acquisito
+ `estimate`: piano acquisito con costi stimati
+ `actual`: piano acquisito con EXPLAIN ANALYZE
+ plan\$1captured\$1time: ultima acquisizione di un piano
## Note per l’utilizzo
`aurora_compute_plan_id` deve essere abilitato e `pg_stat_statements` deve essere in `shared_preload_libraries` affinché i piani possano essere monitorati.
Il numero di piani disponibili è controllato dal valore impostato nel parametro `pg_stat_statements.max`. Quando `aurora_compute_plan_id` è abilitato, è possibile monitorare i piani fino al valore specificato in `aurora_stat_plans`.
Questa funzione è disponibile dalle versioni 14.10, 15.5 di Aurora PostgreSQL e per tutte le altre versioni successive.
## Esempi
Nell’esempio seguente, vengono acquisiti i due piani relativi all’identificatore di query -5471422286312252535 e le statistiche delle istruzioni vengono monitorate dal planid.
```
db1=# select calls, total_exec_time, planid, plan_captured_time, explain_plan
db1-# from aurora_stat_plans(true)
db1-# where queryid = '-5471422286312252535'
calls | total_exec_time | planid | plan_captured_time | explain_plan
---------+--------------------+-------------+-------------------------------+------------------------------------------------------------------
1532632 | 3209846.097107853 | 1602979607 | 2023-10-31 03:27:16.925497+00 | Update on pgbench_branches +
| | | | -> Bitmap Heap Scan on pgbench_branches +
| | | | Recheck Cond: (bid = 76) +
| | | | -> Bitmap Index Scan on pgbench_branches_pkey +
| | | | Index Cond: (bid = 76)
61365 | 124078.18012200127 | -2054628807 | 2023-10-31 03:20:09.85429+00 | Update on pgbench_branches +
| | | | -> Index Scan using pgbench_branches_pkey on pgbench_branches+
| | | | Index Cond: (bid = 17)
```
# aurora\$1stat\$1reset\$1wal\$1cache
Reimposta il contatore per la cache wal logica.
## Sintassi
Per reimpostare uno slot specifico
```
SELECT * FROM aurora_stat_reset_wal_cache('slot_name')
```
Per ripristinare tutti gli slot
```
SELECT * FROM aurora_stat_reset_wal_cache(NULL)
```
## Argomenti
`NULL` o `slot_name`
## Tipo restituito
Messaggio di stato, stringa di testo
+ Reimposta il contatore logico della cache wal. Messaggio di esito positivo. Questo testo viene restituito quando la funzione ha esito positivo.
+ Lo slot di replica non è stato trovato Riprova. Messaggio di errore Questo testo viene restituito quando la funzione non riesce.
## Note per l'utilizzo
Questa funzione è disponibile per le seguenti versioni.
+ Aurora PostgreSQL 14.5 e versioni successive
+ Aurora PostgreSQL 13.8 e versioni successive
+ Aurora PostgreSQL 12.12 e versioni successive
+ Aurora PostgreSQL 11.7 e versioni successive
## Esempi
L'esempio seguente utilizza la funzione `aurora_stat_reset_wal_cache` per reimpostare uno slot denominato `test_results` e quindi tenta di reimpostare uno slot che non esiste.
```
=> SELECT *
FROM aurora_stat_reset_wal_cache('test_slot');
aurora_stat_reset_wal_cache
--------------------------------------
Reset the logical wal cache counter.
(1 row)
=> SELECT *
FROM aurora_stat_reset_wal_cache('slot-not-exist');
aurora_stat_reset_wal_cache
-----------------------------------------------
Replication slot not found. Please try again.
(1 row)
```
# aurora\$1stat\$1resource\$1usage
Riporta l’utilizzo delle risorse in tempo reale, che comprende le metriche delle risorse backend e l’utilizzo della CPU per tutti i processi backend Aurora PostgreSQL.
## Sintassi
```
aurora_stat_resource_usage()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF con colonne:
+ pid: identificatore del processo
+ allocated\$1memory: memoria totale allocata dal processo in byte
+ used\$1memory: memoria effettivamente utilizzata per processo in byte
+ cpu\$1usage\$1percent: percentuale di utilizzo della CPU del processo
## Note per l'utilizzo
Questa funzione mostra l’utilizzo delle risorse backend per ogni processo backend Aurora PostgreSQL.
Questa funzione è disponibile a partire dalle seguenti versioni di Aurora PostgreSQL:
+ Aurora PostgreSQL 17.5 e versioni 17 successive
+ Aurora PostgreSQL 16.9 e versioni 16 successive
+ Aurora PostgreSQL 15.13 e versioni 15 successive
+ Aurora PostgreSQL 14.18 e versioni 14 successive
+ Aurora PostgreSQL 13.21 e versioni 13 successive
## Esempi
Il seguente esempio mostra l’output della funzione `aurora_stat_resource_usage`.
```
=> select * from aurora_stat_resource_usage();
pid | allocated_memory | used_memory | cpu_usage_percent
------+------------------+-------------+-----------------------
666 | 1074032 | 333544 | 0.00729274882897963
667 | 787312 | 287360 | 0.0029263928146372746
668 | 3076776 | 1563488 | 0.006013116835953961
684 | 803744 | 307480 | 0.002226855426881142
2401 | 1232992 | 943144 | 0
647 | 8000 | 944 | 0.48853387812429855
659 | 319344 | 243000 | 0.0004135602076683591
663 | 262000 | 185736 | 0.008181301476644002
664 | 9024 | 1216 | 0.10992313082653653
(9 rows)
```
# aurora\$1stat\$1statements
Mostra tutte le colonne `pg_stat_statements` e ne aggiunge altre alla fine.
## Sintassi
```
aurora_stat_statements(showtext boolean)
```
## Argomenti
*showtext boolean*
## Tipo restituito
Record SETOF con tutte le colonne `pg_stat_statements` e le seguenti colonne aggiuntive. Per ulteriori informazioni sulle colonne `pg_stat_statements`, consulta [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html).
È possibile ripristinare le statistiche per questa funzione utilizzando `pg_stat_statements_reset()`.
+ `storage_blks_read`: numero totale di blocchi condivisi letti dall'archiviazione Aurora con questa istruzione.
+ `orcache_blks_hit`: numero totale di accessi alla cache di Letture ottimizzate con questa istruzione.
+ `storage_blk_read_time`: se `track_io_timing` è abilitato, tiene traccia del tempo totale, in millisecondi, impiegato dall’istruzione per leggere i blocchi condivisi dall’archiviazione Aurora, altrimenti il valore è zero. Per ulteriori informazioni, consulta [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time`: se `track_io_timing` è abilitato, tiene traccia del tempo totale, in millisecondi, impiegato dall’istruzione per leggere i blocchi locali, altrimenti il valore è zero. Per ulteriori informazioni, consulta [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time`: se `track_io_timing` è abilitato, tiene traccia del tempo totale, in secondi, impiegato dall’istruzione per leggere i blocchi condivisi dalla cache di letture ottimizzate, altrimenti il valore è zero. Per ulteriori informazioni, consulta [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `total_plan_peakmem`: somma totale dei valori di memoria di picco durante la fase di pianificazione per tutte le chiamate a questa istruzione. Per visualizzare la memoria di picco media durante la pianificazione dell’istruzione, dividi questo valore per il numero di chiamate.
+ `min_plan_peakmem`: il valore di memoria di picco più basso rilevato durante la pianificazione di tutte le chiamate a questa istruzione.
+ `max_plan_peakmem`: il valore di memoria di picco più alto durante la pianificazione di tutte le chiamate a questa istruzione.
+ `total_exec_peakmem`: somma totale dei valori di memoria di picco durante la fase di esecuzione per tutte le chiamate a questa istruzione. Per visualizzare la memoria di picco media durante l’esecuzione dell’istruzione, dividi questo valore per il numero di chiamate.
+ `min_exec_peakmem`: il valore di memoria di picco più basso, in byte, rilevato durante l’esecuzione di tutte le chiamate a questa istruzione.
+ `max_exec_peakmem`: il valore di memoria di picco più alto, in byte, rilevato durante l’esecuzione di tutte le chiamate a questa istruzione.
**Nota**
`total_plan_peakmen`, `min_plan_peakmem` e `max_plan_peakmem` vengono monitorati solo quando l’impostazione `pg_stat_statements.track_planning` è attivata.
## Note per l'utilizzo
Per utilizzare la funzione aurora\$1stat\$1statements(), è necessario includere l’estensione `pg_stat_statements` nel parametro `shared_preload_libraries`.
Questa funzione è disponibile per le seguenti versioni di Aurora PostgreSQL:
+ 15.4 e versioni successive
+ 14.9 e versioni successive
Le colonne che mostrano i picchi di memoria sono disponibili nelle seguenti versioni:
+ 16.3 e versioni successive
+ 15.7 e versioni successive
+ 14.12 e versioni successive
## Esempi
L’esempio seguente mostra come contiene tutte le colonne pg\$1stat\$1statements e aggiunge 11 nuove colonne alla fine:
```
=> select * from aurora_stat_statements(true) where query like 'with window_max%';
-[ RECORD 1 ]----------+------------------------------------------------------------------------------------------------
userid | 16409
dbid | 5
toplevel | t
queryid | -8347523682669847482
query | with window_max as (select custid, max(scratch) over (order by scratch rows between $1 preceding
and $2 following) wmax from ts) select sum(wmax), max(custid) from window_max
plans | 0
total_plan_time | 0
min_plan_time | 0
max_plan_time | 0
mean_plan_time | 0
stddev_plan_time | 0
calls | 4
total_exec_time | 254.105121
min_exec_time | 57.503164000000005
max_exec_time | 68.687418
mean_exec_time | 63.52628025
stddev_exec_time | 5.150765359979643
rows | 4
shared_blks_hit | 200192
shared_blks_read | 0
shared_blks_dirtied | 0
shared_blks_written | 0
local_blks_hit | 0
local_blks_read | 0
local_blks_dirtied | 0
local_blks_written | 0
temp_blks_read | 0
temp_blks_written | 0
blk_read_time | 0
blk_write_time | 0
temp_blk_read_time | 0
temp_blk_write_time | 0
wal_records | 0
wal_fpi | 0
wal_bytes | 0
jit_functions | 0
jit_generation_time | 0
jit_inlining_count | 0
jit_inlining_time | 0
jit_optimization_count | 0
jit_optimization_time | 0
jit_emission_count | 0
jit_emission_time | 0
storage_blks_read | 0
orcache_blks_hit | 0
storage_blk_read_time | 0
local_blk_read_time | 0
orcache_blk_read_time | 0
total_plan_peakmem | 0
min_plan_peakmem | 0
max_plan_peakmem | 0
total_exec_peakmem | 6356224
min_exec_peakmem | 1589056
max_exec_peakmem | 1589056
```
# aurora\$1stat\$1system\$1waits
Segnala le informazioni sugli eventi di attesa per l'istanza database di Aurora PostgreSQL.
## Sintassi
```
aurora_stat_system_waits()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF
## Note per l'utilizzo
Questa funzione restituisce il numero cumulativo di attese e tempo di attesa cumulativo per ogni evento di attesa generato dall'istanza database a cui si è attualmente connessi.
Il recordset restituito include i seguenti campi:
+ `type_id`: ID del tipo di evento di attesa.
+ `event_id`: ID dell'evento di attesa.
+ `waits`: numero di volte in cui si è verificato l'evento di attesa.
+ `wait_time`: tempo di attesa totale in microsecondi per questo evento.
Le statistiche restituite da questa funzione vengono reimpostate al riavvio di un'istanza database.
## Esempi
Nell'esempio seguente vengono mostrati i risultati della chiamata alla funzione `aurora_stat_system_waits`.
```
=> SELECT *
FROM aurora_stat_system_waits();
type_id | event_id | waits | wait_time
---------+-----------+-----------+--------------
1 | 16777219 | 11 | 12864
1 | 16777220 | 501 | 174473
1 | 16777270 | 53171 | 23641847
1 | 16777271 | 23 | 319668
1 | 16777274 | 60 | 12759
.
.
.
10 | 167772231 | 204596 | 790945212
10 | 167772232 | 2 | 47729
10 | 167772234 | 1 | 888
10 | 167772235 | 2 | 64
```
L'esempio seguente mostra come puoi utilizzare questa funzione insieme a `aurora_stat_wait_event` e `aurora_stat_wait_type` per produrre risultati più leggibili.
```
=> 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();
type_name | event_name | waits | wait_time
-----------+------------------------+----------+--------------
LWLock | XidGenLock | 11 | 12864
LWLock | ProcArrayLock | 501 | 174473
LWLock | buffer_content | 53171 | 23641847
LWLock | rdsutils | 2 | 12764
Lock | tuple | 75686 | 2033956052
Lock | transactionid | 1765147 | 47267583409
Activity | AutoVacuumMain | 136868 | 56305604538
Activity | BgWriterHibernate | 7486 | 55266949471
Activity | BgWriterMain | 7487 | 1508909964
.
.
.
IO | SLRURead | 3 | 11756
IO | WALWrite | 52544463 | 388850428
IO | XactSync | 187073 | 597041642
IO | ClogRead | 2 | 47729
IO | OutboundCtrlRead | 1 | 888
IO | OutboundCtrlWrite | 2 | 64
```
# aurora\$1stat\$1wait\$1event
Elenca tutti gli eventi di attesa supportati per Aurora PostgreSQL. Per ulteriori informazioni sulla sicurezza con Aurora PostgreSQL, consulta [Eventi di attesa Amazon Aurora PostgreSQL](AuroraPostgreSQL.Reference.Waitevents.md).
## Sintassi
```
aurora_stat_wait_event()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ type\$1id: ID del tipo di evento di attesa.
+ event\$1id: ID dell'evento di attesa.
+ type\$1name: nome del tipo di attesa
+ event\$1name: nome dell’evento di attesa
## Note per l'utilizzo
Per visualizzare i nomi degli eventi con tipi di evento anziché ID, utilizzare questa funzione insieme ad altre funzioni, ad esempio `aurora_stat_wait_type` e `aurora_stat_system_waits`. I nomi degli eventi di attesa restituiti da questa funzione sono gli stessi di quelli restituiti dalla funzione `aurora_wait_report`.
## Esempi
Nell'esempio seguente vengono mostrati i risultati della chiamata alla funzione `aurora_stat_wait_event`.
```
=> SELECT *
FROM aurora_stat_wait_event();
type_id | event_id | event_name
---------+-----------+-------------------------------------------
1 | 16777216 |
1 | 16777217 | ShmemIndexLock
1 | 16777218 | OidGenLock
1 | 16777219 | XidGenLock
.
.
.
9 | 150994945 | PgSleep
9 | 150994946 | RecoveryApplyDelay
10 | 167772160 | BufFileRead
10 | 167772161 | BufFileWrite
10 | 167772162 | ControlFileRead
.
.
.
10 | 167772226 | WALInitWrite
10 | 167772227 | WALRead
10 | 167772228 | WALSync
10 | 167772229 | WALSyncMethodAssign
10 | 167772230 | WALWrite
10 | 167772231 | XactSync
.
.
.
11 | 184549377 | LsnAllocate
```
L'esempio seguente unisce `aurora_stat_wait_type` e `aurora_stat_wait_event` per restituire nomi di tipo e nomi di eventi per una migliore leggibilità.
```
=> SELECT *
FROM aurora_stat_wait_type() t
JOIN aurora_stat_wait_event() e
ON t.type_id = e.type_id;
type_id | type_name | type_id | event_id | event_name
---------+-----------+---------+-----------+-------------------------------------------
1 | LWLock | 1 | 16777216 |
1 | LWLock | 1 | 16777217 | ShmemIndexLock
1 | LWLock | 1 | 16777218 | OidGenLock
1 | LWLock | 1 | 16777219 | XidGenLock
1 | LWLock | 1 | 16777220 | ProcArrayLock
.
.
.
3 | Lock | 3 | 50331648 | relation
3 | Lock | 3 | 50331649 | extend
3 | Lock | 3 | 50331650 | page
3 | Lock | 3 | 50331651 | tuple
.
.
.
10 | IO | 10 | 167772214 | TimelineHistorySync
10 | IO | 10 | 167772215 | TimelineHistoryWrite
10 | IO | 10 | 167772216 | TwophaseFileRead
10 | IO | 10 | 167772217 | TwophaseFileSync
.
.
.
11 | LSN | 11 | 184549376 | LsnDurable
```
# aurora\$1stat\$1wait\$1type
Elenca tutti i tipi di attesa supportati per Aurora PostgreSQL.
## Sintassi
```
aurora_stat_wait_type()
```
## Argomenti
Nessuno
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ type\$1id: ID del tipo di evento di attesa.
+ type\$1name: nome del tipo di attesa
## Note per l'utilizzo
Per visualizzare i nomi degli eventi di attesa con tipi di eventi di attesa anziché ID, utilizzare questa funzione insieme ad altre funzioni come `aurora_stat_wait_event` e `aurora_stat_system_waits`. I nomi dei tipi di attesa restituiti da questa funzione sono gli stessi di quelli restituiti dalla funzione `aurora_wait_report`.
## Esempi
Nell'esempio seguente vengono mostrati i risultati della chiamata alla funzione `aurora_stat_wait_type`.
```
=> SELECT *
FROM aurora_stat_wait_type();
type_id | type_name
---------+-----------
1 | LWLock
3 | Lock
4 | BufferPin
5 | Activity
6 | Client
7 | Extension
8 | IPC
9 | Timeout
10 | IO
11 | LSN
```
# aurora\$1version
Restituisce il valore di stringa del numero di versione di Amazon Aurora PostgreSQL-Compatible Edition.
## Sintassi
```
aurora_version()
```
## Argomenti
Nessuno
## Tipo restituito
Stringa CHAR o VARCHAR
## Note per l'utilizzo
Questa funzione visualizza la versione del motore di database di Amazon Aurora PostgreSQL-Compatible Edition. Il numero di versione viene restituito come stringa formattata come *principale*.*secondaria*.*patch*. Per ulteriori informazioni sui numeri di versione del motore Aurora PostgreSQL, consulta [Numero versione Aurora](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions.AuroraNumber)
Puoi scegliere quando applicare aggiornamenti di versione secondaria impostando la finestra di manutenzione per il cluster database Aurora PostgreSQL. Per scoprire come fare, consulta [Manutenzione di un cluster di database Amazon Aurora](USER_UpgradeDBInstance.Maintenance.md).
A partire dal rilascio di PostgreSQL versioni 13.3, 12.8, 11.13, 10.18 e per tutte le altre versioni successive, i numeri di versione di Aurora seguono i numeri di versione di PostgreSQL. Per ulteriori informazioni su questa versione, consulta [Aggiornamenti di Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) nelle *Note di rilascio di Aurora PostgreSQL*.
## Esempi
L'esempio seguente mostra i risultati della chiamata della funzione `aurora_version` su un cluster database Aurora PostgreSQL in esecuzione prima su [PostgreSQL 12.7, Aurora PostgreSQL versione 4.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.42) e poi su [Aurora PostgreSQL versione 13.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.133X).
```
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
```
Questo esempio mostra varie opzioni di utilizzo della funzione per ottenere maggiori dettagli sulla versione di Aurora PostgreSQL. In questo esempio Aurora presenta un numero di versione distinto rispetto a PostgreSQL.
```
=> SHOW SERVER_VERSION;
server_version
----------------
12.7
(1 row)
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
(1 row)
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
12.7
(1 row)
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------------------
PostgreSQL 12.7 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 7.4.0, 64-bit
(1 row)
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
------------------------------------------------
Aurora: 4.2.2 Compatible with PostgreSQL: 12.7
(1 row)
```
Nell'esempio successivo, la funzione viene utilizzata con le stesse opzioni dell'esempio precedente. In questo esempio il numero di versione di Aurora non è distinto rispetto al numero di versione di PostgreSQL.
```
=> SHOW SERVER_VERSION;
server_version
----------------
13.3
=> SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
13.3
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------
PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 7.4.0, 64-bit
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
-------------------------------------------------------
Aurora: 13.3.0 Compatible with PostgreSQL: 13.3
```
# aurora\$1volume\$1logical\$1start\$1lsn
Restituisce il numero di sequenza di log (LSN) utilizzato per identificare l'inizio di un record nel flusso WAL (write-ahead log) logico del volume del cluster Aurora.
## Sintassi
```
aurora_volume_logical_start_lsn()
```
## Argomenti
Nessuno
## Tipo restituito
`pg_lsn`
## Note per l'utilizzo
Questa funzione identifica l'inizio del record nel flusso WAL logico per un determinato volume del cluster Aurora. È possibile utilizzare questa funzione durante l'aggiornamento della versione principale utilizzando la replica logica e la clonazione rapida Aurora per determinare il numero di sequenza di log in corrispondenza del quale viene eseguito uno snapshot o un clone del database. È quindi possibile utilizzare la replica logica per trasmettere continuamente i record di dati più recenti dopo il numero di sequenza di log e sincronizzare le modifiche da editore a sottoscrittore.
Per ulteriori informazioni sull'utilizzo della replica logica per l'aggiornamento di una versione principale, consulta [Utilizzo della replica logica per eseguire l'aggiornamento a una versione principale per Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
Questa funzione è disponibile per le seguenti versioni di Aurora PostgreSQL:
+ 15.2 o versioni successive alla 15
+ 14.3 o versioni successive alla 14
+ 13.6 o versioni successive alla 13
+ 12.10 e versioni successive alla 12
+ 11.15 e versioni successive alla 11
+ 10.20 e versioni successive alla 10
## Esempi
È possibile ottenere il numero di sequenza di log utilizzando la seguente query:
```
postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn
---------------
0/402E2F0
(1 row)
```
# aurora\$1wait\$1report
Questa funzione mostra l'attività dell'evento di attesa durante un periodo di tempo.
## Sintassi
```
aurora_wait_report([time])
```
## Argomenti
*tempo (facoltativo) *
Il tempo in secondi. Il valore predefinito è 10 secondi.
## Tipo restituito
Record SETOF avente le seguenti colonne:
+ type\$1name: nome del tipo di attesa
+ event\$1name: nome dell’evento di attesa
+ wait: numero di attese
+ wait\$1time: tempo di attesa in millisecondi
+ ms\$1per\$1wait: durata media di un’attesa in millisecondi
+ waits\$1per\$1xact: media delle attese per ogni transazione
+ ms\$1per\$1xact: durata media di una transizione in millisecondi
## Note per l'utilizzo
Questa funzione è disponibile a partire da Aurora PostgreSQL versione 1.1 compatibile con PostgreSQL 9.6.6 e versioni successive.
Per utilizzare questa funzione è necessario innanzitutto creare l’estensione `aurora_stat_utils` Aurora PostgreSQL, nel modo seguente:
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Per ulteriori informazioni sulle versioni dell'estensione Aurora PostgreSQL disponibili, consulta [Versioni delle estensioni per Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in *Note di rilascio di Aurora PostgreSQL*.
Questa funzione calcola gli eventi di attesa a livello di istanza confrontando i dati statistici di due snapshot della funzione aurora\$1stat\$1system\$1waits () e di pg\$1stat\$1database, acquisite dalla vista delle statistiche di PostgreSQL.
Per ulteriori informazioni su `aurora_stat_system_waits()` e `pg_stat_database`, consulta [Raccolta di statistiche](https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-DATABASE-VIEW) nella *documentazione di PostgreSQL*.
Quando è in esecuzione, questa funzione acquisisce una snapshot iniziale, attende il numero di secondi specificato e acquisisce una seconda snapshot. La funzione confronta le due snapshot e restituisce la differenza. Questa differenza rappresenta l'attività dell'istanza in quell'intervallo di tempo.
Sull'istanza di scrittura, la funzione visualizza anche il numero di transazioni di cui è stato eseguito il commit e il TPS (transazioni al secondo). Questa funzione restituisce informazioni a livello di istanza e include tutti i database sull'istanza.
## Esempi
Questo esempio mostra come creare l’estensione aurora\$1stat\$1utils per poter utilizzare la funzione aurora\$1wait\$1report.
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Questo esempio mostra come controllare il report delle attese per 10 secondi.
```
=> SELECT *
FROM aurora_wait_report();
NOTICE: committed 34 transactions in 10 seconds (tps 3)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+-------------------+-------+-----------+-------------+----------------+-------------
Client | ClientRead | 26 | 30003.00 | 1153.961 | 0.76 | 882.441
Activity | WalWriterMain | 50 | 10051.32 | 201.026 | 1.47 | 295.627
Timeout | PgSleep | 1 | 10049.52 | 10049.516 | 0.03 | 295.574
Activity | BgWriterHibernate | 1 | 10048.15 | 10048.153 | 0.03 | 295.534
Activity | AutoVacuumMain | 18 | 9941.66 | 552.314 | 0.53 | 292.402
Activity | BgWriterMain | 1 | 201.09 | 201.085 | 0.03 | 5.914
IO | XactSync | 15 | 25.34 | 1.690 | 0.44 | 0.745
IO | RelationMapRead | 12 | 0.54 | 0.045 | 0.35 | 0.016
IO | WALWrite | 84 | 0.21 | 0.002 | 2.47 | 0.006
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.03 | 0.001
```
Questo esempio mostra come controllare il report delle attese per 60 secondi.
```
=> SELECT *
FROM aurora_wait_report(60);
NOTICE: committed 1544 transactions in 60 seconds (tps 25)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+------------------------+---------+-----------+-------------+----------------+-------------
Lock | transactionid | 6422 | 477000.53 | 74.276 | 4.16 | 308.938
Client | ClientRead | 8265 | 270752.99 | 32.759 | 5.35 | 175.358
Activity | CheckpointerMain | 1 | 60100.25 | 60100.246 | 0.00 | 38.925
Timeout | PgSleep | 1 | 60098.49 | 60098.493 | 0.00 | 38.924
Activity | WalWriterMain | 296 | 60010.99 | 202.740 | 0.19 | 38.867
Activity | AutoVacuumMain | 107 | 59827.84 | 559.139 | 0.07 | 38.749
Activity | BgWriterMain | 290 | 58821.83 | 202.834 | 0.19 | 38.097
IO | XactSync | 1295 | 55220.13 | 42.641 | 0.84 | 35.764
IO | WALWrite | 6602259 | 47810.94 | 0.007 | 4276.07 | 30.966
Lock | tuple | 473 | 29880.67 | 63.173 | 0.31 | 19.353
LWLock | buffer_mapping | 142 | 3540.13 | 24.930 | 0.09 | 2.293
Activity | BgWriterHibernate | 290 | 1124.15 | 3.876 | 0.19 | 0.728
IO | BufFileRead | 7615 | 618.45 | 0.081 | 4.93 | 0.401
LWLock | buffer_content | 73 | 345.93 | 4.739 | 0.05 | 0.224
LWLock | lock_manager | 62 | 191.44 | 3.088 | 0.04 | 0.124
IO | RelationMapRead | 72 | 5.16 | 0.072 | 0.05 | 0.003
LWLock | ProcArrayLock | 1 | 2.01 | 2.008 | 0.00 | 0.001
IO | ControlFileWriteUpdate | 2 | 0.03 | 0.013 | 0.00 | 0.000
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.00 | 0.000
IO | ControlFileSyncUpdate | 1 | 0.00 | 0.000 | 0.00 | 0.000
```