- Amazon Relational Database Service

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.

La postgres_get_av_diag() fonction 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 NOTICE suivant, cela indique que 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'identifiant de transaction est le plus ancien

La postgres_get_av_diag() fonction fournit le résultat le plus précis lorsqu'elle est connectée à la base de données dont l'identifiant de transaction est le plus ancien. La base de données dont l'âge de l'identifiant de transaction est le plus ancien indiqué par postgres_get_av_diag() sera différente de « my_database » dans votre cas. Si vous n'êtes pas connecté à la bonne base de données, le 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.

La connexion à la base de données dont l'âge de transaction est le plus élevé est importante 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 être trompeur. La connexion à la base de données appropriée garantit l'identification précise du bloqueur de table temporaire.

  • Diagnostic des aspirateurs lents : Les métadonnées de l'index et les informations relatives au nombre de tables sont spécifiques à la base de données et sont nécessaires pour diagnostiquer les problèmes d'aspiration lente.

La base de données avec la transaction la plus ancienne par âge se trouve sur une base de données rdsadmin ou template0

Dans certains cas, les rdsadmin template0 bases de données peuvent être identifiées comme étant celles dont l'identifiant de transaction est le plus ancien. Dans ce cas, postgres_get_av_diag() émettra l'AVIS 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 l'un rdsadmin ou l'autretemplate0, 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 template0 données rdsadmin ou la base de données contienne un bloqueur supérieur.

Lorsqu'un aspirateur agressif est déjà en marche

La postgres_get_av_diag() fonction est conçue pour signaler lorsqu'un processus de vide agressif est en cours d'exécution, mais elle ne déclenche cette sortie que lorsque le vide est actif pendant au moins 1 minute. Ce délai intentionnel contribue à réduire les risques de faux positifs. En attendant, la fonction garantit que seuls les aspirateurs efficaces et significatifs sont signalés, ce qui permet une surveillance plus précise et plus fiable de l'activité du vide.

La postgres_get_av_diag() fonction génère l'AVIS suivant lorsqu'elle détecte un ou plusieurs aspirateurs agressifs en cours de réalisation.

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.

Comme indiqué dans l'AVIS, continuez à surveiller les performances de l'aspirateur. Pour plus d'informations sur l'aspirateur agressif, voir Un aspirateur agressif (pour éviter tout enroulement) fonctionne

Lorsque l'aspirateur automatique est désactivé

La postgres_get_av_diag() fonction génère le 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.

Autovacuum est une fonctionnalité essentielle de votre instance de base de données PostgreSQL RDS pour PostgreSQL qui garantit le bon fonctionnement de la base de données. Il supprime automatiquement les anciennes versions de lignes, récupère de l'espace de stockage et évite le surpeuplement des tables, ce qui contribue à garantir l'efficacité des tables et des index pour des performances optimales. En outre, il protège contre l'encapsulation des identifiants 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 le garder allumé en permanence.

Note

La désactivation de l'aspirateur automatique n'arrête pas les aspirateurs agressifs. Elles se produiront toujours une fois que vos tables auront atteint le autovacuum_freeze_max_age seuil.

Le nombre de transactions restantes est extrêmement bas

La postgres_get_av_diag() fonction génère l'AVIS suivant lorsqu'un aspirateur enveloppant est imminent. Cet AVIS 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.

Votre action immédiate est requise pour éviter les interruptions de service de la base de données. Vous devez surveiller de près vos opérations d'aspiration 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.