Re: Mangement of alert and listener logs - best practice?

If you are not going to shutdown the listener, then I think a good way is to do something like this (on Solaris):

cat listener.log | gzip -c -1 >
/dba/audit/listener.log_9.2.0_14_JAN_2003.gz ; echo "" > listener.log

Both commands should be done on the one line with the semicolon to make sure it happens as quickly as possible. You will have trouble if you try to move the listener.log without shutting down the listener.

If you shutdown and then restart the listener, it makes things easier and cleaner, but you won't be able to connect to the database for a few seconds or less. Something like this I think:

lsnrctl stop; mv listener.log listener.log.backup; lsnrctl start

The above will then create a new log file and then you can simply do whatever you want with the now cold listener.log.backup file. If you have a password set then you will need to take this into account and probably write a script for it.

"Ed Stevens" <nospam_at_noway.nohow> wrote in message news:ei4k7v41m32i4flrkhbqrjlhutva39d60p_at_4ax.com...
> How do you guys handle your alrt.log and listener.log files, to
> contain their growth without losing too much history?
>
> Early on on in our Oracle "experience" -- we started with 7.2 on NT
> 3.11. This seemed to have a lot of stability issues and I ended up
> writing a batch file to stop and start the databases on a weekly
> basis. As an aside, I built into the shutdown script some code to
> rename the just closed alert and listener logs, retaining several
> 'generations' of these files.
>
> Now that I'm moving into the *nix world and there is no need to
> routinely bounce the databases, I'm wondering about what to do about
> these logs. I don't want to let them go and grow forever, but don't
> know how I might go about keeping them down to a reasonable, stable
> size and at the same time keep a reasonable amount of history. I
> particularly don't like the idea of just chopping them off at the top
> and potentially losing any msgs related to the latest startup, which
> could be several weeks (or hopefully, months) old. Or am I being too
> cautious in that regard?
>
> SELECT experienced_advice
> FROM newsgroup_participants
> WHERE experience LIKE '%NIX';
>
>
Received on Sun Mar 23 2003 - 20:37:25 CST