Listener.log grows big

[omegamark]

My listener.log is growing every day .
To truncate the file I did
cat /dev/null >listener.log

but after that for every 10 mins I am getting a entry like service update ...Is this normal .In the old logfile I do not see this words ...

02-AUG-2002 11:38:40 * service_update * SPRDDEV * 0
02-AUG-2002 11:38:40 * service_update * SPRDUAT * 0
02-AUG-2002 11:38:40 * service_update * CMSDEV * 0
02-AUG-2002 11:38:40 * service_update * CAPSUAT * 0
02-AUG-2002 11:38:40 * service_update * CMSUAT * 0
02-AUG-2002 11:45:26 * service_update * CAPSDEV * 0
02-AUG-2002 11:48:40 * service_update * SPRDDEV * 0
02-AUG-2002 11:48:40 * service_update * SPRDUAT * 0
02-AUG-2002 11:48:40 * service_update * CMSDEV * 0
02-AUG-2002 11:48:40 * service_update * CAPSUAT * 0
02-AUG-2002 11:48:40 * service_update * CMSUAT * 0
02-AUG-2002 11:55:27 * service_update * CAPSDEV * 0
02-AUG-2002 11:58:41 * service_update * CMSDEV * 0
02-AUG-2002 11:58:41 * service_update * CAPSUAT * 0
02-AUG-2002 11:58:41 * service_update * CMSUAT * 0
02-AUG-2002 11:58:41 * service_update * SPRDUAT * 0
02-AUG-2002 11:58:41 * service_update * SPRDDEV * 0

[stecal]

Can you afford 10 seconds of downtime? lsnrctl stop, mv or rm the log file, then lsnrctl start.

[ramaral]

I think this is quite common. I get this in my RAC environment.

Look at this one -specifically Table 17.9 in the middle of the page):

http://otn.oracle.com/docs/products/...les.htm#444555

In terms of normal for your enviroment though...

Have you added anything new to the listener config within the last few months? Or maybe someone else has changed this?

Duration of the polling/service_update is similar to mine - @10 minutes per instance. This frequency is not tunable.

http://metalink.oracle.com/metalink/...1&p_showHelp=1

Question 2 of the FAQ touches on this.

In terms of rapid growth do you have an application that is constantly running (ie, 24x7) or that consistently times out? Check metalink as there a couple of queries on this specific topic - all of which point to an application trying to access the database and for various reasons creating multiple connections, closing them, then opening them again, or failing to connect properly, etc.

[Edited by ramaral on 08-02-2002 at 01:31 PM]

[marist89]

Originally posted by stecal
Can you afford 10 seconds of downtime? lsnrctl stop, mv or rm the log file, then lsnrctl start.

Youch! You'd be better off:
lsnrctl set log_status off
mv listener.log listener.log.old
lsnrctl set log_status on

This way, you don't have to bounce your listener.

[Shestakov]

check listener trace level.

$ lsnrctl

LSNRCTL> show trc_level
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxxxxxxx.com)(PORT=1521)))
LISTENER parameter "trc_level" set to off
The command completed successfully
LSNRCTL> trace user
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxxxxxx.com)(PORT=1521)))
Opened trace file: /opt/oracle/product/8.1.6/network/trace/listener.trc
The command completed successfully
LSNRCTL> show trc_level
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxxxxxx.com)(PORT=1521)))
LISTENER parameter "trc_level" set to user
The command completed successfully
LSNRCTL> trace off
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxxxxxx.com)(PORT=1521)))
The command completed successfully
LSNRCTL> show trc_level
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxxxxxx.com)(PORT=1521)))
LISTENER parameter "trc_level" set to off
The command completed successfully


if u don't want a lot of log records in listener.log file set:
LSNRCTL> trace off
or
LSNRCTL> trace user

[st2000]

Yes .. This is very normal.. I get more than 2mb of file generation of listener.log everyday and I just delete the same with lsnrctl stop, inode off, lsnrctl start or using /dev/null.

If you need more info, I guess Jeff answered clearly for the same Question I had on Jul 25th..

Thanks, ST2000