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. # Utilisation de l'extension log\$1fdw pour accéder au journal de base de données à l'aide de SQL L'instance de base de données RDS for PostgreSQL prend en charge l'extension `log_fdw`, qui vous permet d'accéder au journal de votre moteur de base de données à l'aide d'une interface SQL. L'extension `log_fdw` fournit deux fonctions qui facilitent la création de tables source pour les journaux de base de données : + `list_postgres_log_files` – Répertorie les fichiers dans le répertoire du journal de base de données et indique la taille des fichiers en octets. + `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)` – Crée un tableau source pour le fichier spécifié dans la base de données actuelle. Toutes les fonctions créées par `log_fdw` appartiennent à `rds_superuser`. Les membres du rôle `rds_superuser` peuvent accorder l'accès à ces fonctions à d'autres utilisateurs de base de données. Par défaut, les fichiers journaux sont générés par Amazon RDS au format `stderr` (erreur standard), comme spécifié dans le paramètre `log_destination`. Il n'y a que deux options pour ce paramètre, `stderr` et `csvlog` (valeurs séparées par des virgules, CSV). Si vous ajoutez l'option `csvlog` au paramètre, Amazon RDS génère les journaux `stderr` et `csvlog`. Cela peut affecter la capacité de stockage de votre cluster de base de données. Vous devez donc connaître les autres paramètres qui affectent la gestion des journaux. Pour de plus amples informations, veuillez consulter [Définition de la destination du journal (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format). L'un des avantages de la génération de journaux `csvlog` est que l'extension `log_fdw` vous permet de créer des tables externes dont les données sont soigneusement réparties en plusieurs colonnes. Pour ce faire, votre instance doit être associée à un groupe de paramètres de base de données personnalisé afin que vous puissiez modifier le paramètre de `log_destination`. Pour plus d'informations sur la manière de procéder, consultez [Utilisation de paramètres sur votre instance de base de données RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md). L'exemple suivant suppose que le paramètre `log_destination` comprend le champ `cvslog`. **Pour utiliser l'extension log\$1fdw** 1. Installez l’extension `log_fdw`. ``` postgres=> CREATE EXTENSION log_fdw; CREATE EXTENSION ``` 1. Créez le serveur de journal en tant qu'encapsuleur de données externes. ``` postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw; CREATE SERVER ``` 1. Sélectionnez l'ensemble des fichiers journaux d'une liste. ``` postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1; ``` Voici un exemple de réponse. ``` file_name | file_size_bytes ------------------------------+----------------- postgresql.log.2023-08-09-22.csv | 1111 postgresql.log.2023-08-09-23.csv | 1172 postgresql.log.2023-08-10-00.csv | 1744 postgresql.log.2023-08-10-01.csv | 1102 (4 rows) ``` 1. Créez une table avec une seule colonne « log\$1entry » pour le fichier sélectionné. ``` postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log', 'log_server', 'postgresql.log.2023-08-09-22.csv'); ``` La réponse ne fournit aucun détail autre que l'existence de la table. ``` ----------------------------------- (1 row) ``` 1. Sélectionnez un exemple de fichier journal. Le code suivant récupère l'heure du journal et la description du message d'erreur. ``` postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1; ``` Voici un exemple de réponse. ``` log_time | message ----------------------------------+--------------------------------------------------------------------------- Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0 Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578 Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0 Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1 (7 rows) ```