Re: revisit old question about listener log

EdStevens wrote:
> 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.

Hi Ed.

If you're on 10g, the log_file can be changed on the fly, provided that admin_restrictions has not been set, e.g.:

LSNRCTL> set log_file foo

hth.

-bdbafh Received on Thu Sep 07 2006 - 17:07:44 CDT