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. # Identification et résolution des bloqueurs de vacuum agressifs dans Aurora 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 établi 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 Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md) + [Fonctions de postgres\$1get\$1av\$1diag() dans Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md) + [Résolution des bloqueurs de vacuum identifiables dans Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md) + [Résolution des bloqueurs de vacuum non identifiables dans Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md) + [Résolution des problèmes de performance de vacuum dans Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md) + [Explication des messages NOTICE dans Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)