Oracle RDS : récupérer les tracefiles, comment faire ?

jeudi, janvier 10, 2019
By Emmanuel RAMI in AWS (erami@capdata-osmozium.com) [3 article(s)]

 

                                            Comme nous le savons, l’utilisation de Oracle RDS sur AWS est une solution Platform As A Service (PaaS). Il n’y a donc aucune possibilité de se connecter directement sur le(s) seveur(s) ou sont hébergées les bases de données Oracle, et d’aller lire ou récupérer via scp ces fichiers .


Nos seules informations connues sont les points d’entrée ainsi que le port liés à une base et qui constituent les informations qui nous permettront de construire notre entrée dans TNSNAMES.ORA :

Sur le fichier TNSNAMES.ORA, notre entrée base capdatadb :




Un client Oracle installé, avec l’outil SqlPlus, sera utilisé afin d’interroger les packages relatifs à RDS , “RDSADMIN”.

Comme on le sait, l’utilisation d’ordre de type “ALTER SYSTEM” est proscrit sur Oracle RDS, nous pourrons en revanche, user des “ALTER SESSION” :

Voir les fichiers de trace

Nous aurons la possibilité, grâce à des commandes SQL, de voir l’ensemble des fichiers de trace générés dans l’espace “bdump” configuré en base et dédié à ceux ci.
On sait qu’ils sont dans un filesystem /rdsdbdata, mais qui est propre au serveur défini par Amazon. 

Avant de pouvoir lire ce qu’il y’a dans le répertoire, on doit, tout d’abord, actualiser les informations:

A partir de la, on pourra lire son contenu,  par exemple s’il l’on souhaite lire les fichiers trace du jour  :

 

Générer et récupérer des traces 

Il sera possible d’interfacer avec le package “rdsadmin”, des ordres de trace de type ‘oradebug’

Générer un hanganalyze
Générer un systemstate dump

Afin de tracer une session précise, on utilisera les mêmes procédés que ce qui se fait sur une base on-premise. Par exemple, on pourra utiliser DBMS_MONITOR comme package référence pour tracer une session utilisateur :

La session utilisateur à tracer est portée par le user MANUELO

Soit 

Une fois connecté avec le schéma utilisateur concerné, on génère un peu d’activité :

On stoppe la trace , connecté via un schéma ayant des droit execute sur dbms_monitor.

On repère le numéro du process OS généré par cette session utilisateur :

Et on interroge, via RDSADMIN la trace généré par le processus 20019 :

On retrouve notre trace parmi le répertoire

Puis, pour lire son contenu, on inscrira ce fichier au sein d’une vue appelé “tracefile_table”.

Génération de la vue tracefile_table à partir de ce fichier

On interroge la vue tracefile_table tout en ayant pris soin de faire un spool dans un fichier auparavant :

Notre trace ainsi généré sur un disque local.




On pourra utiliser TKPROF pour générer et analyser cette trace 

 

 

Purge des fichiers trace 

Afin de purger cette trace, et d’autres également, c’est la procédure 
manage_tracefiles.purge_tracefiles” du package rdsadmin qui sera proposé :

Par défaut, les fichiers trace générés par Oracle sous ce répertoire sont conservés 7 jours. Pensez donc à conserver vos traces en local si besoin.

Il sera possible, cependant, de changer cette rétention via “rdsadmin_util.set_configuration(‘tracefile retention’,<number>)

 

Utilisation via AWS CLI

Pour la gestion de ses nombreux services, AWS met à diposition une API nommé AWS CLI afin de pouvoir effectuer en mode “scripting” de nombreuses opérations sur les composants (ec2, s3, rds….).

Dans notre cas précis, nous pourrons récupérer les logs bases de données Oracle via cette API à partir de simples commandes.

Par exemple, si nous souhaitons récupérer le fichier “alert.log” de la base, nous pourrions utiliser le package ‘rdsamin’ et la procédure :

exec rdsadmin.manage_tracefiles.set_tracefile_table_location();

Mais avec aws cli, on écrira directement via une commande cmd. Les options sont describe-db-log-files pour chercher le fichier log selon le critère choisi. Puis download-db-log-file-portion pour récupérer tout ou une partie de la trace.

Ainsi, l’opération de recherche de l’alert.log se fera via la méthode suivante :

On notera que le résultat de l’option describe-db-log-files apparait sous un format JSON. Les autres paramètres sont –db-instance-identifier pour le nom de la base et –filename-contains pour le critère lié au nom de la trace à rechercher. La région devra être défini si celle ci n’a pas été configurée lors de la commande “aws configure“.

Nous irons chercher le fichier “trace/alert_CAPDATA.log”.  On prendra soit les dernières lignes du fichier via la commande :

Soit le fichier intégral:




Dans le cas du fichier intégral, nous avons ajouter l’option –starting-token 0 afin de débuter à la toute première ligne du fichier. Le paramètre –output permet de choisir le format pour le fichier, ici format texte.

Le fichier “CAPDATA_alert_log_FULL.trc” est maintenant présent sur le disque local, et éditable via un traitement de texte classique.

 

Emmanuel RAMI

Continuez votre lecture sur le blog :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Tags: , ,

Leave a Reply