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.
# Tâches courantes d’administration de bases de données pour Amazon RDS pour PostgreSQL
Les administrateurs de base de données (DBAs) exécutent diverses tâches lors de l'administration d'une instance de base de données Amazon RDS for PostgreSQL. Si vous êtes administrateur de base de données déjà familier avec PostgreSQL, vous devez connaître certaines des différences importantes entre l’exécution de PostgreSQL sur votre matériel et RDS pour PostgreSQL. Par exemple, comme il s'agit d'un service géré, Amazon RDS n'autorise pas l'accès shell à vos instances de base de données. Cela signifie que vous n'avez pas d'accès direct à `pg_hba.conf` et aux autres fichiers de configuration. Pour RDS pour PostgreSQL, les modifications généralement apportées au fichier de configuration PostgreSQL d’une instance sur site sont apportées à un groupe de paramètres de base de données personnalisé associé à l’instance de base de données RDS pour PostgreSQL. Pour de plus amples informations, veuillez consulter [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous ne pouvez pas non plus accéder aux fichiers journaux de la même manière qu'avec une instance PostgreSQL sur site. Pour en savoir plus sur la journalisation, consultez [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
Autre exemple, vous n'avez pas accès au compte `superuser` PostgreSQL. Sur RDS pour PostgreSQL, le rôle `rds_superuser` dispose des privilèges les plus élevés. Il est accordé à `postgres` au moment de la configuration. Que vous soyez familier avec l’utilisation de PostgreSQL sur site ou que vous n’ayez aucune expérience avec RDS pour PostgreSQL, nous vous recommandons de comprendre le rôle `rds_superuser` et de vous renseigner sur l’utilisation des rôles, des utilisateurs, des groupes et des autorisations. Pour de plus amples informations, veuillez consulter [Comprendre les rôles et les autorisations PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Voici quelques tâches DBA courantes pour RDS pour PostgreSQL.
**Topics**
+ [
# Collations prises en charge dans pour PostgreSQL
](PostgreSQL-Collations.md)
+ [
# Comprendre les rôles et les autorisations PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [
# Gestion des connexions inactives dans PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [
# Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [
# Gestion d'un nombre élevé d'objets dans Amazon RDS pour PostgreSQL Amazon Aurora
](PostgreSQL.HighObjectCount.md)
+ [
#
](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [
## Utilisation de mécanismes de journalisation pris en charge par RDS pour PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [
# Gestion des fichiers temporaires avec PostgreSQL
](PostgreSQL.ManagingTempFiles.md)
+ [
## Utilisation de pgBadger pour l'analyse de journal serveur avec PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [
## Utilisation PGSnapper pour la surveillance de PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [
#
](PostgreSQL.CustomCasts.md)
+ [
# Meilleures pratiques pour les requêtes parallèles dans pour PostgreSQL
](PostgreSQL.ParallelQueries.md)
+ [
# Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Collations prises en charge dans pour PostgreSQL
Les classements sont un ensemble de règles qui déterminent la manière dont les chaînes de caractères stockées dans la base de données sont triées et comparées. Les classements jouent un rôle fondamental dans le système informatique et sont inclus dans le système d’exploitation. Les classements changent au fil du temps lorsque de nouveaux caractères sont ajoutés aux langues ou lorsque les règles de classement changent.
Les bibliothèques de classement définissent des règles et des algorithmes spécifiques pour un classement. Les bibliothèques de classement les plus populaires utilisées dans PostgreSQL sont GNU C (glibc) et les composants d’internationalisation pour Unicode (ICU). Par défaut, RDS pour PostgreSQL utilise le classement glibc qui inclut les ordres de tri des caractères Unicode pour les séquences de caractères multi-octets.
Lorsque vous créez une nouvelle instance de base de données dans RDS pour PostgreSQL, le classement disponible est vérifié dans le système d’exploitation. Les paramètres PostgreSQL de la commande `CREATE DATABASE` `LC_COLLATE` et `LC_CTYPE` sont utilisés pour spécifier un classement, qui constitue le classement par défaut dans cette base de données. Vous pouvez également utiliser le paramètre `LOCALE` dans `CREATE DATABASE` pour définir ces paramètres. Cela détermine le classement par défaut pour les chaînes de caractères dans la base de données et les règles de classification des caractères sous forme de lettres, de chiffres ou de symboles. Vous pouvez également choisir un classement à utiliser sur une colonne, un index ou une requête.
RDS pour PostgreSQL dépend de la bibliothèque glibc du système d’exploitation pour la prise en charge du classement. L’instance RDS pour PostgreSQL est régulièrement mise à jour avec les dernières versions du système d’exploitation. Ces mises à jour incluent parfois une version plus récente de la bibliothèque glibc. Dans de rares cas, les nouvelles versions de glibc modifient l’ordre de tri ou le classement de certains caractères, ce qui peut entraîner un tri différent des données ou la production d’entrées d’index non valides. Si vous découvrez des problèmes d’ordre de tri pour le classement lors d’une mise à jour, vous devrez peut-être reconstruire les index.
Pour réduire les impacts possibles des mises à jour glibc, RDS pour PostgreSQL inclut désormais une bibliothèque de classement par défaut indépendante. Cette bibliothèque de classement est disponible dans RDS pour PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 et les versions mineures plus récentes. Elle est compatible avec glibc 2.26-59.amzn2 et assure la stabilité de l’ordre de tri afin d’éviter des résultats de requêtes incorrects.
# Comprendre les rôles et les autorisations PostgreSQL
Lorsque vous créez une instance de base de RDS pour PostgreSQL à l'aide de, un compte administrateur est créé en AWS Management Console même temps. Par défaut, son nom est `postgres`, comme illustré dans la capture d'écran ci-dessous :
![\[L'identité de connexion par défaut pour les informations d'identification sur la page Create database (Créer une base de données) est postgres.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Vous pouvez choisir un autre nom plutôt que d'accepter le nom par défaut (`postgres`). Le nom que vous choisissez doit commencer par une lettre et comporter entre 1 et 16 caractères alphanumériques. Par souci de simplicité, nous nous référons à ce compte utilisateur principal par sa valeur par défaut (`postgres`) tout au long de ce manuel.
Si vous utilisez le `create-db-instance` AWS CLI plutôt que le AWS Management Console, vous créez le nom en le transmettant avec le `master-username` paramètre dans la commande. Pour plus d'informations, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
Que vous utilisiez l'API AWS Management Console AWS CLI, la ou l'API Amazon RDS, que vous utilisiez le `postgres` nom par défaut ou que vous choisissiez un autre nom, ce premier compte utilisateur de base de données est membre du `rds_superuser` groupe et dispose de `rds_superuser` privilèges.
**Topics**
+ [
# Comprendre le rôle rds\$1superuser
](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [
# Contrôle de l'accès utilisateur à la base de données PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [
# Délégation et contrôle de la gestion des mots de passe utilisateur
](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [
# Utilisation de SCRAM pour le chiffrement de mot de passe PostgreSQL
](PostgreSQL_Password_Encryption_configuration.md)
# Comprendre le rôle rds\$1superuser
Dans PostgreSQL, un *rôle* peut définir un utilisateur, un groupe ou un ensemble d’autorisations spécifiques accordées à un groupe ou à un utilisateur pour divers objets de la base de données. Les commandes PostgreSQL `CREATE USER` et `CREATE GROUP` ont été remplacées par la commande `CREATE ROLE` plus générique avec des propriétés spécifiques permettant de distinguer les utilisateurs de la base de données. Un utilisateur de base de données peut être considéré comme un rôle disposant du privilège LOGIN.
**Note**
Les commandes `CREATE USER` et `CREATE GROUP` peuvent toujours être utilisées. Pour plus d’informations, consultez [Database Roles](https://www.postgresql.org/docs/current/user-manag.html) dans la documentation de PostgreSQL.
L’utilisateur `postgres` est l’utilisateur de base de données disposant des privilèges les plus élevés sur votre instance de base de données RDS pour PostgreSQL. Il présente les caractéristiques définies par l’instruction `CREATE ROLE` suivante.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Sauf indication contraire, les propriétés `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` et `VALID UNTIL 'infinity'` sont les options par défaut de CREATE ROLE.
Par défaut, `postgres` fait en sorte que des privilèges soient octroyés au rôle `rds_superuser` ainsi que des autorisations permettant de créer des rôles et des bases de données. Le rôle `rds_superuser` permet à l’utilisateur `postgres` d’effectuer les opérations suivantes :
+ Ajoutez les extensions qu’il est possible d’utiliser avec Amazon RDS. Pour plus d’informations, consultez [Utilisation des fonctions PostgreSQL prises en charge par Amazon RDS pour PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Créer des rôles pour les utilisateurs et leur accorder des privilèges. Pour plus d’informations, consultez [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) et [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) dans la documentation de PostgreSQL.
+ Créer des bases de données. Pour plus d’informations, consultez [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) dans la documentation de PostgreSQL.
+ Accorder des privilèges `rds_superuser` aux rôles utilisateur qui ne disposent pas de ces privilèges, et révoquer les privilèges si nécessaire. Nous vous recommandons d’accorder ce rôle uniquement aux utilisateurs effectuant des tâches de super-utilisateur. En d'autres termes, vous pouvez attribuer ce rôle aux administrateurs de base de données (DBAs) ou aux administrateurs système.
+ Accorder (et révoquer) le rôle `rds_replication` aux utilisateurs de base de données qui ne possèdent pas le rôle `rds_superuser`.
+ Accorder (et révoquer) le rôle `rds_password` aux utilisateurs de base de données qui ne possèdent pas le rôle `rds_superuser`.
+ Obtenir des informations d’état sur toutes les connexions à la base de données en utilisant la vue `pg_stat_activity`. En cas de besoin, `rds_superuser` peut arrêter toutes les connexions à l’aide de `pg_terminate_backend` ou `pg_cancel_backend`.
Dans l’instruction `CREATE ROLE postgres...`, vous pouvez voir que le rôle utilisateur `postgres` rejette spécifiquement les autorisations `superuser` PostgreSQL. RDS pour PostgreSQL étant un service géré, vous ne pouvez ni accéder au système d’exploitation hôte, ni vous connecter à l’aide du compte `superuser` PostgreSQL. La plupart des tâches qui exigent un accès `superuser` sur une instance autonome de PostgreSQL sont gérées automatiquement par Amazon RDS.
Pour plus d’informations sur l’octroi de privilèges, consultez [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) dans la documentation de PostgreSQL.
Le rôle `rds_superuser` est l’un des nombreux rôles *prédéfinis* d’un Instance de base de données RDS pour PostgreSQL.
**Note**
Dans PostgreSQL 13 et versions antérieures, les rôles *prédéfinis* s’appellent rôles *par défaut*.
La liste suivante répertorie certains des autres rôles prédéfinis créés automatiquement pour un nouveau Instance de base de données RDS pour PostgreSQL. Les rôles prédéfinis et leurs privilèges ne peuvent pas être modifiés. Vous ne pouvez pas supprimer, renommer ou modifier les privilèges de ces rôles prédéfinis. Toute tentative de ce type génère une erreur.
+ **rds\$1password** : rôle pouvant modifier les mots de passe et configurer des contraintes de mot de passe pour les utilisateurs de base de données. Le rôle `rds_superuser` se voit accorder ce rôle par défaut et peut accorder le rôle aux utilisateurs de base de données. Pour plus d’informations, consultez [Contrôle de l'accès utilisateur à la base de données PostgreSQLContrôle de l'accès utilisateur à PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ Pour les versions de RDS pour PostgreSQL antérieures à 14, le rôle `rds_password` peut modifier les mots de passe et configurer des contraintes de mot de passe pour les utilisateurs de bases de données et les utilisateurs ayant un rôle `rds_superuser`. À partir de RDS pour PostgreSQL versions 14 et ultérieures, le rôle `rds_password` peut modifier les mots de passe et configurer des contraintes de mot de passe uniquement pour les utilisateurs de bases de données. Seuls les utilisateurs ayant le rôle `rds_superuser` peuvent effectuer ces actions sur d’autres utilisateurs ayant le rôle `rds_superuser`.
+ **rdsadmin** : rôle créé pour gérer la plupart des tâches de gestion que l’administrateur qui utilise les privilèges `superuser` aurait exécutées sur une base de données PostgreSQL autonome. Ce rôle est utilisé en interne par RDS pour PostgreSQL pour de nombreuses tâches de gestion.
+ **rdstopmgr** : rôle utilisé en interne par Amazon RDS pour prendre en charge les déploiements multi-AZ.
+ **rds\$1reserved** : rôle utilisé en interne par Amazon RDS pour réserver des connexions à la base de données.
# Affichage des rôles et de leurs privilèges
Vous pouvez afficher les rôles prédéfinis et leurs privilèges dans votre instance de base de données RDS pour PostgreSQL à l’aide de différentes commandes en fonction de votre version de PostgreSQL. Pour voir tous les rôles prédéfinis, vous pouvez vous connecter à votre instance de base de données RDS pour PostgreSQL et exécuter les commandes suivantes à l’aide de `psql`.
**Pour `psql` 15 et versions antérieures**
Connectez-vous à votre instance de base de données RDS pour PostgreSQL et utilisez la commande `\du` dans psql :
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Pour `psql` 16 et versions ultérieures**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Pour vérifier l’appartenance à un rôle sans dépendance de version, vous pouvez utiliser la requête SQL suivante :
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
Dans la sortie, vous pouvez voir que `rds_superuser` n’est pas un rôle utilisateur de base de données (il ne peut pas se connecter), mais qu’il dispose des privilèges de nombreux autres rôles. Vous pouvez également voir que l’utilisateur de base de données `postgres` est membre du rôle `rds_superuser`. Comme mentionné précédemment, `postgres` est la valeur par défaut sur la page **Create database** (Créer une base de données) de la console Amazon RDS. Si vous avez choisi un autre nom, ce nom apparaît dans la liste des rôles.
# Contrôle de l'accès utilisateur à la base de données PostgreSQL
Les nouvelles bases de données de PostgreSQL sont toujours créées avec un ensemble de privilèges par défaut dans le schéma `public` de la base de données, qui permet à tous les utilisateurs et rôles de base de données de créer des objets. Ces privilèges permettent aux utilisateurs de base de données de se connecter à la base de données, par exemple, et de créer des tables temporaires lorsqu'ils sont connectés.
Pour mieux contrôler l'accès des utilisateurs aux instances de base de données que vous créez sur votre instance de base de données RDS for PostgreSQL, nous vous recommandons de révoquer ces privilèges `public` par défaut. Vous accordez ensuite des privilèges spécifiques aux utilisateurs de base de données de manière plus détaillée, comme indiqué dans la procédure suivante.
**Pour configurer des rôles et des privilèges pour une nouvelle instance de base de données**
Supposons que vous configuriez une base de données sur une instance de base de données RDS for PostgreSQL récemment créée à l'usage de plusieurs chercheurs, qui ont tous besoin d'un accès en lecture/écriture à la base de données.
1. Utilisez `psql` (ou pgAdmin) pour vous connecter à votre instance de base de données RDS for PostgreSQL :
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Lorsque vous y êtes invité, saisissez votre mot de passe. Le client `psql` se connecte à la base de données de connexions administratives par défaut, `postgres=>`, et l'affiche sous forme d'invite.
1. Pour empêcher les utilisateurs de base de données de créer des objets dans le schéma `public`, procédez comme suit :
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Vous créez ensuite une instance de base de données :
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Révoquez tous les privilèges du schéma `PUBLIC` sur cette nouvelle base de données.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Créez un rôle pour les utilisateurs de base de données.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Donnez aux utilisateurs de base de données disposant de ce rôle la possibilité de se connecter à la base de données.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Accordez à tous les utilisateurs dotés du rôle `lab_tech` tous les privilèges sur cette base de données.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Créez des utilisateurs de base de données, comme suit :
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Accordez à ces deux utilisateurs les privilèges associés au rôle lab\$1tech :
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
À ce stade, `lab_user1` et `lab_user2` peuvent se connecter à la base de données `lab_db`. Cet exemple ne respecte pas les bonnes pratiques pour une utilisation en entreprise, qui peuvent inclure la création de plusieurs instances de base de données, différents schémas et l'octroi d'autorisations limitées. Pour des informations plus complètes et des scénarios supplémentaires, consultez [Managing PostgreSQL Users and Roles](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Pour plus d'informations sur les privilèges dans les bases de données PostgreSQL, veuillez consulter la commande [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) dans la documentation PostgreSQL.
# Délégation et contrôle de la gestion des mots de passe utilisateur
En tant qu'administrateur de base de données, vous souhaitez peut-être déléguer la gestion des mots de passe utilisateur. Vous souhaitez peut-être également empêcher les utilisateurs de base de données de modifier leurs mots de passe ou de reconfigurer les contraintes de mot de passe, telles que la durée de vie d'un mot de passe. Pour vous assurer que seuls les utilisateurs de base de données que vous choisissez peuvent modifier les paramètres de mot de passe, vous pouvez activer la fonctionnalité de gestion restreinte des mots de passe. Lorsque vous activez cette fonctionnalité, seuls les utilisateurs de base de données qui ont obtenu le rôle `rds_password` peuvent gérer les mots de passe.
**Note**
Pour utiliser la gestion restreinte des mots de passe, votre instance de base de données RDS for PostgreSQL doit exécuter PostgreSQL 10.6 ou versions ultérieures.
Par défaut, cette fonctionnalité est désactivée (`off`), comme illustré ci-dessous :
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Pour l'activer, vous utilisez un groupe de paramètres personnalisé et redéfinissez le paramètre `rds.restrict_password_commands` sur 1. Assurez-vous de redémarrer votre instance de base de données RDS for PostgreSQL pour que le réglage prenne effet.
Lorsque cette fonctionnalité est activée, les privilèges `rds_password` sont requis pour les commandes SQL suivantes :
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Le changement de nom d'un rôle (`ALTER ROLE myrole RENAME TO newname`) est également restreint si le mot de passe utilise l'algorithme de MD5 hachage.
Lorsque cette fonctionnalité est activée, toute tentative d'exécution de l'une de ces commandes SQL sans les autorisations de rôle `rds_password` génère l'erreur suivante :
```
ERROR: must be a member of rds_password to alter passwords
```
Nous vous recommandons de n'accorder `rds_password` qu'à quelques rôles utilisés exclusivement pour la gestion des mots de passe. Si vous accordez des privilèges `rds_password` aux utilisateurs de base de données qui ne disposent pas de privilèges `rds_superuser`, vous devez également leur accorder l'attribut `CREATEROLE`.
Assurez-vous de vérifier les exigences de mot de passe telles que la date d'expiration et le niveau de complexité requis du côté du client. Si vous utilisez votre propre utilitaire côté client pour les modifications relatives aux mots de passe, l'utilitaire doit être membre de `rds_password` et disposer des privilèges `CREATE ROLE`.
# Utilisation de SCRAM pour le chiffrement de mot de passe PostgreSQL
Le *mécanisme d'authentification Salted Challenge Response (SCRAM)* est une alternative à l'algorithme message digest (MD5) par défaut de PostgreSQL pour chiffrer les mots de passe. Le mécanisme d'authentification SCRAM est considéré comme plus sûr que. MD5 Pour en savoir plus sur ces deux approches différentes de sécurisation des mots de passe, consultez [Password Authentication](https://www.postgresql.org/docs/14/auth-password.html) (Authentification par mot de passe) dans la documentation PostgreSQL.
Nous vous recommandons d'utiliser SCRAM plutôt que MD5 comme schéma de chiffrement de mot de passe pour votre cluster de bases de données . Instance de base de données RDS pour PostgreSQL. Il s’agit d’un mécanisme stimulation/réponse cryptographique qui utilise l’algorithme scram-sha-256 pour l’authentification par mot de passe et le chiffrement de mot de passe.
Vous devrez peut-être mettre à jour les bibliothèques pour vos applications clientes de sorte qu’elles prennent en charge SCRAM. Par exemple, les versions JDBC antérieures à 42.2.0 ne prennent pas en charge SCRAM. Pour plus d’informations, consultez [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) (Pilote JDBC PostgreSQL) dans la documentation du pilote JDBC PostgreSQL. Pour obtenir la liste des autres pilotes PostgreSQL prenant en charge SCRAM, consultez la [liste des pilotes](https://wiki.postgresql.org/wiki/List_of_drivers) dans la documentation PostgreSQL.
RDS pour PostgreSQL versions 13.1 et ultérieures prennent en charge scram-sha-256. Ces versions vous permettent également de configurer votre instance de base de données pour qu’elle requiert SCRAM, comme indiqué dans les procédures suivantes.
## Configuration du cluster de de base de données PostgreSQL nécessite de la SCRAM
Pour , vous pouvez exiger que l’instance de base de données RDS pour PostgreSQL n’accepte que les mots de passe qui utilisent l’algorithme scram-sha-256.
**Important**
Pour les proxys RDS existants avec des bases de données PostgreSQL, si vous modifiez l’authentification de base de données pour utiliser uniquement `SCRAM`, le proxy devient indisponible pendant 60 secondes au maximum. Pour éviter ce problème, effectuez l’une des actions suivantes :
Veillez à ce que la base de données permette à la fois l’authentification `SCRAM` et `MD5`.
Pour utiliser uniquement l’authentification `SCRAM`, créez un nouveau proxy, migrez le trafic de votre application vers ce nouveau proxy, puis supprimez le proxy précédemment associé à la base de données.
Avant d’apporter des modifications à votre système, assurez-vous de bien comprendre le processus complet, comme suit :
+ Obtenez des informations sur tous les rôles et sur le chiffrement des mots de passe pour tous les utilisateurs de base de données.
+ Revérifiez les paramètres de votre instance de base de données RDS pour PostgreSQL qui contrôlent le chiffrement des mots de passe.
+ Si votre instance de base de données RDS pour PostgreSQL utilise un groupe de paramètres par défaut, vous devez créer un groupe de paramètres de base de données personnalisé et l’appliquer à votre instance de base de données RDS pour PostgreSQL de sorte à pouvoir modifier les paramètres si nécessaire. Si votre instance de base de données RDS pour PostgreSQL utilise un groupe de paramètres personnalisé, vous pouvez modifier ultérieurement les paramètres nécessaires dans le processus, selon vos besoins.
+ Remplacez le paramètre `password_encryption` par `scram-sha-256`.
+ Informez tous les utilisateurs de la base de données qu’ils doivent mettre à jour leurs mots de passe. Faites de même pour votre compte `postgres`. Les nouveaux mots de passe sont chiffrés et stockés à l’aide de l’algorithme scram-sha-256.
+ Vérifiez que tous les mots de passe utilisent le même type de chiffrement.
+ Si tous les mots de passe utilisent scram-sha-256, vous pouvez modifier le paramètre `rds.accepted_password_auth_method` de `md5+scram` à `scram-sha-256`.
**Avertissement**
Après avoir changé `rds.accepted_password_auth_method` pour scram-sha-256 uniquement, tous les utilisateurs (rôles) avec des mots de passe chiffrés par `md5` ne peuvent pas se connecter.
### Préparez-vous à avoir besoin de SCRAM pour votre instance de base de données
Avant d’apporter des modifications à votre instance de base de données RDS pour PostgreSQL, vérifiez tous les comptes utilisateurs de base de données existants. Vérifiez également le type de chiffrement utilisé pour les mots de passe. Pour ce faire, utilisez l’extension `rds_tools`. Pour savoir quelles versions de PostgreSQL prennent en charge `rds_tools`, consultez [Versions d’extension pour Amazon RDS pour PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**Pour obtenir la liste des utilisateurs de base de données (rôles) et des méthodes de chiffrement des mots de passe**
1. Utilisez `psql` pour vous connecter à votre instance de base de données RDS pour PostgreSQL, comme suit.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Installez l’extension `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Obtenez la liste des rôles et des méthodes de chiffrement.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Vous voyez des résultats similaires à ce qui suit.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Création d’un groupe de paramètres de base de données personnalisé
**Note**
Si votre instance de base de données RDS pour PostgreSQL utilise déjà un groupe de paramètres personnalisé, vous n’avez pas besoin d’en créer un.
Pour obtenir un aperçu des groupes de paramètres pour Amazon RDS, consultez [Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Le type de chiffrement utilisé pour les mots de passe est défini dans un paramètre, `password_encryption`. Le chiffrement autorisé par l’instance de base de données RDS pour PostgreSQL est défini dans un autre paramètre, `rds.accepted_password_auth_method`. Le remplacement de l’un de ces paramètres par une valeur autre que celle par défaut requiert de créer un groupe de paramètres de base de données personnalisé et de l’appliquer à votre instance.
Vous pouvez également utiliser l'API AWS Management Console ou l'API RDS pour créer un de base de données personnalisé. Pour plus d'informations, consultez
Vous pouvez maintenant employer le groupe de paramètres personnalisés avec votre instance de base de données.
**Pour créer un groupe de de paramètres de base de données**
1. Utilisez la commande CLI `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` pour créer le groupe de paramètres de base de données personnalisé. Cet exemple utilise `postgres13` comme source pour ce groupe de paramètres personnalisé.
Pour Linux, macOS ou Unix :
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Pour Windows :
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Utilisez la commande CLI `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` pour appliquer ce groupe de paramètres personnalisé à votre cluster de bases de données RDS pour PostgreSQL.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Pour Windows :
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Pour resynchroniser votre instance de base de données RDS pour PostgreSQL avec votre groupe de paramètres de base de données personnalisé, vous devez redémarrer l’instance principale et toutes les autres instances du cluster. Planifiez cette opération pendant votre fenêtre de maintenance habituelle afin de minimiser l’impact sur vos utilisateurs.
### Configuration du chiffrement des mots de passe pour utiliser SCRAM
Le mécanisme de chiffrement du mot de passe utilisé par une instance de base de données RDS pour PostgreSQL est défini(e) dans le groupe de paramètres de base de données dans le paramètre `password_encryption`. Les valeurs autorisées incluent une valeur non définie, `md5` ou `scram-sha-256`. La valeur par défaut dépend de la version de RDS pour PostgreSQL, comme suit :
+ RDS pour PostgreSQL versions 14 et ultérieures : la valeur par défaut est `scram-sha-256`
+ RDS pour PostgreSQL 13 : la valeur par défaut est `md5`
En attachant un groupe de paramètres de base de données personnalisé à votre instance de base de données RDS pour PostgreSQL, vous pouvez modifier les valeurs du paramètre de chiffrement des mots de passe.
![\[Puis, la console RDS affiche les valeurs par défaut des paramètres password_encryption pour RDS pour PostgreSQL.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Pour remplacer le paramètre de chiffrement des mots de passe par scram-sha-256**
+ Remplacez la valeur du chiffrement des mots de passe par scram-sha-256, comme indiqué ci-après. Cette modification peut être appliquée immédiatement, car le paramètre est dynamique. Aucun redémarrage n’est donc nécessaire pour que la modification soit appliquée.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Pour Windows :
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migration des mots de passe des rôles utilisateur vers SCRAM
Vous pouvez migrer les mots de passe pour les rôles d’utilisateur vers SCRAM comme décrit ci-dessous.
**Pour migrer les mots de passe des utilisateurs (rôles) de base de données MD5 vers SCRAM**
1. Connectez-vous en tant qu’utilisateur administrateur (nom d’utilisateur par défaut, `postgres`) comme suit.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Vérifiez la valeur du paramètre `password_encryption` sur votre instance de base de données RDS pour PostgreSQL à l’aide de la commande suivante.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Remplacez la valeur de ce paramètre par scram-sha-256. Pour de plus amples informations, veuillez consulter [Configuration du chiffrement des mots de passe pour utiliser SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Vérifiez à nouveau la valeur pour vous assurer qu’elle est maintenant réglée sur `scram-sha-256`, comme suit.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Demandez à tous les utilisateurs de base de données de modifier leurs mots de passe. Veillez également à modifier votre propre mot de passe pour le compte `postgres` (utilisateur de base de données avec privilèges `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Répétez l’opération pour toutes les bases de données de votre Instance de base de données RDS pour PostgreSQL.
### Modification du paramètre de sorte à utiliser SCRAM
Il s’agit de la dernière étape du processus. Une fois que vous avez effectué la modification de la procédure suivante, tous les comptes utilisateurs (rôles) qui utilisent toujours le chiffrement `md5` pour les mots de passe ne pourront pas se connecter au Instance de base de données RDS pour PostgreSQL.
Le paramètre `rds.accepted_password_auth_method` spécifie la méthode de chiffrement acceptée par l’instance de base de données RDS pour PostgreSQL pour un mot de passe utilisateur pendant le processus de connexion. La valeur par défaut est `md5+scram`, ce qui signifie que l’une des méthodes est acceptée. L’image suivante indique la valeur par défaut de ce paramètre.
![\[La console RDS affiche les valeurs par défaut et autorisées pour les paramètres rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Les valeurs autorisées pour ce paramètre sont `md5+scram` ou `scram`. Si la valeur de ce paramètre est remplacée par `scram`, le paramètre devient obligatoire.
**Pour modifier la valeur du paramètre afin d’exiger l’authentification SCRAM pour les mots de passe**
1. Vérifiez que tous les mots de passe utilisateur de toutes les bases de données de votre instance de base de données RDS pour PostgreSQL utilisent `scram-sha-256` pour le chiffrement des mots de passe. Pour ce faire, interrogez `rds_tools` pour obtenir le rôle (utilisateur) et le type de chiffrement, comme suit.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Répétez la requête sur toutes les instances de base de données de votre Instance de base de données RDS pour PostgreSQL.
Si tous les mots de passe utilisent scram-sha-256, vous pouvez continuer.
1. Remplacez la valeur de l’authentification par mot de passe acceptée par scram-sha-256, comme suit.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Pour Windows :
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Gestion des connexions inactives dans PostgreSQL
Les connexions inactives se produisent lorsqu’une session de base de données reste active sur le serveur alors que l’application cliente a été abandonnée ou interrompue de manière anormale. Cette situation se produit généralement lorsque les processus clients se bloquent ou se terminent de manière inattendue sans fermer correctement leurs connexions à la base de données ou sans annuler les demandes en cours.
PostgreSQL identifie et nettoie efficacement les connexions inactives lorsque les processus du serveur sont inactifs ou tentent d’envoyer des données aux clients. Cependant, la détection est difficile pour les sessions inactives, pour les sessions qui attendent une entrée du client ou pour les sessions qui exécutent activement des requêtes. Pour gérer ces scénarios, PostgreSQL fournit les paramètres `tcp_keepalives_*`, `tcp_user_timeout` et `client_connection_check_interval`.
**Topics**
+ [
## Comprendre TCP Keepalive
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [
## Principaux paramètres TCP keepalive dans RDS pour PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [
## Cas d’utilisation des paramètres TCP Keepalive
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [
## Bonnes pratiques
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Comprendre TCP Keepalive
TCP Keepalive est un mécanisme de niveau protocole qui permet de maintenir et de vérifier l’intégrité de la connexion. Chaque connexion TCP gère les paramètres au niveau du noyau, lesquels régissent le comportement de keepalive. Lorsque le minuteur Keepalive expire, le système procède comme suit :
+ Il envoie un paquet de test sans aucune donnée, en définissant l’indicateur ACK.
+ Attend une réponse du point de terminaison distant conformément aux TCP/IP spécifications.
+ Il gère l’état de la connexion en fonction de la réponse ou de l’absence de réponse.
## Principaux paramètres TCP keepalive dans RDS pour PostgreSQL
| Paramètre | Description | Valeurs par défaut |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Spécifie le nombre de secondes d'inactivité avant l'envoi du message keepalive. | 300 |
| tcp\$1keepalives\$1interval | Spécifie le nombre de secondes entre les retransmissions de messages keepalive non reconnus. | 30 |
| tcp\$1keepalives\$1count | Nombre maximum de messages KeepAlive perdus avant de déclarer la fin de la connexion | 2 |
| tcp\$1user\$1timeout | Spécifie la durée (en millisecondes) pendant laquelle les données non reconnues peuvent rester avant de fermer de force la connexion. | 0 |
| client\$1connection\$1check\$1interval | Définit l'intervalle (en millisecondes) pour vérifier l'état de la connexion client lors de requêtes de longue durée. Cela garantit une détection plus rapide des connexions fermées. | 0 |
## Cas d’utilisation des paramètres TCP Keepalive
### Maintien en vie des sessions inactives
Pour éviter que des connexions inactives ne soient arrêtées par des pare-feux ou des routeurs pour cause d’inactivité :
+ Configurez `tcp_keepalives_idle` pour envoyer des paquets keepalive à intervalles réguliers.
### Détection des connexions inactives
Pour détecter rapidement les connexions inactives, procédez comme suit :
+ Ajustez `tcp_keepalives_idle`, `tcp_keepalives_interval` et `tcp_keepalives_count`. Par exemple, avec les paramètres par défaut d’Aurora PostgreSQL, il faut environ une minute (2 tests de 30 secondes) pour détecter une connexion inactive. La réduction de ces valeurs peut accélérer la détection.
+ Utilisez `tcp_user_timeout` pour spécifier le temps d’attente maximal pour un accusé de réception.
Les paramètres TCP keepalive aident le noyau à détecter les connexions inactives, mais PostgreSQL peut ne pas agir tant que le socket n’est pas utilisé. Si une session exécute une longue requête, il est possible que les connexions inactives ne soient détectées qu’une fois la requête terminée. Dans PostgreSQL 14 et versions ultérieures, `client_connection_check_interval` peut accélérer la détection des connexions inactives en interrogeant régulièrement le socket lors de l’exécution de la requête.
## Bonnes pratiques
+ **Définissez des intervalles keepalive raisonnables :** réglez `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` et `tcp_keepalives_interval` pour équilibrer la vitesse de détection et l’utilisation des ressources.
+ **Optimisez les conditions pour votre environnement :** alignez les paramètres sur le comportement du réseau, les politiques de pare-feu et les besoins des sessions.
+ **Tirez parti des fonctionnalités de PostgreSQL :** utilisez `client_connection_check_interval` dans PostgreSQL versions 14 et ultérieures pour des contrôles de connexion efficaces.
# Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS pour PostgreSQL
Nous vous conseillons vivement d’utiliser la fonction autovacuum afin de maintenir l’intégrité de votre instance de base de données PostgreSQL. La fonction autovacuum automatise le lancement des commandes VACUUM et ANALYZE. Elle vérifie les tables ayant eu un grand nombre de tuples insérés, mis à jour ou supprimés. Après cette vérification, elle récupère le stockage en supprimant les données ou les tuples obsolètes de la base de données PostgreSQL.
Par défaut, la fonction autovacuum est activée sur les instances de base de données RDS pour PostgreSQL que vous créez en utilisant l’un des groupes de paramètres de base de données PostgreSQL par défaut. Les autres paramètres de configuration associés à la fonction autovacuum sont également définis par défaut. Comme ces valeurs par défaut sont relativement génériques, vous pouvez bénéficier du réglage de certains paramètres associés à la fonction d’autovacuum pour votre charge de travail spécifique.
Vous trouverez ci-dessous de plus amples informations sur l’autovacuum et sur la façon de régler certains de ses paramètres sur votre instance de base de données RDS pour PostgreSQL. Pour obtenir des informations générales, consultez [Bonnes pratiques pour utiliser les moteurs de stockage PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [
## Allocation de mémoire pour la fonction autovacuum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [
## Réduction de la probabilité de bouclage de l’ID de transaction
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [
# Déterminer si les tables de votre base de données ont besoin d’une opération VACUUM
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [
# Déterminer les tables actuellement éligibles pour autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [
# Déterminer si autovacuum est en cours d'exécution et pour combien de temps
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [
# Réalisation d’un gel manuel du processus vacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [
# Réindexation d'une table pendant l'exécution du processus autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [
# Gestion de la fonction autovacuum avec de grands index
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [
# Autres paramètres qui affectent la fonction d'autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [
# Définition des paramètres d'autovacuum au niveau de la table
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [
# Enregistrement des activités d'autovacuum et de vacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [
# Comprendre le comportement de l’autovacuum avec les bases de données non valides
](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [
# Identification et résolution des bloqueurs de vacuum agressifs dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Allocation de mémoire pour la fonction autovacuum
L’un des paramètres les plus importants qui influencent les performances d’autovacuum est [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). Dans RDS pour PostgreSQL versions 14 et antérieures, le paramètre `autovacuum_work_mem` est défini sur -1, ce qui indique que le paramètre `maintenance_work_mem` est utilisé à la place. Pour toutes les autres versions, `autovacuum_work_mem` est déterminé par GREATEST (\$1DBInstanceClassMemory/32768\$1, 65536).
Les opérations d'aspiration manuelles utilisent toujours ce `maintenance_work_mem` réglage, le réglage par défaut étant GREATEST (\$1DBInstanceClassMemory/63963136 \$11024\$1, 65536), et il peut également être ajusté au niveau de la session à l'aide de la commande pour des opérations manuelles plus ciblées. `SET` `VACUUM`
`autovacuum_work_mem` détermine la mémoire permettant à l’autovacuum de contenir les identifiants des tuples inactifs (`pg_stat_all_tables.n_dead_tup`) pour les opérations de vacuum d’index.
Lors des calculs visant à déterminer la valeur du paramètre `autovacuum_work_mem`, tenez compte des points suivants :
+ Si vous définissez une valeur trop basse pour ce paramètre, le processus vacuum pourrait avoir à analyser la table plusieurs fois pour mener à bien sa tâche. Ces nombreuses analyses peuvent avoir un impact négatif sur les performances. Pour les instances plus grandes, le réglage de `maintenance_work_mem` ou `autovacuum_work_mem` sur au moins 1 Go peut améliorer les performances des opérations de vacuum des tables contenant un grand nombre de tuples inactifs. Cependant, dans les versions 16 et antérieures de PostgreSQL, l’utilisation de la mémoire de vacuum est limitée à 1 Go, ce qui est suffisant pour traiter environ 179 millions de tuples inactifs en un seul passage. Si une table contient plus de tuples inactifs que cela, l’opération de vacuum doit effectuer plusieurs passages dans les index de la table, ce qui augmente considérablement le temps requis. À partir de la version 17 de PostgreSQL, il n’y a pas de limite de 1 Go et l’autovacuum peut traiter plus de 179 millions de tuples en utilisant des arbres radix.
Un identifiant de tuple a une taille de 6 octets. Pour estimer la mémoire nécessaire afin d’effectuer le vacuum d’un index d’une table, interrogez `pg_stat_all_tables.n_dead_tup` pour chercher le nombre de tuples inactifs, puis multipliez ce nombre par 6 pour déterminer la mémoire requise pour effectuer le vacuum de l’index en un seul passage. Vous pouvez utiliser la requête suivante :
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ Le paramètre `autovacuum_work_mem` fonctionne en conjonction avec le paramètre `autovacuum_max_workers`. Chaque application de travail parmi `autovacuum_max_workers` peut utiliser la mémoire que vous allouez. Si vous avez beaucoup de petites tables, allouez plus de `autovacuum_max_workers` et moins de `autovacuum_work_mem`. Si vous avez de grandes tables (d’une taille supérieure à 100 Go), allouez plus de mémoire et moins de processus de travail. Vous devez avoir alloué suffisamment de mémoire pour pouvoir prendre en charge votre plus grande table. Assurez-vous donc que la combinaison des processus de travail et de la mémoire est égale à la mémoire totale que vous souhaitez allouer.
## Réduction de la probabilité de bouclage de l’ID de transaction
Dans certains cas, les valeurs du groupe de paramètres associées à la fonction autovacuum peuvent ne pas être suffisamment agressives pour empêcher le bouclage de l’ID de transaction. Pour résoudre ce problème, RDS pour PostgreSQL fournit un mécanisme qui adapte automatiquement les valeurs des paramètres d’autovacuum. *Autovacuum adaptatif* est une fonctionnalité pour RDS pour PostgreSQL. Une explication détaillée du [bouclage de l’ID de transaction](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) figure dans la documentation PostgreSQL.
L’autovacuum adaptatif est activé par défaut pour les instances RDS pour PostgreSQL avec le paramètre dynamique `rds.adaptive_autovacuum` défini sur ON. Nous vous recommandons vivement de garder cette option activée. Toutefois, pour désactiver le réglage adaptatif des paramètres d’autovacuum, définissez le paramètre `rds.adaptive_autovacuum` sur 0 ou OFF.
Le bouclage de l’ID de transaction reste possible même lorsque Amazon RDS Amazon RDS ajuste les paramètres d’autovacuum. Nous vous encourageons à implémenter une CloudWatch alarme Amazon pour l'encapsulation des identifiants de transaction. Pour plus d'informations, consultez l'article [Implémenter un système d'alerte précoce pour l'encapsulation des identifiants de transaction dans RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) sur le blog de base de données. AWS
Lorsque le réglage adaptatif des paramètres d'aspiration automatique est activé, Amazon RDS commence à ajuster les paramètres d'aspiration automatique lorsque la CloudWatch métrique `MaximumUsedTransactionIDs` atteint la valeur du `autovacuum_freeze_max_age` paramètre ou 500 000 000, la valeur la plus élevée étant retenue.
Amazon RDS continue à ajuster les paramètres pour la fonction autovacuum si une table continue à s’orienter vers le bouclage de l’ID de transaction. Chacun de ces ajustements dédie plus de ressources à la fonction d’autovacuum pour éviter le bouclage. Amazon RDS met à jour les paramètres suivants associés à la fonction d’autovacuum :
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS modifie ces paramètres seulement si la nouvelle valeur rend la fonction d’autovacuum plus agressive. Ces paramètres sont modifiés dans la mémoire sur l’instance de base de données. Les valeurs figurant dans le groupe de paramètres ne sont pas modifiées. Pour afficher les paramètres en mémoire actuels, utilisez la commande SQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html) de PostgreSQL.
Chaque fois que Amazon RDS modifie l’un de ces paramètres d’autovacuum, il génère un événement pour l’instance de base de données concernée. Cet événement est visible sur AWS Management Console et via l'API Amazon RDS. Une fois que la `MaximumUsedTransactionIDs` CloudWatch métrique est revenue en dessous du seuil, Amazon RDS réinitialise les paramètres relatifs à l'autovacuum en mémoire aux valeurs spécifiées dans le groupe de paramètres. Il génère ensuite un autre événement correspondant à cette modification.
# Déterminer si les tables de votre base de données ont besoin d’une opération VACUUM
Vous pouvez utiliser la requête suivante pour afficher le nombre de transactions dégelées dans une base de données. La `datfrozenxid` colonne de la `pg_database` ligne d'une base de données est la limite inférieure de la transaction normale qui IDs apparaît dans cette base de données. Cette colonne représente le minimum des valeurs `relfrozenxid` par table au sein de la base de données.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Par exemple, les résultats de l’exécution de la requête précédente pourraient être les suivants.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Lorsque l'âge d'une base de données atteint 2 milliards de transactions IDs, l'ID de transaction (XID) est contourné et la base de données passe en lecture seule. Vous pouvez utiliser cette requête pour produire une métrique et l’exécuter plusieurs fois par jour. Par défaut, autovacuum est défini pour conserver un âge de transactions inférieur à 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Un exemple de politique de surveillance peut ressembler à ceci :
+ Définissez la valeur `autovacuum_freeze_max_age` sur 200 millions de transactions.
+ Si une table atteint les 500 millions de transactions dégelées, elle déclenche une alarme de faible gravité. Ce n’est pas une valeur déraisonnable, mais elle peut indiquer que la fonction d’autovacuum ne suit pas.
+ Si l’âge d’une table atteint 1 milliard, cela doit être considéré comme une alarme exigeant une action. En général, il est conseillé de conserver des âges plus proches de `autovacuum_freeze_max_age` pour des raisons de performances. Nous vous recommandons d’enquêter en appliquant les recommandations suivantes.
+ Si une table atteint les 1,5 million de transactions non vidées, elle déclenche une alarme de haute gravité. Selon la rapidité avec laquelle votre base de données utilise les transactions IDs, cette alarme peut indiquer que le système n'a plus le temps d'exécuter Autovacuum. Dans ce cas, nous vous recommandons une résolution immédiate.
Si une table enfreint constamment ces seuils, vous devez continuer à modifier vos paramètres d’autovacuum. Par défaut, l’utilisation manuelle de VACUUM (pour lequel les retards basés sur les coûts sont désactivés) est plus agressive que le processus d’autovacuum par défaut, mais elle est également plus intrusive pour le système dans son ensemble.
Nous vous recommandons la procédure suivante :
+ Gardez tout cela à l’esprit et activez un mécanisme de surveillance afin de connaître l’âge de vos transactions les plus anciennes.
Pour plus d'informations sur la création d'un processus qui vous avertit de l'encapsulation des identifiants de transaction, consultez le billet de blog consacré à la AWS base de données [Implémentation d'un système d'alerte précoce pour l'encapsulation des identifiants de transaction dans Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/).
+ Pour les tables plus occupées, procédez régulièrement au gel manuel du processus de vacuum pendant une fenêtre de maintenance, en plus de compter sur la fonction d’autovacuum. Pour plus d’informations sur le gel manuel du processus vacuum, consultez [Réalisation d’un gel manuel du processus vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Déterminer les tables actuellement éligibles pour autovacuum
Souvent, une ou deux tables ont besoin d’une opération VACUUM. Les tables dont la valeur `relfrozenxid` est supérieure au nombre de transactions dans `autovacuum_freeze_max_age` sont toujours ciblées par la fonction d’autovacuum. Sinon, si le nombre de tuples rendus obsolètes depuis la dernière opération VACUUM dépasse le seuil de vacuum, la table est vidée.
Le [seuil d’autovacuum](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) est défini comme suit :
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
où le `vacuum base threshold` est `autovacuum_vacuum_threshold`, le `vacuum scale factor` est `autovacuum_vacuum_scale_factor` et le `number of tuples` est `pg_class.reltuples`.
Pendant que vous êtes connecté à votre base de données, exécutez la requête suivante pour afficher la liste des tables qu’autovacuum considère comme éligibles pour une action vacuum.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Déterminer si autovacuum est en cours d'exécution et pour combien de temps
Si vous avez besoin de vider manuellement une table, vous devez déterminer si autovacuum est en cours d'exécution. Si c'est le cas, vous devrez peut-être ajuster les paramètres pour le faire fonctionner plus efficacement, ou mettre fin à autovacuum afin de pouvoir exécuter manuellement VACUUM.
Utilisez la requête suivante pour déterminer si autovacuum est en cours d'exécution, pendant combien de temps il a été en cours d'exécution et s'il est en attente sur une autre session.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Après l'exécution de la requête, vous devez obtenir un résultat similaire à ce qui suit.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Plusieurs problèmes peuvent occasionner des longueurs d'exécution (plusieurs jours) d'une session autovacuum. Le problème le plus courant est que la valeur de votre paramètre [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) est trop basse pour la taille de la table ou pour la fréquence des mises à jour.
Nous vous recommandons d'utiliser la formule suivante pour définir la valeur du paramètre `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
De courtes sessions autovacuum peuvent également indiquer des problèmes :
+ Cela peut indiquer un nombre `autovacuum_max_workers` insuffisant pour votre charge de travail. Dans ce cas, vous devez indiquer le nombre d'exécutants.
+ Cela peut indiquer une corruption d'index (la fonction d'autovacuum se bloque et redémarre sur la même relation, mais ne progresse pas). Dans ce cas, exécutez un `vacuum freeze verbose table` manuel pour voir la cause exacte.
# Réalisation d’un gel manuel du processus vacuum
Vous pouvez effectuer un gel manuel sur une table pour laquelle un processus vacuum est déjà en cours. C’est utile si vous avez identifié une table avec un âge proche de 2 milliards de transactions (ou supérieur à tous les seuils que vous surveillez).
Les étapes suivantes sont fournies à titre informatif et il existe plusieurs variantes de ce processus. Par exemple, pendant le test, supposons que vous trouviez que la valeur du paramètre [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) a été définie trop bas et que vous devez agir immédiatement sur une table. Toutefois, vous ne voulez pas renvoyer l’instance à l’expéditeur pour le moment. À l’aide des requêtes des sections précédentes, vous déterminez quelle table pose problème et remarquez une session autovacuum en cours d’exécution depuis longtemps. Vous savez que vous devez modifier le paramètre `maintenance_work_mem`, mais vous devez également agir immédiatement et effectuer un processus vacuum sur la table concernée. La procédure suivante montre ce que vous devez faire dans cette situation.
**Pour procéder manuellement au gel du processus vacuum**
1. Ouvrez les deux sessions de la base de données contenant la table sur laquelle vous voulez effectuer le processus vacuum. Pour la seconde session, utilisez « écran » ou un autre utilitaire qui gère la session si votre connexion est abandonnée.
1. Dans la première session, obtenez le PID de la session autovacuum en cours d’exécution sur la table.
Exécutez la requête suivante pour obtenir le PID de la session autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Dans la deuxième session, calculez la quantité de mémoire dont vous avez besoin pour cette opération. Dans cet exemple, nous déterminons que nous pouvons nous permettre d’utiliser jusqu’à 2 Go de mémoire pour cette opération. Nous affectons donc 2 Go à [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) pour la session en cours.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Dans la deuxième session, émettez une commande `vacuum freeze verbose` pour la table. Le paramètre de mode détaillé est utile, car il vous permet de voir l’activité bien qu’il n’existe actuellement aucun rapport d’avancement de cette opération dans PostgreSQL.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Dans la première session, si l’autovacuum provoquait un blocage de la session de vacuum, `pg_stat_activity` indique que l’attente a la valeur `T` pour votre session de vacuum. Dans ce cas, mettez fin au processus d’autovacuum comme suit.
```
SELECT pg_terminate_backend('the_pid');
```
**Note**
Certaines versions antérieures d’Amazon RDS ne peuvent pas mettre fin à un processus d’autovacuum à l’aide de la commande précédente et échouent avec l’erreur suivante : `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
À ce stade, votre session commence. L’autovacuum redémarre immédiatement parce que cette table figure probablement tout en haut de sa liste de tâches.
1. Lancez votre commande `vacuum freeze verbose` dans la session 2, puis terminez le processus autovacuum de la session 1.
# Réindexation d'une table pendant l'exécution du processus autovacuum
Si un index a été corrompu, la fonction d'autovacuum continue à traiter la table et échoue. Si vous essayez d'effectuer un processus vacuum manuel dans cette situation, vous recevez un message d'erreur similaire à ce qui suit.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Lorsque l'index est corrompu et que la fonction d'autovacuum tente de s'exécuter sur la table, vous vous heurtez à une session autovacuum déjà en cours d'exécution. Lorsque vous émettez une commande [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html), vous retirez un verrou exclusif sur la table. Les opérations d'écriture sont bloquées, ainsi que les opérations de lecture qui utilisent cet index spécifique.
**Pour réindexer une table lorsque la fonction d'autovacuum est en cours d'exécution sur la table**
1. Ouvrez les deux sessions de la base de données contenant la table sur laquelle vous voulez effectuer le processus vacuum. Pour la seconde session, utilisez « écran » ou un autre utilitaire qui gère la session si votre connexion est abandonnée.
1. Dans la première session, obtenez le PID de la session autovacuum en cours d'exécution sur la table.
Exécutez la requête suivante pour obtenir le PID de la session autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Dans la deuxième session, émettez la commande reindex.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Dans la première session, si autovacuum provoquait un blocage du processus, vous voyez dans `pg_stat_activity` que l'attente a la valeur « T » pour votre session vacuum. Dans ce cas, vous mettrez fin au processus autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
À ce stade, votre session commence. Il est important de noter que la fonction d'autovacuum redémarre immédiatement parce que cette table figure probablement tout en haut de sa liste de tâches.
1. Lancez votre commande dans la session 2, puis terminez le processus autovacuum de la session 1.
# Gestion de la fonction autovacuum avec de grands index
Dans le cadre de son fonctionnement, la fonction *autovacuum* effectue plusieurs [phases de mise à vide](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) lorsqu’elle s’exécute sur une table. Avant que la table ne soit nettoyée, tous ses index sont d’abord vidés. Lorsque vous supprimez plusieurs grands index, cette phase consomme beaucoup de temps et de ressources. Par conséquent, il est recommandé de contrôler le nombre d’index d’une table et d’éliminer les index inutilisés.
Pour ce processus, vérifiez d’abord la taille globale de l’index. Déterminez ensuite s’il existe des index potentiellement inutilisés qui peuvent être supprimés comme le montrent les exemples suivants.
**Pour vérifier la taille de la table et de ses index**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
Dans cet exemple, la taille des index est supérieure à celle de la table. Cette différence peut entraîner des problèmes de performances, car les index sont surchargés ou inutilisés, ce qui a une incidence sur la fonction autovacuum ainsi que sur les opérations d’insertion.
**Pour vérifier la présence d’index inutilisés**
À l’aide de la vue [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), vous pouvez vérifier la fréquence d’utilisation d’un index avec la colonne `idx_scan`. Dans l’exemple suivant, les index non utilisés ont la valeur `idx_scan` définie sur `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**Note**
Ces statistiques sont incrémentielles à partir du moment où elles sont réinitialisées. Supposons que vous disposiez d’un index qui n’est utilisé qu’à la fin d’un trimestre ou uniquement pour un rapport spécifique. Il est possible que cet index n’ait pas été utilisé depuis la réinitialisation des statistiques. Pour plus d’informations, consultez [Statistics Functions](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS) (Fonctions statistiques). Les index utilisés pour renforcer l’unicité ne seront pas analysés et ne devraient pas être identifiés comme des index inutilisés. Pour identifier les index inutilisés, vous devez avoir une connaissance approfondie de l’application et de ses requêtes.
Pour vérifier quand les statistiques ont été réinitialisées pour la dernière fois pour une base de données, utilisez [ 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)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Vidage d’une table le plus rapidement possible
**RDS pour PostgreSQL versions 12 et ultérieures**
Si vous avez trop d’index dans une grande table, il se peut que votre instance de base de données soit proche du bouclage de l’ID de transaction (XID), c’est-à-dire lorsque le compteur XID revient à zéro. Si elle n’est pas vérifiée, cette situation peut entraîner une perte de données. Toutefois, vous pouvez rapidement vider la table sans nettoyer les index. Dans RDS pour PostgreSQL versions 12 et ultérieures, vous pouvez utiliser VACUUM avec la clause [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Si une session de mise à vide automatique est déjà en cours, vous devez y mettre fin pour démarrer le processus VACUUM manuel. Pour plus d’informations sur le gel manuel du processus vacuum, consultez [Réalisation d’un gel manuel du processus vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**Note**
Ignorer régulièrement le nettoyage de l’index entraîne un gonflement de l’index, ce qui dégrade les performances des analyses. L’index conserve les lignes inactives et le tableau conserve les pointeurs de ligne inactive. Par conséquent, `pg_stat_all_tables.n_dead_tup` augmente jusqu’à l’exécution d’un autovacuum ou d’un VACUUM manuel avec nettoyage d’index. Une bonne pratique consiste à n’utiliser la procédure précédente que pour empêcher le bouclage de l’ID de transaction.
**RDS pour PostgreSQL versions 11 et ultérieures**
Toutefois, dans RDS pour PostgreSQL versions 11 et ultérieures, la seule façon de permettre au processus vacuum de se terminer plus rapidement est de réduire le nombre d’index sur une table. La suppression d’un index peut affecter les plans de requête. Nous vous recommandons de supprimer d’abord les index inutilisés, puis de les supprimer lorsque le bouclage de l’ID de transaction est très proche. Une fois le processus vacuum terminé, vous pouvez recréer ces index.
# Autres paramètres qui affectent la fonction d'autovacuum
Cette requête affiche les valeurs de certains des paramètres qui ont un impact direct sur la fonction d'autovacuum et son comportement. Les [paramètres d'autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) sont décrits en détails dans la documentation PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Tous ces paramètres affectent la fonction d'autovacuum, mais les plus importants sont :
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Définition des paramètres d'autovacuum au niveau de la table
Les [paramètres de stockage](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) liés à la fonction d'autovacuum peuvent être définis au niveau de la table, ce qui peut être plus judicieux que de modifier le comportement de toute la base de données. Pour les grandes tables, vous devrez peut-être définir des paramètres agressifs et il est déconseillé de faire en sorte que la fonction d'autovacuum se comporte de cette manière pour toutes les tables.
La requête suivante affiche les tables qui ont actuellement des options en place au niveau de la table.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Par exemple, cela peut être utile sur les tables qui sont beaucoup plus grandes que le reste de vos tables. Supposez que vous avez une table de 300 Go et 30 autres tables de moins de 1 Go. Dans ce cas, vous pouvez définir des paramètres spécifiques pour votre grande table afin de ne pas modifier le comportement de l'intégralité de votre système.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Cela permet de désactiver le retard d'autovacuum basé sur les coûts pour cette table au détriment d'une plus grande utilisation des ressources sur votre système. Normalement, l'autovacuum s'arrête pour `autovacuum_vacuum_cost_delay` à chaque fois que `autovacuum_cost_limit` est atteinte. Pour plus d'informations, veuillez consulter la documentation PostgreSQL concernant le [processus de vacuum basé sur les coûts](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Enregistrement des activités d'autovacuum et de vacuum
Les informations sur les activités d'autovacuum sont envoyées au `postgresql.log` en fonction du niveau spécifié dans le paramètre `rds.force_autovacuum_logging_level`. Voici les valeurs autorisées pour ce paramètre et les versions de PostgreSQL pour lesquelles cette valeur est le paramètre par défaut :
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL versions 13 et ultérieures)
+ `error`, journal, `fatal`, `panic`
`rds.force_autovacuum_logging_level` fonctionne avec le paramètre `log_autovacuum_min_duration`. La valeur du paramètre `log_autovacuum_min_duration` est le seuil (en millisecondes) au-dessus duquel les actions autovacuum sont enregistrées. Une valeur de `-1` n'enregistre rien, tandis qu'une valeur de 0 enregistre toutes les actions. Comme avec `rds.force_autovacuum_logging_level`, valeurs par défaut pour `log_autovacuum_min_duration` dépendent de la version, comme suit :
+ `10000 ms` : PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 et PostgreSQL 11
+ `(empty)` : aucune valeur par défaut pour PostgreSQL 10 et PostgreSQL 9.6
Nous vous recommandons de définir le `rds.force_autovacuum_logging_level` à la valeur `WARNING`. Nous vous recommandons également de définir `log_autovacuum_min_duration` à une valeur comprise entre 1000 et 5000. Un paramètre de 5000 journaux d'activité qui prend plus de 5000 millisecondes. Tout paramètre autre que -1 enregistre également les messages si l'action autovacuum est ignorée en raison d'un verrouillage en conflit ou d'une perte simultanée de relations. Pour plus d'informations, veuillez consulter [Action Vacuum automatique](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) dans la documentation PostgreSQL.
Pour résoudre les problèmes, vous pouvez modifier le paramètre `rds.force_autovacuum_logging_level` à l'un des niveaux de débogage, de `debug1` jusqu'à `debug5` pour obtenir les informations les plus détaillées. Nous vous recommandons d'utiliser les paramètres de débogage pendant de courtes périodes et à des fins de dépannage uniquement. Pour en savoir plus, veuillez consulter la rubrique [Quand journaliser](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) dans la documentation de PostgreSQL.
**Note**
PostgreSQL permet au compte `rds_superuser` d'afficher les sessions autovacuum dans `pg_stat_activity`. Par exemple, vous pouvez identifier et mettre fin à la session qui bloque l'exécution d'une commande ou empêche la commande de s'exécuter plus lentement qu'une commande vacuum exécutée manuellement.
# Comprendre le comportement de l’autovacuum avec les bases de données non valides
Une nouvelle valeur `-2` est introduite dans la colonne `datconnlimit` du catalogue `pg_database` pour indiquer que les bases de données qui ont été interrompues au milieu de l’opération DROP DATABASE ne sont pas valides.
Cette nouvelle valeur est disponible dans les versions suivantes de RDS pour PostgreSQL :
+ Version 15.4 et toutes les versions ultérieures
+ 14.9 et versions ultérieures
+ 13.12 et versions ultérieures
+ 12.16 et versions ultérieures
+ 11.21 et versions ultérieures
Les bases de données non valides n’affectent pas la capacité de la fonction d’autovacuum à geler la fonctionnalité des bases de données valides. Autovacuum ignore les bases de données non valides. Par conséquent, les opérations de vacuum régulières continueront à fonctionner correctement et efficacement pour toutes les bases de données valides de votre environnement PostgreSQL.
**Topics**
+ [
## Surveillance de l’ID de transaction
](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [
## Ajustement de la requête de surveillance
](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [
## Résolution du problème de base de données non valide
](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Surveillance de l’ID de transaction
Cette fonction `age(datfrozenxid)` est couramment utilisée pour surveiller l’âge des ID de transaction (XID) des bases de données afin d’empêcher le bouclage de l’ID de transaction.
Les bases de données non valides étant exclues de l’autovacuum, leur compteur d’ID de transaction (XID) peut atteindre la valeur maximale de `2 billion`, revenir à `- 2 billion` et poursuivre ce cycle indéfiniment. Une requête typique pour surveiller le bouclage de l’ID de transaction peut ressembler à ceci :
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Cependant, avec l’introduction de la valeur -2 pour `datconnlimit`, les bases de données non valides peuvent fausser les résultats de cette requête. Étant donné que ces bases de données ne sont pas valides et ne doivent pas faire l’objet de contrôles de maintenance réguliers, elles peuvent générer des faux positifs, ce qui vous laisse penser que `age(datfrozenxid)` est supérieur à ce qu’il est réellement.
## Ajustement de la requête de surveillance
Pour garantir une surveillance précise, vous devez ajuster votre requête de surveillance afin d’exclure les bases de données non valides. Suivez cette requête recommandée :
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Cette requête garantit que seules les bases de données valides sont prises en compte dans le calcul `age(datfrozenxid)`, ce qui reflète fidèlement l’âge des ID de transaction dans l’environnement PostgreSQL.
## Résolution du problème de base de données non valide
Lorsque vous essayez de vous connecter à une base de données non valide, vous pouvez rencontrer un message d’erreur similaire à ce qui suit :
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
En outre, si le paramètre `log_min_messages` est défini sur `DEBUG2` ou supérieur, vous remarquerez peut-être que les entrées de journal suivantes indiquent que le processus autovacuum ignore la base de données non valide :
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Pour résoudre le problème, suivez le `HINT` fourni lors de la tentative de connexion. Connectez-vous à n’importe quelle base de données valide à l’aide de votre compte principal RDS ou d’un compte de base de données doté du rôle `rds_superuser`, puis supprimez les bases de données non valides.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# Identification et résolution des bloqueurs de vacuum agressifs dans RDS pour PostgreSQL
Dans PostgreSQL, l’opération de vacuum est essentielle pour garantir l’intégrité de la base de données, car elle permet de récupérer de l’espace de stockage et d’éviter les problèmes de [bouclage de l’ID de transaction.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) Cependant, il peut arriver que l’opération de vacuum ne fonctionne pas comme vous le souhaitez, ce qui peut entraîner une dégradation des performances ou une surcharge de l’espace de stockage et même avoir un impact sur la disponibilité de votre instance de base de données par bouclage de l’ID de transaction. Il est donc essentiel d’identifier et de résoudre ces problèmes pour optimiser les performances et la disponibilité des bases de données. Lisez [Présentation d’autovacuum dans les environnements Amazon RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) pour en savoir plus sur l’autovacuum.
La fonction `postgres_get_av_diag()` permet d’identifier les problèmes qui empêchent ou retardent la progression du vacuum agressif. Des suggestions sont fournies, qui peuvent inclure des commandes pour résoudre le problème lorsqu’il est identifiable ou des conseils pour des diagnostics supplémentaires lorsque le problème n’est pas identifiable. Les bloqueurs d'aspiration agressifs sont signalés lorsque leur âge dépasse le seuil d'[autoaspiration adaptatif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) de 500 millions de transactions fixé par RDS. IDs
**Quel est l’âge de l’ID de transaction ?**
La `age()` fonction de transaction IDs calcule le nombre de transactions survenues depuis le plus ancien identifiant de transaction dégelé pour une base de données (`pg_database.datfrozenxid`) ou une table (`pg_class.relfrozenxid`). Cette valeur indique l’activité de la base de données depuis la dernière opération de vacuum agressif et met en évidence la charge de travail probable pour les prochains processus VACUUM.
**Qu’est-ce qu’un vacuum agressif ?**
Une opération VACUUM agressive effectue une numérisation complète de toutes les pages d'un tableau, y compris celles qui sont généralement ignorées en mode normal VACUUMs. Cette analyse approfondie vise à « geler » les transactions IDs qui approchent de leur âge maximum, évitant ainsi une situation connue sous le nom d'[encapsulation des identifiants de transaction](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
Pour que `postgres_get_av_diag()` signale un bloqueur, celui-ci doit dater d’au moins 500 millions de transactions.
**Topics**
+ [
# Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [
# Fonctions de postgres\$1get\$1av\$1diag() dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [
# Résolution des bloqueurs de vacuum identifiables dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [
# Résolution des bloqueurs de vacuum non identifiables dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [
# Résolution des problèmes de performance de vacuum dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [
# Explication des messages NOTICE dans RDS pour PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL
La fonction `postgres_get_av_diag()` est actuellement disponible dans les versions RDS pour PostgreSQL suivantes :
+ 17.2 et versions 17 ultérieures
+ 16.7 et versions 16 ultérieures
+ 15.11 et versions 15 ultérieures
+ 14.16 et versions 14 ultérieures
+ 13.19 et versions 13 ultérieures
Pour pouvoir utiliser `postgres_get_av_diag()`, créez l’extension `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Vérifiez que l’extension est installée.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Vérifiez que la fonction est créée.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Fonctions de postgres\$1get\$1av\$1diag() dans RDS pour PostgreSQL
La fonction `postgres_get_av_diag()` récupère des informations de diagnostic sur les processus autovacuum qui bloquent ou sont en retard dans une base de données RDS pour PostgreSQL. Pour obtenir des résultats précis, la requête doit être exécutée dans la base de données dont l’ID de transaction est le plus ancien. Pour plus d’informations sur l’utilisation de la base de données ayant l’ID de transaction le plus ancien, consultez [Non connecté à la base de données dont l’ID de transaction est le plus ancien](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
La fonction `postgres_get_av_diag()` retourne un tableau avec les informations suivantes :
**blocker**
Spécifie la catégorie d’activité de base de données qui bloque le vacuum.
+ [Instruction active](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [État Idle in transaction (Transaction inactive)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transaction préparée](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Emplacement de réplication logique](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Réplica en lecture avec emplacement de réplication physique](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Réplica en lecture avec réplication de streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tables temporaires](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**database**
Spécifie le nom de la base de données, le cas échéant. Il s’agit de la base de données dans laquelle l’activité est en cours et bloque ou bloquera l’autovacuum. Il s’agit de la base de données à laquelle vous devez vous connecter et sur laquelle vous devez agir.
**blocker\$1identifier**
Spécifie l’identifiant de l’activité qui bloque ou bloquera l’autovacuum. Il peut s’agir d’un ID de processus accompagné d’une instruction SQL, d’une transaction préparée, de l’adresse IP d’un réplica en lecture et du nom de l’emplacement de réplication, logique ou physique.
**wait\$1event**
Spécifie l’[événement d’attente](PostgreSQL.Tuning.md) de la session de blocage et s’applique aux bloqueurs suivants :
+ Instruction active
+ État Idle in transaction (Transaction inactive)
**autovacum\$1lagging\$1by**
Spécifie le nombre de transactions pour lesquelles l’autovacuum a pris du retard dans le traitement des éléments en attente par catégorie.
**suggestion**
Spécifie des suggestions pour résoudre le bloqueur. Ces instructions incluent le nom de la base de données dans laquelle l’activité existe, le cas échéant, l’ID de processus (PID) de la session, le cas échéant, et les actions à effectuer.
**suggested\$1action**
Suggère l’action à effectuer pour résoudre le bloqueur.
# Résolution des bloqueurs de vacuum identifiables dans RDS pour PostgreSQL
L’autovacuum effectue des opérations vacuum agressives et abaisse l’âge des ID de transaction en dessous du seuil spécifié par le paramètre `autovacuum_freeze_max_age` de votre instance RDS. Vous pouvez suivre cet âge à l’aide de la métrique `MaximumUsedTransactionIDs` d’Amazon CloudWatch.
Pour trouver le paramètre `autovacuum_freeze_max_age` (dont la valeur par défaut est de 200 millions d’ID de transaction) pour votre instance Amazon RDS, vous pouvez utiliser la requête suivante :
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Notez que `postgres_get_av_diag()` recherche uniquement les bloqueurs de vacuum agressifs quand l’âge dépasse le seuil de 500 millions d’ID de transaction pour l’[autovacuum adaptatif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) d’Amazon RDS. Pour que `postgres_get_av_diag()` détecte un bloqueur, celui-ci doit dater d’au moins 500 millions de transactions.
La fonction `postgres_get_av_diag()` identifie les types de bloqueurs suivants :
**Topics**
+ [
## Instruction active
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [
## État Idle in transaction (Transaction inactive)
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [
## Transaction préparée
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [
## Emplacement de réplication logique
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [
## Réplicas en lecture
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [
## Tables temporaires
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Instruction active
Dans PostgreSQL, une instruction active est une instruction SQL qui est exécutée par la base de données. Cela inclut les requêtes, les transactions ou les opérations en cours. Lors de la surveillance via `pg_stat_activity`, la colonne d’état indique que le processus avec le PID correspondant est actif.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une instruction active.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Action suggérée**
En suivant les instructions de la colonne `suggestion`, l’utilisateur peut se connecter à la base de données dans laquelle l’instruction active se trouve et, comme indiqué dans la colonne `suggested_action`, il est conseillé de vérifier attentivement l’option permettant de mettre fin à la session. Si la résiliation est sûre, vous pouvez utiliser la fonction `pg_terminate_backend()` pour résilier la session. Cette action peut être effectuée par un administrateur (tel que le compte principal RDS) ou par un utilisateur disposant du privilège `pg_terminate_backend()` requis.
**Avertissement**
Une session résiliée annule (`ROLLBACK`) les modifications apportées. En fonction de vos besoins, vous souhaiterez peut-être réexécuter l’instruction. Cependant, il est recommandé de ne le faire qu’une fois que le processus d’autovacuum a terminé son opération de vacuum agressif.
## État Idle in transaction (Transaction inactive)
Une instruction idle in transaction fait référence à toute session qui a ouvert une transaction explicite (par exemple en émettant une instruction `BEGIN`), qui a effectué un certain travail et qui attend maintenant que le client transmettre plus de travail ou signale la fin de la transaction en émettant une instruction `COMMIT`, `ROLLBACK`, ou `END` (ce qui se traduirait par un `COMMIT` implicite).
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une instruction `idle in transaction` comme un bloqueur.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Action suggérée**
Comme indiqué dans la colonne `suggestion`, vous pouvez vous connecter à la base de données dans laquelle la session idle in transaction est présente et mettre fin à la session à l’aide de la fonction `pg_terminate_backend()`. L’utilisateur peut être votre administrateur (compte principal RDS) ou un utilisateur disposant du privilège `pg_terminate_backend()`.
**Avertissement**
Une session résiliée annule (`ROLLBACK`) les modifications apportées. En fonction de vos besoins, vous souhaiterez peut-être réexécuter l’instruction. Cependant, il est recommandé de ne le faire qu’une fois que le processus d’autovacuum a terminé son opération de vacuum agressif.
## Transaction préparée
PostgreSQL autorise les transactions qui font partie d’une stratégie de validation en deux phases appelée [transactions préparées](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Elles sont activées en définissant une valeur différente de zéro pour le paramètre `max_prepared_transactions`. Les transactions préparées sont conçues pour garantir qu’une transaction est durable et reste disponible même après une panne de base de données, un redémarrage ou une déconnexion du client. Comme les transactions régulières, elles reçoivent un ID de transaction et peuvent affecter l’autovacuum. Si elles restent à l’état préparé, l’autovacuum ne peut pas les geler et cela peut entraîner un bouclage de l’ID de transaction.
Lorsque les transactions restent à l’état préparé indéfiniment sans être résolues par un gestionnaire de transactions, elles deviennent des transactions préparées orphelines. La seule façon de résoudre ce problème est de valider ou d’annuler la transaction à l’aide des commandes `COMMIT PREPARED` ou `ROLLBACK PREPARED`, respectivement.
**Note**
Sachez qu’une sauvegarde effectuée lors d’une transaction préparée contiendra toujours cette transaction après restauration. Reportez-vous aux informations suivantes pour savoir comment localiser et clôturer de telles transactions.
La fonction `postgres_get_av_diag()` affiche le résultat suivant lorsqu’elle identifie un bloqueur qui est une transaction préparée.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Action suggérée**
Comme indiqué dans la colonne de suggestions, connectez-vous à la base de données où se trouve la transaction préparée. Sur la base de la colonne `suggested_action`, examinez attentivement s’il faut exécuter `COMMIT` ou `ROLLBACK`, et quelle est l’action appropriée.
Pour surveiller les transactions préparées en général, PostgreSQL propose une vue de catalogue appelée `pg_prepared_xacts`. Vous pouvez utiliser la requête suivante pour rechercher les transactions préparées.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Emplacement de réplication logique
L’objectif d’un emplacement de réplication est de conserver les modifications non consommées jusqu’à ce qu’elles soient répliquées sur un serveur cible. Pour plus d’informations, consultez [Réplication logique](https://www.postgresql.org/docs/current/logical-replication.html) de PostgreSQL.
Il existe deux types d’emplacement de réplication logique.
**Emplacements de réplication logique inactifs**
Lorsque la réplication est interrompue, les journaux de transactions non consommés ne peuvent pas être supprimés et l’emplacement de réplication devient inactif. Même si un emplacement de réplication logique inactif n’est pas utilisé par un abonné, il reste sur le serveur, ce qui entraîne la conservation des fichiers WAL et empêche la suppression des anciens journaux de transactions. Cela peut augmenter l’utilisation du disque et empêcher spécifiquement l’autovacuum de nettoyer les tables de catalogue internes, car le système doit empêcher le remplacement des informations LSN. Si rien n’est fait, cela peut entraîner un gonflement du catalogue, une dégradation des performances et un risque accru de vacuum de bouclage, ce qui peut entraîner une durée d’indisponibilité des transactions.
**Emplacements de réplication logique actifs mais lents**
Parfois, la suppression des tuples inactifs du catalogue est retardée en raison de la dégradation des performances de la réplication logique. Ce retard de réplication ralentit la mise à jour de `catalog_xmin` et peut entraîner un gonflement du catalogue et un vacuum de bouclage.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un emplacement de réplication logique en tant que bloqueur.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Action suggérée**
Pour résoudre ce problème, vérifiez la configuration de réplication afin de détecter tout problème lié au schéma cible ou aux données susceptibles de mettre fin au processus d’application. Voici les raisons les plus courantes de ce problème :
+ Colonnes manquantes
+ Types de données incompatibles
+ Non-correspondance des données
+ Table manquante
Si le problème est lié à des problèmes d’infrastructure :
+ Problèmes de réseau : [comment résoudre les problèmes liés à une base de données Amazon RDS dans un état réseau incompatible](https://repost.aws/knowledge-center/rds-incompatible-network).
+ La base de données ou l’instance de base de données n’est pas disponible pour les raisons suivantes :
+ L’instance de réplica n’a plus d’espace de stockage : consultez [Instances de base de données Amazon RDS à court de stockage](https://repost.aws/knowledge-center/rds-out-of-storage) pour en savoir plus sur l’ajout d’espace de stockage.
+ Paramètres incompatibles : consultez [Comment puis-je réparer une instance de base de données Amazon RDS bloquée avec le statut de paramètres incompatibles ?](https://repost.aws/knowledge-center/rds-incompatible-parameters) pour plus d’informations sur la façon dont vous pouvez résoudre le problème.
Si votre instance se trouve en dehors du réseau AWS ou sur AWS EC2, demandez à votre administrateur comment résoudre les problèmes liés à la disponibilité ou à l’infrastructure.
**Suppression de l’emplacement inactif**
**Avertissement**
Attention : avant de supprimer un emplacement de réplication, assurez-vous qu’il n’est pas en cours de réplication, qu’il est inactif et qu’il est dans un état irrécupérable. La suppression prématurée d’un emplacement peut perturber la réplication ou entraîner une perte de données.
Après avoir confirmé que l’emplacement de réplication n’est plus nécessaire, supprimez-le pour permettre à l’autovacuum de continuer. La condition `active = 'f'` garantit que seul un emplacement inactif est supprimé.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Réplicas en lecture
Lorsque le paramètre `hot_standby_feedback` est activé pour les [réplicas en lecture Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), il empêche l’autovacuum sur la base de données principale de supprimer les lignes inactives qui pourraient encore être nécessaires aux requêtes exécutées sur le réplica en lecture. Cela concerne tous les types de réplicas en lecture physiques, y compris ceux gérés avec ou sans emplacements de réplication. Ce comportement est nécessaire, car les requêtes exécutées sur le réplica de secours nécessitent que ces lignes restent disponibles sur le réplica principal pour éviter les [conflits de requêtes](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) et les annulations.
**Réplica en lecture avec emplacement de réplication physique**
Les réplicas en lecture avec des emplacements de réplication physiques améliorent considérablement la fiabilité et la stabilité de la réplication dans RDS pour PostgreSQL. Ces emplacements garantissent que la base de données principale conserve les fichiers journaux d’écriture anticipée essentiels jusqu’à ce que le réplica les traite, préservant ainsi la cohérence des données même en cas de perturbation du réseau.
À partir de RDS pour PostgreSQL version 14, tous les réplicas utilisent des emplacements de réplication. Dans les versions antérieures, seuls les réplicas entre régions utilisaient des emplacements de réplication.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un réplica en lecture avec un emplacement de réplication logique en tant que bloqueur.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Réplica en lecture avec réplication de streaming**
Amazon RDS permet de configurer des réplicas en lecture sans emplacement de réplication physique dans les anciennes versions, jusqu’à la version 13. Cette approche réduit la surcharge en permettant au système principal de recycler les fichiers WAL de manière plus agressive, ce qui est avantageux dans les environnements où l’espace disque est limité et peut tolérer des retards de réplica occasionnels. Cependant, sans emplacement, le réplica de secours doit rester synchronisé pour éviter de manquer des fichiers WAL. Amazon RDS utilise des fichiers WAL archivés pour aider le réplica à rattraper son retard, mais ce processus nécessite une surveillance attentive et peut être lent.
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un réplica en lecture de diffusion avec un emplacement de réplication logique en tant que bloqueur.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Action suggérée**
Comme recommandé dans la colonne `suggested_action`, examinez attentivement ces options pour débloquer l’autovacuum.
+ **Résilier la requête** : en suivant les instructions de la colonne de suggestions, vous pouvez vous connecter au réplica en lecture, comme indiqué dans la colonne suggested\$1action. Il est conseillé de vérifier attentivement l’option permettant de résilier la session. Si la résiliation est considérée comme sûre, vous pouvez utiliser la fonction `pg_terminate_backend()` pour résilier la session. Cette action peut être effectuée par un administrateur (tel que le compte principal RDS) ou par un utilisateur disposant du privilège pg\$1terminate\$1backend() requis.
Vous pouvez exécuter la commande SQL suivante sur le réplica en lecture pour résilier la requête qui empêche le vacuum sur la base de données principale de nettoyer les anciennes lignes. La valeur de `backend_xmin` est indiquée dans la sortie de la fonction :
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Désactiver les commentaires de veille permanente** : pensez à désactiver le paramètre `hot_standby_feedback` s’il entraîne des retards de vacuum importants.
Le paramètre `hot_standby_feedback` permet à un réplica en lecture d’informer la base de données principale de son activité de requête, empêchant ainsi la base de données principale d’effectuer une opération de vacuum sur les tables ou les lignes utilisées sur le réplica de secours. Bien que cela garantisse la stabilité des requêtes sur le réplica de secours, cela peut retarder considérablement l’opération de vacuum sur la base de données principale. La désactivation de cette fonction permet à la base de données principale d’effectuer l’opération de vacuum sans attendre que le réplica de secours rattrape le retard. Toutefois, cela peut entraîner des annulations de requêtes ou des échecs sur le réplica de secours s’il tente d’accéder à des lignes qui ont été supprimées par la base de données principale.
+ **Supprimer les réplicas en lecture s’ils ne sont pas nécessaires** : si le réplica en lecture n’est plus nécessaire, vous pouvez le supprimer. Cela supprime la surcharge de réplication associée et permet au système principal de recycler les journaux de transactions sans être freiné par le réplica.
## Tables temporaires
Les [tables temporaires](https://www.postgresql.org/docs/current/sql-createtable.html), créées à l’aide du mot-clé `TEMPORARY`, résident dans le schéma temporaire, par exemple pg\$1temp\$1xxx, et ne sont accessibles qu’à la session qui les a créées. Les tables temporaires sont supprimées à la fin de la session. Cependant, ces tables sont invisibles pour le processus autovacuum de PostgreSQL et doivent être nettoyées manuellement par la session qui les a créées. Essayer d’effectuer un vacuum sur la table temporaire d’une autre session n’a aucun effet.
Dans des circonstances exceptionnelles, une table temporaire peut exister sans qu’elle appartienne à une session active. Si la session liée à une table temporaire se termine de façon inattendue en raison d’un incident fatal, d’un problème réseau ou d’un événement similaire, il est possible que cette table ne soit pas nettoyée et qu’elle devienne ainsi une table « orpheline ». Lorsque le processus autovacuum de PostgreSQL détecte une table temporaire orpheline, il consigne le message suivant :
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une table temporaire comme un bloqueur. Pour que cette fonction affiche correctement la sortie relative aux tables temporaires, elle doit être exécutée dans la base de données dans laquelle se trouvent ces tables.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Action suggérée**
Suivez les instructions fournies dans la colonne `suggestion` de sortie pour identifier et supprimer la table temporaire qui empêche l’exécution de l’autovacuum. Utilisez la commande suivante pour supprimer la table temporaire signalée par `postgres_get_av_diag()`. Remplacez le nom de la table en fonction de la sortie fournie par la fonction `postgres_get_av_diag()`.
```
DROP TABLE my_temp_schema.my_temp_table;
```
La requête suivante peut être utilisée pour identifier les tables temporaires :
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Résolution des bloqueurs de vacuum non identifiables dans RDS pour PostgreSQL
Cette section explore d’autres raisons qui peuvent empêcher l’opération de vacuum de progresser. Ces problèmes ne sont actuellement pas directement identifiables par la fonction `postgres_get_av_diag()`.
**Topics**
+ [
## Pages non valides
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [
## Incohérence de l’index
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [
## Taux de transaction exceptionnellement élevé
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Pages non valides
Une erreur de page non valide se produit lorsque PostgreSQL détecte une incompatibilité dans le total de contrôle d’une page lors de l’accès à cette page. Le contenu est illisible, ce qui empêche l’autovacuum de geler les tuples. Cela arrête efficacement le processus de nettoyage. L’erreur suivante est écrite dans le journal de PostgreSQL :
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Détermination du type d’objet**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
À partir du message d’erreur, le chemin `base/16403/186752608` fournit les informations suivantes :
+ « base » est le nom du répertoire situé sous le répertoire de données PostgreSQL.
+ « 16403 » est l’OID de la base de données, que vous pouvez consulter dans le catalogue système `pg_database`.
+ « 186752608 » est le `relfilenode`, que vous pouvez utiliser pour rechercher le schéma et le nom de l’objet dans le catalogue système `pg_class`.
En vérifiant le résultat de la requête suivante dans la base de données concernée, vous pouvez déterminer le type d’objet. La requête suivante récupère les informations d’objet pour l’oid 186752608. Remplacez l’OID par celui correspondant à l’erreur que vous avez rencontrée.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Pour plus d’informations, consultez la documentation de PostgreSQL [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) pour connaître tous les types d’objets pris en charge, indiqués par la colonne `relkind` dans `pg_class`.
**Conseils**
La solution la plus efficace à ce problème dépend de la configuration de votre instance Amazon RDS spécifique et du type de données concerné par la page incohérente.
**Si le type d’objet est un index :**
Il est recommandé de reconstruire l’index.
+ **Utilisation de l’option `CONCURRENTLY`** : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option `CONCURRENTLY` permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande :
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Bien que l’option `CONCURRENTLY` soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible.
Pour plus d’informations, consultez la documentation de PostgreSQL sur [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html).
+ **Utilisation de l’option `INDEX_CLEANUP FALSE`** : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération `VACUUM FREEZE` manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures.
Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index.
**Si le type d’objet est une vue matérialisée :**
Si une erreur de page non valide se produit sur une vue matérialisée, connectez-vous à la base de données concernée et actualisez-la pour corriger la page non valide :
Actualisez la vue matérialisée :
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Si l’actualisation échoue, essayez de recréer la vue :
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
L’actualisation ou la recréation de la vue matérialisée permet de la restaurer sans affecter les données de la table sous-jacente.
**Pour tous les autres types d’objets :**
Pour tous les autres types d’objets, contactez l’assistance AWS.
## Incohérence de l’index
Un index dont la logique est incohérente peut empêcher l’autovacuum de progresser. Les erreurs suivantes ou des erreurs similaires sont journalisées pendant la phase de vacuum de l’index ou lorsque des instructions SQL accèdent à l’index.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Conseils**
Reconstruisez l’index ou ignorez les index en utilisant `INDEX_CLEANUP` lors d’une opération `VACUUM FREEZE` manuelle. Pour plus d’informations sur la façon de reconstruire l’index, consultez [Si le type d’objet est un index](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Utilisation de l’option CONCURRENTLY** : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option CONCURRENTLY permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande :
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Bien que l’option CONCURRENTLY soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible. Pour plus d’informations, consultez [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) dans la documentation de *PostgreSQL*.
+ **Utilisation de l’option INDEX\$1CLEANUP FALSE** : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération VACUUM FREEZE manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures.
Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index.
## Taux de transaction exceptionnellement élevé
Dans PostgreSQL, les taux de transactions élevés peuvent avoir un impact significatif sur les performances de l’autovacuum, ce qui ralentit le nettoyage des tuples inactifs et augmente le risque de bouclage des ID de transaction. Vous pouvez surveiller le taux de transaction en mesurant la différence de `max(age(datfrozenxid))` entre deux périodes, généralement par seconde. En outre, vous pouvez utiliser les métriques de compteur suivantes de RDS Performance Insights pour mesurer le taux de transaction (somme de xact\$1commit et xact\$1rollback), qui est le nombre total de transactions.
| Compteur | Type | Unité | Métrique |
| --- | --- | --- | --- |
| xact\$1commit | Transactions | Validations par seconde | db.Transactions.xact\$1commit |
| xact\$1rollback | Transactions | Restaurations par seconde | db.Transactions.xact\$1rollback |
Une augmentation rapide indique une charge de transactions élevée, qui peut surcharger l’autovacuum, provoquant un gonflement, des conflits de verrouillage et des problèmes de performances potentiels. Cela peut avoir un impact négatif sur le processus d’autovacuum de plusieurs manières :
+ **Activité liée à la table :** la table en question peut faire l’objet d’un volume élevé de transactions, ce qui peut entraîner des retards.
+ **Ressources système :** l’ensemble du système est peut-être surchargé, ce qui rend difficile pour l’autovacuum d’accéder aux ressources nécessaires pour fonctionner efficacement.
Envisagez les stratégies suivantes pour permettre à l’autovacuum de fonctionner plus efficacement et de mener à bien ses tâches dans le délai imparti :
1. Réduisez le taux de transaction si possible. Envisagez de traiter par lots ou de regrouper les transactions similaires dans la mesure du possible.
1. Ciblez les tables fréquemment mises à jour avec une opération `VACUUM FREEZE` manuelle tous les soirs, toutes les semaines ou toutes les deux semaines pendant les heures creuses.
1. Envisagez d’augmenter verticalement votre classe d’instance pour allouer davantage de ressources système afin de gérer le volume élevé de transactions et l’autovacuum.
# Résolution des problèmes de performance de vacuum dans RDS pour PostgreSQL
Cette section décrit les facteurs qui contribuent souvent au ralentissement des performances de vacuum et explique comment résoudre ces problèmes.
**Topics**
+ [
## Vacuum des index de grande taille
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [
## Trop de tables ou de bases de données pour le vacuum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [
## Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Vacuum des index de grande taille
VACUUM fonctionne selon des phases séquentielles : initialisation, analyse des tas, vacuum des index et des tas, nettoyage des index, troncature des tas et nettoyage final. Pendant l’analyse des tas, le processus élague les pages, les défragmente et les gèle. Une fois l’analyse des tas terminée, VACUUM nettoie les index, renvoie les pages vides au système d’exploitation et effectue les dernières tâches de nettoyage, telles que le vacuum de la carte de l’espace libre et la mise à jour des statistiques.
L’opération de vacuum de l’index peut nécessiter plusieurs passages lorsque la capacité `maintenance_work_mem` (ou `autovacuum_work_mem`) est insuffisante pour traiter l’index. Dans PostgreSQL 16 et versions antérieures, une limite de mémoire de 1 Go pour le stockage des ID de tuple inactifs imposait souvent plusieurs passages sur les index volumineux. PostgreSQL 17 introduit `TidStore`, qui alloue de la mémoire de manière dynamique au lieu d’utiliser un tableau à allocation unique. Cela permet de supprimer la contrainte de 1 Go, d’utiliser la mémoire de manière plus efficace et d’éviter d’avoir à analyser plusieurs fois chaque index.
Les index de grande taille peuvent toujours nécessiter plusieurs passages dans PostgreSQL 17 si la mémoire disponible ne peut pas prendre en charge l’intégralité du traitement des index en une seule fois. Généralement, les index de grande taille contiennent davantage de tuples inactifs qui nécessitent plusieurs passages.
**Détection des opérations de vacuum lentes**
La fonction `postgres_get_av_diag()` peut détecter les opérations de vacuum qui sont lentes en raison d’une mémoire insuffisante. Pour plus d’informations sur cette fonction, consultez [Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
La fonction `postgres_get_av_diag()` émet les notifications suivantes lorsque la mémoire disponible n’est pas suffisante pour terminer l’opération de vacuum de l’index en un seul passage.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**Note**
La fonction `postgres_get_av_diag()` repose sur `pg_stat_all_tables.n_dead_tup` pour l’estimation de la quantité de mémoire requise pour l’opération de vacuum de l’index.
Lorsque la fonction `postgres_get_av_diag()` identifie une opération de vacuum lente qui nécessite plusieurs analyses d’index en raison d’une capacité `autovacuum_work_mem` insuffisante, elle génère le message suivant :
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Conseils**
Vous pouvez appliquer les solutions de contournement suivantes à l’aide d’une opération `VACUUM FREEZE` manuelle pour accélérer le gel de la table.
**Augmentation de la mémoire pour l’opération de vacuum**
Comme suggéré par la fonction `postgres_get_av_diag()`, il est conseillé d’augmenter le paramètre `autovacuum_work_mem` pour faire face aux contraintes de mémoire potentielles au niveau de l’instance. Même si `autovacuum_work_mem` est un paramètre dynamique, il est important de noter que pour que le nouveau paramètre de mémoire prenne effet, le démon autovacuum doit redémarrer ses applications de travail. Pour ce faire :
1. Vérifiez que le nouveau paramètre est en place.
1. Arrêtez les processus qui exécutent une opération d’autovacuum.
Cette approche garantit que l’allocation de mémoire ajustée est appliquée aux nouvelles opérations d’autovacuum.
Pour des résultats plus immédiats, pensez à effectuer une opération `VACUUM FREEZE` manuelle avec un paramètre `maintenance_work_mem` augmenté au cours de votre session :
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Si vous utilisez Amazon RDS et que vous constatez que vous avez besoin de mémoire supplémentaire pour prendre en charge des valeurs plus élevées pour `maintenance_work_mem` ou `autovacuum_work_mem`, envisagez de passer à une classe d’instance avec plus de mémoire. Cela peut fournir les ressources nécessaires pour améliorer les opérations de vacuum manuelles et automatiques, ce qui se traduit par une amélioration des performances globales du vacuum et des bases de données.
**Désactivation d’INDEX\$1CLEANUP**
L’opération `VACUUM` manuelle de PostgreSQL 12 et versions ultérieures permet d’ignorer la phase de nettoyage de l’index, tandis que l’autovacuum d’urgence dans PostgreSQL 14 et versions ultérieures le fait automatiquement en fonction du paramètre [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE).
**Avertissement**
Ignorer le nettoyage de l’index peut entraîner un gonflement de l’index et avoir un impact négatif sur les performances des requêtes. Pour pallier ce problème, pensez à réindexer les index concernés ou à en effectuer le vacuum pendant une période de maintenance.
Pour obtenir des conseils supplémentaires sur la gestion des index de grande taille, reportez-vous à la documentation sur [Gestion de la fonction autovacuum avec de grands index](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Opérations de vacuum d’index en parallèle**
À partir de PostgreSQL 13, les index peuvent faire l’objet d’un vacuum et d’un nettoyage en parallèle par défaut avec une opération `VACUUM` manuelle. Un processus de travail de vacuum est alors assigné à chaque index. Cependant, pour que PostgreSQL puisse déterminer si une opération de vacuum peut être exécutée en parallèle, des critères spécifiques doivent être remplis :
+ Il doit y avoir au moins deux index.
+ Le paramètre `max_parallel_maintenance_workers` doit être défini sur au moins 2.
+ La taille de l’index doit dépasser la limite de `min_parallel_index_scan_size`, qui est par défaut de 512 Ko.
Vous pouvez ajuster le paramètre `max_parallel_maintenance_workers` en fonction du nombre de processeurs virtuels disponibles sur votre instance Amazon RDS et du nombre d’index sur la table afin d’optimiser le délai d’exécution de l’opération de vacuum.
Pour plus d’informations, consultez [Opérations de vacuum en parallèle dans Amazon RDS pour PostgreSQL et Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Trop de tables ou de bases de données pour le vacuum
Comme indiqué dans la documentation [The Autovacuum Daemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') de PostgreSQL, le démon autovacuum fonctionne par le biais de plusieurs processus. Cela inclut un lanceur d’autovacuum permanent chargé de démarrer les processus de travail d’autovacuum pour chaque base de données du système. Le lanceur programme ces applications de travail pour qu’elles soient lancées environ toutes les `autovacuum_naptime` secondes par base de données.
Avec « N » bases de données, une nouvelle application de travail commence environ toutes les [`autovacuum_naptime`/N secondes]. Cependant, le nombre total d’applications de travail simultanés est limité par le paramètre `autovacuum_max_workers`. Si le nombre de bases de données ou de tables qui nécessitent un vacuum dépasse cette limite, la base de données ou table suivante est traitée dès qu’une application de travail est disponible.
Lorsque de nombreuses tables ou bases de données volumineuses nécessitent un vacuum simultané, toutes les applications de travail d’autovacuum disponibles peuvent être occupées pendant une période prolongée, ce qui retarde la maintenance des autres tables et bases de données. Dans les environnements où les taux de transactions sont élevés, ce goulot d’étranglement peut rapidement s’aggraver et potentiellement entraîner des problèmes de vacuum de bouclage au sein de votre instance Amazon RDS.
Lorsque `postgres_get_av_diag()` détecte un nombre élevé de tables ou de bases de données, il fournit la recommandation suivante :
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Conseils**
**Augmentation d’autovacuum\$1max\$1workers**
Pour accélérer l’opération de vacuum, nous vous recommandons de régler le paramètre `autovacuum_max_workers` afin d’autoriser un plus grand nombre d’applications de travail d’autovacuum simultanées. Si les problèmes de performances persistent, envisagez d’augmenter verticalement votre instance Amazon RDS vers une classe comportant davantage de processeurs virtuels, ce qui peut améliorer encore les capacités de traitement parallèle.
## Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution
L’âge de la base de données (MaximumUsedTransactionIDs) dans PostgreSQL ne diminue que lorsqu’un vacuum agressif (pour empêcher tout bouclage) s’est terminé avec succès. Jusqu’à ce que ce vacuum se termine, l’âge continue d’augmenter en fonction du taux de transaction.
La fonction `postgres_get_av_diag()` génère le message `NOTICE` suivant lorsqu’elle détecte un vacuum agressif. Cependant, elle ne déclenche cette sortie qu’après que le vacuum a été actif pendant au moins deux minutes.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Pour plus d’informations sur le vacuum agressif, consultez [Lorsqu’un vacuum agressif est déjà en cours d’exécution](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Vous pouvez vérifier si un vacuum agressif est en cours à l’aide de la requête suivante :
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Vous pouvez déterminer s’il s’agit d’un vacuum agressif (pour éviter tout bouclage) en vérifiant la colonne de requête dans la sortie. L’expression « pour éviter tout bouclage » indique qu’il s’agit d’un vacuum agressif.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Supposons, par exemple, que vous disposiez d’un bloqueur à l’âge d’un milliard de transactions et d’une table nécessitant un vacuum agressif pour éviter tout bouclage au même âge de transaction. De plus, il existe un autre bloqueur à l’âge de 750 millions de transactions. Après avoir éliminé le bloqueur à l’âge d’un milliard de transactions, l’âge des transactions ne tombera pas immédiatement à 750 millions. Il restera élevé jusqu’à ce que la table nécessitant un vacuum agressif ou toute transaction dont l’âge est supérieur à 750 millions soit finalisée. Au cours de cette période, l’âge des transactions de votre cluster PostgreSQL continuera d’augmenter. Une fois le processus de vacuum terminé, l’âge des transactions tombe à 750 millions, mais recommence à augmenter jusqu’à ce que l’opération de vacuum soit terminée. Ce cycle se poursuit tant que ces conditions persistent, jusqu’à ce que l’âge des transactions atteigne finalement le niveau configuré pour votre instance Amazon RDS, spécifié par `autovacuum_freeze_max_age`.
# Explication des messages NOTICE dans RDS pour PostgreSQL
La fonction `postgres_get_av_diag()` fournit les messages NOTICE suivants :
**Lorsque l’âge n’a pas encore atteint le seuil de surveillance**
Le seuil de surveillance `postgres_get_av_diag()` pour identifier les bloqueurs est de 500 millions de transactions par défaut. Si `postgres_get_av_diag()` génère le message NOTICE suivant, l’âge de la transaction n’a pas encore atteint ce seuil.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Non connecté à la base de données dont l’ID de transaction est le plus ancien**
La fonction `postgres_get_av_diag()` fournit le résultat le plus précis lorsqu’elle est connectée à la base de données dont l’ID de transaction est le plus ancien. La base de données dont l’âge de l’ID de transaction est le plus ancien indiqué par `postgres_get_av_diag()` sera différente de « my\$1database » dans votre cas. Si vous n’êtes pas connecté à la bonne base de données, le message NOTICE suivant est généré :
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Il est important de se connecter à la base de données dont l’âge de la transaction est le plus ancien pour les raisons suivantes :
+ **Identification des bloqueurs de tables temporaires :** les métadonnées des tables temporaires étant spécifiques à chaque base de données, elles se trouvent généralement dans la base de données dans laquelle elles ont été créées. Toutefois, si une table temporaire se trouve être le principal bloqueur et qu’elle se trouve dans la base de données contenant la transaction la plus ancienne, cela peut prêter à confusion. La connexion à la base de données appropriée garantit l’identification précise du bloqueur de table temporaire.
+ **Diagnostic des vacuums lents :** les métadonnées d’index et les informations relatives au nombre de tables sont spécifiques à chaque base de données et sont nécessaires pour diagnostiquer les problèmes de lenteur du vacuum.
**La base de données dont l’âge de la transaction est le plus ancien se trouve sur une base de données rdsadmin ou template0**
Dans certains cas, les bases de données `rdsadmin` ou `template0` peuvent être identifiées comme étant celles dont l’ID de transaction est le plus ancien. Dans ce cas, `postgres_get_av_diag()` émet le message NOTICE suivant :
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Vérifiez que le bloqueur répertorié ne provient d’aucune de ces deux bases de données. Si la présence du bloqueur est signalée dans `rdsadmin` ou `template0`, contactez le support, car ces bases de données ne sont pas accessibles aux utilisateurs et nécessitent une intervention.
Il est très peu probable que la base de données `rdsadmin` ou `template0` contienne un bloqueur principal.
**Lorsqu’un vacuum agressif est déjà en cours d’exécution**
La fonction `postgres_get_av_diag()` est conçue pour signaler lorsqu’un processus de vacuum agressif est en cours d’exécution, mais elle ne déclenche cette sortie que lorsque le vacuum est actif depuis au moins 1 minute. Ce délai intentionnel contribue à réduire les risques de faux positifs. En attendant, la fonction garantit que seuls les vacuums efficaces et significatifs sont signalés, ce qui permet une surveillance plus précise et plus fiable de l’activité du vacuum.
La fonction `postgres_get_av_diag()` génère le message NOTICE suivant lorsqu’elle détecte un ou plusieurs vacuums agressifs en cours.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Comme indiqué dans le message NOTICE, continuez à surveiller les performances du vacuum. Pour plus d’informations sur le vacuum agressif, consultez [Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Lorsque l’autovacuum est désactivé**
La fonction `postgres_get_av_diag()` génère le message NOTICE suivant si l’autovacuum est désactivé sur votre instance de base de données :
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
L’autovacuum est une fonctionnalité essentielle de votre instance de base de données RDS pour PostgreSQL. Elle garantit le bon fonctionnement de la base de données. Elle supprime automatiquement les anciennes versions de lignes, récupère de l’espace de stockage et évite le gonflement des tables, ce qui contribue à garantir l’efficacité des tables et des index pour des performances optimales. En outre, elle protège contre le bouclage des ID de transaction, qui peut interrompre les transactions sur votre instance Amazon RDS. La désactivation de l’autovacuum peut entraîner une baisse à long terme des performances et de la stabilité de la base de données. Nous vous conseillons de laisser cette fonctionnalité activée en permanence. Pour plus d’informations, consultez [Présentation d’autovacuum dans les environnements RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
La désactivation de l’autovacuum n’arrête pas les vacuums agressifs. Ils se produiront toujours une fois que vos tables auront atteint le seuil `autovacuum_freeze_max_age`.
**Le nombre de transactions restantes est extrêmement faible**
La fonction `postgres_get_av_diag()` génère le message NOTICE suivant lorsqu’un vacuum de bouclage est imminent. Ce message NOTICE est émis lorsque votre instance Amazon RDS est à 100 millions de transactions avant que de nouvelles transactions ne soient potentiellement rejetées.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Une action immédiate est nécessaire pour éviter toute durée d’indisponibilité de la base de données. Vous devez surveiller de près vos opérations de vacuum et envisager de lancer manuellement une opération `VACUUM FREEZE` sur la base de données concernée afin d’éviter les échecs de transaction.
# Gestion d'un nombre élevé d'objets dans Amazon RDS pour PostgreSQL Amazon Aurora
Bien que les limites de PostgreSQL soient théoriques, le nombre d'objets extrêmement élevé dans une base de données peut avoir un impact notable sur les performances de diverses opérations. Cette documentation couvre plusieurs types d'objets courants qui, lorsqu'ils ont un nombre total élevé, peuvent avoir plusieurs impacts possibles.
Le tableau suivant fournit un résumé des types d'objets et de leurs impacts potentiels :
**Types d'objets et impacts potentiels**
| Type d'objet | Aspirateur automatique | Réplication logique | Mise à niveau de la version majeure | pg\$1dumpg/pg\$1restore | Performance générale | Redémarrage de l'instance |
| --- | --- | --- | --- | --- | --- | --- |
| [Relations](#PostgreSQL.HighObjectCount.Relations) | x | | h/24, j/7 | h/24, j/7 | x | |
| [Tables temporaires](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tables non enregistrées](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partitions](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Fichiers temporaires](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Séquences](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Objets de grande taille](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relations
Il n'existe pas de limite stricte spécifique concernant le nombre de tables dans une base de données PostgreSQL. La limite théorique est extrêmement élevée, mais d'autres limites pratiques doivent être prises en compte lors de la conception de la base de données.
**Conséquence : Autovacuum prend du retard**
Autovacuum peut avoir du mal à faire face à la croissance des numéros de transaction ou à la surcharge de travail en raison du manque de personnel par rapport à la quantité de travail.
**Action recommandée :** Plusieurs facteurs permettent de régler l'autovacuum afin de s'adapter correctement à un nombre donné de tables et à une charge de travail donnée. Consultez [Meilleures pratiques d'utilisation de l'aspirateur automatique PostgreSQL Meilleures pratiques d'utilisation de l'aspirateur automatique PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) d'aspirateur automatique appropriés. Utilisez l'[utilitaire ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) pour surveiller les problèmes liés à la croissance des identifiants de transaction.
**Conséquence : mise à niveau de la version majeure /pg\$1dump et restauration**
Amazon RDS utilise l'option « --link » lors de l'exécution de pg\$1upgrade pour éviter d'avoir à faire des copies des fichiers de données. Les métadonnées du schéma doivent toujours être restaurées dans la nouvelle version de la base de données. Même avec parallel pg\$1restore, s'il existe un nombre important de relations, cela augmentera le temps d'arrêt.
**Conséquence : dégradation générale des performances**
Dégradation générale des performances due à la taille du catalogue. Chaque table et ses colonnes associées s'ajouteront `pg_class` aux `pg_attribute` `pg_depend` tables fréquemment utilisées dans les opérations de base de données normales. Aucun événement d'attente spécifique ne sera visible, mais l'efficacité de la mémoire tampon partagée sera affectée.
**Action recommandée :** Vérifiez régulièrement la saturation des tables pour ces tables spécifiques et effectuez occasionnellement une opération `VACUUM FULL` sur ces tables spécifiques. Sachez que les tables `VACUUM FULL` du catalogue nécessitent un `ACCESS EXCLUSIVE` verrou, ce qui signifie qu'aucune autre requête ne pourra y accéder tant que l'opération ne sera pas terminée.
**Conséquence : épuisement du descripteur de fichier**
Erreur : « Descripteurs de fichiers insuffisants : trop de fichiers ouverts dans le système ; relâchez-les et réessayez ». Le `max_files_per_process` paramètre PostgreSQL détermine le nombre de fichiers que chaque processus peut ouvrir. Si un grand nombre de connexions rejoignent un grand nombre de tables, il est possible d'atteindre cette limite.
**Action recommandée :**
+ La réduction de la valeur du paramètre `max_files_per_process` peut contribuer à atténuer cette erreur. Chaque processus et sous-processus (par exemple, une requête parallèle) peut ouvrir ce nombre de fichiers, et si les requêtes joignent plusieurs tables, cette limite peut être dépassée.
+ Réduisez le nombre total de connexions et utilisez un pool de connexions tel qu'[Amazon RDS Proxy, Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) ou d'autres solutions telles que. PgBouncer Pour en savoir plus, consultez le [PgBouncer site Web](https://www.pgbouncer.org/).
**Impact : épuisement des inodes**
Erreur : « Il ne reste plus d'espace sur l'appareil ». Si cela se produit alors qu'il y a suffisamment d'espace libre de stockage, cela est dû au manque d'inodes. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) fournit une visibilité sur les inodes utilisés et sur le nombre maximum d'inodes disponibles pour votre hôte.
**Seuil approximatif :** [millions](#PostgreSQL.HighObjectCount.Note)
## Tables temporaires
L'utilisation de tables temporaires est utile pour les données de test ou les résultats intermédiaires et constitue un modèle courant observé dans de nombreux moteurs de base de données. Les implications d'une utilisation intensive dans PostgreSQL doivent être comprises pour éviter certains écueils. Chaque table temporaire créée et supprimée ajoute des lignes aux tables du catalogue du système, ce qui, lorsqu'elles deviennent trop volumineuses, entraîne des problèmes de performances généraux.
**Conséquence : Autovacuum prend du retard**
Les tables temporaires ne sont pas aspirées par autovacuum, mais elles conserveront les transactions IDs pendant leur existence et peuvent être enveloppées si elles ne sont pas retirées.
**Action recommandée :** Les tables temporaires seront conservées pendant toute la durée de la session qui les a créées ou peuvent être supprimées manuellement. Une bonne pratique consistant à éviter les transactions de longue durée avec des tables temporaires empêchera ces tables de contribuer à la croissance maximale des identifiants de transaction utilisés.
**Conséquence : dégradation générale des performances**
Dégradation générale des performances due à la taille du catalogue. Lorsque les sessions créent et suppriment continuellement des tables temporaires, elles s'ajoutent à celles `pg_attribute` qui sont fréquemment utilisées dans le cadre des opérations normales de base de données. `pg_class` `pg_depend` Aucun événement d'attente spécifique ne sera visible, mais l'efficacité de la mémoire tampon partagée sera affectée.
**Action recommandée :**
+ Vérifiez régulièrement l'excès de volume des tables pour ces tables spécifiques et effectuez de temps en temps une `VACUUM FULL` sur ces tables spécifiques. Sachez que les tables `VACUUM FULL` du catalogue nécessitent un `ACCESS EXCLUSIVE` verrou, ce qui signifie qu'aucune autre requête ne pourra y accéder tant que l'opération ne sera pas terminée.
+ Si les tables temporaires sont très utilisées, il est vivement recommandé d'utiliser l'une `VACUUM FULL` de ces tables de catalogue spécifiques avant une mise à niveau majeure de version afin de réduire les temps d'arrêt.
**Bonnes pratiques générales :**
+ Réduisez l'utilisation de tables temporaires en utilisant des expressions de table communes pour produire des résultats intermédiaires. Cela peut parfois compliquer les requêtes nécessaires, mais éliminera les impacts énumérés ci-dessus.
+ Réutilisez les tables temporaires en utilisant la `TRUNCATE` commande pour effacer le contenu au lieu de suivre des drop/create étapes. Cela éliminera également le problème de croissance des identifiants de transaction causé par les tables temporaires.
**Seuil approximatif :** [dizaines de milliers](#PostgreSQL.HighObjectCount.Note)
## Tables non enregistrées
Les tables non enregistrées peuvent offrir des gains de performance car elles ne génèrent aucune information WAL. Ils doivent être utilisés avec précaution car ils n'offrent aucune durabilité lors de la restauration d'une base de données suite à un crash, car ils seront tronqués. Il s'agit d'une opération coûteuse dans PostgreSQL car chaque table délogée est tronquée en série. Bien que cette opération soit rapide pour un petit nombre de tables non enregistrées, lorsqu'elles se comptent par milliers, elle peut commencer à retarder considérablement le démarrage.
**Conséquence : réplication logique**
Les tables non enregistrées ne sont généralement pas incluses dans la réplication logique, y compris les déploiements [bleu/vert Les déploiements](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) .
**Conséquence : temps d'arrêt prolongé pendant la restauration**
Quel que soit l'état d'une base de données impliquant une restauration après incident, tel que le redémarrage multi-AZ avec basculement, la point-in-time restauration Amazon RDS et la mise à niveau de la version majeure d'Amazon RDS, l'opération sérialisée de troncation des tables non enregistrées se produit. Cela peut entraîner des temps d'arrêt bien plus élevés que prévu.
**Action recommandée :**
+ Limitez l'utilisation de tables non enregistrées uniquement aux données susceptibles d'être perdues lors des opérations de restauration après incident de base de données.
+ Réduisez l'utilisation de tables non enregistrées, car le comportement actuel de troncature en série peut entraîner un temps considérable de démarrage d'une base de données.
**Bonnes pratiques générales :**
+ Les tables non enregistrées ne sont pas protégées contre les pannes. Le lancement d'une point-in-time restauration, qui implique une restauration après incident, prend beaucoup de temps dans PostgreSQL car il s'agit d'un processus en série qui tronque chaque table.
**Seuil approximatif :** en [milliers](#PostgreSQL.HighObjectCount.Note)
## Partitions
Le partitionnement peut améliorer les performances des requêtes et fournir une organisation logique des données. Dans les scénarios idéaux, le partitionnement est organisé de telle sorte que l'élagage des partitions puisse être utilisé lors de la planification et de l'exécution des requêtes. L'utilisation d'un trop grand nombre de partitions peut avoir un impact négatif sur les performances des requêtes et la maintenance de la base de données. Le choix du mode de partitionnement d'une table doit être fait avec soin, car les performances de planification et d'exécution des requêtes peuvent être affectées négativement par une mauvaise conception. Consultez la documentation de [PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) pour plus de détails sur le partitionnement.
**Conséquence : dégradation générale des performances**
Parfois, le temps de planification augmente et il devient plus difficile d'expliquer les plans pour vos requêtes, ce qui rend difficile l'identification des opportunités de réglage. Pour les versions de PostgreSQL antérieures à 18, de nombreuses partitions présentant une charge de travail élevée peuvent entraîner des temps d'attente. `LWLock:LockManager`
**Action recommandée :** déterminez un nombre minimum de partitions qui vous permettront d'organiser vos données tout en garantissant une exécution performante des requêtes.
**Impact : complexité de la maintenance**
Un nombre très élevé de partitions entraînera des difficultés de maintenance, telles que la pré-création et la suppression. Autovacuum traitera les cloisons comme des relations normales et devra effectuer un nettoyage régulier, ce qui nécessitera un nombre suffisant de travailleurs pour effectuer la tâche.
**Action recommandée :**
+ Assurez-vous de précréer des partitions afin que la charge de travail ne soit pas bloquée lorsqu'une nouvelle partition est nécessaire (par exemple, des partitions mensuelles) et que les anciennes partitions sont supprimées.
+ Assurez-vous de disposer d'un nombre suffisant d'aspirateurs automatiques pour effectuer l'entretien normal de nettoyage de toutes les cloisons.
**Seuil approximatif :** [centaines](#PostgreSQL.HighObjectCount.Note)
## Fichiers temporaires
Contrairement aux tables temporaires mentionnées ci-dessus, les fichiers temporaires sont créés par PostgreSQL lorsqu'une requête complexe peut effectuer plusieurs opérations de tri ou de hachage en même temps, chaque opération utilisant la mémoire d'instance pour stocker les résultats jusqu'à la valeur spécifiée dans le paramètre. `work_mem` Lorsque la mémoire de l’instance n’est pas suffisante, des fichiers temporaires sont créés pour stocker les résultats. Voir [Gestion des fichiers temporaires](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) pour plus de détails sur les fichiers temporaires. Si votre charge de travail génère un grand nombre de ces fichiers, cela peut avoir plusieurs conséquences.
**Conséquence : épuisement du descripteur de fichier**
Erreur : « Descripteurs de fichiers insuffisants : trop de fichiers ouverts dans le système ; relâchez-les et réessayez ». Le `max_files_per_process` paramètre PostgreSQL détermine le nombre de fichiers que chaque processus peut ouvrir. Si un grand nombre de connexions rejoignent un grand nombre de tables, il est possible d'atteindre cette limite.
**Action recommandée :**
+ La réduction de la valeur du paramètre `max_files_per_process` peut contribuer à atténuer cette erreur. Chaque processus et sous-processus (par exemple, une requête parallèle) peut ouvrir ce nombre de fichiers, et si les requêtes joignent plusieurs tables, cette limite peut être dépassée.
+ Réduisez le nombre total de connexions et utilisez un pool de connexions tel qu'[Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) ou d'autres solutions telles que. PgBouncer Pour en savoir plus, consultez le [PgBouncer site Web](https://www.pgbouncer.org/).
**Impact : épuisement des inodes**
Erreur : « Il ne reste plus d'espace sur l'appareil ». Si cela se produit alors qu'il y a suffisamment d'espace libre de stockage, cela est dû au manque d'inodes. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) fournit une visibilité sur les inodes utilisés et sur le nombre maximum d'inodes disponibles pour votre hôte.
**Bonnes pratiques générales :**
+ Surveillez l'utilisation de vos fichiers temporaires avec [Performance Insights ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
+ Réglez les requêtes qui génèrent des fichiers temporaires importants pour voir s'il est possible de réduire le nombre total de fichiers temporaires.
**Seuil approximatif :** en [milliers](#PostgreSQL.HighObjectCount.Note)
## Séquences
Les séquences sont l'objet sous-jacent utilisé pour l'auto-incrémentation des colonnes dans PostgreSQL. Elles fournissent l'unicité et une clé pour les données. Ils peuvent être utilisés sur des tables individuelles sans aucune conséquence lors des opérations normales, à l'exception de la réplication logique.
Dans PostgreSQL, la réplication logique ne réplique actuellement la valeur actuelle d'une séquence vers aucun abonné. Pour en savoir plus, consultez la [page Restrictions de la documentation de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Conséquence : délai de transition prolongé**
Si vous envisagez d'utiliser [les Blue/Green déploiements d'Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) pour tout type de modification ou de mise à niveau de configuration, il est important de comprendre l'impact d'un grand nombre de séquences sur le passage au numérique. L'une des dernières phases d'une commutation synchronisera la valeur actuelle des séquences, et s'il y en a plusieurs milliers, cela augmentera le temps global de commutation.
**Action recommandée :** Si la charge de travail de votre base de données autorisait l'utilisation d'un UUID partagé au lieu d'une sequence-per-table approche, cela réduirait l'étape de synchronisation lors d'un basculement.
**Seuil approximatif :** en [milliers](#PostgreSQL.HighObjectCount.Note)
## Objets volumineux
Les objets de grande taille sont stockés dans une seule table système nommée pg\$1largeobject. Chaque objet de grande taille possède également une entrée dans la table système pg\$1largeobject\$1metadata. Ces objets sont créés, modifiés et nettoyés de manière très différente des relations standard. Les objets volumineux ne sont pas manipulés par autovacuum et doivent être nettoyés périodiquement via un processus distinct appelé vacuumlo. Voir gestion d'objets volumineux avec le module lo pour des exemples de gestion d'objets de grande taille.
**Conséquence : réplication logique**
Les objets volumineux ne sont actuellement pas répliqués dans PostgreSQL lors de la réplication logique. Pour en savoir plus, consultez la [page Restrictions de la documentation de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). Dans une configuration [bleu/vert](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) , cela signifie que les objets volumineux de l'environnement bleu ne sont pas répliqués dans l'environnement vert.
**Conséquence : mise à niveau de la version majeure**
Une mise à niveau peut manquer de mémoire et échouer s'il existe des millions d'objets volumineux et que l'instance ne peut pas les gérer pendant une mise à niveau. Le processus de mise à niveau de la version majeure de PostgreSQL comprend deux grandes phases : le vidage du schéma via pg\$1dump et sa restauration via pg\$1restore. Si votre base de données contient des millions d'objets volumineux, vous devez vous assurer que votre instance dispose de suffisamment de mémoire pour gérer les fichiers pg\$1dump et pg\$1restore lors d'une mise à niveau et pour les adapter à un type d'instance plus important.
**Bonnes pratiques générales :**
+ Utilisez régulièrement l'utilitaire vacuumlo pour retirer tous les gros objets orphelins que vous pourriez avoir.
+ Envisagez d'utiliser le type de données BYTEA pour stocker vos objets volumineux dans la base de données.
**Seuil approximatif :** [millions](#PostgreSQL.HighObjectCount.Note)
## Seuils approximatifs
Les seuils approximatifs mentionnés dans cette rubrique ne sont utilisés que pour fournir une estimation de la mesure dans laquelle une ressource donnée peut évoluer. Ils représentent la plage générale dans laquelle les impacts décrits sont les plus probables, mais le comportement réel dépend de votre charge de travail, de la taille de l'instance et de la configuration spécifiques. Bien qu'il soit possible de dépasser ces estimations, le soin et l'entretien doivent être respectés afin d'éviter les impacts énumérés.
#
TOAST (The Oversized-Attribute Storage Technique) est une fonctionnalité de PostgreSQL conçue pour gérer de grandes valeurs de données dépassant la taille de bloc de base de données habituelle de 8 Ko. PostgreSQL n'autorise pas les lignes physiques à s'étendre sur plusieurs blocs. La taille du bloc agit comme une limite supérieure de la taille des lignes. TOAST surmonte cette restriction en divisant les grandes valeurs de champs en plus petits morceaux. Il les stocke séparément dans une table TOAST dédiée liée à la table principale. Pour plus d'informations, consultez le [mécanisme de stockage TOAST de PostgreSQL](https://www.postgresql.org/docs/current/storage-toast.html) et la documentation d'implémentation.
**Topics**
+ [
## Comprendre les opérations de TOAST
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [
## Identifier les défis en matière de performance
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [
## Recommandations
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [
## Contrôle
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Comprendre les opérations de TOAST
TOAST effectue la compression et stocke de grandes valeurs de champ hors ligne. TOAST attribue un OID (identifiant d'objet) unique à chaque bloc de données surdimensionné stocké dans la table TOAST. La table principale stocke l'ID de valeur TOAST et l'ID de relation sur la page pour référencer la ligne correspondante dans la table TOAST. Cela permet à PostgreSQL de localiser et de gérer efficacement ces fragments TOAST. Cependant, au fur et à mesure que la table TOAST s'allonge, le système risque d'épuiser le stock disponible OIDs, ce qui entraîne à la fois une dégradation des performances et des temps d'arrêt potentiels dus à l'épuisement de l'OID.
### Identifiants d'objets dans TOAST
Un identifiant d'objet (OID) est un identifiant unique à l'échelle du système utilisé par PostgreSQL pour référencer des objets de base de données tels que des tables, des index et des fonctions. Ces identifiants jouent un rôle essentiel dans les opérations internes de PostgreSQL, car ils permettent à la base de données de localiser et de gérer efficacement les objets.
Pour les tables contenant des ensembles de données éligibles au toasting, PostgreSQL OIDs attribue une identification unique à chaque bloc de données surdimensionné stocké dans la table TOAST associée. Le système associe chaque fragment à un`chunk_id`, ce qui permet à PostgreSQL d'organiser et de localiser efficacement ces fragments dans la table TOAST.
## Identifier les défis en matière de performance
La gestion des OID de PostgreSQL repose sur un compteur global de 32 bits, de sorte qu'il fonctionne après avoir généré 4 milliards de valeurs uniques. Bien que le cluster de base de données partage ce compteur, l'allocation d'OID implique deux étapes lors des opérations TOAST :
+ **Compteur global pour l'allocation** : le compteur global attribue un nouvel OID à l'ensemble du cluster.
+ **Recherche locale de conflits** — La table TOAST garantit que le nouvel OID n'entre pas en conflit avec l'OID OIDs déjà utilisé dans cette table spécifique.
Une dégradation des performances peut se produire lorsque :
+ La table TOAST présente une fragmentation élevée ou une utilisation dense des OID, ce qui entraîne des retards dans l'attribution de l'OID.
+ Le système alloue et réutilise fréquemment des données OIDs dans des environnements présentant un taux de perte de données élevé ou de larges tables utilisant largement TOAST.
Pour plus d'informations, consultez la documentation relative aux [limites de taille des tables TOAST de PostgreSQL et](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit) à l'allocation d'OID :
Un compteur global génère des valeurs OIDs et les englobe tous les 4 milliards, de sorte que le système génère à nouveau de temps en temps une valeur déjà utilisée. PostgreSQL le détecte et réessaie avec l'OID suivant. Un INSERT lent peut se produire s'il y a une très longue série de valeurs OID utilisées sans interruption dans la table TOAST. Ces difficultés s'accentuent à mesure que l'espace OID se remplit, ce qui ralentit les insertions et les mises à jour.
### Identifier le problème
+ `INSERT`Les instructions simples prennent beaucoup plus de temps que d'habitude de manière incohérente et aléatoire.
+ Les retards se produisent uniquement pour `INSERT` les `UPDATE` déclarations impliquant des opérations TOAST.
+ Les entrées de journal suivantes apparaissent dans les journaux PostgreSQL lorsque le système peine à les trouver dans les tables TOAST OIDs :
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights indique un nombre élevé de sessions actives (AAS) moyennes associées à des événements `LWLock:buffer_io` et à des événements `LWLock:OidGenLock` d'attente.
Vous pouvez exécuter la requête SQL suivante pour identifier les transactions INSERT de longue durée associées à des événements d'attente :
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Exemples de résultats de requête affichant des opérations INSERT avec des temps d'attente prolongés :
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Isoler le problème
+ **Test small insert** — Insérez un enregistrement inférieur au `toast_tuple_target` seuil. N'oubliez pas que la compression est appliquée avant le stockage de TOAST. Si cela fonctionne sans problèmes de performances, le problème est lié aux opérations TOAST.
+ **Tester une nouvelle table** — Créez une nouvelle table avec la même structure et insérez un enregistrement supérieur à`toast_tuple_target`. Si cela fonctionne sans problème, le problème est localisé dans l'allocation OID de la table d'origine.
## Recommandations
Les approches suivantes peuvent aider à résoudre les problèmes de contention des OID TOAST.
+ **Nettoyage et archivage des données** : passez en revue et supprimez toutes les données obsolètes ou inutiles afin de OIDs les libérer pour une utilisation future, ou archivez-les. Prenez en compte les restrictions suivantes :
+ Évolutivité limitée, car le nettoyage futur ne sera peut-être pas toujours possible.
+ Possibilité d'une opération VACUUM de longue durée pour éliminer les tuples morts qui en résultent.
+ **Écrire dans une nouvelle table** : créez une nouvelle table pour les futures insertions et utilisez une `UNION ALL` vue pour combiner les anciennes et les nouvelles données pour les requêtes. Cette vue présente les données combinées des anciennes et des nouvelles tables, ce qui permet aux requêtes d'y accéder sous la forme d'une seule table. Prenez en compte les restrictions suivantes :
+ Les mises à jour de l'ancienne table risquent tout de même d'entraîner l'épuisement de l'OID.
+ **Partition ou partition** : partitionnez les données de la table ou de la partition pour améliorer l'évolutivité et les performances. Prenez en compte les restrictions suivantes :
+ Complexité accrue de la logique des requêtes et de la maintenance, nécessité potentielle de modifier les applications pour gérer correctement les données partitionnées.
## Contrôle
### Utilisation des tables du système
Vous pouvez utiliser les tables système de PostgreSQL pour surveiller l'augmentation de l'utilisation des OID.
**Avertissement**
Selon le nombre de personnes figurant OIDs dans le tableau TOAST, le processus peut prendre un certain temps. Nous vous recommandons de planifier la surveillance en dehors des heures de bureau afin de minimiser l'impact.
Le bloc anonyme suivant compte le nombre de caractères distincts OIDs utilisés dans chaque table TOAST et affiche les informations de la table parent :
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Exemple de sortie affichant les statistiques d'utilisation des OID par table TOAST :
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
Le bloc anonyme suivant récupère l'OID maximal attribué pour chaque table TOAST non vide :
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Exemple de sortie affichant la partie maximale IDs pour les tables TOAST :
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Utilisation de l'Analyse des performances
Les événements `LWLock:buffer_io` d'attente `LWLock:OidGenLock` apparaissent dans Performance Insights lors d'opérations nécessitant l'attribution de nouveaux identifiants d'objet ()OIDs. Les sessions actives à moyenne élevée (AAS) associées à ces événements indiquent généralement des conflits lors de l'attribution des OID et de la gestion des ressources. Cela est particulièrement courant dans les environnements caractérisés par une perte de données élevée, une utilisation importante de données ou une création d'objets fréquente.
#### LWLock:buffer\$1io
`LWLock:buffer_io`est un événement d'attente qui se produit lorsqu'une session PostgreSQL attend la fin I/O des opérations sur une mémoire tampon partagée. Cela se produit généralement lorsque la base de données lit les données du disque dans la mémoire ou écrit des pages modifiées de la mémoire sur le disque. L'événement `BufferIO` d'attente garantit la cohérence en empêchant plusieurs processus d'accéder à la même mémoire tampon ou de la modifier pendant que les I/O opérations sont en cours. La fréquence élevée de cet événement d'attente peut indiquer un engorgement du disque ou une I/O activité excessive de la charge de travail de la base de données.
Pendant les opérations TOAST :
+ PostgreSQL OIDs alloue des fonds aux objets volumineux et garantit leur unicité en analysant l'index de la table TOAST.
+ Les grands index TOAST peuvent nécessiter l'accès à plusieurs pages pour vérifier l'unicité de l'OID. Cela entraîne une augmentation des E/S sur le disque, en particulier lorsque le pool de mémoire tampon ne peut pas mettre en cache toutes les pages requises.
La taille de l'index influe directement sur le nombre de pages tampon auxquelles il est nécessaire d'accéder au cours de ces opérations. Même si l'indice n'est pas gonflé, sa taille même peut augmenter les E/S de la mémoire tampon, en particulier dans les environnements à forte concurrence ou à taux de désabonnement élevé. Pour plus d'informations, consultez : Guide de résolution des problèmes liés aux [événements d'LWLockattente](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html) BufferIO.
#### LWLock:OidGenLock
`OidGenLock`est un événement d'attente qui se produit lorsqu'une session PostgreSQL attend d'allouer un nouvel identifiant d'objet (OID). Ce verrou garantit qu' OIDs ils sont générés de manière séquentielle et sûre, en ne permettant de générer qu'un seul processus OIDs à la fois.
Pendant les opérations TOAST :
+ **Allocation d'OID pour les segments dans les tables TOAST** : PostgreSQL les OIDs affecte aux segments des tables TOAST lors de la gestion d'enregistrements de données volumineux. Chaque OID doit être unique pour éviter les conflits dans le catalogue système.
+ **Haute simultanéité** : l'accès au générateur d'OID étant séquentiel, des conflits peuvent survenir lorsque plusieurs sessions créent simultanément des objets qui en ont besoin OIDs. `OidGenLock` Cela augmente la probabilité que les sessions attendent la fin de l'allocation des OID.
+ **Dépendance à l'égard de l'accès au catalogue du système** : l'allocation OIDs nécessite des mises à jour des tables de catalogue système partagées, telles que `pg_class` et`pg_type`. Si ces tables sont soumises à une activité intense (en raison de fréquentes opérations DDL), cela peut augmenter le nombre de conflits de verrouillage pour. `OidGenLock`
+ **Demande d'allocation d'OID élevée** — Les charges de travail lourdes de TOAST associées à des enregistrements de données volumineux nécessitent une allocation d'OID constante, ce qui augmente les contentions.
Facteurs supplémentaires qui augmentent la contention des OID :
+ **Création fréquente d'objets** : les charges de travail qui créent et suppriment fréquemment des objets, tels que des tables temporaires, amplifient la contention sur le compteur d'OID global.
+ **Verrouillage global du compteur** : le compteur OID global est accessible en série pour garantir l'unicité, créant ainsi un point de conflit unique dans les environnements à forte simultanéité.
## Utilisation de mécanismes de journalisation pris en charge par RDS pour PostgreSQL
Il existe plusieurs paramètres, extensions et autres éléments configurables que vous pouvez définir pour journaliser les activités qui se produisent sur votre instance de base de données PostgreSQL. Cela inclut les éléments suivants :
+ Le paramètre`log_statement` peut être utilisé pour consigner l'activité utilisateur dans votre base de données PostgreSQL. Pour en savoir plus sur la journalisation RDS pour PostgreSQL et sur la façon de surveiller les journaux, consultez [Fichiers journaux de base de données RDS pour PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
+ Le paramètre `rds.force_admin_logging_level` journalise les actions effectuées par l'utilisateur interne Amazon RDS (rdsadmin) dans les bases de données sur l'instance de base de données. Il écrit la sortie dans le journal d'erreurs PostgreSQL. Les valeurs autorisées sont `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, journal,`fatal` et `panic`. La valeur par défaut est `disabled`.
+ Le paramètre `rds.force_autovacuum_logging_level` peut être configuré pour capturer diverses opérations d'autovacuum dans le journal des erreurs PostgreSQL. Pour de plus amples informations, veuillez consulter [Enregistrement des activités d'autovacuum et de vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ L'extension PostgreSQL Audit (pgAudit) peut être installée et configurée pour capturer des activités au niveau de la session ou au niveau de l'objet. Pour de plus amples informations, veuillez consulter [Utilisation de pgAudit pour journaliser l'activité de la base de données](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ L'extension `log_fdw` vous permet d'accéder au journal du moteur de base de données à l'aide de SQL. Pour de plus amples informations, veuillez consulter [Utilisation de l'extension log\$1fdw pour accéder au journal de base de données à l'aide de SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ La bibliothèque `pg_stat_statements` est spécifiée par défaut pour le paramètre `shared_preload_libraries` dans RDS pour PostgreSQL 10 et versions ultérieures. C'est cette bibliothèque que vous pouvez utiliser pour analyser les requêtes en cours d'exécution. Assurez-vous que `pg_stat_statements` est défini dans votre groupe de paramètres de base de données. Pour plus d’informations sur la surveillance de votre instance de base de données RDS pour PostgreSQL à l’aide des informations fournies par cette bibliothèque, consultez [Statistiques SQL pour RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ Le paramètre `log_hostname` capture dans le journal le nom d'hôte de chaque connexion client. Pour RDS pour PostgreSQL versions 12 et ultérieures, ce paramètre est défini sur `off` par défaut. Si vous l'activez, veillez à surveiller les temps de connexion des sessions. Lorsqu'il est activé, le service utilise la demande de recherche inversée DNS pour obtenir le nom d'hôte du client qui établit la connexion et pour l'ajouter au journal PostgreSQL. Cela a un impact notable au cours de la connexion à la session. Nous vous recommandons d'activer ce paramètre à des fins de dépannage uniquement.
D'une manière générale, le but de la journalisation est de permettre au DBA de surveiller, d'ajuster les performances et de résoudre les problèmes. La plupart des journaux sont chargés automatiquement sur Amazon CloudWatch ou Performance Insights. Ici, ils sont triés et regroupés pour fournir des métriques complètes pour votre instance de base de données. Pour en savoir plus sur la surveillance et les métriques d’Amazon RDS, consultez [Surveillance des métriques dans une instance Amazon RDS](CHAP_Monitoring.md).
# Gestion des fichiers temporaires avec PostgreSQL
Dans PostgreSQL, une requête complexe peut exécuter simultanément plusieurs opérations de tri ou de hachage, chacune utilisant la mémoire de l’instance pour stocker les résultats jusqu’à la valeur spécifiée par le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Lorsque la mémoire de l’instance n’est pas suffisante, des fichiers temporaires sont créés pour stocker les résultats. Ils sont écrits sur le disque pour terminer l’exécution de la requête. Par la suite, ces fichiers sont automatiquement supprimés une fois la requête terminée. Dans RDS pour PostgreSQL, ces fichiers sont stockés dans Amazon EBS sur le volume de données. Pour plus d’informations, consultez [Stockage d’instance de base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Vous pouvez surveiller la `FreeStorageSpace` métrique publiée dans CloudWatch pour vous assurer que votre instance de base de données dispose de suffisamment d'espace de stockage disponible. Pour plus d’informations, consultez [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).
Nous recommandons d’utiliser des instances Lectures optimisées pour Amazon RDS pour les charges de travail impliquant plusieurs requêtes simultanées qui augmentent l’utilisation de fichiers temporaires. Ces d'instances utilisent un stockage local au niveau des blocs basé sur un disque SSD (Non-Volatile Memory Express) pour placer les fichiers temporaires. NVMe Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour RDS pour PostgreSQL avec Lectures optimisées pour Amazon RDS](USER_PostgreSQL.optimizedreads.md).
Vous pouvez utiliser les paramètres et fonctions suivants pour gérer les fichiers temporaires dans votre instance.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** : ce paramètre annule toute requête dépassant la taille des fichiers temp\$1files en Ko. Cette limite empêche toute requête de s’exécuter indéfiniment et de consommer de l’espace disque avec des fichiers temporaires. Vous pouvez estimer la valeur à l’aide des résultats du paramètre `log_temp_files`. Nous vous recommandons d’examiner le comportement de la charge de travail et de définir la limite en fonction de l’estimation. L’exemple suivant présente la manière dont une requête est annulée lorsqu’elle dépasse la limite.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** : ce paramètre envoie des messages au fichier postgresql.log lorsque les fichiers temporaires d’une session sont supprimés. Ce paramètre produit des journaux lorsqu’une requête est terminée avec succès. Par conséquent, cela peut ne pas aider à résoudre les requêtes actives et de longue durée.
L’exemple suivant montre que lorsque la requête aboutit, les entrées sont journalisées dans le fichier postgresql.log pendant que les fichiers temporaires sont nettoyés.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** : cette fonction disponible auprès de RDS pour PostgreSQL versions 13 et ultérieures offre une visibilité sur l’utilisation actuelle des fichiers temporaires. La requête terminée n’apparaît pas dans les résultats de la fonction. Dans l’exemple suivant, vous pouvez visualiser les résultats de cette fonction.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
Le nom du fichier inclut l’ID de traitement (PID) de la session qui a généré le fichier temporaire. Une requête plus avancée, comme dans l’exemple suivant, effectue la somme des fichiers temporaires pour chaque PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** : si vous activez le paramètre pg\$1stat\$1statements, vous pouvez consulter l’utilisation moyenne des fichiers temporaires par appel. Vous pouvez identifier le query\$1id de la requête et l’utiliser pour examiner l’utilisation des fichiers temporaires, comme indiqué dans l’exemple suivant.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** : dans le tableau de bord Performance Insights, vous pouvez consulter l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. Vous pouvez ensuite voir la moyenne de ces deux métriques et voir comment elles correspondent à la charge de travail des requêtes. La vue de Performance Insights n’affiche pas spécifiquement les requêtes qui génèrent les fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête indiquée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes.
Pour plus d’informations sur l’analyse des métriques et des requêtes à l’aide de Performance Insights, consultez [Analyse des métriques à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.UsingDashboard.md).
Pour consulter un exemple d’utilisation des fichiers temporaires avec Performance Insights, consultez [Affichage de l’utilisation des fichiers temporaires avec Performance Insights](PostgreSQL.ManagingTempFiles.Example.md)
# Affichage de l’utilisation des fichiers temporaires avec Performance Insights
Vous pouvez consulter utiliser Performance Insights pour afficher l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. La vue indiquée dans Performance Insights ne montre pas les requêtes spécifiques qui génèrent des fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête affichée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes.
1. Dans le tableau de bord de Performance Insights, choisissez **Gérer les métriques**.
1. Choisissez **Métriques de base de données** et sélectionnez les métriques **temp\$1bytes** et **temp\$1files** comme indiqué dans l’image suivante.
![\[Métriques affichées dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Dans l’onglet **SQL maximum**, cliquez sur l’icône **Préférences**.
1. Dans la fenêtre **Préférences**, activez les statistiques suivantes pour qu’elles apparaissent dans l’onglet **SQL maximum** et choisissez **Continuer**.
+ Nombre d’écritures temporaires/seconde
+ Nombre de lectures temporaires/seconde
+ Écritures/appels en bloc temporaires
+ Lectures/appels en bloc temporaires
1. Le fichier temporaire est décomposé lorsqu’il est associé à la requête affichée pour `pg_ls_tmpdir`, comme le montre l’exemple suivant.
![\[Requête qui affiche l’utilisation du fichier temporaire.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Les événements `IO:BufFileRead` et `IO:BufFileWrite` se produisent lorsque les requêtes les plus importantes de votre charge de travail créent souvent des fichiers temporaires. Vous pouvez utiliser l’analyse des performances pour identifier les requêtes les plus importantes en attente sur `IO:BufFileRead` et `IO:BufFileWrite` en passant en revue Sessions actives en moyenne (AAS) dans les sections Charge de base de données et Principaux éléments SQL.
![\[IO : BufFileRead et IO : BufFileWrite dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Pour plus d’informations sur la façon d’analyser les requêtes les plus importantes et la charge par événement d’attente à l’aide de l’analyse des performances, consultez [Présentation de l'onglet Top SQL (Principaux éléments SQL)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Vous devez identifier et ajuster les requêtes qui entraînent une augmentation de l’utilisation des fichiers temporaires et des événements d’attente associés. Pour plus d'informations sur ces événements d'attente et les mesures correctives, voir [IO : BufFileRead et IO : BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html) .
**Note**
Le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) contrôle le moment où la mémoire de l’opération de tri est insuffisante et les résultats sont écrits dans des fichiers temporaires. Nous vous recommandons de ne pas modifier la valeur de ce paramètre au-delà de la valeur par défaut, car cela permettrait à chaque session de base de données de consommer davantage de mémoire. En outre, une session unique qui effectue des jointures et des tris complexes peut effectuer des opérations parallèles au cours desquelles chaque opération consomme de la mémoire.
Il est recommandé de définir ce paramètre au niveau de la session à l’aide de la commande `SET work_mem` lorsque vous disposez d’un rapport volumineux comportant plusieurs jointures et tris. La modification n’est alors appliquée qu’à la session en cours et ne modifie pas la valeur de manière globale.
## Utilisation de pgBadger pour l'analyse de journal serveur avec PostgreSQL
Vous pouvez utiliser un analyseur de journaux tel que [pgBadger](http://dalibo.github.io/pgbadger/) pour analyser les journaux PostgreSQL. La documentation pgBadger indique que le motif %l (ligne de journal pour la session ou le processus) doit faire partie du préfixe. Cependant, si vous fournissez le `log_line_prefix` RDS actuel en tant que paramètre à pgBadger, il devrait quand même produire un rapport.
Par exemple, la commande suivante formate correctement un fichier journal Amazon RDS pour PostgreSQL daté du 04/02/2014 à l’aide de pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Utilisation PGSnapper pour la surveillance de PostgreSQL
Vous pouvez l'utiliser PGSnapper pour faciliter la collecte périodique de statistiques et de mesures relatives aux performances d'Amazon RDS for PostgreSQL. Pour plus d'informations, consultez [Surveiller les performances d'Amazon RDS for PostgreSQL à l'aide de](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/). PGSnapper
#
**Le casting de type** dans PostgreSQL est le processus de conversion d'une valeur d'un type de données à un autre. PostgreSQL fournit des conversions intégrées pour de nombreuses conversions courantes, mais vous pouvez également créer des conversions personnalisées pour définir le comportement de conversions de type spécifique.
Un cast indique comment effectuer une conversion d'un type de données à un autre. Par exemple, convertir du texte `'123'` en entier `123` ou un nombre numérique `45.67` en texte`'45.67'`.
Pour obtenir des informations complètes sur les concepts et la syntaxe de PostgreSQL Cast, consultez la documentation [PostgreSQL](https://www.postgresql.org/docs/current/sql-createcast.html) CREATE CAST.
À partir des , vous pouvez utiliser l'extension rds\$1casts pour installer des conversions supplémentaires pour les types intégrés, tout en étant en mesure de créer vos propres conversions pour les types personnalisés.
**Topics**
+ [
## Installation et utilisation de l'extension rds\$1casts
](#PostgreSQL.CustomCasts.Installing)
+ [
## Castings pris en charge
](#PostgreSQL.CustomCasts.Supported)
+ [
## Création ou suppression de moulages
](#PostgreSQL.CustomCasts.Creating)
+ [
## Création de moulages personnalisés avec une stratégie contextuelle appropriée
](#PostgreSQL.CustomCasts.BestPractices)
## Installation et utilisation de l'extension rds\$1casts
Pour créer l'`rds_casts`extension, connectez-vous à (votre instance de base de données RDS pour PostgreSQL en tant que telle) et exécutez la commande suivante : `rds_superuser`
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Castings pris en charge
Créez l'extension dans chaque base de données dans laquelle vous souhaitez utiliser des moulages personnalisés. Après avoir créé l'extension, utilisez la commande suivante pour afficher tous les casts disponibles :
```
SELECT * FROM rds_casts.list_supported_casts();
```
Cette fonction répertorie les combinaisons de diffusion disponibles (type de source, type de cible, contexte de coercition et fonction de diffusion). Par exemple, si vous souhaitez le `text` créer en `numeric` tant que `implicit` casting. Vous pouvez utiliser la requête suivante pour savoir si le casting est disponible pour être créé :
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
L'extension rds\$1casts fournit deux types de fonctions de conversion pour chaque cast :
+ *Fonctions \$1inout* - Utilisez le mécanisme de I/O conversion standard de PostgreSQL, en se comportant de la même manière que les conversions créées avec la méthode INOUT
+ *\$1custom functions* - Fournissez une logique de conversion améliorée qui gère les cas extrêmes, tels que la conversion de chaînes vides en valeurs NULL pour éviter les erreurs de conversion
Les `inout` fonctions reproduisent le comportement de casting natif de PostgreSQL, tandis que les `custom` fonctions étendent cette fonctionnalité en gérant des scénarios que les conversions INOUT standard ne peuvent pas prendre en charge, tels que la conversion de chaînes vides en entiers.
## Création ou suppression de moulages
Vous pouvez créer et supprimer des diffusions prises en charge à l'aide de deux méthodes :
### Création du casting
**Méthode 1 : utilisation de la commande native CREATE CAST**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Méthode 2 : utilisation de la fonction rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
La `create_cast` fonction prend l'identifiant de la `list_supported_casts()` sortie. Cette méthode est plus simple et garantit que vous utilisez la bonne combinaison de fonction et de contexte. Il est garanti que cet identifiant restera le même dans les différentes versions de Postgres.
Pour vérifier que le cast a bien été créé, interrogez le catalogue du système pg\$1cast :
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
La `castcontext` colonne indique : `e` pour EXPLICIT, `a` pour ASSIGNMENT ou `i` pour IMPLICIT.
### Lancer des moulages
**Méthode 1 : utilisation de la commande DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Méthode 2 : utilisation de la fonction rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
La `drop_cast` fonction utilise le même identifiant que celui utilisé lors de la création du casting. Cette méthode garantit que vous supprimez le casting exact créé avec l'ID correspondant.
## Création de moulages personnalisés avec une stratégie contextuelle appropriée
Lors de la création de plusieurs conversions pour des types entiers, des erreurs d'ambiguïté d'opérateur peuvent se produire si toutes les conversions sont créées en tant que valeur IMPLICITE. L'exemple suivant illustre ce problème en créant deux conversions implicites à partir du texte en différentes largeurs de nombres entiers :
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
L'erreur se produit parce que PostgreSQL ne peut pas déterminer la conversion implicite à utiliser lors de la comparaison d'une colonne entière avec une valeur de texte. Les conversions implicites int4 et int8 sont des candidats valides, ce qui crée une ambiguïté.
Pour éviter cette ambiguïté d'opérateur, utilisez le contexte ASSIGNMENT pour les largeurs entières plus petites et le contexte IMPLICITE pour les largeurs entières plus grandes :
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Avec cette stratégie, seul le cast int8 est implicite, de sorte que PostgreSQL peut déterminer sans ambiguïté le cast à utiliser.
# Meilleures pratiques pour les requêtes parallèles dans pour PostgreSQL
L'exécution parallèle de requêtes est une fonctionnalité de PostgreSQL qui permet de diviser une seule requête SQL en tâches plus petites traitées simultanément par plusieurs processus de travail en arrière-plan. Au lieu d'exécuter une requête entièrement dans un seul processus principal, PostgreSQL peut répartir certaines parties de la requête, telles que les scans, les jointures, les agrégations ou le tri, sur plusieurs cœurs de processeur. Le *processus leader* coordonne cette exécution et recueille les résultats auprès des *travailleurs parallèles*.
Toutefois, pour la plupart des charges de travail de production, en particulier les systèmes OLTP à haute simultanéité, nous recommandons de désactiver l'exécution automatique des requêtes en parallèle. Bien que le parallélisme puisse accélérer les requêtes sur de grands ensembles de données dans le cadre des charges de travail d'analyse ou de reporting, il présente des risques importants qui l'emportent souvent sur les avantages dans les environnements de production chargés.
L'exécution parallèle entraîne également une surcharge importante. Chaque parallel worker est un processus principal de PostgreSQL complet, qui nécessite une bifurcation des processus (copie des structures de mémoire et initialisation de l'état du processus) et une authentification (consommation d'emplacements de connexion supérieurs à votre limite). `max_connections` Chaque travailleur consomme également sa propre mémoire, notamment `work_mem` pour les opérations de tri et de hachage, avec plusieurs travailleurs par requête, l'utilisation de la mémoire se multiplie rapidement (par exemple, 4 travailleurs × 64 Mo `work_mem` = 256 Mo par requête). Par conséquent, les requêtes parallèles peuvent consommer beaucoup plus de ressources système que les requêtes à processus unique. S'ils ne sont pas correctement réglés, ils peuvent entraîner une saturation du processeur (plusieurs travailleurs surchargent la capacité de traitement disponible), une augmentation du changement de contexte (le système d'exploitation passe fréquemment d'un processus de travail à un autre, augmente la charge de travail et réduit le débit) ou un épuisement des connexions (chaque travailleur parallèle occupe un emplacement de connexion, une requête avec 4 travailleurs au total, ce qui peut rapidement épuiser votre pool de connexions en cas de forte simultanéité, empêchant de nouvelles connexions clients et provoquant des défaillances d'applications). Ces problèmes sont particulièrement graves dans le cas de charges de travail hautement simultanées où plusieurs requêtes peuvent tenter une exécution parallèle simultanément.
PostgreSQL décide d'utiliser ou non le parallélisme en fonction des estimations de coûts. Dans certains cas, le planificateur peut automatiquement passer à un plan parallèle s'il semble moins cher, même si ce n'est pas l'idéal dans la pratique. Cela peut se produire si les statistiques d'index ne sont plus à jour ou si le surcroît de données rend les scans séquentiels plus attrayants que les recherches d'index. En raison de ce comportement, les plans parallèles automatiques peuvent parfois entraîner des régressions au niveau des performances des requêtes ou de la stabilité du système.
Pour tirer le meilleur parti des requêtes parallèles dans , il est important de les tester et de les ajuster en fonction de votre charge de travail, de surveiller l'impact sur le système et de désactiver la sélection automatique des plans parallèles au profit du contrôle au niveau des requêtes.
## Paramètres de configuration
PostgreSQL utilise plusieurs paramètres pour contrôler le comportement et la disponibilité des requêtes parallèles. Il est essentiel de les comprendre et de les ajuster pour obtenir des performances prévisibles :
| Paramètre | Description | Par défaut |
| --- | --- | --- |
| max\$1parallel\$1workers | Nombre maximum de processus de travail en arrière-plan pouvant être exécutés au total | MEILLEUR (\$1 DBInstance VCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Nombre maximum de travailleurs par nœud du plan de requête (par exemple, parGather) | 2 |
| parallel\$1setup\$1cost | Coût du planificateur ajouté pour le lancement d'une infrastructure de requêtes parallèles | 1 000 |
| parallel\$1tuple\$1cost | Coût par tuple traité en mode parallèle (influence la décision du planificateur) | 0.1 |
| force\$1parallel\$1mode | Force le planificateur à tester des plans parallèles (off,on,regress) | off |
### Considérations clés
+ `max_parallel_workers`contrôle le pool total de travailleurs parallèles. Si cette valeur est trop faible, certaines requêtes peuvent revenir à l'exécution en série.
+ `max_parallel_workers_per_gather`affecte le nombre de travailleurs qu'une seule requête peut utiliser. Une valeur plus élevée augmente la simultanéité, mais également l'utilisation des ressources.
+ `parallel_setup_cost`et `parallel_tuple_cost` affectent le modèle de coûts du planificateur. En les abaissant, les plans parallèles sont plus susceptibles d'être choisis.
+ `force_parallel_mode`est utile pour les tests mais ne doit pas être utilisé en production sauf si cela est nécessaire.
**Note**
La valeur par défaut du `max_parallel_workers` paramètre est calculée dynamiquement en fonction de la taille de l'instance à l'aide de la formule`GREATEST($DBInstanceVCPU/2, 8)`. Cela signifie que lorsque vous adaptez votre à une taille de calcul plus grande avec plus de vCPUs, le nombre maximum de travailleurs parallèles disponibles augmente automatiquement. Par conséquent, les requêtes précédemment exécutées en série ou avec un parallélisme limité peuvent soudainement utiliser davantage de travailleurs parallèles après une opération de mise à l'échelle, ce qui peut entraîner une augmentation inattendue de l'utilisation des connexions, de l'utilisation du processeur et de la consommation de mémoire. Il est important de surveiller le comportement des requêtes parallèles après tout événement de dimensionnement du calcul et de les ajuster `max_parallel_workers_per_gather` si nécessaire pour garantir une utilisation prévisible des ressources.
## Identifier l'utilisation des requêtes parallèles
Les requêtes peuvent passer à des plans parallèles en fonction de la distribution des données ou des statistiques. Par exemple :
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Cette requête peut utiliser un index pour les données récentes, mais passer à un scan séquentiel parallèle pour les données historiques.
Vous pouvez enregistrer les plans d'exécution des requêtes en chargeant le `auto_explain` module. Pour en savoir plus, consultez la section [Enregistrement des plans d'exécution des requêtes](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) dans le centre de AWS connaissances.
Vous pouvez surveiller [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) pour détecter les événements d'attente liés aux requêtes parallèles. Pour en savoir plus sur les événements d'attente liés à Parallel Query, consultez [IPC:Parallel](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html) wait events
À partir de la version 18 de PostgreSQL, vous pouvez surveiller l'activité des travailleurs parallèles à l'aide de nouvelles colonnes dans et : [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)
+ `parallel_workers_to_launch`: Nombre de travailleurs parallèles dont le lancement est prévu
+ `parallel_workers_launched`: Nombre de travailleurs parallèles réellement lancés
Ces mesures permettent d'identifier les écarts entre le parallélisme prévu et le parallélisme réel, ce qui peut indiquer des contraintes de ressources ou des problèmes de configuration. Utilisez les requêtes suivantes pour surveiller l'exécution parallèle :
Pour les métriques de travail parallèle au niveau de la base de données :
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Pour les métriques de travail parallèle au niveau de la requête
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Comment contrôler le parallélisme
Il existe plusieurs méthodes pour contrôler le parallélisme des requêtes, chacune étant conçue pour différents scénarios et exigences.
Pour désactiver le parallélisme automatique de manière globale, [de paramètres pour définir](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html) :
```
max_parallel_workers_per_gather = 0;
```
Pour les paramètres persistants spécifiques à l'utilisateur, la commande ALTER ROLE permet de définir des paramètres qui s'appliqueront à toutes les futures sessions d'un utilisateur en particulier.
Par exemple :
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;`garantit que chaque fois que cet utilisateur se connecte à la base de données, ses sessions utilisent ce paramètre de travail parallèle lorsque cela est nécessaire.
Le contrôle au niveau de la session peut être réalisé à l'aide de la commande SET, qui modifie les paramètres pendant la durée de la session de base de données en cours. Cela est particulièrement utile lorsque vous devez ajuster temporairement les paramètres sans affecter les autres utilisateurs ou les sessions futures. Une fois définis, ces paramètres restent actifs jusqu'à ce qu'ils soient explicitement réinitialisés ou jusqu'à la fin de la session. Les commandes sont simples :
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Pour un contrôle encore plus précis, SET LOCAL vous permet de modifier les paramètres d'une seule transaction. C'est idéal lorsque vous devez ajuster les paramètres d'un ensemble spécifique de requêtes au sein d'une transaction, après quoi les paramètres reviennent automatiquement à leurs valeurs précédentes. Cette approche permet d'éviter des effets indésirables sur les autres opérations au cours de la même session.
## Diagnostic du comportement des requêtes parallèles
`EXPLAIN (ANALYZE, VERBOSE)`À utiliser pour vérifier si une requête a utilisé l'exécution parallèle :
+ Recherchez des nœuds tels que `Gather``Gather Merge`, ou`Parallel Seq Scan`.
+ Comparez les forfaits avec et sans parallélisme.
Pour désactiver temporairement le parallélisme à des fins de comparaison :
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL
Dans certains cas, vous pouvez créer une instance de base de données RDS pour PostgreSQL sans spécifier de groupe de paramètres personnalisé. Si tel est le cas, votre instance de base de données est créée à l'aide du groupe de paramètres par défaut de la version de PostgreSQL que vous choisissez. Par exemple, supposons que vous créez une instance de base de données RDS pour PostgreSQL à l’aide de PostgreSQL 13.3. Dans ce cas, l'instance de base de données est créée à l'aide des valeurs du groupe de paramètres pour les versions PostgreSQL 13, `default.postgres13`.
Vous pouvez créer votre propre groupe de paramètres de base de données avec des paramètres personnalisés. Vous devez le faire si vous souhaitez modifier les paramètres de l’instance de base de données RDS pour PostgreSQL à partir de leurs valeurs par défaut. Pour savoir comment procéder, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous pouvez suivre les paramètres de votre instance de base de données RDS pour PostgreSQL de plusieurs manières différentes. Vous pouvez utiliser l'API AWS Management Console, la AWS CLI, ou l'API Amazon RDS. Vous pouvez également interroger les valeurs à partir de la table `pg_settings` PostgreSQL de votre instance, comme illustré ci-dessous.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Pour plus d’informations sur les valeurs renvoyées par cette requête, consultez [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) dans la documentation PostgreSQL.
Soyez particulièrement prudent lorsque vous modifiez les paramètres de `max_connections` et `shared_buffers` sur votre instance de base de données RDS pour PostgreSQL. Par exemple, supposons que vous modifiiez les paramètres de `max_connections` ou `shared_buffers` et vous utilisez des valeurs trop élevées pour votre charge de travail réelle. Dans ce cas, votre instance de base de données RDS pour PostgreSQL ne démarrera pas. Si cela se produit, une erreur telle que la suivante s'affiche dans le `postgres.log`.
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Toutefois, notez que vous ne pouvez modifier aucune valeur des paramètres contenus dans les groupes de paramètres RDS pour PostgreSQL DB par défaut. Pour modifier n'importe quel paramètre, créez d'abord un groupe de paramètres de base de données personnalisé. Modifiez ensuite les paramètres de ce groupe personnalisé, puis appliquez le groupe de paramètres personnalisé à votre instance de base de données RDS pour PostgreSQL. Pour en savoir plus, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Il existe deux types de paramètres dans RDS pour PostgreSQL.
+ **Paramètres statiques** : les paramètres statiques exigent que l’instance de base de données RDS pour PostgreSQL soit réinitialisée après une modification afin que la nouvelle valeur puisse prendre effet.
+ **Paramètres dynamiques** : les paramètres dynamiques ne nécessitent pas de réinitialisation après avoir modifié leurs paramètres.
**Note**
Si votre instance de base de données RDS pour PostgreSQL utilise votre propre groupe de paramètres de base de données personnalisé, vous pouvez modifier les valeurs des paramètres dynamiques sur l’instance en cours d’exécution. Pour ce faire AWS Management Console, vous pouvez utiliser l'API AWS CLI, ou l'API Amazon RDS.
Vous pouvez également modifier des valeurs de paramètres, si vous disposez des privilèges nécessaires, en utilisant les commandes `ALTER DATABASE`, `ALTER ROLE` et `SET`.
## Liste de paramètres d’instance de base de données RDS pour PostgreSQL
Le tableau suivant répertorie certains (mais pas tous) des paramètres disponibles (mais pas tous) dans une instance de base de données RDS pour PostgreSQL. Pour afficher tous les paramètres disponibles, utilisez la [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI commande. Par exemple, pour obtenir la liste de tous les paramètres disponibles dans le groupe de paramètres par défaut pour RDS pour PostgreSQL version 13, procédez comme suit.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Vous pouvez également utiliser la console. Choisissez **Parameter groups** (Groupes de paramètres) dans le menu Amazon RDS, puis choisissez le groupe de paramètres parmi ceux disponibles dans votre Région AWS.
| Nom du paramètre | Type d'application | Description |
| --- | --- | --- |
| `application_name` | Répartition dynamique | Définit le nom de l'application à indiquer dans les statistiques et les journaux. |
| `archive_command` | Répartition dynamique | Définit la commande shell qui sera appelée pour archiver un fichier WAL. |
| `array_nulls` | Répartition dynamique | Autorise l'entrée d'éléments NULL dans les tableaux. |
| `authentication_timeout` | Répartition dynamique | Définit le délai maximum autorisé pour procéder à l'authentification du client. |
| `autovacuum` | Répartition dynamique | Démarre le sous-processus autovacuum. |
| `autovacuum_analyze_scale_factor` | Répartition dynamique | Nombre de tuples insérés, mis à jour ou supprimés avant analyse en tant que partie de reltuples. |
| `autovacuum_analyze_threshold` | Répartition dynamique | Nombre minimum de tuples insérés, mis à jour ou supprimés avant analyse. |
| `autovacuum_freeze_max_age` | Statique | Âge auquel lancer le processus autovacuum sur une table pour empêcher le bouclage de l’ID de transaction. |
| `autovacuum_naptime` | Répartition dynamique | Temps de repos entre les exécutions autovacuum. |
| `autovacuum_max_workers` | Statique | Définit le nombre maximum de processus autovacuum qui peuvent être exécutés simultanément. |
| `autovacuum_vacuum_cost_delay` | Répartition dynamique | Valeur du coût de retard du processus vacuum en millisecondes, pour le processus autovacuum. |
| `autovacuum_vacuum_cost_limit` | Répartition dynamique | Coût cumulé qui provoque l'endormissement du processus vacuum, pour le processus autovacuum. |
| `autovacuum_vacuum_scale_factor` | Répartition dynamique | Nombre de tuples mis à jour ou supprimés avant le processus vacuum en tant que partie de reltuples. |
| `autovacuum_vacuum_threshold` | Répartition dynamique | Nombre de tuples mis à jour ou supprimés avant le processus vacuum. |
| `backslash_quote` | Répartition dynamique | Définit si une barre oblique inverse (\$1) peut être utilisée dans les littéraux de chaîne. |
| `bgwriter_delay` | Répartition dynamique | Délai d'inactivité entre les tours d'activité du processus d'écriture en arrière-plan. |
| `bgwriter_lru_maxpages` | Répartition dynamique | Nombre maximum de pages récemment utilisées qui peuvent être vidées à chaque tour par le processus d'écriture en tâche de fond. |
| `bgwriter_lru_multiplier` | Répartition dynamique | Multiple de l'utilisation moyenne de tampons à libérer par tour. |
| `bytea_output` | Répartition dynamique | Configure le format de sortie pour les valeurs de type octets. |
| `check_function_bodies` | Répartition dynamique | Vérifie les corps des fonctions pendant la fonction CREATE FUNCTION. |
| `checkpoint_completion_target` | Répartition dynamique | Temps nécessaire pour vider les tampons sales au moment de la vérification, sous la forme d'une fraction de temps entre deux points de vérification. |
| `checkpoint_segments` | Répartition dynamique | Définit la distance maximale dans les segments de journaux entre deux points de vérification automatique de journal WAL. |
| `checkpoint_timeout` | Répartition dynamique | Définit le temps maximum entre deux points de vérification automatique des WAL. |
| `checkpoint_warning` | Répartition dynamique | Active les avertissements si des segments de points de vérification sont remplis à une fréquence supérieure à ce paramètre. |
| `client_connection_check_interval` | Répartition dynamique | Définit l’intervalle de temps entre les vérifications de déconnexion lors de l’exécution des requêtes. |
| `client_encoding` | Répartition dynamique | Définit l'encodage du jeu de caractères du client. |
| `client_min_messages` | Répartition dynamique | Définit les niveaux des messages envoyés au client. |
| `commit_delay` | Répartition dynamique | Définit la durée, en micro-secondes, entre le déclenchement de la sonde transaction-commit et le vidage de WAL vers le disque. |
| `commit_siblings` | Répartition dynamique | Définit le nombre minimum de transactions ouvertes simultanément avant d'atteindre le délai commit\$1delay. |
| `constraint_exclusion` | Répartition dynamique | Autorise le planificateur à utiliser des contraintes pour optimiser les requêtes. |
| `cpu_index_tuple_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût de traitement de chaque entrée d'index pendant la vérification d'un index. |
| `cpu_operator_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût de traitement de chaque opérateur ou appel de fonction. |
| `cpu_tuple_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût de traitement de chaque ligne. |
| `cursor_tuple_fraction` | Répartition dynamique | Définit l'estimation faite par le planificateur de la fraction des lignes d'un curseur qui sera récupérée. |
| `datestyle` | Répartition dynamique | Définit le format d'affichage des valeurs de type date et heure. |
| `deadlock_timeout` | Répartition dynamique | Définit le délai d'attente au niveau d'un verrou avant blocage. |
| `debug_pretty_print` | Répartition dynamique | Indente les affichages des arborescence d'analyse et de planification. |
| `debug_print_parse` | Répartition dynamique | Enregistre l'arborescence d'analyse de chaque requête. |
| `debug_print_plan` | Répartition dynamique | Enregistre le plan d'exécution de chaque requête. |
| `debug_print_rewritten` | Répartition dynamique | Enregistre l'arbre d'interprétation réécrit de chaque requête. |
| `default_statistics_target` | Répartition dynamique | Définit la cible des statistiques par défaut. |
| `default_tablespace` | Répartition dynamique | Définit l'espace de table par défaut dans lequel créer des tables et des index. |
| `default_transaction_deferrable` | Répartition dynamique | Définit le statut reportable des nouvelles transactions. |
| `default_transaction_isolation` | Répartition dynamique | Définit le niveau d’isolement de transaction de chaque nouvelle transaction. |
| `default_transaction_read_only` | Répartition dynamique | Définit le statut en lecture seule des nouvelles transactions. |
| `default_with_oids` | Répartition dynamique | Crée de nouvelles tables avec object IDs (OIDs) par défaut. |
| `effective_cache_size` | Répartition dynamique | Définit l'estimation faite par le planificateur de la taille du cache du disque. |
| `effective_io_concurrency` | Répartition dynamique | Nombre de demandes simultanées pouvant être traitées de manière efficace par le sous-système du disque. |
| `enable_bitmapscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours de bitmap par le planificateur. |
| `enable_hashagg` | Répartition dynamique | Autorise l'utilisation de plans d'agrégation hachée par le planificateur. |
| `enable_hashjoin` | Répartition dynamique | Autorise l'utilisation de plans de jointures de hachage par le planificateur. |
| `enable_indexscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours d'index par le planificateur. |
| `enable_material` | Répartition dynamique | Autorise l'utilisation de la matérialisation par le planificateur. |
| `enable_mergejoin` | Répartition dynamique | Autorise l'utilisation de plans de jointures de fusion par le planificateur. |
| `enable_nestloop` | Répartition dynamique | Autorise l'utilisation de plans de jointures de boucles imbriquées par le planificateur. |
| `enable_seqscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours séquentiels par le planificateur. |
| `enable_sort` | Répartition dynamique | Autorise l'utilisation des étapes de tri explicite par le planificateur. |
| `enable_tidscan` | Répartition dynamique | Autorise l'utilisation de plans de parcours de TID par le planificateur. |
| `escape_string_warning` | Répartition dynamique | Avertit sur l'utilisation des barres obliques inverses (\$1) dans des littéraux de chaîne ordinaires. |
| `extra_float_digits` | Répartition dynamique | Définit le nombre de chiffres affichés pour les valeurs à virgule flottante. |
| `from_collapse_limit` | Répartition dynamique | Définit la taille FROM-list au-delà de laquelle les sous-requêtes ne sont pas regroupées. |
| `fsync` | Répartition dynamique | Force la synchronisation des mises à jour sur le disque. |
| `full_page_writes` | Répartition dynamique | Ecrit les pages complètes dans les WAL lors de la première modification après un point de vérification. |
| `geqo` | Répartition dynamique | Active l'optimisation génétique des requêtes. |
| `geqo_effort` | Répartition dynamique | geqo\$1effort est utilisé pour définir la valeur par défaut pour les autres paramètres GEQO. |
| `geqo_generations` | Répartition dynamique | GEQO : nombre d'itérations de l'algorithme. |
| `geqo_pool_size` | Répartition dynamique | GEQO : nombre d'individus au sein d'une population. |
| `geqo_seed` | Répartition dynamique | GEQO : valeur initiale pour la sélection des chemins au hasard. |
| `geqo_selection_bias` | Répartition dynamique | GEQO : pression de sélectivité au sein de la population. |
| `geqo_threshold` | Répartition dynamique | Définit le seuil d'éléments FROM au-delà duquel GEQO est utilisé. |
| `gin_fuzzy_search_limit` | Répartition dynamique | Définit le résultat maximum autorisé pour la recherche exacte par GIN. |
| `hot_standby_feedback` | Répartition dynamique | Détermine si une instance de secours envoie des messages de commentaire aux instances principales ou de veille en amont. |
| `intervalstyle` | Répartition dynamique | Définit le format d'affichage des valeurs de type intervalle. |
| `join_collapse_limit` | Répartition dynamique | Définit la taille FROM-list au-delà de laquelle les constructions JOIN ne sont pas mises à plat. |
| `lc_messages` | Répartition dynamique | Définit la langue d'affichage des messages. |
| `lc_monetary` | Répartition dynamique | Définit la locale à utiliser pour le formatage des montants monétaires. |
| `lc_numeric` | Répartition dynamique | Définit la locale à utiliser pour le formatage des nombres. |
| `lc_time` | Répartition dynamique | Définit la locale à utiliser pour le formatage des valeurs de date et d'heure. |
| `log_autovacuum_min_duration` | Répartition dynamique | Définit la durée minimum d'exécution au-delà de laquelle les actions autovacuum seront enregistrées. |
| `log_checkpoints` | Répartition dynamique | Enregistre chaque point de vérification. |
| `log_connections` | Répartition dynamique | Enregistre toutes les connexions réussies. |
| `log_disconnections` | Répartition dynamique | Enregistre la fin d'une session, y compris sa durée. |
| `log_duration` | Répartition dynamique | Enregistre la durée de chaque instruction SQL terminée. |
| `log_error_verbosity` | Répartition dynamique | Définit la quantité de détails dans les messages enregistrés. |
| `log_executor_stats` | Répartition dynamique | Ecrit les statistiques de performance de l'exécuteur dans le journal du serveur. |
| `log_filename` | Répartition dynamique | Définit le modèle de nom de fichier pour les fichiers journaux. |
| `log_file_mode` | Répartition dynamique | Définit les autorisations de fichier pour les fichiers journaux. La valeur par défaut est 0644. |
| `log_hostname` | Répartition dynamique | Enregistre le nom de l'hôte dans les journaux de connexion. À partir de PostgreSQL 12 et des versions ultérieures, ce paramètre est « désactivé » par défaut. Lorsqu'il est activé, la connexion utilise la recherche inversée DNS pour obtenir le nom d'hôte qui est capturé dans les journaux de connexion. Si vous activez ce paramètre, vous devez surveiller son impact sur le temps nécessaire à l'établissement des connexions. |
| `log_line_prefix ` | Répartition dynamique | Contrôle les informations préfixées à chaque ligne de journal. |
| `log_lock_waits` | Répartition dynamique | Enregistre les longs temps d'attente pour l'acquisition d'un verrou. |
| `log_min_duration_statement` | Répartition dynamique | Définit la durée minimum d'exécution au-delà de laquelle les instructions seront enregistrées. |
| `log_min_error_statement` | Répartition dynamique | Déclenche l'enregistrement de toutes les instructions générant une erreur à ce niveau ou à un niveau supérieur. |
| `log_min_messages` | Répartition dynamique | Définit les niveaux des messages qui sont enregistrés. |
| `log_parser_stats` | Répartition dynamique | Ecrit les statistiques de performance de l'analyseur dans le journal du serveur. |
| `log_planner_stats` | Répartition dynamique | Ecrit les statistiques de performance du planificateur dans le journal du serveur. |
| `log_rotation_age` | Répartition dynamique | Déclenchement de la rotation de fichier journal automatique au-delà d'un délai de N minutes. |
| `log_rotation_size` | Répartition dynamique | Déclenchement de la rotation de fichier journal automatique au-delà de N kilo-octets. |
| `log_statement` | Répartition dynamique | Définit le type d'instructions enregistrées. |
| `log_statement_stats` | Répartition dynamique | Ecrit les statistiques de performance cumulées dans le journal du serveur. |
| `log_temp_files` | Répartition dynamique | Enregistre l'utilisation des fichiers temporaires dont la taille est supérieure à cette taille en kilo-octets. |
| `log_timezone` | Répartition dynamique | Définit le fuseau horaire à utiliser dans les messages de journaux. |
| `log_truncate_on_rotation` | Répartition dynamique | Tronquez les fichiers journaux existants du même nom pendant la rotation des journaux. |
| `logging_collector` | Statique | Démarrez un sous-processus pour capturer les fichiers and/or CSV de sortie stderr dans des fichiers journaux. |
| `maintenance_work_mem` | Répartition dynamique | Définit la quantité maximum de mémoire que peuvent utiliser les opérations de maintenance. |
| `max_connections` | Statique | Définit le nombre maximum de connexions simultanées. |
| `max_files_per_process` | Statique | Définit le nombre maximum de fichiers ouverts simultanément pour chaque processus serveur. |
| `max_locks_per_transaction` | Statique | Définit le nombre maximum de verrous par transaction. |
| `max_pred_locks_per_transaction` | Statique | Définit le nombre maximum de verrous de prédicat par transaction. |
| `max_prepared_transactions` | Statique | Définit le nombre maximum de transactions préparées simultanément. |
| `max_stack_depth` | Répartition dynamique | Définit la profondeur maximum de la pile, en kilo-octets. |
| `max_standby_archive_delay` | Répartition dynamique | Définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur hot standby traite des données WAL archivées. |
| `max_standby_streaming_delay` | Répartition dynamique | Définit le délai maximum avant l'annulation des requêtes lorsqu'un serveur hot standby traite des données WAL diffusées. |
| max\$1wal\$1size | Répartition dynamique | Définit la taille (en Mo) de journal WAL qui déclenche un point de vérification. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Utilisez la commande suivante sur votre instance de base de données Amazon RDS pour PostgreSQL pour voir sa valeur actuelle : SHOW max_wal_size;
|
| min\$1wal\$1size | Répartition dynamique | Définit la taille minimale à laquelle réduire le journal WAL. Pour PostgreSQL version 9.6 ou antérieure, la taille min\$1wal\$1size est exprimée en unités de 16 Mo. Pour PostgreSQL version 10 ou supérieure, la taille min\$1wal\$1size est exprimée en unités de 1 Mo. |
| `quote_all_identifiers` | Répartition dynamique | Ajoute des guillemets (") à tous les identifiants lors de la génération de fragments SQL. |
| `random_page_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût d'une page de disque extraite de façon non séquentielle. Ce paramètre n'a aucune valeur sauf si la gestion du plan de requête (QPM) est activée. Lorsque QPM est activée, la valeur par défaut de ce paramètre est 4. |
| rds.adaptive\$1autovacuum | Répartition dynamique | Règle automatiquement les paramètres d'autovacuum chaque fois que les seuils d'ID de transaction sont dépassés. |
| rds.force\$1ssl | Répartition dynamique | Nécessite l'utilisation de connexions SSL. La valeur par défaut est définie sur 1 (activé) pour RDS pour PostgreSQL version 15. Toutes les autres versions majeures 14 et antérieures de RDS pour PostgreSQL ont la valeur par défaut définie sur 0 (désactivé). |
| `rds.local_volume_spill_enabled` | Statique | Permet d’écrire des fichiers de déversement logiques sur le volume local. |
| `rds.log_retention_period` | Répartition dynamique | Définit la rétention des journaux de telle manière qu'Amazon RDS supprime les journaux PostgreSQL antérieurs à n minutes. |
| rds.rds\$1superuser\$1reserved\$1connections | Statique | Définit le nombre d’emplacements de connexion réservés pour rds\$1superusers. Ce paramètre est uniquement disponible dans les versions 15 et antérieures. Pour plus d’informations, consultez la documentation de PostgreSQL sur [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). |
| `rds.replica_identity_full` | Répartition dynamique | Lorsque vous définissez ce paramètre sur `on`, il remplace le paramètre d’identité de réplique sur `FULL` pour toutes les tables de base de données. Cela signifie que toutes les valeurs des colonnes sont écrites dans le journal d’écriture anticipée (WAL), quels que soient vos paramètres `REPLICA IDENTITY FULL`. L’activation de ce paramètre peut augmenter les IOPS de votre instance de base de données en raison de la journalisation WAL supplémentaire. |
| rds.restrict\$1password\$1commands | Statique | Limite la gestion des mots de passe aux utilisateurs auxquels le rôle rds\$1password a été affecté. Pour la restriction par mot de passe, définissez ce paramètre sur 1. La valeur par défaut est 0. |
| `search_path` | Répartition dynamique | Définit l'ordre de recherche des schémas pour les noms pour lesquels le schéma n'est pas précisé. |
| `seq_page_cost` | Répartition dynamique | Définit l'estimation faite par le planificateur du coût d'une page de disque extraite de façon séquentielle. |
| `session_replication_role` | Répartition dynamique | Définit le comportement des sessions concernant les déclencheurs et les règles de réécriture. |
| `shared_buffers` | Statique | Définit le nombre de tampons de mémoire partagée utilisés par le serveur. |
| `shared_preload_libraries ` | Statique | Répertorie les bibliothèques partagées à précharger dans l’instance de base de données RDS pour PostgreSQL. Les valeurs prises en charge incluent auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler et plrust. |
| `ssl` | Répartition dynamique | Active les connexions SSL. |
| `sql_inheritance` | Répartition dynamique | Entraîne l'ajout par défaut de sous-tables dans plusieurs commandes. |
| `ssl_renegotiation_limit` | Répartition dynamique | Définit la quantité de trafic à envoyer et recevoir avant de renégocier les clés de chiffrement. |
| `standard_conforming_strings` | Répartition dynamique | Entraîne les chaînes ... à traiter littéralement les barres obliques inverses. |
| `statement_timeout` | Répartition dynamique | Définit la durée maximum de toute instruction. |
| `synchronize_seqscans` | Répartition dynamique | Active les analyses séquentielles synchronisées. |
| `synchronous_commit` | Répartition dynamique | Définit le niveau de synchronisation des transactions actuelles. |
| `tcp_keepalives_count` | Répartition dynamique | Nombre maximum de paquets TCP keepalive. |
| `tcp_keepalives_idle` | Répartition dynamique | Délai entre les émissions de paquets TCP keepalive. |
| `tcp_keepalives_interval` | Répartition dynamique | Délai entre les envois de paquets TCP keepalive. |
| `temp_buffers` | Répartition dynamique | Définit le nombre maximum de tampons temporaires utilisés par chaque session. |
| temp\$1file\$1limit | Répartition dynamique | Définit la taille maximale en Ko que peuvent atteindre les fichiers temporaires. |
| `temp_tablespaces` | Répartition dynamique | Définit l'espace de table à utiliser pour les tables et fichiers de tri temporaires. |
| `timezone` | Répartition dynamique | Définit le fuseau horaire pour l'affichage et l'interprétation de la date et de l'heure. L'Internet Assigned Numbers Authority (IANA) publie de nouveaux fuseaux horaires sur [https://www.iana.org/time-zones](https://www.iana.org/time-zones) plusieurs fois par an. Chaque fois que RDS publie une nouvelle version de maintenance mineure de PostgreSQL, elle est livrée avec les dernières données de fuseau horaire au moment de la publication. Lorsque vous utilisez les dernières versions de RDS pour PostgreSQL, vous disposez de données de fuseau horaire récentes provenant de RDS. Pour vous assurer que votre instance de base de données dispose de données de fuseau horaire récentes, nous vous recommandons de passer à une version supérieure du moteur de base de données. Vous ne pouvez pas modifier les tables de fuseau horaire des instances de base de données PostgreSQL manuellement. RDS ne modifie ni ne réinitialise les données de fuseau horaire des instances de base de données en cours d'exécution. Les nouvelles données de fuseau horaire ne sont installées que lorsque vous effectuez une mise à niveau de la version du moteur de base de données. |
| `track_activities` | Répartition dynamique | Collecte des informations sur les commandes en cours d'exécution. |
| `track_activity_query_size` | Statique | Définit la taille réservée pour pg\$1stat\$1activity.current\$1query, en octets. |
| `track_counts` | Répartition dynamique | Active la collecte de statistiques sur l'activité de la base de données. |
| `track_functions` | Répartition dynamique | Active la collecte de statistiques au niveau de la fonction sur l'activité de la base de données. |
| `track_io_timing` | Répartition dynamique | Collecte des statistiques temporelles sur l' I/O activité de la base de données. |
| `transaction_deferrable` | Répartition dynamique | Indique si une transaction sérialisable en lecture seule doit être différée jusqu'à ce qu'elle puisse être démarrée sans échec de sérialisation possible. |
| `transaction_isolation` | Répartition dynamique | Définit le niveau d’isolement des transactions actuelles. |
| `transaction_read_only` | Répartition dynamique | Définit le statut en lecture seule des transactions actuelles. |
| `transform_null_equals` | Répartition dynamique | Traite l'expression =NULL en tant que IS NULL. |
| `update_process_title` | Répartition dynamique | Met à jour le titre du processus pour indiquer la commande SQL active. |
| `vacuum_cost_delay` | Répartition dynamique | Valeur du coût de délai du processus vacuum en millisecondes. |
| `vacuum_cost_limit` | Répartition dynamique | Coût cumulé qui provoque l'endormissement du processus vacuum. |
| `vacuum_cost_page_dirty` | Répartition dynamique | Coût du processus vacuum pour une page salie par le processus vacuum. |
| `vacuum_cost_page_hit` | Répartition dynamique | Coût du processus vacuum pour une page trouvée dans le cache des tampons. |
| `vacuum_cost_page_miss` | Répartition dynamique | Coût du processus vacuum pour une page non trouvée dans le cache des tampons. |
| `vacuum_defer_cleanup_age` | Répartition dynamique | Nombre de transactions pendant lesquelles le processus vacuum et le nettoyage hot seront reportés à plus tard, le cas échéant. |
| `vacuum_freeze_min_age` | Répartition dynamique | Âge limite auquel le processus vacuum doit figer une ligne de tableau. |
| `vacuum_freeze_table_age` | Répartition dynamique | Âge auquel le processus vacuum effectue une analyse complète de la table pour figer des lignes. |
| `wal_buffers` | Statique | Définit le nombre de tampons de page de disque dans la mémoire partagée pour les WAL. |
| `wal_writer_delay` | Répartition dynamique | Délai d'inactivité de l'enregistreur des WAL entre les actions de vidage WAL. |
| `work_mem` | Répartition dynamique | Définit la quantité maximum de mémoire que peuvent utiliser les espaces de travail des requêtes. |
| `xmlbinary` | Répartition dynamique | Définit la façon dont les valeurs binaires doivent être codées en XML. |
| `xmloption` | Répartition dynamique | Définit si des données XML dans des opérations d'analyse ou de sérialisation implicites doivent être considérées comme des documents ou des fragments de contenu. |
Amazon RDS utilise les unités PostgreSQL par défaut pour tous les paramètres. Le tableau suivant présente l'unité par défaut PostgreSQL pour chaque paramètre.
| Nom du paramètre | Unit |
| --- | --- |
| `archive_timeout` | s |
| `authentication_timeout` | s |
| `autovacuum_naptime` | s |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | s |
| `checkpoint_warning` | s |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 Ko |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | minutes |
| `log_rotation_size` | Ko |
| `log_temp_files` | Ko |
| `maintenance_work_mem` | Ko |
| `max_stack_depth` | Ko |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | s |
| `pre_auth_delay` | s |
| `segment_size` | 8 Ko |
| `shared_buffers` | 8 Ko |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | Ko |
| `tcp_keepalives_idle` | s |
| `tcp_keepalives_interval` | s |
| `temp_file_limit` | Ko |
| `work_mem` | Ko |
| `temp_buffers` | 8 Ko |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 Ko |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | s |