Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Récupération de l’espace de table via une opération de vacuum
PostgreSQL Multiversion Concurrency Control (MVCC) permet de préserver l’intégrité des données en enregistrant une copie interne des lignes mises à jour ou supprimées jusqu’à ce qu’une transaction soit validée ou annulée. Ces copies, également appelées *tuples*, peuvent provoquer un gonflement de la table si elles ne sont pas nettoyées régulièrement. Les instances PostgreSQL ordonnent les transactions en fonction de leur transaction IDs, et PostgreSQL utilise le MVCC basé sur l'ID de transaction pour contrôler la visibilité des tuples et isoler les transactions. Chaque transaction établit un instantané des données, et chaque tuple possède une version. L’instantané et la version sont tous deux basés sur l’ID de transaction.
Pour nettoyer les données, l’utilitaire `VACUUM`exécute quatre fonctions clés dans PostgreSQL :
+ `VACUUM` : supprime les versions de ligne expirées, rendant ainsi l’espace disponible pour une réutilisation.
+ `VACUUM FULL` : permet une défragmentation complète en supprimant les lignes inactives et en compactant les tables, en réduisant la taille et en augmentant l’efficacité.
+ `VACUUM FREEZE` : protège contre les problèmes de bouclage des ID de transaction en marquant les anciennes versions de lignes comme étant bloquées.
+ `VACUUM ANALYZE` : supprime les versions des lignes inactives et met à jour les statistiques de planification des requêtes de la base de données. Il s’agit d’une combinaison des fonctions `VACUUM` et `ANALYZE`. Pour plus d’informations sur le fonctionnement de `ANALYZE` dans Aurora PostgreSQL Limitless Database, consultez [ANALYSE](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.ANALYZE).
Comme dans MVCC, l’opération de vacuum dans Aurora PostgreSQL est basée sur l’ID de transaction. Si une transaction est en cours lorsque le l’opération de vacuum commence, les lignes qui sont toujours visibles pour cette transaction ne sont pas supprimées.
Pour plus d’informations sur l’utilitaire `VACUUM`, consultez [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) dans la documentation PostgreSQL. Pour plus d’informations sur la prise en charge de `VACUUM` dans Aurora PostgreSQL Limitless Database, consultez [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM).
**Topics**
+ [AUTOVACUUM](#limitless-autovacuum)
+ [Vacuum basé sur le temps dans Aurora PostgreSQL Limitless Database](#limitless-vacuum.time-based)
+ [Utilisation des statistiques de base de données pour l’opération de vacuum](#limitless-vacuum.stats)
+ [Différences dans le comportement des opérations de vacuum entre Aurora PostgreSQL et Aurora PostgreSQL Limitless Database](#limitless-vacuum-limitations)
## AUTOVACUUM
Aurora PostgreSQL utilise les utilitaires `VACUUM` et `AUTOVACUUM` pour supprimer les tuples inutiles. Le mécanisme sous-jacent de l’`AUTOVACUUM` et du `VACUUM` manuel sont les mêmes ; la seule différence réside dans l’automatisation.
`AUTOVACUUM` dans Aurora PostgreSQL et Aurora PostgreSQL Limitless Database est une combinaison des utilitaires `VACUUM` et `ANALYZE`. `AUTOVACUUM` détermine les bases de données et les tables à nettoyer, selon une règle prédéfinie, telle que le pourcentage de tuples inactifs et le nombre d’insertions.
Par exemple, `AUTOVACUUM` « se réveille » périodiquement pour effectuer un nettoyage. L’intervalle est contrôlé par le paramètre `autovacuum_naptime`. La valeur par défaut est de 1 minute. Les valeurs par défaut des paramètres de configuration `AUTOVACUUM` et `VACUUM` sont les mêmes dans Aurora PostgreSQL Limitless Database et Aurora PostgreSQL.
Le démon `AUTOVACUUM`, s’il est activé, émet automatiquement des commandes `ANALYZE` chaque fois que le contenu d’une table a suffisamment changé. Dans Aurora PostgreSQL Limitless Database, `AUTOVACUUM` émet une command `ANALYZE` sur les routeurs et les partitions.
Pour plus d’informations sur le démon `AUTOVACUUM` et les paramètres de stockage des tables associés à `AUTOVACUUM`, consultez [Le démon autovacuum](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM ) et les [Paramètres de stockage](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) dans la documentation PostgreSQL.
## Vacuum basé sur le temps dans Aurora PostgreSQL Limitless Database
Aurora PostgreSQL Limitless Database est un système distribué, ce qui signifie que plusieurs instances peuvent être impliquées dans une transaction. Par conséquent, la visibilité basée sur l’ID de transaction ne s’applique pas. La base de données Aurora PostgreSQL Limitless *utilise* plutôt une visibilité basée sur le temps, car les IDs transactions ne sont pas « unifiées » entre les instances, mais le temps peut être « unifié » entre les instances. Chaque instantané de transaction et chaque version de tuple se réfèrent au temps plutôt qu’à l’ID de transaction. Plus précisément, chaque instantané de transaction est associé à une heure de début, et chaque tuple enregistre une heure de création (au moment d’une `INSERT` ou d’une `UPDATE`) ainsi qu’une heure de suppression (au moment d’une `DELETE`).
Pour maintenir la cohérence des données entre les instances du groupe de partitions de base de données, Aurora PostgreSQL Limitless Database doit s’assurer que l’opération de vacuum ne supprime aucun tuple encore visible pour les transactions actives du groupe de partitions de base de données. Par conséquent, les opérations de vacuum sont également basées sur le temps dans Aurora PostgreSQL Limitless Database. D’autres aspects de `VACUUM` demeurent inchangés, notamment le fait que, pour exécuter `VACUUM` sur une table donnée, l’utilisateur doit disposer d’un accès à cette table.
**Note**
Il est vivement déconseillé de laisser les transactions ouvertes pendant de longues périodes.
Les opérations de vacuum basées sur le temps consomme plus de mémoire que celles qui sont basées sur l’ID de transaction.
L’exemple suivant illustre le fonctionnement des opérations de vacuum basées sur le temps.
1. Une table client est répartie sur quatre partitions.
1. La transaction 1 commence par une lecture répétable et ne cible qu’une seule partition (partition 1). Cette transaction reste ouverte.
La transaction 1 est plus ancienne que toute autre transaction lancée après elle.
1. La transaction 2 démarre plus tard et supprime tous les tuples d’une table, puis valide la transaction.
1. Si l’`AUTOVACUUM` ou le `VACUUM` manuel tente de nettoyer les tuples inactifs (résultant de la transaction 2), rien n’est supprimé.
Cela est vrai non seulement pour la partition 1, mais également pour les partitions 2 à 4, car la transaction 1 peut toujours avoir besoin d’accéder à ces tuples. Ils sont toujours visibles pour la transaction 1 grâce au MVCC.
La dernière étape est réalisée par le biais d’une synchronisation, afin que toutes les partitions soient informées de la transaction 1, même si celle-ci ne les concerne pas toutes.
## Utilisation des statistiques de base de données pour l’opération de vacuum
Pour obtenir des informations sur les tuples susceptibles de nécessiter un nettoyage, utilisez la vue [limitless\_stat\_all\_tables](limitless-monitoring-views.md#limitless_stat_all_tables), qui fonctionne de la même manière que [pg\_stat\_all\_tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW). L’exemple suivant illustre l’interrogation de la vue.
```
SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';
```
De même, pour les statistiques de base de données, utilisez [limitless\_stat\_database](limitless-monitoring-views.md#limitless_stat_database) au lieu de [pg\_stat\_database](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW), et [limitless\_stat\_activity](limitless-monitoring-views.md#limitless_stat_activity) plutôt que [pg\_stat\_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW).
Pour vérifier l’utilisation du disque de la table, utilisez la fonction [limitless\_stat\_relation\_sizes](limitless-monitoring-functions.md#limitless_stat_relation_sizes), qui fonctionne de la même manière que [pg\_relation\_size](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-DBOBJECT). Les exemples suivants illustrent l’interrogation de la fonction.
```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer');
```
Pour suivre la progression d’une opération `VACUUM` sur Aurora PostgreSQL Limitless Database, utilisez la vue [limitless\_stat\_progress\_vacuum](limitless-monitoring-views.md#limitless_stat_progress_vacuum) au lieu de [pg\_stat\_progress\_vacuum](https://www.postgresql.org/docs/15/progress-reporting.html#VACUUM-PROGRESS-REPORTING). L’exemple suivant illustre l’interrogation de la vue.
```
SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
```
Pour plus d’informations, consultez [Vues d’Aurora PostgreSQL Limitless Database](limitless-monitoring-views.md) et [Fonctions d’Aurora PostgreSQL Limitless Database](limitless-monitoring-functions.md).
## Différences dans le comportement des opérations de vacuum entre Aurora PostgreSQL et Aurora PostgreSQL Limitless Database
Les différences suivantes distinguent également Aurora PostgreSQL et Aurora PostgreSQL Limitless Database en ce qui concerne le processus de vacuum :
+ Aurora PostgreSQL `VACUUM` exécute des opérations sur les IDs transactions jusqu'à la plus ancienne transaction en cours. S’il n’y a aucune transaction en cours dans la base de données, `VACUUM` exécute l’opération jusqu’à la dernière transaction.
+ Aurora PostgreSQL Limitless Database synchronise le plus ancien instantané toutes les 10 secondes. Par conséquent, `VACUUM` peut ne pas exécuter l’opération sur les transactions ayant été effectuées au cours des 10 dernières secondes.
Pour plus d’informations sur la prise en charge de `VACUUM` dans Aurora PostgreSQL Limitless Database, consultez [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM) dans le [Référence Aurora PostgreSQL Limitless DatabaseRéférence Limitless Database](limitless-reference.md).