Re: background tracefiles reset
From: Mark Weaver <mark-clist_at_npsl.co.uk>
Date: Fri, 23 Oct 2009 16:34:36 +0100
Message-ID: <4AE1CD0C.6040507_at_npsl.co.uk>
On 23/10/2009 3:40 PM, Herring Dave - dherri wrote:
> Folks, is there any way to force Oracle background processes to close and re-open their trace files? As an example, say we've got 4 archiver processes with 4 trace files:
>
> db_arc1_1234.trc
> db_arc2_1235.trc
> db_arc3_1236.trc
> db_arc4_1237.trc
>
> Over time as the instance stays up and processes don't crash, these trace files grow. If we ever want to "clean them up", it'd be great to get those processes to close the file, then we'd copy, tar, gzip those files, then have the process open a new file (same name).
>
> I could try copying the file while it's opened and then "cat /dev/null>db_arc1_1234.trc", but I'm reluctant to test this on production and I don't have anywhere to test this.
>
> The reason this is an issue is we've got trace files that have grown large over time and previously we blindly removed these files. The problem is, since the processes had them opened, future writes couldn't be done and if there's a major crash (which we've had) no tracing gets written. Argg!
>
The copy/truncate procedure seems to work for me. I use logrotate to automate it, e.g. dropping something like:
}
Date: Fri, 23 Oct 2009 16:34:36 +0100
Message-ID: <4AE1CD0C.6040507_at_npsl.co.uk>
On 23/10/2009 3:40 PM, Herring Dave - dherri wrote:
> Folks, is there any way to force Oracle background processes to close and re-open their trace files? As an example, say we've got 4 archiver processes with 4 trace files:
>
> db_arc1_1234.trc
> db_arc2_1235.trc
> db_arc3_1236.trc
> db_arc4_1237.trc
>
> Over time as the instance stays up and processes don't crash, these trace files grow. If we ever want to "clean them up", it'd be great to get those processes to close the file, then we'd copy, tar, gzip those files, then have the process open a new file (same name).
>
> I could try copying the file while it's opened and then "cat /dev/null>db_arc1_1234.trc", but I'm reluctant to test this on production and I don't have anywhere to test this.
>
> The reason this is an issue is we've got trace files that have grown large over time and previously we blindly removed these files. The problem is, since the processes had them opened, future writes couldn't be done and if there's a major crash (which we've had) no tracing gets written. Argg!
>
The copy/truncate procedure seems to work for me. I use logrotate to automate it, e.g. dropping something like:
/path/alert_SID.log {
missingok
notifempty
weekly
copytruncate
compress
rotate 26
}
in /etc/logrotate.d should do the job.
I've seen it suggested that moving/deleting logfiles causes Oracle to notice and create a new one, but in practice I found it just keeps writing to the same inode (with OEL5 + 10gR2).
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Oct 23 2009 - 10:34:36 CDT