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. # Fonctions d’Aurora PostgreSQL Limitless Database Le tableau suivant présente les nouvelles fonctions d’Aurora PostgreSQL Limitless Database. **Note** Les fonctions répertoriées dans ce tableau se trouvent dans le schéma `rds_aurora`. Lorsque vous utilisez une fonction Limitless Database, assurez-vous d’inclure le nom d’objet entièrement qualifié : `rds_aurora`.`object_name`. | Fonctions d’Aurora PostgreSQL Limitless Database | Fonction d’Aurora PostgreSQL correspondante | | --- | --- | | [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 | Les exemples suivants fournissent des détails sur les fonctions d’Aurora PostgreSQL Limitless Database. Pour plus d’informations sur les fonctions PostgreSQL, consultez [Fonctions et opérateurs](https://www.postgresql.org/docs/15/functions.html) dans la documentation PostgreSQL. **limitless\$1backend\$1dsid** La fonction `limitless_backend_dsid` renvoie l’ID de la session distribuée pour la session en cours. Une session distribuée s’exécute sur un routeur d’un groupe de partitions de base de données et implique des processus dorsaux sur une ou plusieurs partitions du groupe de partitions de base de données. L’exemple suivant montre comment utiliser la fonction `limitless_backend_dsid`. ``` SELECT rds_aurora.limitless_backend_dsid(); limitless_backend_dsid ------------------------ 8CACD7B04D0FC2A5 (1 row) ``` **limitless\$1cancel\$1session** La fonction `limitless_cancel_session` se comporte comme `pg_cancel_backend`, à la différence qu’elle essaie d’annuler tous les processus dorsaux liés à l’ID de session distribuée spécifié en leur envoyant un `SIGINT` (signal d’interruption). Le paramètre d’entrée est le suivant : + `distributed_session_id` (texte) : l’ID de la session distribuée à annuler. Les paramètres de sortie sont les suivants : + `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus. + `pid` (texte) : l’ID du processus dorsal. + `success` (booléen) : indique si l’annulation s’est déroulée avec succès. L’exemple suivant montre comment utiliser la fonction `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 fonction `limitless_stat_clear_snapshot` supprime l’instantané des statistiques actuelles ou les informations mises en cache sur tous les nœuds. L’exemple suivant montre comment utiliser la fonction `limitless_stat_clear_snapshot`. ``` SELECT rds_aurora.limitless_stat_clear_snapshot(); ``` **limitless\$1stat\$1database\$1size** La fonction `limitless_stat_database_size` renvoie les tailles d’une base de données dans le groupe de partitions de base de données. Le paramètre d’entrée est le suivant : + `dbname` (nom) : la base de données dont vous souhaitez obtenir les tailles. Les paramètres de sortie sont les suivants : + `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus. + `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`. + `db_size` : la taille de la base de données de ce sous-cluster en octets. L’exemple suivant montre comment utiliser la fonction `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 fonction `limitless_stat_get_snapshot_timestamp` renvoie l’horodatage de l’instantané des statistiques en cours, ou `NULL` si aucun instantané n’a été créé. Un instantané est créé lors de la première consultation des statistiques cumulées dans une transaction, lorsque `stats_fetch_consistency` est défini sur `snapshot`. Renvoie une vue consolidée des horodatages des instantanés de tous les nœuds. Les colonnes `subcluster_id` et `subcluster_type` indiquent de quel nœud proviennent les données. L’exemple suivant montre comment utiliser la fonction `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 fonction `limitless_stat_prepared_xacts` renvoie des informations sur les transactions sur tous les nœuds actuellement préparés pour une validation en deux phases. Pour plus d’informations, consultez [pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html) dans la documentation PostgreSQL. L’exemple suivant montre comment utiliser la fonction `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 fonction `limitless_stat_relation_sizes` renvoie les différentes tailles d’une table dans le groupe de partitions de base de données. Les paramètres d’entrée sont les suivants : + `relnspname` (nom) : le nom du schéma contenant la table. + `relname` (nom) : le nom de la table. Les paramètres de sortie sont les suivants : + `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus. + `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`. + `main_size` : la taille en octets du jeu de données principal de ce nœud. + `fsm_size` : la taille en octets de la carte de l’espace libre de la table dans ce nœud. + `vm_size` : la taille en octets de la carte de visibilité de la table dans ce nœud. + `init_size` : la taille en octets de l’initialisation de la table dans ce nœud. + `toast_size` : la taille en octets de la table Toast associée à la table de ce fork. + `index_size` : la taille en octets de tous les indexes de la table dans ce nœud. + `total_size` : la taille en octets de tous les segments de la table dans ce nœud. L’exemple suivant montre comment utiliser la fonction `limitless_stat_relation_sizes` (certaines colonnes ont été omises). ``` 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 fonction `limitless_stat_reset` remet à zéro (0) l’ensemble des compteurs de statistiques de la base de données actuelle. Si `track_functions` est activé, la colonne `stats_reset` dans `limitless_stat_database` indique la dernière fois que les statistiques ont été réinitialisées pour la base de données. Par défaut, `limitless_stat_reset` ne peut être exécuté que par un super-utilisateur. Les autres utilisateurs peuvent obtenir une autorisation en utilisant le privilège `EXECUTE`. L’exemple suivant montre comment utiliser la fonction `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 fonction `limitless_stat_statements_reset` ignore les statistiques collectées jusqu’à présent par `limitless_stat_statements` correspondant aux paramètres spécifiés `username`, `dbname`, `distributed_query_id` et `queryid`. Si aucun paramètre n’est spécifié, la valeur par défaut `""` ou `0` (non valide) est utilisée pour chacun d’entre eux, et les statistiques correspondant aux autres paramètres sont réinitialisées. Si aucun paramètre n’est spécifié, ou si tous les paramètres spécifiés sont `""` ou `0` (non valides), la fonction ignore toutes les statistiques. Si toutes les statistiques de la vue `limitless_stat_statements` sont supprimées, la fonction réinitialise également les statistiques de la vue `limitless_stat_statements_info`. Les paramètres d’entrée sont les suivants : + `username` (nom) : l’utilisateur qui a interrogé l’instruction. + `dbname` (nom) : la base de données dans laquelle la requête a été exécutée. + `distributed_query_id` (bigint) : l’ID de requête de la requête parent provenant du nœud coordinateur. Cette colonne est `NULL` s’il s’agit de la requête parent. Le nœud coordinateur transmet l’ID de requête distribué aux nœuds participants. Ainsi, pour les nœuds participants, les valeurs de l’ID de requête distribuée et de l’ID de requête sont différentes. + `queryid` (bigint) : l’ID de requête de l’instruction. L’exemple suivant montre comment utiliser la fonction `limitless_stat_statements_reset` pour réinitialiser toutes les statistiques collectées par `limitless_stat_statements`. ``` SELECT rds_aurora.limitless_stat_statements_reset(); ``` **limitless\$1stat\$1system\$1waits** La fonction `limitless_stat_system_waits` renvoie une vue consolidée des données d’événements d’attente provenant de `aurora_stat_system_waits`, qui rapporte l’activité d’attente à l’échelle du système pour une instance, à partir de tous les nœuds. Les colonnes `subcluster_id` et `subcluster_type` indiquent de quel nœud proviennent les données. L’exemple suivant montre comment utiliser la fonction `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 fonction `limitless_terminate_session` se comporte comme `pg_terminate_backend`, à la différence qu’elle essaie d’interrompre tous les processus dorsaux liés à l’ID de session distribuée spécifié en leur envoyant un `SIGTERM` (signal de fin). Le paramètre d’entrée est le suivant : + `distributed_session_id` (texte) : l’ID de la session distribuée à terminer. Les paramètres de sortie sont les suivants : + `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus. + `pid` (texte) : l’ID du processus dorsal. + `success` (booléen) : indique si le processus s’est bien terminé. L’exemple suivant montre comment utiliser la fonction `limitless_terminate_session`. ``` SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B'); subcluster_id | pid | success ---------------+-------+--------- 1 | 26920 | t (1 row) ``` **limitless\$1wait\$1report** La fonction `limitless_wait_report` renvoie l’activité des événements d’attente sur une période donnée, en provenance de l’ensemble des nœuds. Les colonnes `subcluster_id` et `subcluster_type` indiquent de quel nœud proviennent les données. Les paramètres de sortie sont les suivants : + `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus. + `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`. Les autres colonnes sont les mêmes que dans `aurora_wait_report`. L’exemple suivant montre comment utiliser la fonction `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 ```