See once again an advantage of windows. It won't let you rm an in use
file
Niall
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of zhu chao
Sent: 02 December 2003 05:34
To: Multiple recipients of list ORACLE-L
Subject: Re: Where are my trace
It won't let you read it, either.
Niall Litchfield [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
12/02/2003 01:59 PM
Please respond to ORACLE-L
To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Where are my trace files going?
See once
Environment: Oracle 8.1.7.4 on RedHat AS2.1
I'm in the process of preparing to convert a 90M row table from
heap-organized to index organized. I think I've pretty well got a
formula for doing the actual table conversion. It's a very basic
table, four NUMBER columns, with a PK on the first
There are two possibilities:
1) You are hitting a well known bug which doesn't allow you to turn
on 10046 by using set_ev or alter session. The only way to actually do
it is to use oradebug.
2) Your trace files are with Saddam Hussein.
On 12/01/2003 05:04:25 PM, Thomas A. La Porte wrote:
Here's something that may or may not be happening. It's something I ran into when
working with traces. Have you mv'd or rm'd any of your trace files? The reason I ask,
is because while doing some tracing of a certain session on Solaris recently, I began
the tracing, turned it off, and then mv'd
Though I'm intrigued by (2), I'm humbled by the missing (3)
option which you did not consider. That is that *I* had one too
many 0's in my trace event: it's 10046, not 100046! Your post
pointed out my typo, many thanks.
Serves me right for cutting and pasting into different sessions,
so that
Another possiblity is that file has once generated a trace file and you accidently rm
that file.
As the file is still opened by this session, the session still write the trace
content to that rmed tracefile, so you are unable to read that file.
You can use lsof -p $SPID to identify
