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’
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 :
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 :
Puis, pour lire son contenu, on inscrira ce fichier au sein d’une vue appelé “tracefile_table”.
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 :
- Oracle RDS : effectuer des backup RMAN en mode PaaS. (Emmanuel RAMI) [AWSNon classéOracle]
- Une solution de “Disaster Recovery” sous Oracle Standard Edition avec DBVisit standby (Emmanuel RAMI) [GénéralOracle]
- AWS Oracle RDS Read Replicas : un Active Dataguard en mode PaaS ? (Emmanuel RAMI) [AWSNon classéOracle]
- Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (1/2) (David Baffaleuf) [AWSMySQL]
- Export d’une VM d’un ESX vers une EC2 AWS (Emmanuel RAMI) [AWS]