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à.
# 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)
```