RE: Renaming / deleting listener.log and alert log

OK nobody has really addresses the listener.log...

IF you delete the listener.log, the OS still believes that file to be open as it IS being written to/held open by the listener process.

I have seen elegant scripts written to do all sorts of 'stuff' to the listener log file one particular script was over 150 lines long. All that is needed is to cp the file IF you think you want a copy of it for any reason then in *NIX cat /dev/null>listener.log.

The file will be zeroed out and *NIX will continue writing to it. All storage used will be 'truncated'. IF you rm or mv it, *NIX will still think the file is open and continue writing to it at it's current size and continue filling space.

Have to agree ....alert log only gets opened and written to when a process has something to report whereas the listener log is actually held open continuously. Manhandle the alert log all you want..... Careful with the listener log

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Vitalis Jerome Sent: Friday, June 10, 2005 8:15 AM
To: Ignizio, Richard
Cc: Thomas.Mercadante_at_labor.state.ny.us; Paul.Vincent_at_uce.ac.uk; oracle-l_at_freelists.org
Subject: Re: Renaming / deleting listener.log and alert log

On 6/10/05, Ignizio, Richard <richard.ignizio_at_paetec.com> wrote:
> I agree with Tom, we are on a Sun UNIX box and we move the alert.log
(25+=3D
 databases) every week without any issues and have been doing it for the la=3D
st 5 years.
>=3D20
> Rich

I agree it can be done without risks provided the Unix oracle user is allowed to have enough inodes opened simultaneously (and in real environment it's always the case, yes). But it is not clean:

Since the instance is not shut down after the "mv", its processes still hold the old file open. When they need to write an alert, it is written to the new alertSID.log but they hold both files open.

As for a "rm" instead of "cp"+"mv", it also leaves the inode open by the instance:
$ lsof|grep 368024
oracle 10561 oracle 6w REG 254,8 7300 368024 /usr/oracle/admin/TEST/bdump/alert_TEST.log (deleted) oracle 10561 oracle 7w REG 254,8 7300 368024 /usr/oracle/admin/TEST/bdump/alert_TEST.log (deleted) oracle 10563 oracle 6w REG 254,8 7300 368024 /usr/oracle/admin/TEST/bdump/alert_TEST.log (deleted) oracle 10563 oracle 7w REG 254,8 7300 368024 /usr/oracle/admin/TEST/bdump/alert_TEST.log (deleted) ...

Definitely the most simple and neat solution is "cp" and then ">alertSID.lo=3D
g".

Jerome

--
http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l