Re: revisit old question about listener log

"EdStevens" <quetico_man_at_yahoo.com> wrote in message news:1157663725.883351.47530_at_m79g2000cwm.googlegroups.com...
>I am reviewing a shell script I wrote a few years ago to do regular
> houskeeping on the various log files on my db servers, and am looking
> for ways to make a few improvements.
>
> First, I have a chunk of code that renames alert_<sid>.log, retaining
> 'n' generations named 'alert_<sid>.log.1 through 'alert_<sid>.log.n'
> In its original incarnation, I followed this renaming with an in-line
> sqlplus script to 'alter system switch logfile'. This was done simply
> to force an alert log entry to get the new alert log started, instead
> of waiting for the next event to occur naturally. I don't see any real
> problem with this, but wouldn't mind using a more benign command (than
> switching logfiles) to accomplish the same thing.
>
> Second, I do the same thing to the listener log. However, in that case
> it appears that the listener is holding the inode instead of the file
> name (I'm beyond my knowledge here). The evidence is that if I rename
> listener.log to listener.log.1, new entries are written to
> listener.log.1 - the only way I could get a new listener.log was to
> stop and restart the listener. That wasn't a problem in my old
> environment, but now we have multiple DB's and using dynamic
> registration, the listener could end up 'blind' to a database for the
> few minutes it takes for the DB to re-register with the listener. I
> could hard-code the sid list in the listener.ora, but wondering if
> there might be another approach that doesn't require bouncing the
> listener at all.
>
> Thanks.
>

Have you tried :

$ cp -p listener.log listener.log.1
$ cat /dev/null > listener.log

Matthias Received on Fri Sep 08 2006 - 14:51:17 CDT