Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Référence sur les fonctions Aurora PostgreSQL
Vous trouverez ci-dessous une liste des fonctions Aurora PostgreSQL disponibles pour vos clusters de bases de données Aurora qui exécutent le moteur de base de données compatible avec l'édition Aurora PostgreSQL. Ces fonctions Aurora PostgreSQL s'ajoutent aux fonctions PostgreSQL standard. Pour de plus amples informations sur les fonctions PostgreSQL standard, consultez [PostgreSQL : fonctions et opérateurs](https://www.postgresql.org/docs/current/functions.html).
## Présentation de
Vous pouvez utiliser les fonctions suivantes pour les instances de base de données Amazon RDS exécutant 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
Indique nom de l'instance de base de données à laquelle vous êtes connecté.
## Syntaxe
```
aurora_db_instance_identifier()
```
## Arguments
Aucun
## Type de retour
Chaîne VARCHAR
## Notes d’utilisation
Cette fonction affiche le nom de l'instance de base de données du cluster d'Aurora Édition compatible avec PostgreSQL pour la connexion de votre client de base de données ou de votre application.
Cette fonction est disponible à partir de la version d'Aurora PostgreSQL 13.7, 12.11, 11.16, 10.21 et pour toutes les autres versions ultérieures.
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `aurora_db_instance_identifier`.
```
=> SELECT aurora_db_instance_identifier();
aurora_db_instance_identifier
-------------------------------
test-my-instance-name
```
Vous pouvez joindre les résultats de cette fonction avec la fonction `aurora_replica_status` pour obtenir des détails sur l'instance de base de données pour votre connexion. La fonction [aurora\$1replica\$1status](aurora_replica_status.md) seule ne vous indique pas l'instance de base de données que vous utilisez. L'exemple suivant vous montre comment procéder.
```
=> 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
Affiche l'état du gestionnaire de cache du cluster.
## Syntaxe
```
aurora_ccm_status()
```
## Arguments
Aucune.
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ `buffers_sent_last_minute` – Nombre de tampons envoyés au lecteur désigné au cours de la dernière minute.
+ `buffers_found_last_minute` : nombre de tampons fréquemment consultés, identifiés au cours de la dernière minute.
+ `buffers_sent_last_scan` – Nombre de tampons envoyés au lecteur désigné au cours de la dernière analyse terminée du cache du tampon.
+ `buffers_found_last_scan` – Nombre de tampons fréquemment consultés envoyés au cours de la dernière analyse terminée du cache du tampon. Les tampons déjà mis en cache sur le lecteur désigné ne sont pas envoyés.
+ `buffers_sent_current_scan` – Nombre de tampons envoyés au cours de l'analyse actuelle.
+ `buffers_found_current_scan` – Nombre de tampons fréquemment consultés qui ont été identifiés au cours de l'analyse actuelle.
+ `current_scan_progress` – Nombre de tampons visités jusqu'à maintenant au cours de l'analyse actuelle.
## Notes d’utilisation
Vous pouvez utiliser cette fonction pour vérifier et surveiller la fonctionnalité de gestion de cache du cluster (CCM). Cette fonction fonctionne uniquement si la CCM est active sur votre cluster de bases de données Aurora PostgreSQL. Pour utiliser cette fonction, connectez-vous à l'instance de base de données d'écriture sur votre cluster de bases de données Aurora PostgreSQL.
Activez la CCM pour un cluster de bases de données Aurora PostgreSQL en définissant `apg_ccm_enabled` sur 1 dans le groupe de paramètres de cluster de bases de données personnalisé du cluster. Pour savoir comment procéder, veuillez consulter la section [Configuration de la gestion des caches de clusters](AuroraPostgreSQL.cluster-cache-mgmt.md#AuroraPostgreSQL.cluster-cache-mgmt.Configure).
La gestion de cache du cluster est active sur un cluster de bases de données Aurora PostgreSQL lorsque le cluster dispose d'une instance Aurora Reader configurée comme suit :
+ L'instance Aurora Reader utilise le même type et la même taille de classe d'instance de base de données que l'instance d'enregistreur du cluster.
+ L'instance Aurora Reader est configurée en tant que niveau 0 pour le cluster. Si le cluster possède plusieurs lecteurs, il s'agit de son seul lecteur de niveau 0.
La définition de plusieurs lecteurs sur le niveau 0 désactive la CCM. Lorsque la CCM est désactivée, l'appel de cette fonction renvoie le message d'erreur suivant :
```
ERROR: Cluster Cache Manager is disabled
```
Vous pouvez également utiliser l'extension pg\$1buffercache PostgreSQL pour analyser le cache du tampon. Pour plus d'informations, consultez [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html) dans la documentation de PostgreSQL.
Pour plus d'informations, consultez [Introduction to Aurora PostgreSQL cluster cache management](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/).
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `aurora_ccm_status`. Ce premier exemple montre les statistiques CCM.
```
=> 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
```
Pour plus de détails, vous pouvez utiliser l'affichage développé, comme indiqué ci-dessous :
```
\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
```
Cet exemple montre comment vérifier le débit d'activation et le pourcentage d'activation.
```
=> 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
Affiche l'état de toutes les instances Aurora, y compris les réplicas dans un cluster de bases de données global Aurora.
## Syntaxe
```
aurora_global_db_instance_status()
```
## Arguments
Aucun
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ `server_id` – Identifiant de l'instance de base de données.
+ `session_id` – Identifiant unique de la session en cours. La valeur `MASTER_SESSION_ID` identifie l'instance de base de données d'enregistreur (principale).
+ `aws_region` – La Région AWS dans laquelle cette instance de base de données globale s'exécute. Pour obtenir la liste des régions, consultez [Disponibilité dans les Régions](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ `durable_lsn` – Numéro de séquence de journal (LSN) rendu durable dans le stockage. Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont classés de telle sorte qu'un LSN plus grand représente une transaction ultérieure.
+ `highest_lsn_rcvd` – LSN le plus élevé reçu par l'instance de base de données en provenance de l'instance de base de données d'enregistreur.
+ `feedback_epoch` – Époque utilisée par l'instance de base de données lorsqu'elle génère des informations de zone hébergée. Le terme *zone hébergée* fait référence à une instance de base de données qui prend en charge les connexions et les requêtes pendant que la base de données principale est en mode de récupération ou en mode veille. Les informations de zone hébergée incluent l'époque (instant dans le passé) et d'autres détails sur l'instance de base de données utilisée comme une zone hébergée. Pour de plus amples informations, veuillez consulter la documentation PostgreSQL sur [Veille à chaud](https://www.postgresql.org/docs/current/hot-standby.html).
+ `feedback_xmin` – ID de transaction actif minimal (le plus ancien) utilisé par l'instance de base de données.
+ `oldest_read_view_lsn` : le LSN le plus ancien utilisé par l'instance de base de données pour lire à partir du stockage.
+ `visibility_lag_in_msec` – Latence de cette instance de base de données par rapport à l'instance de base de données d'enregistreur en millisecondes.
## Notes d’utilisation
Cette fonction affiche les statistiques de réplication pour un cluster de bases de données Aurora. Pour chaque instance de base de données Aurora PostgreSQL du cluster, la fonction affiche une ligne de données qui inclut tous les réplicas entre régions dans une configuration de base de données globale.
Vous pouvez exécuter cette fonction à partir de n'importe quelle instance d'un cluster de bases de données Aurora PostgreSQL ou d'une base de données globale Aurora PostgreSQL. La fonction renvoie des détails sur la latence décalage pour toutes les instances de réplica.
Pour en savoir plus sur la surveillance de la latence à l'aide de cette fonction (`aurora_global_db_instance_status`) ou de `aurora_global_db_status`, consultez [Surveillance des bases de données globales basées sur Aurora PostgreSQL](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres).
Pour plus d'informations sur les bases de données globales Aurora, consultez [Présentation d’Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
Pour commencer à utiliser les bases de données globales Aurora, consultez [Mise en route avec Amazon Aurora Global Database](aurora-global-database-getting-started.md) ou la [FAQ Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/).
## Exemples
Cet exemple montre les statistiques des instances entre régions.
```
=> 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
```
Cet exemple montre comment vérifier la latence de réplica globale en millisecondes.
```
=> 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
```
Cet exemple montre comment vérifier la latence minimale, maximale et moyenne par Région AWS à partir de la configuration de base de données 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
Affiche des informations sur divers aspects du retard de la base de données globale Aurora, en particulier le retard du stockage Aurora sous-jacent (appelé « retard de durabilité ») et le retard entre l’objectif de point de reprise (RPO).
## Syntaxe
```
aurora_global_db_status()
```
## Arguments
Aucune.
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ `aws_region` : Région AWS dans laquelle se trouve ce cluster de bases de données. Pour obtenir la liste complète des Régions AWS par moteur, consultez [ Régions et zones de disponibilité](Concepts.RegionsAndAvailabilityZones.md).
+ `highest_lsn_written` – Numéro de séquence de journal (LSN) le plus élevé actuellement existant sur ce cluster de bases de données. Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont classés de telle sorte qu’un LSN plus grand représente une transaction ultérieure.
+ `durability_lag_in_msec` – Différence dans les valeurs d’horodatage entre `highest_lsn_written` sur un cluster de bases de données secondaire et `highest_lsn_written` sur le cluster de bases de données principal. La valeur -1 identifie le cluster de bases de données principal de la base de données globale Aurora.
+ `rpo_lag_in_msec` : retard de l’objectif de point de reprise (RPO). Le retard RPO correspond au temps nécessaire au stockage de la transaction utilisateur COMMIT la plus récente sur un cluster de bases de données secondaire, après qu’elle a été stockée sur le cluster de bases de données principal de la base de données globale Aurora. La valeur -1 indique le cluster de bases de données principal (le retard n’est donc pas pertinent).
En termes simples, cette métrique calcule l’objectif de point de reprise pour chaque cluster de bases de données Aurora PostgreSQL dans la base de données globale Aurora, c’est-à-dire la quantité de données qui risque d’être perdue en cas de panne. Comme pour la latence, le RPO est mesuré dans le temps.
+ `last_lag_calculation_time` – Horodatage qui spécifie l’heure à laquelle les valeurs ont été calculées pour la dernière fois pour `durability_lag_in_msec` et `rpo_lag_in_msec`. Une valeur temporelle telle que `1970-01-01 00:00:00+00` signifie qu’il s’agit du cluster de bases de données principal.
+ `feedback_epoch` – Époque utilisée par le cluster de bases de données secondaire lorsqu’il génère des informations de zone hébergée. Le terme *zone hébergée* fait référence à une instance de base de données qui prend en charge les connexions et les requêtes pendant que la base de données principale est en mode de récupération ou en mode veille. Les informations de zone hébergée incluent l’époque (instant dans le passé) et d’autres détails sur l’instance de base de données utilisée comme une zone hébergée. Pour plus d’informations, consultez [Veille à chaud](https://www.postgresql.org/docs/current/hot-standby.html) dans la documentation PostgreSQL.
+ `feedback_xmin` – ID de transaction actif minimum (le plus ancien) utilisé par un cluster de bases de données secondaire.
## Notes d’utilisation
Toutes les versions actuellement disponibles d’Aurora PostgreSQL prennent en charge cette fonction. Cette fonction affiche les statistiques de réplication pour une base de données globale Aurora. Elle affiche une ligne pour chaque cluster de bases de données dans une base de données globale Aurora PostgreSQL. Vous pouvez exécuter cette fonction à partir de n’importe quelle instance de votre base de données globale Aurora PostgreSQL.
Pour évaluer la latence de réplication de la base de données globale Aurora, qui est la latence des données visible, consultez [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md).
Pour en savoir plus sur l’utilisation de `aurora_global_db_status` et `aurora_global_db_instance_status` pour surveiller la latence de la base de données globale Aurora, consultez [Surveillance des bases de données globales basées sur Aurora PostgreSQL](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres). Pour plus d’informations sur les bases de données globales Aurora, consultez [Présentation d’Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
## Exemples
Cet exemple montre comment afficher les statistiques de stockage entre régions.
```
=> 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
Répertorie toutes les fonctions intégrées disponibles d'Aurora PostgreSQL, ainsi que de brèves descriptions et des détails sur les fonctions.
## Syntaxe
```
aurora_list_builtins()
```
## Arguments
Aucun
## Type de retour
Registre SETOF
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `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
Affiche l’état de tous les nœuds de lecture Aurora PostgreSQL.
## Syntaxe
```
aurora_replica_status()
```
## Arguments
Aucun
## Type de retour
Registre SETOF avec les colonnes suivantes :
+ `server_id` : l’ID (identifiant) de l’instance de base de données.
+ `session_id` : un identifiant unique pour la séance en cours, renvoyé pour l’instance principale et les instances de lecture comme suit :
+ Pour l’instance principale, `session_id` est toujours égal à ``MASTER_SESSION_ID’`.
+ Pour les instances de lecture, `session_id` est toujours égal au `UUID` (identifiant universel et unique) de l’instance de lecture.
+ `durable_lsn` : le numéro de séquence du journal (LSN) qui a été stocké.
+ Pour le volume principal, le LSN durable du volume principal (VDL) actuellement en vigueur.
+ Pour tout volume secondaire, le VDL du volume principal sur lequel le volume secondaire a été appliqué.
**Note**
Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont ordonnés de telle sorte qu’un LSN plus grand représente une transaction qui a eu lieu plus tard dans la séquence.
+ `highest_lsn_rcvd` : le LSN le plus élevé (le plus récent) reçu par l’instance de base de données en provenance de l’instance de base de données en écriture.
+ `current_read_lsn` : le LSN de l’instantané le plus récent qui a été appliqué à tous les lecteurs.
+ `cur_replay_latency_in_usec` : le nombre de microsecondes attendu pour relire le journal sur le volume secondaire.
+ `active_txns` : le nombre de transactions actuellement actives.
+ `is_current` : non utilisé.
+ `last_transport_error` : dernier code d’erreur de réplication.
+ `last_error_timestamp` : horodatage de la dernière erreur de réplication.
+ `last_update_timestamp` : horodatage de la dernière mise à jour de l’état du réplica. Depuis Aurora PostgreSQL 13.9, la valeur de `last_update_timestamp` pour l’instance de base de données à laquelle vous êtes connecté est définie sur `NULL`.
+ `feedback_xmin` : la valeur feedback\$1xmin de secours du réplica. ID de transaction actif minimum (le plus ancien) utilisé par l’instance de base de données.
+ `feedback_epoch` : l’époque utilisée par l’instance de base de données lorsqu’elle génère des informations de secours.
+ `replica_lag_in_msec` : temps de retard de l’instance de lecteur par rapport à l’instance d’enregistreur, en millisecondes.
+ `log_stream_speed_in_kib_per_second` : le débit du flux des journaux en kilo-octets par seconde.
+ `log_buffer_sequence_number` : le numéro de séquence de la mémoire tampon du journal.
+ `oldest_read_view_trx_id` : non utilisé.
+ `oldest_read_view_lsn` : LSN le plus ancien utilisé par l’instance de base de données pour lire à partir du stockage.
+ `pending_read_ios` : les lectures de pages en suspens qui sont toujours en attente sur le réplica.
+ `read_ios` : le nombre total de pages lues sur le réplica.
+ `iops` : non utilisé.
+ `cpu` : utilisation du processeur par le démon de stockage Aurora pour chaque nœud du cluster. Pour plus d’informations sur l’utilisation du CPU par l’instance, consultez [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
## Notes d’utilisation
Toutes les versions actuellement disponibles d’Aurora PostgreSQL prennent en charge cette fonction. La fonction `aurora_replica_status` renvoie les valeurs du gestionnaire d’état des réplicas d’un cluster de bases de données Aurora PostgreSQL. Vous pouvez utiliser cette fonction pour obtenir des informations sur l’état de la réplication sur votre cluster de bases de données Aurora PostgreSQL, y compris les métriques pour toutes les instances de base de données dans votre cluster de bases de données Aurora. Par exemple, vous pouvez effectuer les opérations suivantes :
+ **Get information about the type of instance (writer, reader) in the Aurora PostgreSQL DB cluster** (Obtenir des informations sur le type d’instance (écriture, lecture) dans le cluster de bases de données Aurora PostgreSQL) : vous pouvez obtenir ces informations en lisant les valeurs des colonnes suivantes :
+ `server_id` : contient le nom de l’instance que vous avez spécifié lorsque vous avez créé l’instance. Dans certains cas, comme pour l’instance principale (écriture), le nom est généralement créé pour vous en ajoutant *-instance-1* au nom spécifié pour votre cluster de bases de données Aurora PostgreSQL.
+ `session_id` : le champ `session_id` indique si l’instance est une instance de lecture ou d’écriture. Pour une instance d’enregistreur, `session_id` est toujours défini sur `"MASTER_SESSION_ID"`. Pour une instance de lecture, `session_id` est défini sur l’`UUID` de l’instance de lecture en question.
+ **Diagnose common replication issues, such as replica lag** (Diagnostiquer les problèmes de réplication courants, tels que le retard de réplica) : le retard de réplica est le temps, en millisecondes, pendant lequel le cache des pages d’une instance de lecture est en retard sur celui de l’instance d’enregistreur. Ce retard se produit parce que les clusters Aurora utilisent la réplication asynchrone, comme décrit dans [Réplication avec Amazon Aurora](Aurora.Replication.md). La valeur est indiquée dans la colonne `replica_lag_in_msec` des résultats renvoyés par cette fonction. Un retard peut également se produire lorsqu’une requête est annulée en raison de conflits avec la récupération sur un serveur de veille. Vous pouvez consulter `pg_stat_database_conflicts()` pour vérifier qu’un tel conflit est à l’origine du retard du réplica (ou non). Pour plus d’informations, consultez [The Statistics Collector](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW) (Collecteur de statistiques) dans la *documentation de PostgreSQL*. Pour en savoir plus sur la haute disponibilité et la réplication, consultez la [FAQ Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication).
Amazon CloudWatch enregistre les résultats `replica_lag_in_msec` dans le temps, en tant que métrique `AuroraReplicaLag`. Pour obtenir plus d’informations sur l’utilisation des métriques CloudWatch pour Aurora, consultez [Surveillance des métriques (Amazon Aurora) avec Amazon CloudWatch](monitoring-cloudwatch.md).
Pour en savoir plus sur le dépannage et les redémarrages des réplicas en lecture Aurora, consultez la section [Why did my Amazon Aurora read replica fall behind and restart?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/) (Pourquoi mon réplica en lecture Amazon Aurora a-t-il pris du retard et redémarré ?) dans le [Centre AWS Support](https://console.aws.amazon.com/support/home#/).
## Exemples
L’exemple suivant montre comment obtenir l’état de réplication de toutes les instances d’un cluster de bases de données Aurora PostgreSQL :
```
=> SELECT *
FROM aurora_replica_status();
```
L’exemple suivant montre l’instance d’enregistreur dans le cluster de bases de données Aurora PostgreSQL `docs-lab-apg-main` :
```
=> 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
```
L’exemple suivant répertorie toutes les instances de lecture d’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)
```
L’exemple suivant répertorie toutes les instances, le retard de chaque instance par rapport à l’instance d’enregistreur et le temps écoulé depuis la dernière mise à jour :
```
=> 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
Renvoie une ligne par processus serveur, affichant les informations relatives à l’activité actuelle de ce processus.
## Syntaxe
```
aurora_stat_activity();
```
## Arguments
Aucun
## Type de retour
Renvoie une ligne par processus serveur. Outre les colonnes `pg_stat_activity`, le champ suivant est ajouté :
+ planid — identifiant du plan
## Notes d’utilisation
Vue supplémentaire de `pg_stat_activity` renvoyant des mêmes colonnes avec une colonne `plan_id` supplémentaire qui montre le plan d’exécution de la requête.
`aurora_compute_plan_id` doit être activé pour que la vue renvoie un plan\$1id.
Cette fonction est disponible à partir des versions d’Aurora PostgreSQL 14.10, 15.5 et pour toutes les autres versions ultérieures.
## Exemples
L’exemple de requête ci-dessous agrège la charge maximale par query\$1id et 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)
```
Si le plan utilisé pour query\$1id change, un nouveau plan\$1id sera indiqué par aurora\$1stat\$1activity.
```
count | query_id | plan_id
-------+----------------------+-------------
10 | -5471422286312252535 | 1602979607
1 | -6907107586630739258 | -1809935983
1 | -2446282393000597155 | -207532066
(3 rows)
```
# aurora\$1stat\$1backend\$1waits
Affiche les statistiques relatives à l'activité d'attente pour un processus de backend spécifique.
## Syntaxe
```
aurora_stat_backend_waits(pid)
```
## Arguments
`pid` – ID du processus de backend. Vous pouvez obtenir des ID de processus à l'aide de la vue `pg_stat_activity`.
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ `type_id` – Nombre qui indique le type d'événement d'attente, tel que `1` pour un verrou léger (`LWLock`), `3` pour un verrou, ou `6` pour une session client, pour en citer quelques exemples. Ces valeurs deviennent significatives lorsque vous joignez les résultats de cette fonction avec des colonnes issues de la fonction `aurora_stat_wait_type`, comme illustré dans les [Exemples](#aurora_stat_backend_waits-examples).
+ `event_id` – Numéro d'identification de l'événement d'attente. Joignez cette valeur aux colonnes issues de `aurora_stat_wait_event` pour obtenir des noms d'événement significatifs.
+ `waits` – Nombre d'attentes cumulées pour l'ID de processus spécifié.
+ `wait_time` – Temps d'attente en millisecondes.
## Notes d’utilisation
Vous pouvez utiliser cette fonction pour analyser des événements d'attente (session) de backend spécifiques, survenus depuis l'ouverture d'une connexion. Pour obtenir des informations plus significatives sur les noms et les types d'événements d'attente, vous pouvez combiner cette fonction `aurora_stat_wait_type` et `aurora_stat_wait_event` à l'aide de JOIN, comme indiqué dans les exemples.
## Exemples
Cet exemple illustre toutes les attentes, tous les types et tous les noms d'événement pour l'ID de processus de backend 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
```
Cet exemple illustre les types d'attentes et les événements d'attente actuels et cumulatifs pour toutes les sessions actives (`pg_stat_activity state <> 'idle'`) (mais sans la session actuelle qui appelle la fonction (`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
```
Cet exemple illustre les trois (3) premiers types d'attente et événements d'attente cumulatifs en cours pour toutes les sessions actives (`pg_stat_activity state <> 'idle'`), à l'exception de la session actuelle (`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` est une vue statistique comprenant des informations sur les écritures dans le cache Optimized Reads.
## Syntaxe
```
aurora_stat_bgwriter()
```
## Arguments
Aucun
## Type de retour
Registre SETOF contenant toutes les colonnes `pg_stat_bgwriter` et les colonnes supplémentaires suivantes. Pour plus d'informations sur les colonnes `pg_stat_bgwriter`, consultez [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).
Vous pouvez réinitialiser les statistiques de cette fonctionnalité en utilisant `pg_stat_reset_shared("bgwriter")`.
+ `orcache_blks_written` : nombre total de blocs de données écrits dans le cache Optimized Reads.
+ `orcache_blk_write_time` : si `track_io_timing` est activé, le temps total passé à écrire des blocs de données dans le cache Optimized Reads est enregistré en millisecondes. Pour plus d'informations, consultez [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
## Notes d’utilisation
Cette fonctionnalité est disponible dans les versions suivantes d'Aurora PostgreSQL :
+ Version 15.4 et versions 15 ultérieures
+ Version 14.9 et versions 14 ultérieures
## Exemples
```
=> select * from aurora_stat_bgwriter();
-[ RECORD 1 ]-----------------+-----------
orcache_blks_written | 246522
orcache_blk_write_time | 339276.404
```
# aurora\$1stat\$1database
Elle contient toutes les colonnes de pg\$1stat\$1database et en ajoute de nouvelles à la fin.
## Syntaxe
```
aurora_stat_database()
```
## Arguments
Aucun
## Type de retour
Registre SETOF contenant toutes les colonnes `pg_stat_database` et les colonnes supplémentaires suivantes. Pour plus d'informations sur les colonnes `pg_stat_database`, consultez [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` : nombre total de blocs partagés lus à partir du stockage Aurora dans cette base de données.
+ `orcache_blks_hit` : nombre total d'accès au cache Optimized Reads dans cette base de données.
+ `local_blks_read` : nombre total de blocs locaux lus dans cette base de données.
+ `storage_blk_read_time` : si `track_io_timing` est activé, le temps total passé à lire des blocs de données à partir du stockage Aurora est enregistré en millisecondes, sinon la valeur est nulle. Pour plus d'informations, consultez [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time` : si `track_io_timing` est activé, le temps total passé à lire des blocs de données locales est enregistré en millisecondes, sinon la valeur est nulle. Pour plus d'informations, consultez [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time` : si `track_io_timing` est activé, le temps total passé à lire des blocs de données à partir du cache Optimized Reads est enregistré en millisecondes, sinon la valeur est nulle. Pour plus d'informations, consultez [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
**Note**
La valeur de `blks_read` est la somme de `storage_blks_read`, `orcache_blks_hit` et `local_blks_read`.
La valeur de `blk_read_time` est la somme de `storage_blk_read_time`, `orcache_blk_read_time` et `local_blk_read_time`.
## Notes d’utilisation
Cette fonctionnalité est disponible dans les versions suivantes d'Aurora PostgreSQL :
+ Version 15.4 et versions 15 ultérieures
+ Version 14.9 et versions 14 ultérieures
## Exemples
L'exemple suivant montre comment elle transporte toutes les colonnes `pg_stat_database` et en ajoute six nouvelles à la fin :
```
=> 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
Indique l'activité cumulative pour chaque type d'opération de langage de manipulation de données (DML) sur une base de données dans un cluster Aurora PostgreSQL.
## Syntaxe
```
aurora_stat_dml_activity(database_oid)
```
## Arguments
*database\$1oid*
ID d'objet (OID) de la base de données dans le cluster Aurora PostgreSQL.
## Type de retour
Registre SETOF
## Notes d’utilisation
La fonction `aurora_stat_dml_activity` est disponible uniquement avec Aurora PostgreSQL version 3.1 compatible avec le moteur PostgreSQL 11.6 et versions ultérieures.
Utilisez cette fonction sur les clusters Aurora PostgreSQL avec un grand nombre de bases de données pour identifier les bases de données qui ont une activité DML supérieure ou plus lente, ou les deux.
La fonction `aurora_stat_dml_activity` renvoie le nombre de fois que les opérations ont été exécutées et la latence cumulative en microsecondes pour les opérations SELECT, INSERT, UPDATE et DELETE. Le rapport inclut uniquement les opérations DML réussies.
Vous pouvez réinitialiser cette statistique à l'aide de la fonction d'accès aux statistiques PostgreSQL `pg_stat_reset`. Vous pouvez vérifier quand cette statistique a été réinitialisée pour la dernière fois à l'aide de la fonction `pg_stat_get_db_stat_reset_time`. Pour plus d'informations sur les fonctions d'accès aux statistiques PostgreSQL, consultez [Collecteur de statistiques](https://www.postgresql.org/docs/9.1/monitoring-stats.html) dans la documentation PostgreSQL.
## Exemples
L'exemple suivant montre comment signaler les statistiques d'activité DML pour la base de données connectée.
```
––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'exemple suivant montre les statistiques d'activité DML pour toutes les bases de données du cluster Aurora PostgreSQL. Ce groupe comprend deux bases de données, `postgres` et `mydb`. La liste séparée par des virgules correspond aux champs `select_count`, `select_latency_microsecs`, `insert_count`, `insert_latency_microsecs`, `update_count`, `update_latency_microsecs`, `delete_count` et `delete_latency_microsecs`.
Aurora PostgreSQL crée et utilise une base de données système nommée `rdsadmin` pour prendre en charge les opérations administratives telles que les sauvegardes, les restaurations, la surveillance de l'état, la réplication, etc. Ces opérations DML n'ont aucun impact sur votre 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)
```
L'exemple suivant montre les statistiques d'activité DML pour toutes les bases de données, organisées en colonnes pour une meilleure lisibilité.
```
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
```
L'exemple suivant montre la latence cumulative moyenne (latence cumulative divisée par le nombre) pour chaque opération DML pour la base de données avec l'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
Obtient la latence de validation cumulative en microsecondes pour les bases de données PostgreSQL Aurora. La *latence de validation* est mesurée comme le temps entre le moment où un client envoie une demande de validation et le moment où il reçoit la confirmation de validation.
## Syntaxe
```
aurora_stat_get_db_commit_latency(database_oid)
```
## Arguments
*database\$1oid*
ID d'objet (OID) de la base de données Aurora PostgreSQL.
## Type de retour
Registre SETOF
## Notes d’utilisation
Amazon CloudWatch utilise cette fonction pour calculer la latence de validation moyenne. Pour plus d'informations sur les métriques Amazon CloudWatch et sur la manière de résoudre une latence de validation élevée, consultez [Affichage des métriques dans la console Amazon RDS](USER_Monitoring.md) et [Prendre de meilleures décisions concernant Amazon RDS avec les métriques Amazon CloudWatch](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/).
Vous pouvez réinitialiser cette statistique à l'aide de la fonction d'accès aux statistiques PostgreSQL `pg_stat_reset`. Vous pouvez vérifier quand cette statistique a été réinitialisée pour la dernière fois à l'aide de la fonction `pg_stat_get_db_stat_reset_time`. Pour plus d'informations sur les fonctions d'accès aux statistiques PostgreSQL, consultez [Collecteur de statistiques](https://www.postgresql.org/docs/9.1/monitoring-stats.html) dans la documentation PostgreSQL.
## Exemples
L'exemple suivant obtient la latence de validation cumulative pour chaque base de données dans le 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
```
L'exemple suivant obtient la latence de validation cumulative pour la base de données actuellement connectée. Avant d'appeler la fonction `aurora_stat_get_db_commit_latency`, l'exemple utilise d'abord `\gset` pour définir une variable pour l'argument `oid` et définit sa valeur à partir de la base de données connectée.
```
––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
```
L'exemple suivant obtient la latence de validation cumulative pour la base de données `mydb` dans le cluster `pg_database`. Ensuite, il réinitialise cette statistique à l'aide de la fonction `pg_stat_reset` et affiche les résultats. Enfin, il utilise la fonction `pg_stat_get_db_stat_reset_time` pour vérifier quand cette statistique a été réinitialisée pour la dernière fois.
```
=> 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
Affiche l’utilisation du cache du journal d’écriture anticipée (WAL) par option.
## Syntaxe
```
SELECT * FROM aurora_stat_logical_wal_cache()
```
## Arguments
Aucun
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ `name` : nom de l’emplacement de réplication.
+ `active_pid` : ID du processus walsender.
+ `cache_hit` : nombre total d’accès au cache wal depuis la dernière réinitialisation.
+ `cache_miss` : nombre total d’erreurs d’accès au cache wal depuis la dernière réinitialisation.
+ `blks_read` : nombre total de requêtes de lecture de cache wal.
+ `hit_rate` : taux d’accès au cache WAL (cache\$1hit / blks\$1read).
+ `last_reset_timestamp` : dernière fois que le compteur a été remis à zéro.
## Notes d’utilisation
Cette fonction est disponible pour les versions suivantes d’Aurora PostgreSQL.
+ Version 15.2 et toutes les versions ultérieures
+ 14.7 et versions ultérieures
+ 13.8 et versions ultérieures
+ 12.12 et versions ultérieures
+ 11.17 et versions ultérieures
## Exemples
L’exemple suivant montre deux emplacements de réplication avec une seule fonction `aurora_stat_logical_wal_cache` active.
```
=> 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
Signale l'utilisation du contexte de mémoire pour chaque processus PostgreSQL.
## Syntaxe
```
aurora_stat_memctx_usage()
```
## Arguments
Aucun
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ `pid` : ID du processus.
+ `name` : nom du contexte de mémoire.
+ `allocated` : nombre d'octets obtenus à partir du sous-système de mémoire sous-jacent par le contexte de mémoire.
+ `used` : nombre d'octets validés vers les clients du contexte de mémoire.
+ `instances` : nombre de contextes existants de ce type.
## Notes d’utilisation
Cette fonction affiche l'utilisation du contexte de mémoire pour chaque processus PostgreSQL. Certains processus sont étiquetés `anonymous`. Les processus ne sont pas exposés car ils contiennent des mots clés restreints.
Cette fonction est disponible à compter des versions suivantes d'Aurora PostgreSQL :
+ Version 15.3 et versions 15 ultérieures
+ Version 14.8 et versions 14 ultérieures
+ Version 13.11 et versions 13 ultérieures
+ Version 12.15 et versions 12 ultérieures
+ Version 11.20 et versions 11 ultérieures
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `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)
```
Certains mots clés restreints seront masqués et le résultat se présentera comme suit :
```
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
Cette fonction affiche les statistiques du cache à plusieurs niveaux.
## Syntaxe
```
aurora_stat_optimized_reads_cache()
```
## Arguments
Aucun
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ `total_size` : taille totale du cache Optimized Reads.
+ `used_size` : taille de page utilisée dans le cache Optimized Reads.
## Notes d’utilisation
Cette fonctionnalité est disponible dans les versions suivantes d'Aurora PostgreSQL :
+ Version 15.4 et versions 15 ultérieures
+ Version 14.9 et versions 14 ultérieures
## Exemples
Voici un exemple de la sortie d'une instance 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
Renvoie une ligne pour chaque plan d’exécution suivi.
## Syntaxe
```
aurora_stat_plans(
showtext
)
```
## Arguments
+ showtext : affiche le texte de la requête et du plan. Les valeurs valides sont NULL, true ou false. True affiche le texte de la requête et du plan.
## Type de retour
Renvoie une ligne pour chaque plan suivi qui contient toutes les colonnes d’`aurora_stat_statements` et les colonnes supplémentaires suivantes.
+ planid — identifiant du plan
+ explain\$1plan — explique le texte du plan
+ plan\$1type:
+ `no plan` : aucun plan n’a été capturé
+ `estimate` : plan capturé avec estimation des coûts
+ `actual` : plan capturé avec EXPLAIN ANALYZE
+ plan\$1captured\$1time — Dernière fois qu’un plan a été capturé
## Notes d’utilisation
`aurora_compute_plan_id` doit être activé et `pg_stat_statements` doit être dans `shared_preload_libraries` pour que les plans puissent être suivis.
Le nombre de plans disponibles est contrôlé par la valeur définie dans le paramètre `pg_stat_statements.max`. Lorsque `aurora_compute_plan_id` est activé, vous pouvez suivre les plans jusqu’à cette valeur spécifiée dans `aurora_stat_plans`.
Cette fonction est disponible à partir des versions d’Aurora PostgreSQL 14.10, 15.5 et pour toutes les autres versions ultérieures.
## Exemples
Dans l’exemple ci-dessous, les deux plans relatifs à l’identifiant de requête -5471422286312252535 sont capturés et les statistiques des instructions sont suivies par le 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
Réinitialise le compteur du cache wal logique.
## Syntaxe
Pour réinitialiser un emplacement spécifique
```
SELECT * FROM aurora_stat_reset_wal_cache('slot_name')
```
Pour réinitialiser tous les emplacements
```
SELECT * FROM aurora_stat_reset_wal_cache(NULL)
```
## Arguments
`NULL` ou `slot_name`
## Type de retour
Message d'état, chaîne de texte
+ Réinitialisation du compteur de cache wal logique : message de réussite. Ce texte est renvoyé lorsque la fonction réussit.
+ Emplacement de réplication introuvable. Veuillez réessayer. – Message d'échec Ce texte est renvoyé lorsque la fonction échoue.
## Notes d’utilisation
Cette fonction est disponible pour les versions suivantes.
+ Aurora PostgreSQL 14.5 et versions supérieures
+ Aurora PostgreSQL versions 13.8 et ultérieures
+ Aurora PostgreSQL versions 12.12 et ultérieures
+ Aurora PostgreSQL version 11.17 et ultérieures
## Exemples
L'exemple suivant utilise la fonction `aurora_stat_reset_wal_cache` pour réinitialiser un emplacement nommé `test_results`, puis tente de réinitialiser un emplacement qui n'existe pas.
```
=> 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
Indique l’utilisation des ressources en temps réel, ce qui comprend les métriques des ressources dorsales et l’utilisation du processeur pour tous les processus dorsaux d’Aurora PostgreSQL.
## Syntaxe
```
aurora_stat_resource_usage()
```
## Arguments
Aucun
## Type de retour
Enregistrement SETOF avec colonnes :
+ pid — identifiant du processus
+ allocated\$1memory — mémoire totale allouée par le processus en octets
+ used\$1memory — mémoire réellement utilisée par le processus en octets
+ cpu\$1usage\$1percent — pourcentage d’utilisation du processeur par le processus
## Notes d’utilisation
Cette fonction affiche l’utilisation des ressources dorsales pour chaque processus dorsal d’Aurora PostgreSQL.
Cette fonction est disponible à compter des versions suivantes d’Aurora PostgreSQL :
+ Aurora PostgreSQL 17.5 et versions 17 ultérieures
+ Aurora PostgreSQL 16.9 et versions 16 ultérieures
+ Aurora PostgreSQL 15.13 et versions 15 ultérieures
+ Aurora PostgreSQL 14.18 et versions 14 ultérieures
+ Aurora PostgreSQL 13.21 et versions 13 ultérieures
## Exemples
L’exemple suivant illustre la sortie de la fonction `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
Affiche toutes les colonnes `pg_stat_statements` et en ajoute d’autres à la fin.
## Syntaxe
```
aurora_stat_statements(showtext boolean)
```
## Arguments
*showtext boolean*
## Type de retour
Registre SETOF contenant toutes les colonnes `pg_stat_statements` et les colonnes supplémentaires suivantes. Pour plus d’informations sur les colonnes `pg_stat_statements`, consultez [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html).
Vous pouvez réinitialiser les statistiques de cette fonctionnalité en utilisant `pg_stat_statements_reset()`.
+ `storage_blks_read` : nombre total de blocs partagés lus à partir du stockage Aurora par cette instruction.
+ `orcache_blks_hit` : nombre total d’accès au cache Optimized reads par cette instruction.
+ `storage_blk_read_time` : si `track_io_timing` est activé, le temps total que l’instruction a passé à lire des blocs partagés à partir du stockage Aurora est enregistré en millisecondes. Sinon, la valeur est nulle. Pour plus d’informations, consultez [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time` : si `track_io_timing` est activé, le temps total que l’instruction a passé à lire des blocs locaux est enregistré en millisecondes. Sinon, la valeur est nulle. Pour plus d’informations, consultez [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time` : si `track_io_timing` est activé, le temps total que l’instruction a passé à lire des blocs partagés à partir du cache Optimized Reads est enregistré en millisecondes. Sinon, la valeur est nulle. Pour plus d’informations, consultez [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `total_plan_peakmem` : somme totale des valeurs de pic de mémoire pendant la phase de planification pour tous les appels envoyés à cette instruction. Pour connaître le pic de mémoire moyen lors de la planification de l’instruction, divisez cette valeur par le nombre d’appels.
+ `min_plan_peakmem` : valeur de pic de mémoire la plus faible observée lors de la planification parmi tous les appels transmis à cette instruction.
+ `max_plan_peakmem` : valeur de pic de mémoire la plus élevée observée lors de la planification parmi tous les appels transmis à cette instruction.
+ `total_exec_peakmem` : somme totale des valeurs de pic de mémoire pendant la phase d’exécution pour tous les appels envoyés à cette instruction. Pour connaître le pic de mémoire moyen pendant l’exécution de l’instruction, divisez cette valeur par le nombre d’appels.
+ `min_exec_peakmem` : valeur de pic de mémoire la plus faible, en octets, observée lors de l’exécution parmi tous les appels transmis à cette instruction.
+ `max_exec_peakmem` : valeur de pic de mémoire la plus élevée, en octets, observée lors de l’exécution parmi tous les appels transmis à cette instruction.
**Note**
`total_plan_peakmen`, `min_plan_peakmem` et `max_plan_peakmem` ne sont surveillés que lorsque le paramètre `pg_stat_statements.track_planning` est activé.
## Notes d’utilisation
Pour utiliser la fonction aurora\$1stat\$1statements(), vous devez inclure l’extension `pg_stat_statements` dans le paramètre `shared_preload_libraries`.
Cette fonctionnalité est disponible dans les versions suivantes d’Aurora PostgreSQL :
+ 15.4 et versions 15 ultérieures
+ 14.9 et versions 14 ultérieures
Les colonnes indiquant les pics de mémoire sont disponibles dans les versions suivantes :
+ 16.3 et versions ultérieures
+ 15.7 et versions ultérieures
+ 14.12 et versions ultérieures
## Exemples
L’exemple suivant montre comment elle transporte toutes les colonnes de l’instruction pg\$1stat\$1statements et en ajoute 11 nouvelles à la fin :
```
=> 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
Indique les informations sur les événements d'attente pour l'instance de base de données PostgreSQL Aurora.
## Syntaxe
```
aurora_stat_system_waits()
```
## Arguments
Aucun
## Type de retour
Registre SETOF
## Notes d’utilisation
Cette fonction renvoie le nombre cumulé d'attente et le temps d'attente cumulé pour chaque événement d'attente généré par l'instance de base de données à laquelle vous êtes actuellement connecté.
Le jeu d'enregistrements comprend les champs suivants :
+ `type_id` – ID du type d'événement d'attente.
+ `event_id` – ID de l'événement d'attente.
+ `waits` – Nombre de fois où l'événement d'attente s'est produit.
+ `wait_time` – Temps total en microsecondes passé à attendre cet événement.
Les statistiques renvoyées par cette fonction sont réinitialisées lorsqu'une instance de base de données redémarre.
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `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'exemple suivant montre comment utiliser cette fonction avec `aurora_stat_wait_event` et `aurora_stat_wait_type` pour produire des résultats plus lisibles.
```
=> 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
Répertorie tous les événements d'attente pris en charge pour Aurora PostgreSQL. Pour obtenir des informations sur les événements d'attente Aurora PostgreSQL, consultez [Événements d’attente Amazon Aurora PostgreSQL](AuroraPostgreSQL.Reference.Waitevents.md).
## Syntaxe
```
aurora_stat_wait_event()
```
## Arguments
Aucun
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ type\$1id – ID du type d'événement d'attente.
+ event\$1id – ID de l'événement d'attente.
+ type\$1name : nom du type d'attente
+ event\$1name : nom de l'événement d'attente
## Notes d’utilisation
Pour voir les noms d'événements avec le type d'événement au lieu de l'ID, utilisez cette fonction avec d'autres fonctions telles que `aurora_stat_wait_type` et `aurora_stat_system_waits`. Les noms des événements d'attente renvoyés par cette fonction sont les mêmes que ceux renvoyés par la fonction `aurora_wait_report`.
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `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'exemple suivant joint `aurora_stat_wait_type` et `aurora_stat_wait_event` pour renvoyer les noms de type et les noms d'événement pour une meilleure lisibilité.
```
=> 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
Répertorie tous les types d'attentes pris en charge pour Aurora PostgreSQL.
## Syntaxe
```
aurora_stat_wait_type()
```
## Arguments
Aucun
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ type\$1id – ID du type d'événement d'attente.
+ type\$1name – nom du type d'attente.
## Notes d’utilisation
Pour voir les noms d'événements d'attente avec le type d'événement d'attente au lieu de l'ID, utilisez cette fonction avec d'autres fonctions telles que `aurora_stat_wait_event` et `aurora_stat_system_waits`. Les noms des types d'attentes renvoyés par cette fonction sont les mêmes que ceux renvoyés par la fonction `aurora_wait_report`.
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `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
Renvoie la valeur de chaîne du numéro de version de l'Édition compatible avec PostgreSQL d'Amazon Aurora.
## Syntaxe
```
aurora_version()
```
## Arguments
Aucun
## Type de retour
Chaîne CHAR ou VARCHAR
## Notes d’utilisation
Cette fonction affiche la version du moteur de base de données Amazon Aurora Édition compatible avec PostgreSQL. Le numéro de version est renvoyé sous la forme d'une chaîne de caractères formatée comme *major*.*minor*.*patch*. Pour obtenir plus d'informations sur les numéros de versions d'Aurora PostgreSQL, consultez [Numéro de version Aurora](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions.AuroraNumber).
Vous pouvez choisir quand appliquer les mises à niveau de versions mineures en définissant la fenêtre de maintenance pour votre cluster de base de données Aurora PostgreSQL. Pour savoir comment procéder, veuillez consulter la section [Entretien d’un cluster de bases de données Amazon Aurora](USER_UpgradeDBInstance.Maintenance.md).
À partir de la sortie d'Aurora PostgreSQL versions 13.3, 12.8, 11.13, 10.18, et pour toutes les autres versions ultérieures, les numéros de version d'Aurora suivent les numéros de version de PostgreSQL. Pour obtenir plus d'informations sur toutes les versions d'Aurora PostgreSQL, consultez [Amazon Aurora PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) (Mises à jour d'Amazon Aurora PostgreSQL) dans les *Notes de mise à jour d'Aurora PostgreSQL*.
## Exemples
L'exemple suivant montre les résultats de l'appel de la fonction `aurora_version` sur un cluster de base de données Aurora PostgreSQL exécutant [PostgreSQL 12.7, Aurora PostgreSQL version 4.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.42), puis de l'exécution de la même fonction sur un cluster exécutant [Aurora PostgreSQL version 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
```
Cet exemple montre comment utiliser la fonction avec diverses options pour obtenir plus de détails sur la version Aurora PostgreSQL. Cet exemple présente un numéro de version d'Aurora distinct du numéro de version de 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)
```
L'exemple suivant utilise la fonction avec les mêmes options que dans l'exemple précédent. Cet exemple ne présente pas de numéro de version Aurora distinct du numéro de version 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
Renvoie le numéro de séquence du journal (LSN) utilisé pour identifier le début d'un enregistrement dans le flux de journal d'écriture anticipée (WAL) logique du volume du cluster Aurora.
## Syntaxe
```
aurora_volume_logical_start_lsn()
```
## Arguments
Aucun
## Type de retour
`pg_lsn`
## Notes d’utilisation
Cette fonction identifie le début de l'enregistrement dans le flux WAL logique pour un volume de cluster Aurora donné. Vous pouvez utiliser cette fonction lors de la mise à niveau d'une version majeure à l'aide de la réplication logique et du clonage rapide Aurora afin de déterminer le LSN auquel un instantané ou un clone de base de données est pris. Vous pouvez ensuite utiliser la réplication logique pour diffuser en continu les nouvelles données enregistrées après le numéro LSN et synchroniser les modifications du diffuseur de publication à l'abonné.
Pour plus d'informations sur l'utilisation de la réplication logique pour une mise à niveau de version majeure, consultez [Utilisation de la réplication logique pour effectuer une mise à niveau de version majeure pour Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
Cette fonction est disponible dans les versions suivantes d'Aurora PostgreSQL :
+ Versions 15.2 et 15 ultérieures
+ Versions 14.3 et 14 ultérieures
+ Version 13.6 et versions 13 ultérieures
+ Version 12.10 et versions 12 ultérieures
+ Version 11.15 et versions 11 ultérieures
+ Version 10.20 et versions 10 ultérieures
## Exemples
Vous pouvez obtenir le numéro de séquence du journal (LSN) à l'aide de la requête suivante :
```
postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn
---------------
0/402E2F0
(1 row)
```
# aurora\$1wait\$1report
Cette fonction affiche l’activité des événements d’attente sur une période.
## Syntaxe
```
aurora_wait_report([time])
```
## Arguments
*time (optional)* (temps (facultatif))
Le temps en secondes. La valeur par défaut est de 10 secondes.
## Type de retour
Registre SETOF comprenant les colonnes suivantes :
+ type\$1name : nom du type d’attente
+ event\$1name : nom de l’événement d’attente
+ wait : nombre d’attentes
+ wait\$1time : temps d’attente en millisecondes
+ ms\$1per\$1wait : moyenne en millisecondes par nombre d’attentes
+ waits\$1per\$1xact : nombre moyen d’attentes sur le nombre de transactions
+ ms\$1per\$1wait — moyenne en millisecondes par nombre de transactions
## Notes d’utilisation
Cette fonction est disponible à partir de la version 1.1 d’Aurora PostgreSQL compatible avec PostgreSQL 9.6.6 et les versions ultérieures.
Pour utiliser cette fonction, vous devez d’abord créer l’extension Aurora PostgreSQL `aurora_stat_utils` comme suit :
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Pour plus d’informations sur les versions d’extension d’Aurora PostgreSQL disponibles, consultez [Versions d’extension d’Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) dans *Notes de mise à jour d’Aurora PostgreSQL*.
Cette fonction calcule les événements d’attente au niveau de l’instance en comparant deux instantanés de données statistiques provenant de la fonction aurora\$1stat\$1system\$1waits() et des vues des statistiques PostgreSQL pg\$1stat\$1database.
Pour plus d’informations concernant `aurora_stat_system_waits()` et `pg_stat_database`, consultez [The Statistics Collector](https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-DATABASE-VIEW) (Collecteur de statistiques) dans la *documentation de PostgreSQL*.
Lorsqu’elle est exécutée, cette fonction prend un instantané initial, attend le nombre de secondes spécifié, puis prend un deuxième instantané. La fonction compare les deux instantanés et renvoie la différence. Cette différence représente l’activité de l’instance pour cet intervalle de temps.
Sur l’instance d’enregistreur, la fonction affiche également le nombre de transactions validées et la valeur TPS (transactions par seconde). Cette fonction renvoie des informations au niveau de l’instance et inclut toutes les bases de données sur l’instance.
## Exemples
Cet exemple montre comment créer l’extension aurora\$1stat\$1utils pour utiliser la fonction aurora\$1wait\$1report.
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Cet exemple montre comment consulter le rapport d’attente pour 10 secondes.
```
=> 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
```
Cet exemple montre comment consulter le rapport d’attente pour 60 secondes.
```
=> 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
```