RE: Renaming / deleting listener.log and alert log
- From: "Hollis, Les" <Les.Hollis@xxxxxx>
- To: <vitalisman@xxxxxxxxx>, "Ignizio, Richard" <richard.ignizio@xxxxxxxxxx>
- Date: Fri, 10 Jun 2005 08:38:04 -0500
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Vitalis Jerome
Sent: Friday, June 10, 2005 8:15 AM
To: Ignizio, Richard
Cc: Thomas.Mercadante@xxxxxxxxxxxxxxxxx; Paul.Vincent@xxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: Re: Renaming / deleting listener.log and alert log
On 6/10/05, Ignizio, Richard <richard.ignizio@xxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
