Purger le listener.log

Bonsoir,

Ce soir j'ai décidé de vous parler du listener.log. Pour information sur votre serveur vous avez un "LISTENER" qui écoute les demandes de connexion à la base ORACLE.
Le fichier listener.log conserve une trace de ces demandes. Cela peut être utile en cas de soucis.
Tout d'abord si vous voulez desactiver cette trace, il suffit d'ajouter dans le fichier listener.ora la ligne suivante.
TRACE_LEVEL_LISTENER=OFF 

Je rappelle que le fichier en question se trouve dans le répertoire /ORACLE_HOME/Network/admin
Le fichier Listener.log quand à lui se trouve dans le répertoire /ORACLE_HOME/Network/log

Si on ne surveille pas ce fichier, il risque de grossir de facon conséquente. Je pense notammenet aux applications web qui passent leur temps à demander des connexions et à les liberer. Il m'est arrivé de voir des fichiers listener.log de plusieurs GO.

En plus de prendre de la place inutilement sur le serveur, le fichier de log devient difficielment exploitable lorsque le besoin s'en fait sentir.

C'est pourquoi il est fortement conseillé de le purger de temps en temps.
Un moyen relativement simple consite à arreter le listener (LSNRCTL STOP dans une console DOS), puis de vider le fichier. Voir de le supprimer et de le recréer. Bien evidemment, il ne faut pas oublier de redémarrer le LISTENER (LSNRCTL START).

Inconvénient:Lorsque le listener est arrété, il devient impossible pour un poste client de se connecter (ORA - 12541 : TNS : Pas de processus d'écoute). Vous conviendrez assez facilement que cette méthode n'est pas élégante.

Autre méthode ne nécessitant pas de soucis pour les nouvelles connexions clientes

Exemple environnement linux:

LNSRCTL set log_file listener_temp
rm listener
LSNRCTL set log_file listener
rm listener_temp

La première ligne indique que le fichier de log est dorénavant listener_temp
On supprime l'ancien fichier (on peut également l'archiver)
Puis on réaffecte un fichier de log avec nom courrant (LSNRCTL set log_file listener)
Enfin, on supprime le fichier temporaire (rm listener_temp)

Remarque:

Dans un environnement windows, il suffit de remplacer rm par del

Dans l'idéal, il conviendrait de générer un indicateur qui prévienne que le listener.log a atteint une certaine taille afin de se positionner dans un mode "pro actif" plutôt que réactif.

A bientôt,

LAO.

 

Comments

[DROE]

Bonjour Lao,


Attention, je viens de m'apercevoir qu'en 10g c'est 


LOGGING_LISTENER = OFF  dans listener.ora et non TRACE.....=OFF


Sinon, tu n'ecris plus d'articles ?? 


Daniel

[LAO]

Hello; Merci pour l'info. pour les articles, l'envie est présente, mais je dois réussir à dégager du temps. @+

[Dominique Charbonnel]

Oui .... mais ... il y a un mais ... adrci> purge purge tout (les fichiers .xml entre autres) sauf le fichier listener.log qui n'est plus localisable via des commandes lsnrctl....


Bien sûr, on peut le localiser, mais pas de façon propre.


Dominique.

[LAO]

Oui ! Bon reste quand même le fait que des que log.xml atteint 10 MO un fichier log_1.xml (et ainsi de suite) est crée et le xml.log est automatiquement purgé.


LAO.

[Dominique Charbonnel]

Mais en 11g, cette méthode ne fonctionne plus...


Si qqun sait comment faire pour purger à la fois les log.xml et le listener.log, je suis preneur...

[LAO]

Hello... Effectivement en 11 ca ne fonctionne pas. Ca me donner l'occasion de faire un nouvel article (sino Metalink :453125.1). En fait sous Oracle 11, il y a ADR( Automatic Diagnostic
Repository) avec une api adrci et notamment une petite commande PURGE !


LAO.

[franck]

Salut LAO,

Juste une question, tu pourrais nous donner un cas concret où la lecture du log du listener pourrait nous permettre d'identifier un problème. En effet, pourquoi lire le log? Qu'est-ce qu'il peut nous apporter comme information et surtout quels types de problèmes il nous permettrait d'identifier?

Merci d'avance

[LAO]

Bonsoir Franck,

En effet, on ne vas pas lire un fichier de log. C'est un peu comme le journal d'evenement de windows. Je ne connais pas grand monde qui s'amuse à le lire. En revanche, lorsqu'il y a un souci on va
faire un petit tour dedans.
Prenons le cas d'une application web ou la gestion des exception est merdique (si si ca existe).
Les utilisateurs ont un plantage de l'application mais l'erreur n'est pas remontée. Si il s'avère que cela ressemble à un problème de connexion, on peut aller jeter un oeil dans le listener.log, et
l'on devrait avoir confirmation de cela via une ORA-xxxxx qui nous indiquera par exemple que le listener est tombé.
On peut également utiliser ce fichier pour savoir qui s'est connecté à la base (au moins l'IP) et à quelle heure. Dans une autre mesure, une application qui d'habitude fonctionne plutot bien en
terme de performance a justement une chute de perf entre 13 et 15 heures.
Le listener.log peut nous apprendre que durant cette periode le nombre de demande de connexion a triplé par rapport à la veille; ce qui peut être une piste pour nos problème de performance.
Il y a surement d'autres raisons ou le listener.log peut nous être utile. Cela peut faire l'objet d'un prochain article.

LAO.
 

[missmio]

Je dois avouer que je ne comprends pas le contenu de tes articles mais je te souhaite la bienvenue sur Overblog !!
Bise.

[LAO]

Merci beaucoup.
Si tu veux des explications tu peux toujours demander à GIGOT !
LAO.