Partager l'article ! 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" ...
Pour être informé des derniers articles, pensez à vous inscrire à la newsletter. Par ailleurs, n'hésitez pas à faire part
de vos remarques, suggestions,...
LAO.
proposition@lao-dba.com
LAO.
proposition@lao-dba.com
Jeudi 9 octobre 2008
4
09
/10
/Oct
/2008
23:24
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.
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.
Commentaires
Archives
- août 2011 (1)
- juin 2010 (1)
- mai 2010 (1)
- février 2010 (1)
- juin 2009 (1)
- mars 2009 (1)
- février 2009 (6)
- janvier 2009 (6)
- décembre 2008 (10)
- novembre 2008 (15)
- octobre 2008 (17)
Catégories
- RMAN (1)
- FLASHBACK (1)
- ORACLE NET (1)
- PERFORMANCE (12)
- Administration (23)
- ORACLE 11 (7)
- SQL DEVELOPER (1)
- Dataguard (4)
- Clonage de base (3)
- RAC (1)
Recherche
Articles récents
- Envie d'aventures...
- Administration - Export et compression à la volée
- RAC - Passer une base en archivelog
- Oracle 11 & Dataguard active
- Administration - Opérations longues
- Historique volumétrie tablespace
- Dataguard - Physical Standby - Mise en place
- Dataguard - Présentation
- Connaitre la version Oracle qui tourne (32 ou 64 bit)
- Dataguard - Version standard - Mise en place d'une base "standby" (2)
Calendrier
| Février 2012 | ||||||||||
| L | M | M | J | V | S | D | ||||
| 1 | 2 | 3 | 4 | 5 | ||||||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 | ||||
| 13 | 14 | 15 | 16 | 17 | 18 | 19 | ||||
| 20 | 21 | 22 | 23 | 24 | 25 | 26 | ||||
| 27 | 28 | 29 | ||||||||
|
||||||||||
Profil
- LAO
-
- Homme
- 06/05/1972
- IDF
- DBA
C'est corrigé !
Si tu veux des explications tu peux toujours demander à GIGOT !
LAO.
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.
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...
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.
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.
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.
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