Silverlake - Le blog de ADIMCOR

Introduction

La version 11g introduit une nouvelle infrastructure pour le diagnostic des problèmes, Automatic Diagnostic Repository.

ADR se présente sous la forme d'une arborescence de répertoires qui stocke de manière centralisée les données de diagnostic.

Il existe 2 concepts :

• Les problèmes : Erreur Internes ORA-00600, OS ORA-07445...Chaque problème inclut un code ORA...et éventuellement des paramètres supplémentaires.
• Les incidents : Il s'agit d'une occurrence d'un problème, chaque incident porte un numéro

Le référentiel ADR

Stocke tous les fichiers de traces et journaux pour l'ensemble des produits s'exécutant sur le serveur.

• BD,
• listener...

Défini par le paramètre DIAGNOSTIC_DEST, sa valeur par défaut est $ORACLE_BASE si cette variable est définie, sinon $ORACLE_HOME/log

La racine de ce répertoire se nomme diag et contient un sous répertoire par produit Oracle

• rdbms → BD, ce répertoire contient un sous répertoire par instance de base de données.
• tnslsnr→ listener...

Les principaux répertoires sont :

• Alert : Fichier d'alerte format XML
• Incident : Fichiers relatifs aux incidents
• Trace : Fichier de trace des processus et format texte du fichier d'alerte bien connu ( alert.log )

Les anciens paramètres BACKGROUND_DUMP_DEST et USER_DUMP_DEST sont dépréciés.

Fichiers d'alertes et de traces

Oracle maintient un fichier d’alerte dans lequel il écrit des messages d’information ou d’erreurs sur la vie de la base de données :

• Création de la base de données,
• Démarrages et arrêts,
• Modifications de la structure (tablespaces, fichiers de données),
• Erreurs internes (ORA-00600, ORA-07445),
• Erreurs de bloc corrompu (ORA-01578),
• Problèmes relatifs à l’écriture ou à l’archivage des fichiers de journalisation.

En complément, lorsqu’un processus rencontre un problème, il écrit des informations dans un fichier de trace.

Le fichier d'alerte est disponible sous deux formats : texte et XML.

• Le nom du fichier d’alerte xml est de la forme : log.xml ( sous répertoire alert )
• Le nom du fichier d’alerte texte est de la forme : alert_<SID>.log ( sous répertoire trace )

Processus d'arrière plan ( sous répertoire trace )

• Le nom des fichiers de trace des processus d’arrière-plan est de la forme : <sid>_<nom_processus>_<id_processus>.trc.
• Le nom des fichiers de trace des processus serveur est de la forme : <sid>_ora_<id_processus>.trc.

ADRCI

Automatic Diagnostic Repository Command Interpreter. Outil ligne de commande et interactif pour gérer les erreurs Oracle. Dans ce billet nous allons voir les fonctionnalités suivantes :

• Visualiser le fichier alert.log
• Gestion des problèmes et des incidents
• Création de packages zippés pour envoi au support Oracle.
• Purge des fichiers de traces.

Pour la rédaction de cet exemple, je me suis inspiré de l'article anglais suivant

Un exemple de dysfonctionnement

Se connecter en sys

sqlplus sys/manager11@red as sysdba
SQL> create user alice identified by ecila;
SQL> grant connect,resource to alice;
SQL> connect alice/ecila@red
SQL> create table t ( n number );
SQL> select object_id from user_objects;

Noter le numéro retourné par la requête ( exemple 17322 ) et se reconnecter sys

SQL>connect sys/manager11@red as sysdba
SQL>update tab$ set cols=2 where obj#=17322;
SQL>commit;

Cet update fausse le dictionnaire des données, à ne pas faire en production !

Tester le dysfonctionnement

Dans un premier temps purger la shared_pool afin de vider le dictionnary cache

SQL> alter system flush shared_pool;

Se reconnecter alice

SQL> connect alice/eciala@red
SQL> select * from t;
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 2236
Session ID: 29 Serial number: 9

Sortir du SQL par exit

Utilisation de adrci

Au niveau du shell, lancer adrci, puis la commande show home

adrci>show home
ADR Homes: 
diag/tnslsnr/SILVERLAKE/listener
diag/rdbms/red/RED

Il existe plusieurs ADR directory, relatives ici au listener ( diag/tnslsnr ) et au moteur de Oracle ( diag/rdbms ). L'erreur s'est produite au niveau du moteur Oracle donc rdbms. Toujours sous adrci, se positionner dans la bonne arborescence.

adrci> set home diag/rdbms/red/RED

Visualiser la fin du fichier alert.log

adrci>show alert -tail

Identifier le problème

ADR défini les concepts de problème et d'incident.

Un incident est une occurrence d'un problème, ainsi si la même erreur se reproduit une seconde fois il n'y aura qu'un problème mais 2 incidents.

Ouvrir une seconde session et sous sqlplus en connexion alice et relancer la commande select * from t;

A nouveau sous adrci taper la commande show problem.

adrci>show problem

Relever le numero du problème ( problem_id ) exemple ici : 1

Identifier les incidents

adrci> show incident

Relever le numéro de l'incident, par exemple 12971.

Demander l'affichage de l'incident

adrci> show incident -mode detail -p "incident_id=12971"

Repérer le numéro du PROBLEM_ID et demander l'édition de la trace, il s'agit du nom de fichier de la dernière ligne.

adrci>show trace /u01/app/oracle/diag/rdbms/yoda/YODA/incident/incdir_12971/YODA_ora_2944_i12971.trc

Ceci lance dans vi le fichier trace, il est possible de retrouver la requête SQL en recherchant le mot "current_sql"

***** Current SQL Statement for this session (sql_id=89km4qj1thh13) *****
         select * from t
 ***** current_sql_statement *****

Envoyer les traces au support Oracle

Le problème généré dans cet exemple ne peut pas être facilement diagnostiqué, aussi il faut envoyer les traces au support oracle, pour cela créer un package zippé.

adrci>ips create package problem 1 correlate all
Created package 2 based on problem id 1, correlation level all

Selon le cas, le chiffre peut être différent de "1"

adrci>ips generate package 2 in "/home/oracle"
Generated package 2 in file /home/oracle/ORA7445qc_20120606132038_COM_1.zip, mode complete

Ici aussi, selon le cas le chiffre peut être différent de "2"

Envoyer le fichier zip à Oracle.

Il existe sous My Oracle Support une page spéciale pour ce type d'erruer ( ORA-00600 et ORA-07445 )

Purge des traces

Avec le temps il est nécessaire de purger les traces. La commande suivante liste l'ensemble des traces par ordre chronologique

adrci> show tracefile -rt

La durée de retention par défaut des traces ordinaires( switch redo log par exemple ) est de 720 heures, soit 30 jours. Pour les incidents 8760 heures soit un an

adrci>show control
SHORTP_POLICY : Traces ordinaires → 720
LONGP_POLICY : Incidents → 8760

Ceci se paramètre par les commandes suivantes :

adrci> set control (SHORTP_POLICY = 360) → 15 jours
adrci> set control (LONGP_POLICY = 2190) → 3 mois.

Pour purger les traces on indique le nombre de minutes, par exemple purger les traces de plus de 2 jours ( 2880 minutes )

adrci> purge -age 2880 -type trace