Re: background tracefiles reset

From: Tanel Poder <tanel_at_poderc.com>
Date: Sat, 24 Oct 2009 00:32:40 +0800
Message-ID: <4602f23c0910230932ufba7510tb4fb72ea7863b1ca_at_mail.gmail.com>



A process reopens the tracefile itself if there's something to write.

Nevertheless, truncating the tracefile is safer than hacking with oradebug. Tracefile truncate doesn't affect Oracle processes execution path a bit, but oradebug will send a signal to it and the target process stops doing whatever it was doing, handles the signal and then resumes what it was doing. Oracle takes some care that the signal handler call/resume would be clean, but you never know. Despite its frequent use by support, oradebug is fairly uncharted territory.

Regarding alert.log, AFAIK all writes to alert.log are followed by close and the file is reopened for every write. This may depend on OS & Oracle version of course...

Tanel

On Sat, Oct 24, 2009 at 12:19 AM, Herring Dave - dherri < Dave.Herring_at_acxiom.com> wrote:

> Interesting…
>
>
>
> I see you can close the tracefile with oradebug, but how do you reopen it?
> The reason I ask is we've got a situation now where the logfiles are gone
> and future dumps won't get generated. I'd prefer to do something like the
> following instead of forcing instance restarts:
>
>
>
> oradebug close_trace
>
> oradebug flush
>
>
>
> My thought is that'd reset things for the given background process I've
> attached to, to get it to start using a new file. I want to get things
> corrected first, then start with proper logfile management.
>
>
>
> Again, my problem is I don't have a dev system to play with. I've got a
> windows db on my laptop, but the issue with moving files while they're open
> probably doesn't work the same way as under *nix.
>
>
>
> Thanks.
>
>
>
> *David C. Herring* | DBA, Acxiom Database Services
>
>
>
> 630-944-4762 office | 630-430-5988 cell | 630-944-4989 fax
> 1501 Opus Pl | Downers Grove, IL, 60515 | U.S.A. | www.acxiom.com
>
>
>
> ------------------------------
>
> *From:* Tanel Poder [mailto:tanel_at_poderc.com]
> *Sent:* Friday, October 23, 2009 10:20 AM
> *To:* Herring Dave - dherri
> *Cc:* oracle-l_at_freelists.org
> *Subject:* Re: background tracefiles reset
>
>
>
> Hi Dave,
>
> I have used the tracefile truncation using the > operation in past (no cat
> /dev/null is even needed):
>
> "> db_arc1_1234.trc" (without double quotes of course).
>
> Other options are more hard-core, you could connect to the process with
> oradebug and issue oradebug close_trace, but I don't recommend touching
> background processes with oradebug.
>
> Another option would be to set log_archive_processes to 0 temporarily, wait
> until archivers exit and then set the parameter back to original value.
>
> I would use OS level truncate with > , this releases space back to
> filesystem.
>
> As with everything, test this out and verify yourself before doing it in
> production.
>
> --
> Tanel Poder
> http://blog.tanelpoder.com
>
> On Fri, Oct 23, 2009 at 10:40 PM, Herring Dave - dherri <
> Dave.Herring_at_acxiom.com> 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!
>
> David C. Herring | DBA, Acxiom Database Services
>
> 630-944-4762 office | 630-430-5988 cell | 630-944-4989 fax
> 1501 Opus Pl | Downers Grove, IL, 60515 | U.S.A. | www.acxiom.com
>
>
>
> ***************************************************************************
> The information contained in this communication is confidential, is
> intended only for the use of the recipient named above, and may be legally
> privileged.
>
> If the reader of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited.
>
> If you have received this communication in error, please resend this
> communication to the sender and delete the original message or any copy
> of it from your computer system.
>
> Thank You.
> ****************************************************************************
>
>

-- 
Tanel Poder
http://blog.tanelpoder.com



-- http://www.freelists.org/webpage/oracle-l
image001.gif
Received on Fri Oct 23 2009 - 11:32:40 CDT

Original text of this message