Qui n’a jamais perdu du temps à récupérer les logs de tous les composants d’une architecture RAC (CRS, ASM, database) à des fins d’analyse ?
Arrivez-vous toujours à les récupérer sans en oublier au minimum un ?
Pour notre défense, Oracle ne nous facilite pas les choses en éparpillant les logs dans plusieurs niveaux de l’arborescence Grid et RDBMS.
A partir de la version 11.2.0.4, Oracle apporte un nouvel outil bien sympathique qui se charge d’effectuer ce travail de récupération de logs à notre place, le Trace File Analyzer Collector (TFA Collector).
TFA permet de récupérer à travers tous les noeuds de votre cluster les logs des différentes couches de votre architecture RAC :
- Système d’exploitation
- Oracle Clusterware
- Oracle Automatic Storage Management
- Oracle Database
Les avantages du TFA Collector sont multiples suite à un incident sur votre architecture RAC :
- Réduction de l’impact de l’incident de production en terme de coût
TFA Collector compresse le temps de collecte des différents logs, donc par conséquence le temps de résolution de l’incident. Aussi, nous n’avez plus besoin de vous poser la question « Mais où se trouve le fichier de log du daemon crsd ? »
- Optimisation des échanges avec le support Oracle
Lors de la création d’un Service Request, TFA Collector vous permet d’uploader un fichier zip contenant tous les logs des différents composants.
Vous évitez ainsi des échanges infructueux avec le support Oracle lié à l’absence d’un fichier de log.
Cet utilitaire présente aussi l’avantage d’être indépendant des binaires Grid et RDBMS. Ainsi, il peut être utilisé dans un contexte où la version des binaires Oracle (CRS, ASM , database) est comprise entre 10.2 et 12.1.
Par défaut, il est installé dans le GRID_HOME à partir du patchset 11.2.0.4.
Pour les versions antérieures, vous devez le télécharger sur My Oracle Support (TFA Collector) et effectuer l’installation en suivant la note Oracle 1513912.1.
Par contre, TFA Collector n’est pas disponible dans l’environnement Windows.
La collecte des logs s’effectue en ligne de commande (tfactl) depuis le noeud du cluster que vous choisissez.
Les logs des différents noeuds sont copiés simultanément dans le repository du noeud initiateur de la collecte.
Chaque nouveau noeud est identifié automatiquement par TFA.
Lors de la collecte des logs, tfactl s’identifie en tant que root auprès des autres noeuds du cluster en utilisant la clé SSH générée lors de l’installation du clusterware Oracle.
Vous devez donc exécuter tfactl en tant que root.
Par défaut, TFA collecte les informations datant de moins de 4 heures dans les différents logs.
[root@rac1 ~]# /opt/app/oracle/tfa/bin/tfactl diagcollect -all Collecting data for the last 4 hours for this component... Running an inventory clusterwide ... Run inventory completed locally ... Collection name tfa_mar_oct_8_19_50_11_CEST_2013.zip Sending diagcollect request to host : rac2 Getting list of files satisfying time range [Tue Oct 08 15:51:24 CEST 2013, Tue Oct 08 19:51:24 CEST 2013] ... Total Number of Files checked : 837 Total Size of all Files Checked : 296MB Number of files containing required range : 22 Total Size of Files containing required range : 105MB Number of files trimmed : 10 Total Size of data prior to zip : 64MB Saved 104MB by trimming files Zip file size : 284kB Total time taken : 64s Completed collection of zip files. Logs are collected to: /opt/app/oracle/tfa/repository/collection_mar_oct_8_19_50_11_CEST_2013_node_all/rac1.tfa_mar_oct_8_19_50_11_CEST_2013.zip /opt/app/oracle/tfa/repository/collection_mar_oct_8_19_50_11_CEST_2013_node_all/rac2.tfa_mar_oct_8_19_50_11_CEST_2013.zip
Lors d’un incident de production, vous pouvez préciser une fenêtre de temps facilitant l’analyse par la suite avec le format suivant MMM/DD/YYYY HH24:MI:SS
[root@rac1 ~]# /opt/app/oracle/tfa/bin/tfactl diagcollect -all -from "Oct/08/2013 19:30:00" -to "Oct/08/2013 20:00:00"
Vous pouvez filtrer les logs par composant et/ou par noeud lors de la récupération par TFA.
[root@rac1 ~]# /opt/app/oracle/tfa/bin/tfactl diagcollect -database TEST -node rac2 Collecting data for the last 4 hours for this component... Running an inventory in nodes : [rac2] Sending run inventory request to host : rac2 Collection name tfa_mar_oct_8_20_10_06_CEST_2013.zip Sending diagcollect request to host : rac2 Completed submission of diagcollection request. Logs are collected to: /opt/app/oracle/tfa/repository/collection_mar_oct_8_20_10_06_CEST_2013_node_rac2/rac2.tfa_mar_oct_8_20_10_06_CEST_2013.zip
La collecte des logs peut être déclenchée automatiquement par TFA lors d’un évènement :
- L’éviction d’un noeud du cluster ou d’une instance Oracle
- Une erreur ORA-00600 ou ORA-07445
[root@rac1 ~]# /opt/app/oracle/tfa/bin/tfactl set autodiagcollect=ON -c # pour tous les noeuds Successfully set autodiagcollect=ON .---------------------------------------------------. | Configuration Parameter | Value | +-----------------------------------------+---------+ | TFA version | 2.5.1.5 | | Automatic diagnostic collection | ON | | Trimming of files during diagcollection | ON | | Repository current size (MB) in rac1 | 1 | | Repository maximum size (MB) in rac1 | 187 | | Trace level | 1 | '-----------------------------------------+---------'
Pour cette configuration, se pose la question de la volumétrie du repository TFA sur le noeud où s’effectue la collecte.
TFA n’effectue pas de collecte automatique en dessous d’une fréquence de 5 minutes en cas d’erreurs répétées.
La taille maximale du repository peut être aussi configurée afin d’éviter la saturation du file system stockant le repository.
[root@rac1 ~]# /opt/app/oracle/tfa/bin/tfactl set reposizeMB=1024 The minimum recommended repository size is 10 GB. Do you wish to continue with the new size ? [Y/y/N/n] [N] y Successfully changed repository size .--------------------------------------------------------. | Repository Parameter | Value | +-----------------------+--------------------------------+ | Location | /opt/app/oracle/tfa/repository | | Old Maximum Size (MB) | 187 | | New Maximum Size (MB) | 1024 | | Current Size (MB) | 20 | | Status | OPEN | '-----------------------+--------------------------------'
Bien entendu, vous pouvez à tout moment purger les informations collectées depuis plus de n jours.
[root@rac1 ~]# /opt/app/oracle/tfa/bin/tfactl purge -older 1d List of files in the repository older than 1d: /opt/app/oracle/tfa/repository/collection_mer_oct_2_21_28_27_CEST_2013_node_all /opt/app/oracle/tfa/repository/collection_mer_oct_2_21_34_54_CEST_2013_node_rac2 /opt/app/oracle/tfa/repository/collection_dim_oct_6_20_18_00_CEST_2013_node_all /opt/app/oracle/tfa/repository/temp_1380742495970 Do you want to delete the above files. [Y|y|N|n] [Y]: y Deleting /opt/app/oracle/tfa/repository/collection_mer_oct_2_21_28_27_CEST_2013_node_all .....Deleted. Deleting /opt/app/oracle/tfa/repository/collection_mer_oct_2_21_34_54_CEST_2013_node_rac2 .....Deleted. Deleting /opt/app/oracle/tfa/repository/collection_dim_oct_6_20_18_00_CEST_2013_node_all .....Deleted. Deleting /opt/app/oracle/tfa/repository/temp_1380742495970 .....Deleted.
Je vous laisse désormais explorer cet outil facilitant l’administration des architectures cluster Oracle.
Selon moi, il présente beaucoup d’avantages qui justifie que l’on s’attarde dessus.